From kfitzner at excelcia.org Tue May 3 12:56:06 2005 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Tue May 3 13:52:25 2005 Subject: No validity status with expired keys Message-ID: <427758C6.9080203@excelcia.org> The following command line: gpg --status-fd=2 --verify anyfile.sig fails to output any trust information if the key used to create anyfile.sig is an expired key. Thus it is impossible to tell if the key is considered trusted. It is my understanding that it is considered a valid use of an expired key to validate signatures created before the key expired. Should not then the trust model be applied to expired key? Kurt Fitzner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 546 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050503/a06111cf/signature.pgp From jvender at owensboro.net Tue May 3 14:25:53 2005 From: jvender at owensboro.net (Joe Vender) Date: Tue May 3 14:22:54 2005 Subject: strange behavior for --edit-key passwd Message-ID: <000501c54fdb$42c3fda0$821d87d8@computer> I've found some strange, buggy behavior in gpg's --edit-key passwd code of GnuPG 1.4.2-cvs. I haven't tried this with GnuPG 1.4.1, but it's probably there too. I found it while removing password protection from a key in order to export it so that an older PGP version could use it. Try this using a *TEST* key which already has a passphrase set: 1) Remove the passphrase protection by doing: gpg --edit-key 0xXXXXXXXX 2) at the "Command>" prompt, type "passwd". The first thing that I notice is that it gives me an "invalid passphrase; please try again...", even though I haven't entered one yet. 3) Now, enter the current passphrase. When gpg prompts you with "Enter the new passphrase for this secret key", hit ENTER and then ENTER again when it prompts you to repeat the passphrase. 4) Type "y" and hit ENTER when it warns you that this is a bad idea and asks you if you really want to do this. 5) Type "quit", and then "y" and hit ENTER when it asks if you want to save changes. 6) Now, again type gpg --edit-key 0xXXXXXXXX 7) Type "passwd" and hit ENTER. gpg returns the message, "This key is not protected. Enter the new passphrase for this secret key." But, then the prompt asks you to "Repeat passphrase:" Since you don't have a passphrase protecting the key at this point and haven't entered one yet, why is it asking you to "repeat" passphrase and what's it going to compare it to anyway? At this point, there are two things you could do. a) First, you could enter whatever passphrase you want to give the key, at which point gpg then tells you "passphrase not correctly repeated; please try again. Enter passphrase:" If you then again type your new passphrase and repeat it when prompted and then quit and save changes, your secret key is protected with the new passphrase. b) Or, instead of doing a) above, you could just hit ENTER at which point you're again at the "You don't want a passphrase - this is probably a *bad* idea! Do you really want to do this?", but at this point you don't have a passphrase protecting your key anyway so you're back to where you started. *** IN SUMMARY: The strange behaviors are: In step 2) above where gpg gives the "invalid passphrase; please try again..." message before I even enter on yet. In step 7) above at which point, when starting with an unprotected secret key and trying to password protect it, it prompts you to "Repeat passphrase:" before you've entered one yet instead of starting at the "Enter passphrase:" point. From jvender at owensboro.net Tue May 3 23:05:56 2005 From: jvender at owensboro.net (Joe Vender) Date: Tue May 3 23:03:26 2005 Subject: strange behavior for --edit-key passwd Message-ID: <000901c55023$e896c6c0$6a1b87d8@computer> A correction to my previous bug report: It should have stated that this bug shows up for me in the *DYNAMIC* build of GnuPG, not the static build. I'm using MinGW/MSYS to build a native win32 version. The configure line I used to make the dynamic builds is: $ CFLAGS='-O3 -mtune=i386 -march=i386 -mfpmath=387 -mno-mmx -mno-sse -mno-3dnow -mno-sse2' ./configure --enable-backsigs --prefix=/home/gpg-inst When making the static builds, the line is the same except for an "LDFLAGS=-static" appended to the end. I've found the same behavior in dynamic builds of both GnuPG 1.4.1 and GnuPG 1.4.2-cvs. I've also found that the static builds of both versions DON'T show this behavior. Regards, Joe Vender From atom at smasher.org Wed May 4 05:29:59 2005 From: atom at smasher.org (Atom Smasher) Date: Wed May 4 05:25:51 2005 Subject: Key Info Before Import In-Reply-To: <20050429091246.GA615@littlefarm> References: <4271B345.6080102@clemson.edu> <20050429091246.GA615@littlefarm> Message-ID: <20050504032956.97991.qmail@smasher.org> On Fri, 29 Apr 2005, Stephan Beyer wrote: >> Is it possible to extract data about a key (Name, Fingerprint, >> Signatures, Expiration Date, Email, etc) before the key is imported >> into the key ring? > > "gpg -v filename" or "gpg -vv filename" gives you information about the > packets in the OpenPGP file (for example, a key or a keyring). Should > tell you everything you want except the fingerprint. ======== this should show you everything you're looking for: gpg -v --with-fingerprint key-file > Btw: I guess, -devel isn't the right list for this question. ========== this is the type of question best asked on gnupg-users. -- ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "Every successful revolt is termed a revolution, and every unsuccessful one a rebellion." -- Joseph Priestly, 1791 From greve at fsfeurope.org Wed May 4 10:07:51 2005 From: greve at fsfeurope.org (Georg C. F. Greve) Date: Wed May 4 10:38:17 2005 Subject: Compile problems (CVS HEAD) Message-ID: Hi, since Gnus PGG/GPG support is broken for GnuPG using SmartCards, I used Werners patch to disable the keyphrase code in pgg-gpg.el. As a result, I am now being prompted for PIN by the gpg-agent, as things should be. Unfortunately, the gpg-agent does no caching, at all. Apparently, PIN caching was introduced in CVS HEAD, so I tried to compile the current CVS HEAD, which broke in the compile process. Log attached: make[2]: Entering directory `/usr/local/src/gnupg-cvs-20050504/keyserver' if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../intl -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat-nonliteral -MT gpgkeys_hkp-ksutil.o -MD -MP -MF ".deps/gpgkeys_hkp-ksutil.Tpo" -c -o gpgkeys_hkp-ksutil.o `test -f 'ksutil.c' || echo './'`ksutil.c; \ then mv -f ".deps/gpgkeys_hkp-ksutil.Tpo" ".deps/gpgkeys_hkp-ksutil.Po"; else rm -f ".deps/gpgkeys_hkp-ksutil.Tpo"; exit 1; fi ksutil.c:30:23: curl/curl.h: No such file or directory In file included from ksutil.c:33: ksutil.h:27:23: curl/curl.h: No such file or directory In file included from ksutil.c:33: ksutil.h:101: error: parse error before "error" ksutil.h:101: warning: function declaration isn't a prototype ksutil.c:322: error: parse error before "error" ksutil.c:323: warning: function declaration isn't a prototype ksutil.c: In function `curl_err_to_gpg_err': ksutil.c:324: error: `error' undeclared (first use in this function) ksutil.c:324: error: (Each undeclared identifier is reported only once ksutil.c:324: error: for each function it appears in.) ksutil.c:326: error: `CURLE_FTP_COULDNT_RETR_FILE' undeclared (first use in this function) make[2]: *** [gpgkeys_hkp-ksutil.o] Error 1 make[2]: Leaving directory `/usr/local/src/gnupg-cvs-20050504/keyserver' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/gnupg-cvs-20050504' make: *** [all] Error 2 Not sure whether this is a new or temporary problem. Just wanted to let you know. Will try again later. Regards, Georg -- Georg C. F. Greve Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : /pipermail/attachments/20050504/019c7b7f/attachment-0001.pgp From wk at gnupg.org Wed May 4 11:55:12 2005 From: wk at gnupg.org (Werner Koch) Date: Wed May 4 11:56:04 2005 Subject: Compile problems (CVS HEAD) In-Reply-To: (Georg C. F. Greve's message of "Wed, 04 May 2005 10:07:51 +0200") References: Message-ID: <871x8nco3j.fsf@wheatstone.g10code.de> On Wed, 04 May 2005 10:07:51 +0200, Georg C F Greve said: > Apparently, PIN caching was introduced in CVS HEAD, so I tried to > compile the current CVS HEAD, which broke in the compile process. David changed the way cURL is detected; obviously it doesn't yet work anymore without cURl. apt-get install libcurl3-dev should help Shalom-Salam, Werner From greve at fsfeurope.org Wed May 4 12:35:46 2005 From: greve at fsfeurope.org (Georg C. F. Greve) Date: Wed May 4 12:31:44 2005 Subject: Compile problems (CVS HEAD) In-Reply-To: <871x8nco3j.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 04 May 2005 11:55:12 +0200") References: <871x8nco3j.fsf@wheatstone.g10code.de> Message-ID: || On Wed, 04 May 2005 11:55:12 +0200 || Werner Koch wrote: wk> David changed the way cURL is detected; obviously it doesn't yet wk> work anymore without cURl. apt-get install libcurl3-dev should wk> help Thanks. Discovered Debian sarge problem when trying that: The following packages have unmet dependencies: libcurl3-dev: Depends: libssl-dev but it is not installable Oh well. Regards, Georg -- Georg C. F. Greve Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : /pipermail/attachments/20050504/6d257f2e/attachment.pgp From jvender at owensboro.net Wed May 4 12:47:31 2005 From: jvender at owensboro.net (Joe Vender) Date: Wed May 4 12:44:27 2005 Subject: strange behavior for --edit-key passwd Message-ID: <005001c55096$ae498f20$d51c87d8@computer> O.K. I've discovered that this behavior shows up only after installing the GNUwin32 project's Readline 5.0 files into my MinGW/MSYS build environment. For some reason, only dynamic builds find and link to readline, and when used, this strange behavior shows up. I removed readline from the build environment and compiled a new set of dynamically linked binaries, which then behaved normally. Joe From greve at fsfeurope.org Wed May 4 12:54:18 2005 From: greve at fsfeurope.org (Georg C. F. Greve) Date: Wed May 4 12:50:20 2005 Subject: SmartCard: USB Weirdnesses Message-ID: Hi all, since we have shipped our Fellowship cards now, I am switching to using my Fellowship card in production... and have eliminated the first problems in terms of integration with Gnus already. I have been testing things with the SCM SCR-335 & SPR-532 readers and always had the result that they crashed *very* frequently. Sometimes consistently after a single operation. Talking with Werner, he had made good experience with upgrading the Firmware, but that could not be the whole explanation, imho, as they seem to work stable under Windows regardless of the firmware. I am not a USB expert and this may in fact be a Linux kernel problem, but I would still like to share my observations with you: * USB reader connected directly to computer: TROUBLE * USB reader AND USB memory stick connected to computer: TROUBLE * USB reader connected to external USB Hub: WORKS LIKE CHARM * USB reader AND USB memory stick connected to USB Hub: TROUBLE This is reproduceable. So it appears there is some oddness going on -- potentially in the Linux USB Code -- that screws things up for the readers. How are the experience values of the others? Can we help tracking that problem down so the USB maintainers know where to look and how to fix it? Regards, Georg -- Georg C. F. Greve Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : /pipermail/attachments/20050504/aaa2f36a/attachment.pgp From greve at fsfeurope.org Wed May 4 13:03:24 2005 From: greve at fsfeurope.org (Georg C. F. Greve) Date: Wed May 4 12:59:25 2005 Subject: SmartCard: Encryption/Decryption problem Message-ID: Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : /pipermail/attachments/20050504/6fe9dadb/attachment.pgp From mk at fsfe.org Wed May 4 13:17:02 2005 From: mk at fsfe.org (Matthias Kirschner) Date: Wed May 4 13:13:57 2005 Subject: SmartCard: Encryption/Decryption problem In-Reply-To: References: Message-ID: <20050504111701.GJ26775@mbwg.de> * Georg C. F. Greve [2005-05-04 13:03:24 +0200]: > PIN > gpg: ccid_transceive failed: (0x1000a) > gpg: apdu_send_simple(0) failed: card I/O error > gpg: encrypted with 1024-bit RSA key, ID 7DF16B24, created 2005-05-02 > "Georg C. F. Greve " > gpg: public key decryption failed: general error > gpg: decryption failed: secret key not available Same problem here. I am using a 04e6:5115 SCM Microsystems, Inc. SCR335 SmartCard Reader and GnuPG 1.4.1 + ccid patch. Although IIRC 4 weeks ago it worked here on my machine, but I can't remember which packages I updated during this time. I am using Debian testing, is it possible, that is has something to do with some usb stuff? Best wishes, Matze -- Join the Fellowship and protect your freedom! (http://www.fsfe.org) From greve at fsfeurope.org Wed May 4 14:03:55 2005 From: greve at fsfeurope.org (Georg C. F. Greve) Date: Wed May 4 13:59:56 2005 Subject: SmartCard: USB Weirdnesses In-Reply-To: <4278AEA2.6060604@hunt.org> (J. Wren Hunt's message of "Wed, 04 May 2005 07:14:42 -0400") References: <4278AEA2.6060604@hunt.org> Message-ID: || On Wed, 04 May 2005 07:14:42 -0400 || "J. Wren Hunt" wrote: jwh> Which version(s) of the kernel are you running? (Use 'uname -a' jwh> to output a brief listing if you're not sure) Verified this on two machines: One desktop machine running 2.6.11.6. One laptop running 2.6.11.8 with additional ACPI, swsusp2, ipw2100. FYI: I see plenty of resets on the USB bus when using the USB SmartCard readers -- and the device usually seems to get shut down when it rejects being assigned an address after/as part of a reset. The shutdown happens AFTER a successful (in terms of result) operation and NOT before an unsuccessful operation, as one might suspect. If I can provide additional input, please let me know. Regards, Georg -- Georg C. F. Greve Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : /pipermail/attachments/20050504/4cf0cf9e/attachment-0001.pgp From wren at hunt.org Wed May 4 13:14:42 2005 From: wren at hunt.org (J. Wren Hunt) Date: Wed May 4 14:13:16 2005 Subject: SmartCard: USB Weirdnesses In-Reply-To: References: Message-ID: <4278AEA2.6060604@hunt.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Georg C. F. Greve wrote: > I am not a USB expert and this may in fact be a Linux kernel problem, > but I would still like to share my observations with you: > Can we help tracking that problem down so the USB maintainers know > where to look and how to fix it? > Which version(s) of the kernel are you running? (Use 'uname -a' to output a brief listing if you're not sure) Wren -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCeK6iA/qR4Uok1vQRAz55AKDMbR7uErz40Z+SowZ1Ru2UI86oFACg7OIA 0dEKjgJAqjYUE4nE9eeGWfc= =yoOg -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Wed May 4 15:21:13 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Wed May 4 15:17:37 2005 Subject: Compile problems (CVS HEAD) In-Reply-To: References: <871x8nco3j.fsf@wheatstone.g10code.de> Message-ID: <20050504132113.GC24142@jabberwocky.com> On Wed, May 04, 2005 at 12:35:46PM +0200, Georg C. F. Greve wrote: > || On Wed, 04 May 2005 11:55:12 +0200 > || Werner Koch wrote: > > wk> David changed the way cURL is detected; obviously it doesn't yet > wk> work anymore without cURl. apt-get install libcurl3-dev should > wk> help > > Thanks. Sorry about that. I was missing an #ifdef. Try the CVS again, and it should work properly now. David From wk at gnupg.org Wed May 4 15:37:25 2005 From: wk at gnupg.org (Werner Koch) Date: Wed May 4 15:36:03 2005 Subject: SmartCard: USB Weirdnesses In-Reply-To: (Georg C. F. Greve's message of "Wed, 04 May 2005 14:03:55 +0200") References: <4278AEA2.6060604@hunt.org> Message-ID: <87psw79koa.fsf@wheatstone.g10code.de> On Wed, 04 May 2005 14:03:55 +0200, Georg C F Greve said: > FYI: I see plenty of resets on the USB bus when using the USB > SmartCard readers -- and the device usually seems to get shut down That might be due to the reset the gnupg driver issues after timeouts. Salam-Shalom, Werner From wk at gnupg.org Wed May 4 15:45:25 2005 From: wk at gnupg.org (Werner Koch) Date: Wed May 4 15:46:04 2005 Subject: SmartCard: Encryption/Decryption problem In-Reply-To: (Georg C. F. Greve's message of "Wed, 04 May 2005 13:03:24 +0200") References: Message-ID: <87ll6v9kay.fsf@wheatstone.g10code.de> On Wed, 04 May 2005 13:03:24 +0200, Georg C F Greve said: > gpg: DBG: ccid-driver: status: 00 error: 00 octet[9]: 04 > data: 00 90 00 90 > gpg: DBG: ccid-driver: R-block with wrong seqno received on more bit See also bug #419. That is a problem with the T=1 protocol where we get an unexepcted sequence number back. That is not a USB problem but on a layer above. Needs further analysis. Shalom-Salam, Werner From greve at fsfeurope.org Wed May 4 21:12:23 2005 From: greve at fsfeurope.org (Georg C. F. Greve) Date: Wed May 4 21:16:39 2005 Subject: SmartCard: Encryption/Decryption problem In-Reply-To: <87ll6v9kay.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 04 May 2005 15:45:25 +0200") References: <87ll6v9kay.fsf@wheatstone.g10code.de> Message-ID: || On Wed, 04 May 2005 15:45:25 +0200 || Werner Koch wrote: wk> See also bug #419. That is a problem with the T=1 protocol where wk> we get an unexepcted sequence number back. That is not a USB wk> problem but on a layer above. Needs further analysis. I this still in kernel or already in GnuPG? Who would have to analyse this? Any way I can help? This would be somewhat of priority to me as I frequently get encrypted email that I need to decrypt... and that subkey is only on the card, obviously. ;) Regards, Georg -- Georg C. F. Greve Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : /pipermail/attachments/20050504/9915aae5/attachment.pgp From greve at fsfeurope.org Wed May 4 21:20:15 2005 From: greve at fsfeurope.org (Georg C. F. Greve) Date: Wed May 4 21:16:48 2005 Subject: SmartCard: USB Weirdnesses In-Reply-To: <87psw79koa.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 04 May 2005 15:37:25 +0200") References: <4278AEA2.6060604@hunt.org> <87psw79koa.fsf@wheatstone.g10code.de> Message-ID: || On Wed, 04 May 2005 15:37:25 +0200 || Werner Koch wrote: wk> That might be due to the reset the gnupg driver issues after wk> timeouts. The device seems to be reset *after* successfully accessing the card. That seems odd. What are the criteria for a reset? May there be a problem in the routine that determines whether/when to reset? There clearly seems to be a problem in the Linux USB code, but maybe this is making it worse... Regards, Georg -- Georg C. F. Greve Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : /pipermail/attachments/20050504/f7b5ad8d/attachment.pgp From wk at gnupg.org Thu May 5 10:49:18 2005 From: wk at gnupg.org (Werner Koch) Date: Thu May 5 10:46:08 2005 Subject: SmartCard: Encryption/Decryption problem In-Reply-To: (Georg C. F. Greve's message of "Wed, 04 May 2005 21:12:23 +0200") References: <87ll6v9kay.fsf@wheatstone.g10code.de> Message-ID: <87zmva5a7l.fsf@wheatstone.g10code.de> On Wed, 04 May 2005 21:12:23 +0200, Georg C F Greve said: > I this still in kernel or already in GnuPG? I don't assume that the kernel currupts data. So the problem is either in gpg or in the reader. > Who would have to analyse this? I did extensive code staring and could not find a problem in my code. Given that I don't have any problems when using a reader with an updated firmware, I am pretty sure that it is the reader's fault. To develop a workaround for the readers with non-updatable firmware, I need to talk with the vendor. What _might_ help is to limit the packet size even further. In g10/ccid-driver.c, look for DEBUGOUT ("enabling workaround for buggy SCM readers\n"); handle->max_ifsd = 48; and change the ifsd to 45. Salam-Shalom, Werner From greve at fsfeurope.org Thu May 5 11:44:21 2005 From: greve at fsfeurope.org (Georg C. F. Greve) Date: Thu May 5 11:40:42 2005 Subject: SmartCard: Encryption/Decryption problem In-Reply-To: <87zmva5a7l.fsf@wheatstone.g10code.de> (Werner Koch's message of "Thu, 05 May 2005 10:49:18 +0200") References: <87ll6v9kay.fsf@wheatstone.g10code.de> <87zmva5a7l.fsf@wheatstone.g10code.de> Message-ID: || On Thu, 05 May 2005 10:49:18 +0200 || Werner Koch wrote: >> Who would have to analyse this? wk> I did extensive code staring and could not find a problem in my wk> code. Given that I don't have any problems when using a reader wk> with an updated firmware, I am pretty sure that it is the wk> reader's fault. Do we know whether this problem reproduceable under Windows? If not: Where is the difference? It strikes me as odd that they would so consistently not work and still be shipped if the problem also occured on Windows. wk> To develop a workaround for the readers with non-updatable wk> firmware, I need to talk with the vendor. Do you know who to talk to? I have developed some contacts with SCM because I am trying to convince them to adopt a Free Software friendly policy and release all their SmartCard drivers as Free Software -- so we could finally use those PCMCIA readers, for instance. wk> What _might_ help is to limit the packet size even further. In wk> g10/ccid-driver.c, look for wk> DEBUGOUT ("enabling workaround for buggy SCM readers\n"); handle-> max_ifsd = 48; wk> and change the ifsd to 45. Okay. Will try that, thanks. Regards, Georg -- Georg C. F. Greve Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : /pipermail/attachments/20050505/bcb2cdb9/attachment.pgp From marcus.brinkmann at ruhr-uni-bochum.de Thu May 5 13:38:33 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu May 5 13:35:33 2005 Subject: Tricky gpgme_wait bug. In-Reply-To: <426D2E3E.4050803@katehok.ac93.org> References: <426A8523.50304@katehok.ac93.org> <426B15F9.7010904@katehok.ac93.org> <426D2E3E.4050803@katehok.ac93.org> Message-ID: <87wtqdhphi.wl@ulysses.g10code.de> At Mon, 25 Apr 2005 13:51:58 -0400, Igor Belyi wrote: > > The extra sleep between gpgme_wait causes _gpgme_io_select to get > > signal on more than one file handler for the same context. As a result > > an error reported on the first handle causes all context handlers to > > be closed and the associated data released. When the second selected > > handle get processed it causes segmentation fault. > > And just to reply to myself, attached is a proposed patch fixing the > problem. Good catch. There is another bug in wait-global that needs fixing, too, and I will provide a combined solution very soon now. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Thu May 5 13:48:33 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu May 5 13:45:31 2005 Subject: doc/bug gpgme 1.0.1 In-Reply-To: <426F474E.7040102@omicron-persei-8.net> References: <426F474E.7040102@omicron-persei-8.net> Message-ID: <87vf5xhp0u.wl@ulysses.g10code.de> At Wed, 27 Apr 2005 18:03:26 +1000, Tyler Retzlaff wrote: > > The info documentation for initialization of struct gpgme_data_cbs > indicates that release is an optional. However, if it is initialized > to NULL a gpgme_data_release still causes release to be called. It > being initialized to NULL causes things to barf. Right, this is a bug in the code. Thanks for finding it! I applied a correct version of your patch (you still dereference the null pointer), and also added checks to read/write/seek. You can find it in CVS. 2005-05-05 Marcus Brinkmann * data-user.c (user_release): Only call user hook if provided. (user_seek): Return EBADF if no user hook is provided. (user_read): Likewise. (user_write): Likewise. Thanks, Marcus From fw at deneb.enyo.de Thu May 5 14:35:00 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu May 5 15:16:06 2005 Subject: [PATCH] --set-expire Message-ID: <87y8atdf63.fsf@deneb.enyo.de> The following patch adds a --set-expire to GnuPG 1.4.1. It would be really nice if it were possible to include it in a future release of the 1.4 branch. Yes, I know, I should use GPGME for non-interactive use, but after browsing the GPGME documentation, I came to the conclusion that it doesn't support changing data signature expiration, either. Thu May 5 14:19:44 CEST 2005 Florian Weimer * Document the --set-expire option M ./doc/gpg.sgml -1 +16 M ./doc/gpg.texi -2 +13 Thu May 5 14:16:13 CEST 2005 Florian Weimer * Honor --set-expire when creating data signatures M ./g10/sign.c -6 +21 Thu May 5 14:15:28 CEST 2005 Florian Weimer * Add --set-expire option M ./g10/g10.c +17 M ./g10/options.h +1 Thu May 5 12:56:42 CEST 2005 Florian Weimer * Export parse_expire_string from keygen.c M ./g10/keygen.c -1 +1 M ./g10/main.h +1 Thu May 5 12:47:45 CEST 2005 Florian Weimer * Fix comment typo M ./g10/keygen.c -1 +1 diff -rN -u old-stable+set-expire/doc/gpg.sgml new-stable+set-expire/doc/gpg.sgml --- old-stable+set-expire/doc/gpg.sgml 2005-05-05 14:31:34.000000000 +0200 +++ new-stable+set-expire/doc/gpg.sgml 2005-05-05 14:19:43.000000000 +0200 @@ -2522,11 +2522,26 @@ --no-ask-sig-expire When making a data signature, prompt for an expiration time. If this -option is not specified, the expiration time is "never". +option is not specified and an expiration time is not set by other +means, the expiration time is "never". --no-ask-sig-expire disables this option. +--set-expire &ParmString; + +When making a data signature, include an expiration time. +&ParmString; must be one of the following: "0" +(meaning no expiration), a positive integer (counting the +expiration time in days from the creation time of the signature), +a positive integer followed by "w", "m" or "y" (counting +in weeks, months or years, respectively), or an ISO 8601 +date string of the form "YYYY-MM-DD". +If this option is not specified and an expiration time is not +set by other means, the expiration time is "0" (no expiration). + + + --ask-cert-expire --no-ask-cert-expire diff -rN -u old-stable+set-expire/doc/gpg.texi new-stable+set-expire/doc/gpg.texi --- old-stable+set-expire/doc/gpg.texi 2005-05-05 14:31:34.000000000 +0200 +++ new-stable+set-expire/doc/gpg.texi 2005-05-05 14:19:27.000000000 +0200 @@ -1671,10 +1671,21 @@ @item --ask-sig-expire @itemx --no-ask-sig-expire -When making a data signature, prompt for an expiration time. If this -option is not specified, the expiration time is "never". +When making a data signature, prompt for an expiration time. If this +option is not specified and an expiration time is not set by other +means, the expiration time is "never". --no-ask-sig-expire disables this option. +@item --set-expire @code{string} +When making a data signature, include an expiration time. @code{string} +must be one of the following: "0" (meaning no expiration), a positive +integer (counting the expiration time in days from the creation time of +the signature), a positive integer followed by "w", "m" or "y" (counting +in weeks, months or years, respectively), or an ISO 8601 date string of +the form "YYYY-MM-DD". If this option is not specified and an +expiration time is not set by other means, the expiration time is "0" +(no expiration). + @item --ask-cert-expire @itemx --no-ask-cert-expire When making a key signature, prompt for an expiration time. If this diff -rN -u old-stable+set-expire/g10/g10.c new-stable+set-expire/g10/g10.c --- old-stable+set-expire/g10/g10.c 2005-05-05 14:31:34.000000000 +0200 +++ new-stable+set-expire/g10/g10.c 2005-05-05 13:04:38.000000000 +0200 @@ -157,6 +157,7 @@ oNoTextmode, oExpert, oNoExpert, + oSetExpire, oAskSigExpire, oNoAskSigExpire, oAskCertExpire, @@ -443,6 +444,7 @@ { oNoTextmode, "no-textmode", 0, "@"}, { oExpert, "expert", 0, "@"}, { oNoExpert, "no-expert", 0, "@"}, + { oSetExpire, "set-expire", 2, "@"}, { oAskSigExpire, "ask-sig-expire", 0, "@"}, { oNoAskSigExpire, "no-ask-sig-expire", 0, "@"}, { oAskCertExpire, "ask-cert-expire", 0, "@"}, @@ -2223,6 +2225,21 @@ case oNoTextmode: opt.textmode=0; break; case oExpert: opt.expert = 1; break; case oNoExpert: opt.expert = 0; break; + case oSetExpire: + { + int days = parse_expire_string( pargs.r.ret_str ); + + if( days < 0 ) + log_error(_("`%s' is not a valid duration\n"), + pargs.r.ret_str); + else + { + /* v3 signatures cannot expire. */ + opt.force_v3_sigs = 0; + opt.duration = days * 86400L; + } + } + break; case oAskSigExpire: opt.ask_sig_expire = 1; break; case oNoAskSigExpire: opt.ask_sig_expire = 0; break; case oAskCertExpire: opt.ask_cert_expire = 1; break; diff -rN -u old-stable+set-expire/g10/keygen.c new-stable+set-expire/g10/keygen.c --- old-stable+set-expire/g10/keygen.c 2005-05-05 14:31:34.000000000 +0200 +++ new-stable+set-expire/g10/keygen.c 2005-05-05 12:47:27.000000000 +0200 @@ -1483,10 +1483,10 @@ /**************** - * Parse an expire string and return it's value in days. + * Parse an expire string and return its value in days. * Returns -1 on error. */ -static int +int parse_expire_string( const char *string ) { int mult; diff -rN -u old-stable+set-expire/g10/main.h new-stable+set-expire/g10/main.h --- old-stable+set-expire/g10/main.h 2005-05-05 14:31:34.000000000 +0200 +++ new-stable+set-expire/g10/main.h 2005-05-05 12:47:20.000000000 +0200 @@ -163,6 +163,7 @@ void show_basic_key_info (KBNODE keyblock); /*-- keygen.c --*/ +int parse_expire_string( const char *string ); u32 ask_expire_interval(int object); u32 ask_expiredate(void); void generate_keypair( const char *fname, const char *card_serialno, diff -rN -u old-stable+set-expire/g10/options.h new-stable+set-expire/g10/options.h --- old-stable+set-expire/g10/options.h 2005-05-05 14:31:34.000000000 +0200 +++ new-stable+set-expire/g10/options.h 2005-05-05 12:51:23.000000000 +0200 @@ -50,6 +50,7 @@ int list_only; int textmode; int expert; + u32 duration; int ask_sig_expire; int ask_cert_expire; int batch; /* run in batch mode */ diff -rN -u old-stable+set-expire/g10/sign.c new-stable+set-expire/g10/sign.c --- old-stable+set-expire/g10/sign.c 2005-05-05 14:31:34.000000000 +0200 +++ new-stable+set-expire/g10/sign.c 2005-05-05 13:04:59.000000000 +0200 @@ -730,8 +730,13 @@ && (rc=setup_symkey(&efx.symkey_s2k,&efx.symkey_dek))) goto leave; - if(opt.ask_sig_expire && !opt.force_v3_sigs && !opt.batch && !RFC1991) - duration=ask_expire_interval(1); + if(!(opt.force_v3_sigs || RFC1991)) + { + if(opt.duration) + duration=opt.duration; + if(opt.ask_sig_expire) + duration=ask_expire_interval(1); + } if( (rc=build_sk_list( locusr, &sk_list, 1, PUBKEY_USAGE_SIG )) ) goto leave; @@ -993,8 +998,13 @@ memset( &afx, 0, sizeof afx); init_packet( &pkt ); - if(opt.ask_sig_expire && !opt.force_v3_sigs && !opt.batch && !RFC1991) - duration=ask_expire_interval(1); + if(!(opt.force_v3_sigs || RFC1991)) + { + if(opt.duration) + duration=opt.duration; + if(opt.ask_sig_expire) + duration=ask_expire_interval(1); + } if( (rc=build_sk_list( locusr, &sk_list, 1, PUBKEY_USAGE_SIG )) ) goto leave; @@ -1147,8 +1157,13 @@ memset( &cfx, 0, sizeof cfx); init_packet( &pkt ); - if(opt.ask_sig_expire && !opt.force_v3_sigs && !opt.batch && !RFC1991) - duration=ask_expire_interval(1); + if(!(opt.force_v3_sigs || RFC1991)) + { + if(opt.duration) + duration=opt.duration; + if(opt.ask_sig_expire) + duration=ask_expire_interval(1); + } rc = build_sk_list (locusr, &sk_list, 1, PUBKEY_USAGE_SIG); if (rc) From wk at gnupg.org Thu May 5 16:34:06 2005 From: wk at gnupg.org (Werner Koch) Date: Thu May 5 16:31:07 2005 Subject: SmartCard: Encryption/Decryption problem In-Reply-To: (Georg C. F. Greve's message of "Thu, 05 May 2005 11:44:21 +0200") References: <87ll6v9kay.fsf@wheatstone.g10code.de> <87zmva5a7l.fsf@wheatstone.g10code.de> Message-ID: <87u0lh3foh.fsf@wheatstone.g10code.de> On Thu, 05 May 2005 11:44:21 +0200, Georg C F Greve said: > Do we know whether this problem reproduceable under Windows? > If not: Where is the difference? That uses a different driver with different access patterns as well as a different USB stack. It just doesn't exhibit itself under Windows (afaik). Note, that we can't use USB directly under Windows but need to use the OS provided PC/SC API. > Do you know who to talk to? Yes, no problem. Its just for me to find time to discuss this. Salam-Shalom, Werner From dshaw at jabberwocky.com Thu May 5 21:09:36 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu May 5 21:05:56 2005 Subject: [PATCH] --set-expire In-Reply-To: <87y8atdf63.fsf@deneb.enyo.de> References: <87y8atdf63.fsf@deneb.enyo.de> Message-ID: <20050505190936.GD8968@jabberwocky.com> On Thu, May 05, 2005 at 02:35:00PM +0200, Florian Weimer wrote: > The following patch adds a --set-expire to GnuPG 1.4.1. It would be > really nice if it were possible to include it in a future release of > the 1.4 branch. > > Yes, I know, I should use GPGME for non-interactive use, but after > browsing the GPGME documentation, I came to the conclusion that it > doesn't support changing data signature expiration, either. Good idea. I've done something very similar to this for 1.4.2. Rather than a single --set-expire, there are two different options: --default-sig-expire and --default-cert-expire, so that the default may be set for either data or key signatures. If --ask-sig-expire is set, then --default-sig-expire is used as the default (hit return to accept the default). If --ask-sig-expire is not set, then --default-sig-expire is used as the expiration date directly. David From greve at fsfeurope.org Fri May 6 09:41:31 2005 From: greve at fsfeurope.org (Georg C. F. Greve) Date: Fri May 6 09:45:10 2005 Subject: SmartCard: Encryption/Decryption problem In-Reply-To: <87zmva5a7l.fsf@wheatstone.g10code.de> (Werner Koch's message of "Thu, 05 May 2005 10:49:18 +0200") References: <87ll6v9kay.fsf@wheatstone.g10code.de> <87zmva5a7l.fsf@wheatstone.g10code.de> Message-ID: || On Thu, 05 May 2005 10:49:18 +0200 || Werner Koch wrote: wk> To develop a workaround for the readers with non-updatable wk> firmware, I need to talk with the vendor. What _might_ help is wk> to limit the packet size even further. In g10/ccid-driver.c, wk> look for wk> DEBUGOUT ("enabling workaround for buggy SCM readers\n"); handle-> max_ifsd = 48; wk> and change the ifsd to 45. Tried this. No change. Even tried lowering it to 25 out of curiosity. No change. Regards, Georg -- Georg C. F. Greve Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : /pipermail/attachments/20050506/266f23aa/attachment-0001.pgp From wk at gnupg.org Fri May 6 08:15:42 2005 From: wk at gnupg.org (Werner Koch) Date: Fri May 6 09:54:33 2005 Subject: [PATCH] Test process failed on IRIX In-Reply-To: <20050209182354.3090b982.daichi.k@aioros.ocn.ne.jp> (Daichi Kawahata's message of "Wed, 9 Feb 2005 18:23:54 +0900") References: <20050209182354.3090b982.daichi.k@aioros.ocn.ne.jp> Message-ID: <87r7gkq3qp.fsf@wheatstone.g10code.de> On Wed, 9 Feb 2005 18:23:54 +0900, Daichi Kawahata said: > works on other platforms, seems 'ULL' is GCC extension. Anyway, > 'make check' process succeeded on IRIX after modifying. There is a far better patch: * mpi-scan.c (mpi_putbyte, mpi_getbyte): Removed. Not used. Thanks, Werner From fw at deneb.enyo.de Fri May 6 11:03:52 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri May 6 10:59:43 2005 Subject: [PATCH] --set-expire In-Reply-To: <20050505190936.GD8968@jabberwocky.com> (David Shaw's message of "Thu, 5 May 2005 15:09:36 -0400") References: <87y8atdf63.fsf@deneb.enyo.de> <20050505190936.GD8968@jabberwocky.com> Message-ID: <87vf5wsp3b.fsf@deneb.enyo.de> * David Shaw: > Good idea. I've done something very similar to this for 1.4.2. Thanks. > If --ask-sig-expire is set, then --default-sig-expire is used as the > default (hit return to accept the default). If --ask-sig-expire is > not set, then --default-sig-expire is used as the expiration date > directly. If I read your patch correctly, it does not disable --force-v3-sigs, and it ignores --default-sig-expire in batch mode. From greve at gnu.org Fri May 6 09:54:46 2005 From: greve at gnu.org (Georg C. F. Greve) Date: Fri May 6 13:38:49 2005 Subject: SmartCard: USB Weirdnesses In-Reply-To: (Georg C. F. Greve's message of "Wed, 04 May 2005 21:20:15 +0200") References: <4278AEA2.6060604@hunt.org> <87psw79koa.fsf@wheatstone.g10code.de> Message-ID: || On Wed, 04 May 2005 21:20:15 +0200 || "Georg C. F. Greve" wrote: gg> The device seems to be reset *after* successfully accessing the gg> card. Actually, when taking a look at the code, I found that in function do_close_reader in ccid-driver.c the USB reader does indeed get reset after every single operation. Since those resets were what made it die, I commented the usb_reset out and now the SmartCard reader appears to be stable without a USB Hub even though it has an old bios. So my feeling is that: - unnecessary resets should really be avoided - Linux USB code probably has some problem with the way it handles the resets that makes devices die since it does not cause problems for devices behind a Hub. Regards, Georg -- Georg C. F. Greve Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : /pipermail/attachments/20050506/ed4c4d9f/attachment.pgp From dshaw at jabberwocky.com Fri May 6 14:54:27 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Fri May 6 14:50:52 2005 Subject: [PATCH] --set-expire In-Reply-To: <87vf5wsp3b.fsf@deneb.enyo.de> References: <87y8atdf63.fsf@deneb.enyo.de> <20050505190936.GD8968@jabberwocky.com> <87vf5wsp3b.fsf@deneb.enyo.de> Message-ID: <20050506125427.GA10511@jabberwocky.com> On Fri, May 06, 2005 at 11:03:52AM +0200, Florian Weimer wrote: > * David Shaw: > > > Good idea. I've done something very similar to this for 1.4.2. > > Thanks. > > > If --ask-sig-expire is set, then --default-sig-expire is used as the > > default (hit return to accept the default). If --ask-sig-expire is > > not set, then --default-sig-expire is used as the expiration date > > directly. > > If I read your patch correctly, it does not disable --force-v3-sigs, I did that on purpose, figuring that if someone sets --force-v3-sigs, it should not be unset behind the scenes. I have to say that I'm not really thrilled with any of the --force-v3-sigs situations. There are a number of features that are disabled behind --force-v3-sigs, and yet we still have it set by default... but if we didn't have it set by default, some PGP users would have problems. > and it ignores --default-sig-expire in batch mode. That's true, but not a good idea. I've fixed that. David From list at omicron-persei-8.net Sat May 7 12:34:23 2005 From: list at omicron-persei-8.net (Tyler Retzlaff) Date: Sat May 7 12:32:35 2005 Subject: doc/bug gpgme 1.0.1 In-Reply-To: <87vf5xhp0u.wl@ulysses.g10code.de> References: <426F474E.7040102@omicron-persei-8.net> <87vf5xhp0u.wl@ulysses.g10code.de> Message-ID: <427C99AF.4090201@omicron-persei-8.net> Marcus Brinkmann wrote: > At Wed, 27 Apr 2005 18:03:26 +1000, > Tyler Retzlaff wrote: > >>The info documentation for initialization of struct gpgme_data_cbs >>indicates that release is an optional. However, if it is initialized >>to NULL a gpgme_data_release still causes release to be called. It >>being initialized to NULL causes things to barf. > > > Right, this is a bug in the code. Thanks for finding it! > > I applied a correct version of your patch (you still dereference the > null pointer), oops, so I do! good catch and also added checks to read/write/seek. You can find > it in CVS. > > 2005-05-05 Marcus Brinkmann > > * data-user.c (user_release): Only call user hook if provided. > (user_seek): Return EBADF if no user hook is provided. > (user_read): Likewise. > (user_write): Likewise. > > Thanks, > Marcus Excellent, thanks. From wk at gnupg.org Sun May 8 09:59:19 2005 From: wk at gnupg.org (Werner Koch) Date: Sun May 8 12:29:39 2005 Subject: SmartCard: USB Weirdnesses In-Reply-To: (Georg C. F. Greve's message of "Fri, 06 May 2005 09:54:46 +0200") References: <4278AEA2.6060604@hunt.org> <87psw79koa.fsf@wheatstone.g10code.de> Message-ID: <87is1uxi5k.fsf@wheatstone.g10code.de> On Fri, 06 May 2005 09:54:46 +0200, Georg C F Greve said: > - unnecessary resets should really be avoided I once added the reset before the close as the only reliable solution for my environment then not to get stuck in the USB kernel when running gpg several times. Not sure whether it is still needed, Anyway, I disabled this reset and provide an environment kludge to re-enable it in case this change causes problems for others. Shalom-Salam, Werner From bjg at network-theory.co.uk Sat May 7 13:22:17 2005 From: bjg at network-theory.co.uk (Brian Gough) Date: Mon May 9 12:57:06 2005 Subject: smartcard howto notes Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I worked through the smartcard howto in debian stable setting up a reader for my FSFE cryptocard. Below are some notes, I had some problems with hotplug but did get it working -- very cool. - -- Brian Gough Network Theory Ltd, Publishing Free Software Manuals --- http://www.network-theory.co.uk/ - ---------------------------------------------------------------------- - - Section 2.2. Required Hardware SCM card readers can be purchased online in the UK from http://www.crownhill.co.uk/ - - 2.2.1. A List of tested Readers The description for SCM Microsystems SPR532 says The pinpad may be used to securely enter the PIN without using the attached computer. With GPG 1.4.1, I am prompted to enter the pin on the tty. Is secure entry supported? I'd like to use this feature (I bought an SPR532 based on this). If not, suggest adding a note about the actual supported/unsupported status. - - Section 2.3.1. CCID (Chip Card Interface Description) The hotplug package in Debian stable requires all the numbers in gnupg-ccid.usermap to have a 0x prefix, otherwise it gives an "unparseable line" error and the i.e. gnupg-ccid 0x0003 0x04e6 0xe003 0x0 0x0 0x0 0x0 0x00 0x0B 0x00 0x00 0x00000000 instead of gnupg-ccid 0x0003 0x04e6 0xe003 0 0 0 0 0x00 0x0B 0x00 0x00 0x00000000 If hotplug is not working then gpg gives the following error when accessing the card, gpg: apdu_open_reader: failed to open driver `libpcsclite.so': libpcsclite.so: cannot open shared object file: No such file or directory Initially I tried installing the pcsc packages to get rid of the error. Could be worth adding a note that these are not needed for USB readers. - - CVS access On ://www.gnupg.org/(en)/documentation/howtos.html there is a link "The smartcard howto is also available via CVS" I couldn't find the original source, I tried checking out "gnupg-www" but it seems to contain derived files in gnupg-www/howtos/card-howto/en according to the README there. - ---------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCfKTebiFv7WQGnVwRAv06AJ0Q9rGbZEjrDYP44+Dml4M1VhHVOwCfeaEL 4pLLzKpfmQ1j+AztKAWRNTM= =kCDH -----END PGP SIGNATURE----- From mk at fsfe.org Mon May 9 15:45:52 2005 From: mk at fsfe.org (Matthias Kirschner) Date: Mon May 9 15:51:53 2005 Subject: smartcard howto notes In-Reply-To: References: Message-ID: <20050509134552.GC16904@mbwg.de> Hi Brian, * Brian Gough [2005-05-07 12:22:17 +0100]: > - - CVS access > > On ://www.gnupg.org/(en)/documentation/howtos.html there is a link > "The smartcard howto is also available via CVS" > > I couldn't find the original source, I tried checking out "gnupg-www" > but it seems to contain derived files in gnupg-www/howtos/card-howto/en > according to the README there. You can check it out using: cvs -d :pserver:anoncvs@cvs.gnupg.org:/cvs/gpgweb co card-howto (password: anoncvs) With best wishes, Matze -- Join the Fellowship and protect your freedom! (http://www.fsfe.org) From mk at fsfe.org Mon May 9 15:55:17 2005 From: mk at fsfe.org (Matthias Kirschner) Date: Mon May 9 15:51:59 2005 Subject: smartcard howto notes In-Reply-To: References: Message-ID: <20050509135517.GE16904@mbwg.de> Hi Brian, * Brian Gough [2005-05-07 12:22:17 +0100]: > - - Section 2.2. Required Hardware > > SCM card readers can be purchased online in the UK from > http://www.crownhill.co.uk/ Ok, I added this shop in the FAQ section. [...] > - - Section 2.3.1. CCID (Chip Card Interface Description) > > The hotplug package in Debian stable requires all the numbers in > gnupg-ccid.usermap to have a 0x prefix, otherwise it gives an > "unparseable line" error and the Can you sent me your files, then I'll put them online for Debian user, who are using stable, and put a note into the howto. [...] > Initially I tried installing the pcsc packages to get rid of the > error. Could be worth adding a note that these are not needed for USB > readers. Hm, I should also again test it with pcscd. Two questions; Are you using GnuPG 1.4.1? And what kernel version are you using? With best wishes, Matze -- Join the Fellowship and protect your freedom! (http://www.fsfe.org) From mschwendt at gmail.com Tue May 10 14:01:07 2005 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue May 10 14:57:24 2005 Subject: gnupg 1.9.15 test fails on x86_64 and ppc Message-ID: <440f31f605051005014fad6470@mail.gmail.com> Hi everyone! In Fedora Extras for Fedora Core 4 Development we currently experience a build problem with gnupg 1.9.15 on x86_64 (previously on powerpc), which is not reproducible on i386: FAIL: sm-sign+verify PASS: sm-verify ====================================== 1 of 2 tests failed Please report to gnupg-devel@gnupg.org ====================================== Running the test suite in verbose mode gives: sending `VERIFY' expecting OK gpgsm: some signal caught ... exiting I haven't tried yet whether patching the code to use strsignal() instead of the current direct sys_siglist[] access will give a hint instead of the "some signal" catch-all. A complete build log can be found here: http://extras64.linux.duke.edu/failed/development/gnupg2/1.9.15-4/x86_64/gnupg2-1.9.15-4.failure.log Regards, Michael From mschwendt at gmail.com Wed May 11 15:46:30 2005 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed May 11 15:42:48 2005 Subject: gnupg 1.9.15 test fails on x86_64 and ppc In-Reply-To: <440f31f605051005014fad6470@mail.gmail.com> References: <440f31f605051005014fad6470@mail.gmail.com> Message-ID: <440f31f605051106465cbaaf43@mail.gmail.com> On 5/10/05, Michael Schwendt wrote: > > In Fedora Extras for Fedora Core 4 Development we currently experience > a build problem with gnupg 1.9.15 on x86_64 (previously on powerpc), > which is not reproducible on i386: > > FAIL: sm-sign+verify > PASS: sm-verify Today's build of 1.9.16 succeeded for all three platforms (i386, x86_64, ppc), so either something in 1.9.16 has fixed it (side-effects maybe) or it will come back with future rebuilds. > gpgsm: some signal caught ... exiting I had added the following patch to 1.9.16 to get better output than just "some signal": diff -Nur gnupg-1.9.16-orig/common/signal.c gnupg-1.9.16/common/signal.c --- gnupg-1.9.16-orig/common/signal.c 2004-12-21 11:03:00.000000000 +0100 +++ gnupg-1.9.16/common/signal.c 2005-05-10 07:55:06.000000000 +0200 @@ -73,12 +73,12 @@ static const char * get_signal_name( int signum ) { -#if defined(SYS_SIGLIST_DECLARED) && defined(NSIG) - return (signum >= 0 && signum < NSIG) ? sys_siglist[signum] : "?"; -#else - return "some signal"; -#endif + const char* tmp = strsignal(signum); + if (tmp) + return tmp; + else + return "some signal"; } #endif /*!HAVE_DOSISH_SYSTEM*/ From bjg at network-theory.co.uk Thu May 12 13:54:34 2005 From: bjg at network-theory.co.uk (Brian Gough) Date: Thu May 12 14:05:02 2005 Subject: smartcard howto notes In-Reply-To: Message-ID: I am using gpg-1.4.1, kernel 2.4.19. The hotplug file is attached below. Sorry I didn't see your mail until I looked at the list archive, as I'm not subscribed to the list. -- Brian Gough Network Theory Ltd, Publishing Free Software Manuals --- http://www.network-theory.co.uk/ ---------------------------------------------------------------------- /etc/hotplug/usb.usermap.local: # Generic CCID device gnupg-ccid 0x0080 0x0 0x0 0x0 0x0 0x0 0x0 0x00 0x0B 0x00 0x00 0x00000000 # SPR532 is CCID but without the proper CCID class gnupg-ccid 0x0003 0x04e6 0xe003 0x0 0x0 0x0 0x0 0x00 0x0B 0x00 0x00 0x00000000 # SCR33x is CCID but without the proper CCID class gnupg-ccid 0x0003 0x04e6 0x5115 0x0 0x0 0x0 0x0 0x00 0x0B 0x00 0x00 0x00000000 After installing the file, run the following command as root: # update-usb.usermap ---------------------------------------------------------------------- From wk at gnupg.org Fri May 13 14:34:59 2005 From: wk at gnupg.org (Werner Koch) Date: Fri May 13 14:31:01 2005 Subject: gnupg 1.9.15 test fails on x86_64 and ppc In-Reply-To: <440f31f605051106465cbaaf43@mail.gmail.com> (Michael Schwendt's message of "Wed, 11 May 2005 15:46:30 +0200") References: <440f31f605051005014fad6470@mail.gmail.com> <440f31f605051106465cbaaf43@mail.gmail.com> Message-ID: <877ji3xq18.fsf@wheatstone.g10code.de> On Wed, 11 May 2005 15:46:30 +0200, Michael Schwendt said: > I had added the following patch to 1.9.16 to get better output than > just "some signal": There are in fact two problems. The first is a change in the name of the test macro for sys_siglist and the second is that we did not print the signal number if sys_siglist is not available. > + const char* tmp = strsignal(signum); strsignal is a GNU extension, so at least a test would be needed. Further it is not reentrant, so we better avoid it. I have changed it in a better way by using onkly functions allowed within a signal handler. This will print all signal numbers in the range 0 .. 99999 which should be sufficient. On GNU systems sys_siglist is available and thus the code is only used on some other platforms. Here is the patch: Index: signal.c =================================================================== RCS file: /cvs/gnupg/gnupg/common/signal.c,v retrieving revision 1.2.2.1 retrieving revision 1.2.2.3 diff -u -p -r1.2.2.1 -r1.2.2.3 --- signal.c 21 Dec 2004 10:03:00 -0000 1.2.2.1 +++ signal.c 13 May 2005 12:43:07 -0000 1.2.2.3 @@ -1,5 +1,6 @@ /* signal.c - signal handling - * Copyright (C) 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc. + * Copyright (C) 1998, 1999, 2000, 2001, 2002, + * 2005 Free Software Foundation, Inc. * * This file is part of GnuPG. * @@ -73,10 +74,12 @@ init_one_signal (int sig, RETSIGTYPE (*h static const char * get_signal_name( int signum ) { -#if defined(SYS_SIGLIST_DECLARED) && defined(NSIG) + /* Note that we can't use strsignal(), because it is not + reentrant. */ +#if defined(HAVE_DECL_SYS_SIGLIST) && defined(NSIG) return (signum >= 0 && signum < NSIG) ? sys_siglist[signum] : "?"; #else - return "some signal"; + return NULL; #endif } #endif /*!HAVE_DOSISH_SYSTEM*/ @@ -93,19 +96,42 @@ got_fatal_signal (int sig) if (cleanup_fnc) cleanup_fnc (); - /* better don't translate these messages */ + /* Better don't translate these messages. */ write (2, "\n", 1 ); s = log_get_prefix (NULL); if (s) write(2, s, strlen (s)); - write (2, ": ", 2 ); + write (2, ": signal ", 9 ); s = get_signal_name(sig); - write (2, s, strlen(s) ); + if (s) + write (2, s, strlen(s) ); + else + { + /* We are in a signal handler so we can't use any kind of printf + even not sprintf. USe a straightforward algorithm. */ + if (sig < 0 || sig >= 100000) + write (2, "?", 1); + else + { + int i, any=0; + + for (i=10000; i; i /= 10) + { + if (sig >= i || ((any || i==1) && !(sig/i))) + { + write (2, "0123456789"+(sig/i), 1); + if ((sig/i)) + any = 1; + sig %= i; + } + } + } + } write (2, " caught ... exiting\n", 20); - /* reset action to default action and raise signal again */ + /* Reset action to default action and raise signal again */ init_one_signal (sig, SIG_DFL, 0); - /* fixme: remove_lockfiles ();*/ + /* Fixme: remove_lockfiles ();*/ #ifdef __riscos__ close_fds (); #endif /* __riscos__ */ Shalom-Salam, Werner From mschwendt at gmail.com Fri May 13 15:18:57 2005 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri May 13 15:15:16 2005 Subject: gnupg 1.9.15 test fails on x86_64 and ppc In-Reply-To: <877ji3xq18.fsf@wheatstone.g10code.de> References: <440f31f605051005014fad6470@mail.gmail.com> <440f31f605051106465cbaaf43@mail.gmail.com> <877ji3xq18.fsf@wheatstone.g10code.de> Message-ID: <440f31f6050513061823eeb66b@mail.gmail.com> On 5/13/05, Werner Koch wrote: > > > I had added the following patch to 1.9.16 to get better output than > > just "some signal": > > There are in fact two problems. The first is a change in the name of > the test macro for sys_siglist Yes, indeed. That also explains why it didn't use sys_siglist actually. > and the second is that we did not print > the signal number if sys_siglist is not available. > > > + const char* tmp = strsignal(signum); > > strsignal is a GNU extension, so at least a test would be needed. > Further it is not reentrant, so we better avoid it. > > I have changed it in a better way by using onkly functions allowed > within a signal handler. This will print all signal numbers in the > range 0 .. 99999 which should be sufficient. On GNU systems > sys_siglist is available and thus the code is only used on some other > platforms. Okay. Works here, and this is GNU. I just needed a quick way to get a description of the received signal. The configure check for sys_siglist was successful, but I think I only looked whether HAVE_DECL_SYS_SIGLIST was true and then didn't look closer. ;) From mk at fsfe.org Mon May 16 23:11:06 2005 From: mk at fsfe.org (Matthias Kirschner) Date: Mon May 16 23:07:44 2005 Subject: Strange behaviour with different OpenPGP cards Message-ID: <20050516211106.GF13283@mbwg.de> Hi all, I have a strange behaviour here using Debian testing on a PPC, gnupg 1.4.1 + ccid patch, without pcscd. - OpenPGP Card (01000001 000000F9) (I was first asked for the pin then later the admin pin in the generation process) - Generation process always ends with: gpg: ccid_transceive failed: (0x1000a) gpg: apdu_send_simple(0) failed: card I/O error gpg: failed to store the key: general error gpg: storing key onto card failed: general error Key generation failed: general error - But I am able to sign/encrypt files, mails etc. with a key someone created for me on his i386 machine. - Fellowship card - (I was first asked for the admin pin, then for the pin in the generation process) - Generation process always with sucess. - But I am not able to de/encrypt files, it always ends in: PIN gpg: ccid_transceive failed: (0x1000a) gpg: apdu_send_simple(0) failed: card I/O error gpg: encrypted with 1024-bit RSA key, ID A4385295, created 2005-05-16 "Matthias Kirschner (test card user) " gpg: public key decryption failed: general error gpg: decryption failed: secret key not available Does anybody have an idea what the problem might be? With best wishes, Matze -- Join the Fellowship and protect your freedom! (http://www.fsfe.org) From greve at fsfeurope.org Tue May 17 10:33:46 2005 From: greve at fsfeurope.org (Georg C. F. Greve) Date: Tue May 17 10:55:07 2005 Subject: Strange behaviour with different OpenPGP cards In-Reply-To: <20050516211106.GF13283@mbwg.de> (Matthias Kirschner's message of "Mon, 16 May 2005 23:11:06 +0200") References: <20050516211106.GF13283@mbwg.de> Message-ID: || On Mon, 16 May 2005 23:11:06 +0200 || Matthias Kirschner wrote: mk> - Fellowship card mk> - (I was first asked for the admin pin, then for the pin in mk> the generation process) mk> - Generation process always with sucess. Then it should have been successful. What does --card-edit say? mk> - But I am not able to de/encrypt files, it always ends in: mk> PIN mk> gpg: ccid_transceive failed: (0x1000a) mk> gpg: apdu_send_simple(0) failed: card I/O error Are you using the pcscd? This seems the same problem that I reported earlier to the list. When using the pcscd, I can decrypt files and mail without problem. Regards, Georg -- Georg C. F. Greve Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : /pipermail/attachments/20050517/327c0cd8/attachment.pgp From list at omicron-persei-8.net Tue May 17 11:36:53 2005 From: list at omicron-persei-8.net (Tyler Retzlaff) Date: Tue May 17 11:35:34 2005 Subject: sigsuspend during gpgme_engine_check_version Message-ID: <4289BB35.9080308@omicron-persei-8.net> I don't have any significant experience with threaded programming but maybe someone can tell me whats going on here. During gpgme_engine_check_version the gpgme thread (I think) ends up it sigsuspend() waiting for a signal. (A gdb backtrace follows) some background about the application: The application using gpgme is heavily threaded (though only one "worker" thread is accessing the gpgme library). In addition the application catches most signals (perhaps a source of the problem?) Anyway, since at the point this happens only one thread is normally active this call to gpgme_engine_check_version causes the entire app to hang. I'm not sure if I have to kick gpgme in the guts somehow to get things moving... advice would be good. 0x42028d69 in sigsuspend () from /lib/i686/libc.so.6 (gdb) bt #0 0x42028d69 in sigsuspend () from /lib/i686/libc.so.6 #1 0x4034e108 in __pthread_wait_for_restart_signal () from /lib/i686/libpthread.so.0 #2 0x4034e8d3 in pthread_onexit_process () from /lib/i686/libpthread.so.0 #3 0x4034e744 in pthread_kill_other_threads_np () from /lib/i686/libpthread.so.0 #4 0x420ae6b5 in execve () from /lib/i686/libc.so.6 #5 0x420ae742 in execv () from /lib/i686/libc.so.6 #6 0x40034bf6 in _gpgme_io_spawn (path=0x40037efb "/usr/bin/gpg", argv=0xfffffffc, fd_child_list=0x40037efb, fd_parent_list=0x540b6f7c) at posix-io.c:252 #7 0x400363d5 in _gpgme_get_program_version (file_name=0x40037efb "/usr/bin/gpg") at version.c:184 #8 0x40031d64 in gpg_get_version () at rungpg.c:236 #9 0x40031072 in engine_get_version (proto=1108517584) at engine.c:78 #10 0x400310ff in gpgme_engine_check_version (proto=1073970939) at engine.c:102 #11 0x08216e91 in CEncryptionThread (this=0x8692768, esb=0x41fdd528) at /development/CEncryptionThread.cpp:27 #12 0x082149f4 in io::CEncryptedStreamBuffer::open(char const*, std::_Ios_Openmode) (this=0x41fdd528, file=0x83ddb8c "/var/spool/files/xyz.agf", mode=16) at /development/CEncryptedStreamBuffer.cpp:103 #13 0x08213d38 in io::CEncryptedStream::open(char const*, std::_Ios_Openmode) (this=0x41fdd508, file=0x83ddb8c "/var/spool/files/xyz.agf", mode=16) at /development/CEncryptedStream.cpp:28 Thanks Tyler From mk at fsfe.org Tue May 17 15:51:27 2005 From: mk at fsfe.org (Matthias Kirschner) Date: Tue May 17 15:48:02 2005 Subject: Strange behaviour with different OpenPGP cards In-Reply-To: References: <20050516211106.GF13283@mbwg.de> Message-ID: <20050517135126.GG13283@mbwg.de> * Georg C. F. Greve [2005-05-17 10:33:46 +0200]: > What does --card-edit say? The new key is on the card. I can also use the card to sign files, but not de- and encrypt files. > mk> - But I am not able to de/encrypt files, it always ends in: > > mk> PIN > mk> gpg: ccid_transceive failed: (0x1000a) > mk> gpg: apdu_send_simple(0) failed: card I/O error > > Are you using the pcscd? No, this was all without pcscd. > When using the pcscd, I can decrypt files and mail without problem. I have now installed pcscd, the result is, that I am still not able to de and encrpyt (but I can sign). ngpg@woodstock:~$ gpg --disable-ccid test.gpg gpg: pcsc_establish_context failed: no service (0x8010001d) gpg: card reader not available gpg: encrypted with 1024-bit RSA key, ID CF4806D3, created 2005-05-16 "Matthias Kirschner (test card user) " gpg: public key decryption failed: general error gpg: decryption failed: secret key not available I have installed all packages which depends on pcscd. Do I have to do anything else? With best wishes, Matze -- Join the Fellowship and protect your freedom! (http://www.fsfe.org) From greve at fsfeurope.org Tue May 17 16:57:19 2005 From: greve at fsfeurope.org (Georg C. F. Greve) Date: Tue May 17 16:53:14 2005 Subject: Strange behaviour with different OpenPGP cards In-Reply-To: <20050517135126.GG13283@mbwg.de> (Matthias Kirschner's message of "Tue, 17 May 2005 15:51:27 +0200") References: <20050516211106.GF13283@mbwg.de> <20050517135126.GG13283@mbwg.de> Message-ID: || On Tue, 17 May 2005 15:51:27 +0200 || Matthias Kirschner wrote: mk> I have now installed pcscd, the result is, that I am still not mk> able to de and encrpyt (but I can sign). mk> [...] mk> I have installed all packages which depends on pcscd. Do I have mk> to do anything else? Is pcscd actually running and claiming the card? You can tell this for most SCR 335 readers when the LED is turned on when the card is inserted. The Debian packages of pcscd are pretty bad. Try installing the rest of the libraries that depend on pcscd and disable their reader.conf.d configuration so pcscd will actually start. That is what solved the problem for me. Regards, Georg -- Georg C. F. Greve Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : /pipermail/attachments/20050517/25a6afcb/attachment.pgp From Zlat0 at mail.ru Tue May 17 21:32:23 2005 From: Zlat0 at mail.ru (=?KOI8-R?Q?=ED=C1=CB=D3=C9=CD_=FA=C9=CE=C1=CC=D8?=) Date: Tue May 17 22:35:49 2005 Subject: sigsuspend during gpgme_engine_check_version In-Reply-To: <4289BB35.9080308@omicron-persei-8.net> References: <4289BB35.9080308@omicron-persei-8.net> Message-ID: <428A46C7.5090304@mail.ru> Tyler Retzlaff wrote: > I don't have any significant experience with threaded programming but > maybe someone can tell me whats going on here. During > gpgme_engine_check_version the gpgme thread (I think) ends up it > sigsuspend() waiting for a signal. (A gdb backtrace follows) > > some background about the application: > The application using gpgme is heavily threaded (though only one > "worker" thread is accessing the gpgme library). In addition the > application catches most signals (perhaps a source of the problem?) > > Anyway, since at the point this happens only one thread is normally > active this call to gpgme_engine_check_version causes the entire app to > hang. I'm not sure if I have to kick gpgme in the guts somehow to get > things moving... advice would be good. > > 0x42028d69 in sigsuspend () from /lib/i686/libc.so.6 > (gdb) bt > #0 0x42028d69 in sigsuspend () from /lib/i686/libc.so.6 > #1 0x4034e108 in __pthread_wait_for_restart_signal () from > /lib/i686/libpthread.so.0 > #2 0x4034e8d3 in pthread_onexit_process () from /lib/i686/libpthread.so.0 > #3 0x4034e744 in pthread_kill_other_threads_np () from > /lib/i686/libpthread.so.0 > #4 0x420ae6b5 in execve () from /lib/i686/libc.so.6 > #5 0x420ae742 in execv () from /lib/i686/libc.so.6 > #6 0x40034bf6 in _gpgme_io_spawn (path=0x40037efb "/usr/bin/gpg", > argv=0xfffffffc, fd_child_list=0x40037efb, fd_parent_list=0x540b6f7c) at > posix-io.c:252 > #7 0x400363d5 in _gpgme_get_program_version (file_name=0x40037efb > "/usr/bin/gpg") at version.c:184 > #8 0x40031d64 in gpg_get_version () at rungpg.c:236 > #9 0x40031072 in engine_get_version (proto=1108517584) at engine.c:78 > #10 0x400310ff in gpgme_engine_check_version (proto=1073970939) at > engine.c:102 > #11 0x08216e91 in CEncryptionThread (this=0x8692768, esb=0x41fdd528) at > /development/CEncryptionThread.cpp:27 > #12 0x082149f4 in io::CEncryptedStreamBuffer::open(char const*, > std::_Ios_Openmode) (this=0x41fdd528, file=0x83ddb8c > "/var/spool/files/xyz.agf", mode=16) > at /development/CEncryptedStreamBuffer.cpp:103 > #13 0x08213d38 in io::CEncryptedStream::open(char const*, > std::_Ios_Openmode) (this=0x41fdd508, file=0x83ddb8c > "/var/spool/files/xyz.agf", mode=16) > at /development/CEncryptedStream.cpp:28 > The lockup occured at execv() call, which is not a normal situation. Perhaps your Linux system has an old threading library (LinuxThreads?) which doesn't work quite well for complex application, especially with complex signal handling code. Try testing your code with magical `LD_ASSIME_KERNEL=2.2.5`. Also consider testing it on a modern Linux distribution with NPTL support. -- Max Zinal. From rjh at sixdemonbag.org Wed May 18 04:19:37 2005 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed May 18 05:15:17 2005 Subject: GPGMail and the GPL? Message-ID: <6B3D4D20-CC24-4E38-AEF6-B93C87FFA541@sixdemonbag.org> http://www.sente.ch/software/GPGMail/English.lproj/GPGMail.html http://www.sente.ch/software/GPGMail/English.lproj/LICENSE.txt ... St?phane Corth?sy's GPGMail is a fine implementation of GnuPG for the OS X platform, but my reading of the license suggests it's not GPL-compliant. The other text on the site suggests that he's using gpgme to do some of the work, which would seem to lead to a license conflict. Particularly, St?phane's license requires: * His written permission before: * Large-scale redistribution of the source code * Distributing source code in printed form * Distributing modified source * Using his source to create commercial products * No fees may be charged for source, not even to accomodate reasonable copying fees * He can change the license at any time and have it binding, without you agreeing to the new terms He's also misattributing GPGME's copyright; he's attributing it to 2001-2003 the MacGPG Group. I believe this attribution is in error. I'm not in any way trying to slight St?phane's excellent work. It's good stuff. I'm just hoping that one of the core GnuPG devels, someone who holds copyright on a part of GnuPG, can politely ask St?phane what's going on and resolve any conflict, should one actually exist. From stephane at sente.ch Wed May 18 08:54:28 2005 From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Wed May 18 09:51:33 2005 Subject: GPGMail and the GPL? In-Reply-To: <6B3D4D20-CC24-4E38-AEF6-B93C87FFA541@sixdemonbag.org> References: <6B3D4D20-CC24-4E38-AEF6-B93C87FFA541@sixdemonbag.org> Message-ID: Hi, There is actually a problem with present version (1.1): GPGMail conflicts with the LGPL (gpgme/GPGME are LGPL'd), as it directly uses the code in the binary instead of linking to dynamic libraries; I wrongly assumed that I could use the LGPL'd code directly in my binary which is not LGPL'd (and not compatible with LGPL); originally I wanted to link to the libs dynamically, but encountered some problems at link stage and finally statically linked the lib to my bundle, without realizing that it was illegal. I will fix problem by the end of the week (it's been fixed in my work area) and I'm really sorry about that. Note also that gpgme != GPGME: gpgme is g10's C library, whereas GPGME is MacGPG's ObjC framework (that I wrote, but copyright is to MacGPG). Both are LGPL'd, and not GPL'd, since version 1.0.2; before that version I didn't link GPGMail to any of these libs, nor statically neither dynamically, and was using them in a GPL'd tool called GPGMEProxyServer which was a standalone GPL'd executable. Once again I'm sorry about that and didn't intend to make any harm. Now let's face the consequences. St?phane On May 18, 2005, at 4:19, Robert J. Hansen wrote: > http://www.sente.ch/software/GPGMail/English.lproj/GPGMail.html > http://www.sente.ch/software/GPGMail/English.lproj/LICENSE.txt > > ... St?phane Corth?sy's GPGMail is a fine implementation of GnuPG for > the OS X platform, but my reading of the license suggests it's not > GPL-compliant. The other text on the site suggests that he's using > gpgme to do some of the work, which would seem to lead to a license > conflict. > > Particularly, St?phane's license requires: > > * His written permission before: > * Large-scale redistribution of the source code > * Distributing source code in printed form > * Distributing modified source > * Using his source to create commercial products > * No fees may be charged for source, not even to > accomodate reasonable copying fees > * He can change the license at any time and have it > binding, without you agreeing to the new terms > > He's also misattributing GPGME's copyright; he's attributing it to > 2001-2003 the MacGPG Group. I believe this attribution is in error. > > I'm not in any way trying to slight St?phane's excellent work. It's > good stuff. I'm just hoping that one of the core GnuPG devels, > someone who holds copyright on a part of GnuPG, can politely ask > St?phane what's going on and resolve any conflict, should one actually > exist. > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : /pipermail/attachments/20050518/74520eff/PGP.pgp From wk at gnupg.org Wed May 18 11:48:26 2005 From: wk at gnupg.org (Werner Koch) Date: Wed May 18 11:45:56 2005 Subject: GPGMail and the GPL? In-Reply-To: ( =?utf-8?q?St=C3=A9phane_Corth=C3=A9sy's_message_of?= "Wed, 18 May 2005 08:54:28 +0200") References: <6B3D4D20-CC24-4E38-AEF6-B93C87FFA541@sixdemonbag.org> Message-ID: <87ll6cc1at.fsf@wheatstone.g10code.de> On Wed, 18 May 2005 08:54:28 +0200, St?phane Corth?sy said: > wanted to link to the libs dynamically, but encountered some problems > at link stage and finally statically linked the lib to my bundle, > without realizing that it was illegal. That is not illegal. You merely need to provide a way to the user to link it against a modified gpgme. This can be done by linking the non-free stuff into a relocatable object (ld's option -r) so that it may later be linked with a modified gpgme to bukld the final thing. Dynamic shared objects are of course much easier to handle. > I will fix problem by the end of the week (it's been fixed in my work > area) and I'm really sorry about that. Okay. > that version I didn't link GPGMail to any of these libs, nor > statically neither dynamically, and was using them in a GPL'd tool > called GPGMEProxyServer which was a standalone GPL'd executable. Just for the records: The GPL does not say what makes up a derivative work. The impression that the process boundary (i.e. a separate executable) is a decision criteria for whether something is a derivative work or a mere aggregation is not correct. In particular, writing a proxy for the sole purpose of working around the terms of the GPL is not an option. > Once again I'm sorry about that and didn't intend to make any > harm. Now let's face the consequences. Anyway, now that GPGME is available under the LGPL, g10 Code GmbH won't care anymore about past violations of the GPL by your software GPGMail. Shalom-Salam, Werner -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20050518/7afc63c2/attachment.pgp From folkert at vanheusden.com Wed May 18 11:58:26 2005 From: folkert at vanheusden.com (Folkert van Heusden) Date: Wed May 18 11:54:08 2005 Subject: gpgme doesn't seem to return the signatures Message-ID: <20050518095823.GQ17168@vanheusden.com> I have the following version: 130 folkert@keetweej:~/Personal/src/gpgstats$ dpkg --list | grep gpgme ii libgpgme11 1.0.2-1 GPGME - GnuPG Made Easy ii libgpgme11-dev 1.0.2-1 GPGME - GnuPG Made Easy ii libgpgme6 0.3.16-2 GPGME - GnuPG Made Easy lrwxrwxrwx 1 root root 18 Apr 14 08:27 /usr/lib/libgpgme.so -> libgpgme.so.11.3.3 lrwxrwxrwx 1 root root 18 Apr 14 08:26 /usr/lib/libgpgme.so.11 -> libgpgme.so.11.3.3 -rw-r--r-- 1 root root 127368 Jan 15 15:27 /usr/lib/libgpgme.so.11.3.3 lrwxrwxrwx 1 root root 17 Apr 3 02:12 /usr/lib/libgpgme.so.6 -> libgpgme.so.6.3.7 -rw-r--r-- 1 root root 99184 May 1 2004 /usr/lib/libgpgme.so.6.3.7 I'm doing: (void)gpgme_check_version(NULL); err = gpgme_new(&ctx); err = gpgme_op_keylist_start (ctx, NULL, 0); err = gpgme_op_keylist_next(ctx, &r_key); gpgme_user_id_t uids = r_key -> uids; ...for each uid... gpgme_key_sig_t sigs = uids -> signatures; Now sigs in this case is *always* NULL! And I've verified (with gpg --list-sigs) that *all* keys have one or more signature. Oh, and do I need to free-up something after I do gpgme_op_keylist_next? Folkert van Heusden -- Auto te koop, zie: http://www.vanheusden.com/daihatsu.php Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden. -------------------------------------------------------------------- UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) a try, it brings monitoring logfiles to a different level! See http://vanheusden.com/multitail/features.html for a feature-list. -------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.com! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 282 bytes Desc: Digital signature Url : /pipermail/attachments/20050518/9a7da5b1/attachment.pgp From wk at gnupg.org Wed May 18 15:50:16 2005 From: wk at gnupg.org (Werner Koch) Date: Wed May 18 15:50:55 2005 Subject: Latest changes to scdaemon Message-ID: <87acmsabjb.fsf@wheatstone.g10code.de> Hi! FYI: I worked a bit on scdaemon and gpg-agent to allow for concurrent access to the smartcard reader. A first test shows that it basically works but it has not undergo more than very basic testing, so expect all kinds of bugs. Its all in the CVS. This change is a prerequisite to allow peaceful coexistence of the standalong gpg 1.4 and the gpg-agent with ssh-support. It is anyway a useful thing. Note that the gpg-connect-agent tool is very handy to test these things. I am now going to work on the gpg 1.4 part. Shalom-Salam, Werner From rjh at sixdemonbag.org Thu May 19 01:45:55 2005 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu May 19 01:41:41 2005 Subject: GPG 1.4 and 2.6-style keys Message-ID: For reasons I've never quite been able to figure out, some people are fond of their legacy PGP 2.6 keys and are reluctant to part with them. Nowadays I'm getting some traffic from people using legacy keys with SHA2 as a signature algorithm, which GnuPG 1.4 sees as a signature conflict. Is this new behavior to GnuPG? I don't recall seeing signature conflicts of that sort in past releases. From dshaw at jabberwocky.com Thu May 19 11:22:59 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu May 19 11:19:14 2005 Subject: GPG 1.4 and 2.6-style keys In-Reply-To: References: Message-ID: <20050519092259.GA23229@jabberwocky.com> On Wed, May 18, 2005 at 06:45:55PM -0500, Robert J. Hansen wrote: > For reasons I've never quite been able to figure out, some people are > fond of their legacy PGP 2.6 keys and are reluctant to part with > them. Nowadays I'm getting some traffic from people using legacy > keys with SHA2 as a signature algorithm, which GnuPG 1.4 sees as a > signature conflict. Is this new behavior to GnuPG? I don't recall > seeing signature conflicts of that sort in past releases. I'd have to see an example message to be sure, but by the description, this was fixed in CVS and will be part of 1.4.2. It actually has nothing to do with legacy keys, but a legacy signature format. David From rtr at omicron-persei-8.net Wed May 18 10:16:33 2005 From: rtr at omicron-persei-8.net (Tyler Retzlaff) Date: Thu May 19 14:19:32 2005 Subject: sigsuspend during gpgme_engine_check_version In-Reply-To: <428A46C7.5090304@mail.ru> References: <4289BB35.9080308@omicron-persei-8.net> <428A46C7.5090304@mail.ru> Message-ID: <428AF9E1.1020502@omicron-persei-8.net> ?????? ?????? wrote: > Tyler Retzlaff wrote: > > The lockup occured at execv() call, which is not a normal situation. > Perhaps your Linux system has an old threading library (LinuxThreads?) > which doesn't work quite well for complex application, especially > with complex signal handling code. Try testing your code with > magical `LD_ASSIME_KERNEL=2.2.5`. Also consider testing it on a > modern Linux distribution with NPTL support. indeed you were correct, I didn't look as close at that backtrace as I thought I had I tried the same code on a newer userland & kernel and it works fine. Thanks for the help. > -- > Max Zinal. > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From mk at fsfe.org Thu May 19 14:24:52 2005 From: mk at fsfe.org (Matthias Kirschner) Date: Thu May 19 14:21:13 2005 Subject: Strange behaviour with different OpenPGP cards In-Reply-To: References: <20050516211106.GF13283@mbwg.de> <20050517135126.GG13283@mbwg.de> Message-ID: <20050519122451.GU3453@mbwg.de> Hi Georg, * Georg C. F. Greve [2005-05-17 16:57:19 +0200]: > Is pcscd actually running and claiming the card? You can tell this for > most SCR 335 readers when the LED is turned on when the card is > inserted. Yes, the LED is turned on. > The Debian packages of pcscd are pretty bad. Try installing the rest > of the libraries that depend on pcscd and disable their reader.conf.d > configuration so pcscd will actually start. That is what solved the > problem for me. I have done this. If I plug in the card reader I get an [...] May 19 14:18:24 woodstock pcscd: ccid_usb.c:225:OpenUSBByName Manufacturer: Ludovic Rousseau (ludovic.rousseau@free.fr) May 19 14:18:24 woodstock pcscd: ccid_usb.c:235:OpenUSBByName ProductString: Generic CCID reader v0.9.3 May 19 14:18:24 woodstock pcscd: ccid_usb.c:241:OpenUSBByName Copyright: This driver is protected by terms of the GNU General Public License version 2, or (at your option) any later version. May 19 14:18:24 woodstock pcscd: ccid_usb.c:376:OpenUSBByName Found Vendor/Product: 04E6/5115 (SCR 335) May 19 14:18:24 woodstock pcscd: ccid_usb.c:378:OpenUSBByName Using USB bus/device: 003/002 May 19 14:18:24 woodstock pcscd: ccid_usb.c:679:ccid_check_firmware Firmware (4.16) is bogus! Upgrade the reader firmware or get a new reader. May 19 14:18:24 woodstock pcscd: ifdhandler.c:85:IFDHCreateChannelByName failed May 19 14:18:24 woodstock pcscd: readerfactory.c:1101:RFInitializeReader() Open Port 200000 Failed (usb:04e6/5115:libusb:003) May 19 14:18:24 woodstock pcscd: readerfactory.c:219:RFAddReader() SCR 335 init failed. in my syslog. As far as I know 4.16 is not upgradable, is this still true? Best wishes, Matze -- Join the Fellowship and protect your freedom! (http://www.fsfe.org) From greve at fsfeurope.org Thu May 19 16:15:20 2005 From: greve at fsfeurope.org (Georg C. F. Greve) Date: Thu May 19 16:11:48 2005 Subject: Strange behaviour with different OpenPGP cards In-Reply-To: <20050519122451.GU3453@mbwg.de> (Matthias Kirschner's message of "Thu, 19 May 2005 14:24:52 +0200") References: <20050516211106.GF13283@mbwg.de> <20050517135126.GG13283@mbwg.de> <20050519122451.GU3453@mbwg.de> Message-ID: || On Thu, 19 May 2005 14:24:52 +0200 || Matthias Kirschner wrote: mk> As far as I know 4.16 is not upgradable, is this still true? AFAIK, yes. Maybe Werner can help with this in terms of possibly exchanging it. Regards, Georg -- Georg C. F. Greve Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : /pipermail/attachments/20050519/acb83261/attachment.pgp From folkert at vanheusden.com Fri May 20 14:34:44 2005 From: folkert at vanheusden.com (Folkert van Heusden) Date: Fri May 20 14:30:28 2005 Subject: Fw: gpgme doesn't seem to return the signatures Message-ID: <20050520123443.GF1124@vanheusden.com> I'm doing: (void)gpgme_check_version(NULL); err = gpgme_new(&ctx); err = gpgme_op_keylist_start (ctx, NULL, 0); err = gpgme_op_keylist_next(ctx, &r_key); gpgme_user_id_t uids = r_key -> uids; ...for each uid... gpgme_key_sig_t sigs = uids -> signatures; Now sigs in this case is *always* NULL! And I've verified (with gpg --list-sigs) that *all* keys have one or more signature. Folkert van Heusden -- Auto te koop, zie: http://www.vanheusden.com/daihatsu.php Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden. -------------------------------------------------------------------- UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) a try, it brings monitoring logfiles to a different level! See http://vanheusden.com/multitail/features.html for a feature-list. -------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.com! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 282 bytes Desc: Digital signature Url : /pipermail/attachments/20050520/6fb3c329/attachment.pgp From rhwood at mac.com Fri May 20 14:41:25 2005 From: rhwood at mac.com (Randall Wood) Date: Fri May 20 14:37:41 2005 Subject: gpgme doesn't seem to return the signatures In-Reply-To: <20050520123443.GF1124@vanheusden.com> References: <20050520123443.GF1124@vanheusden.com> Message-ID: <877643f7bdd1c59e6a11c66eff9fded4@mac.com> see the function gpgme_set_keylist_mode(gpgme_ctx_t CTX, gpgme_keylist_mode_t MODE) to solve your problem. Since I only use gpgme via the GPGME.framework Objective-C wrapper, I can't help beyond that except to note that gpgme by default will not list signatures. On 20 May 2005, at 21:34, Folkert van Heusden wrote: > I'm doing: > (void)gpgme_check_version(NULL); > err = gpgme_new(&ctx); > err = gpgme_op_keylist_start (ctx, NULL, 0); > err = gpgme_op_keylist_next(ctx, &r_key); > gpgme_user_id_t uids = r_key -> uids; > ...for each uid... > gpgme_key_sig_t sigs = uids -> signatures; > > Now sigs in this case is *always* NULL! > And I've verified (with gpg --list-sigs) that *all* keys have one or > more signature. > > > Folkert van Heusden > > -- > Auto te koop, zie: http://www.vanheusden.com/daihatsu.php > Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden. > -------------------------------------------------------------------- > UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) > a try, it brings monitoring logfiles to a different level! See > http://vanheusden.com/multitail/features.html for a feature-list. > -------------------------------------------------------------------- > Phone: +31-6-41278122, PGP-key: 1F28D8AE > Get your PGP/GPG key signed at www.biglumber.com! > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -- Randall Wood rhwood@mac.com "The ball is round. The game lasts ninety minutes. The rest is theory..." -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : /pipermail/attachments/20050520/711765b5/PGP.pgp From folkert at vanheusden.com Fri May 20 15:28:23 2005 From: folkert at vanheusden.com (Folkert van Heusden) Date: Fri May 20 15:24:03 2005 Subject: gpgme doesn't seem to return the signatures In-Reply-To: <877643f7bdd1c59e6a11c66eff9fded4@mac.com> References: <20050520123443.GF1124@vanheusden.com> <877643f7bdd1c59e6a11c66eff9fded4@mac.com> Message-ID: <20050520132820.GG1124@vanheusden.com> Ah great, that fixed it! Thanks. On Fri, May 20, 2005 at 09:41:25PM +0900, Randall Wood wrote: > see the function gpgme_set_keylist_mode(gpgme_ctx_t CTX, > gpgme_keylist_mode_t MODE) > to solve your problem. Since I only use gpgme via the GPGME.framework > Objective-C wrapper, I can't help beyond that except to note that gpgme > by default will not list signatures. > > On 20 May 2005, at 21:34, Folkert van Heusden wrote: > > >I'm doing: > > (void)gpgme_check_version(NULL); > > err = gpgme_new(&ctx); > > err = gpgme_op_keylist_start (ctx, NULL, 0); > > err = gpgme_op_keylist_next(ctx, &r_key); > > gpgme_user_id_t uids = r_key -> uids; > > ...for each uid... > > gpgme_key_sig_t sigs = uids -> signatures; > > > >Now sigs in this case is *always* NULL! > >And I've verified (with gpg --list-sigs) that *all* keys have one or > >more signature. Folkert van Heusden -- Auto te koop, zie: http://www.vanheusden.com/daihatsu.php Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden. -------------------------------------------------------------------- UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) a try, it brings monitoring logfiles to a different level! See http://vanheusden.com/multitail/features.html for a feature-list. -------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.com! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 282 bytes Desc: Digital signature Url : /pipermail/attachments/20050520/fe1f6d16/attachment.pgp From kg at office.fsfeurope.org Thu May 19 16:41:10 2005 From: kg at office.fsfeurope.org (Karsten Gerloff) Date: Fri May 20 18:05:44 2005 Subject: smartcard use with sylpheed-claws Message-ID: <20050519164110.5cc0c424@gerloffium.fsfeurope.org> Hi, unfortunately, my beloved mail reader sylpheed-claws does not work with smartcards. The problem seems to be that the PIN request is not working; sylpheed-claws simply does not ask for a PIN at the point where it usually requests the passphrase. Then, it concludes that no valid passphrase was entered and refuses to process the mail. Sylpheed-claws uses GPGME for GPG integration. How could this problem be fixed? Best regards Karsten -- Karsten Gerloff Free Software Foundation Europe (http://www.fsfeurope.org) Office t. ++49-700-FSFEUROPE Join the Fellowship and protect your Freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050519/03c6b58a/attachment-0001.pgp From madduck at debian.org Thu May 19 23:41:37 2005 From: madduck at debian.org (martin f krafft) Date: Fri May 20 18:05:48 2005 Subject: failure to verify a message with 1.4.0 Message-ID: <20050519214137.GA12809@cirrus.madduck.net> Hi there, I just stumbled over this problem today and wanted to make sure it's known. I received a message over a Debian mailing list which failed to verify ("BADSIG") in mutt when verified against the Debian gnupg package 1.4.0-2. The same message does verify fine with 1.2.5-3 and 1.4.1-1. If this is a known bug, I apologise. However, I am still providing you with all the information to make sure that it's not a lingering Heisenbug or something of that sort in 1.4.x versions. *** If this is not known, please let me know ASAP as we might be facing a security-grade bug in 1.4.1-1, which is about to go into Debian sarge. If possible, also include security@debian.org in such a reply *** The message (in an mbox): http://madduck.net/~madduck/scratch/roberto.mbox Size: 4923 MD5: cfb69c8464140a33f5c281a50ea7126e The binary: 2649ac364358281f4bf1b13e31335dfa 797452 /usr/bin/gpg The package: http://madduck.net/~madduck/scratch/gnupg_1.4.0-2_i386.deb.SUSPECT Size: 1844922 MD5: 1978fe19f44e68e350dc4bf187d85b6a Either way -- please CC me on replies and let me know the resolution. Thanks a lot. -- .''`. martin f. krafft : :' : proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! "man kann die menschen nur von ihren eigenen meinungen ?berzeugen." -- charles tschopp -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20050519/3895aeb2/attachment.pgp From wk at gnupg.org Fri May 20 22:13:45 2005 From: wk at gnupg.org (Werner Koch) Date: Fri May 20 22:10:57 2005 Subject: card related bug 419 fixed Message-ID: <87wtptzmdi.fsf@wheatstone.g10code.de> Hi! we had sometimes serious problems in gpg storing keys on the card as well as other failures. I have now figured out the faulty bit. The patch below should fix it. Shalom-Salam, Werner 2005-05-20 Werner Koch * ccid-driver.c (ccid_transceive): Arghhh. The seqno is another bit in the R-block than in the I block, this was wrong at one place. Fixes bug #419 and hopefully several others. diff -u -p -r1.24 ccid-driver.c --- g10/ccid-driver.c 7 May 2005 15:22:01 -0000 1.24 +++ g10/ccid-driver.c 20 May 2005 20:20:20 -0000 @@ -1814,7 +1814,7 @@ ccid_transceive (ccid_driver_t handle, msg = send_buffer; tpdulen = last_tpdulen; } - else if (sending && !!(tpdu[1] & 0x40) == handle->t1_ns) + else if (sending && !!(tpdu[1] & 0x10) == handle->t1_ns) { /* Reponse does not match our sequence number. */ DEBUGOUT ("R-block with wrong seqno received on more bit\n"); return CCID_DRIVER_ERR_CARD_IO_ERROR; From cesar.kuroiwa at poli.usp.br Sat May 21 16:55:56 2005 From: cesar.kuroiwa at poli.usp.br (Cesar Henrique Keiti Kuroiwa) Date: Sat May 21 17:26:57 2005 Subject: gpgme with cgi Message-ID: <05C8A642CE8A704FA4A3C6F4D77C9F4E2223D2@apl13.poli.usp.br> hi I`m trying to use the gpgme library in a cgi program, more especifically to do an import operation, but somehow it doesnt work and no error are indicated, only that the number of considered keys is 0. What is also very strange is that by calling the same function via a command-line program, it works fine! So is there anything different to be done when using gpgme in a CGI? thanx From dshaw at jabberwocky.com Sun May 22 15:10:25 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Sun May 22 15:06:42 2005 Subject: failure to verify a message with 1.4.0 In-Reply-To: <20050519214137.GA12809@cirrus.madduck.net> References: <20050519214137.GA12809@cirrus.madduck.net> Message-ID: <20050522131025.GC32196@jabberwocky.com> On Thu, May 19, 2005 at 11:41:37PM +0200, martin f krafft wrote: > I just stumbled over this problem today and wanted to make sure it's > known. I received a message over a Debian mailing list which failed > to verify ("BADSIG") in mutt when verified against the Debian gnupg > package 1.4.0-2. The same message does verify fine with 1.2.5-3 and > 1.4.1-1. > > If this is a known bug, I apologise. However, I am still providing > you with all the information to make sure that it's not a lingering > Heisenbug or something of that sort in 1.4.x versions. > > *** If this is not known, please let me know ASAP as we might be > facing a security-grade bug in 1.4.1-1, which is about to go into > Debian sarge. If possible, also include security@debian.org in such > a reply *** This is a known issue, but it's not a bug that was fixed between 1.4.0 and 1.4.1. It's a bit more complicated than that. The problem here is actually in the mail message itself - the program that generated it does not fully follow the PGP/MIME standard. Around the time of the 1.4.0 release, the OpenPGP specification clarified a lingering text line-ending encoding incompatibility between PGP and GnuPG. 1.4.0 made this change (which should have been invisible to 99.9% of users) but unfortunately some mail programs didn't exactly follow the PGP/MIME specification about text line endings (trailing spaces must be escaped). The reason that it works with 1.4.1 but not 1.4.0 is that 1.4.1 has a switch (set by default) to use the old behavior. The whole story is at: http://lists.gnupg.org/pipermail/gnupg-users/2005-January/024408.html David -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 246 bytes Desc: not available Url : /pipermail/attachments/20050522/13135cba/attachment.pgp From kfitzner at excelcia.org Sun May 22 18:47:26 2005 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Sun May 22 18:43:29 2005 Subject: gpgme with cgi In-Reply-To: <05C8A642CE8A704FA4A3C6F4D77C9F4E2223D2@apl13.poli.usp.br> References: <05C8A642CE8A704FA4A3C6F4D77C9F4E2223D2@apl13.poli.usp.br> Message-ID: <4290B79E.4030808@excelcia.org> CGI programs are often run in a chroot "jail", that might be something to check. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 546 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050522/aaca3422/signature.pgp From wk at gnupg.org Mon May 23 11:07:22 2005 From: wk at gnupg.org (Werner Koch) Date: Mon May 23 11:05:59 2005 Subject: smartcard use with sylpheed-claws In-Reply-To: <20050519164110.5cc0c424@gerloffium.fsfeurope.org> (Karsten Gerloff's message of "Thu, 19 May 2005 16:41:10 +0200") References: <20050519164110.5cc0c424@gerloffium.fsfeurope.org> Message-ID: <87ekbyxqd1.fsf@wheatstone.g10code.de> On Thu, 19 May 2005 16:41:10 +0200, Karsten Gerloff said: > The problem seems to be that the PIN request is not working; > sylpheed-claws simply does not ask for a PIN at the point where it You probably nedd to blame me for that. I wrote that code many years ago. There is however a solution which is far better then letting Sylpheed asking for the passphrase: Use gpg-agent. There should be a Debian package for it. Shalom-Salam, Werner From greve at fsfeurope.org Mon May 23 11:18:24 2005 From: greve at fsfeurope.org (Georg C. F. Greve) Date: Mon May 23 11:15:29 2005 Subject: card related bug 419 fixed In-Reply-To: <87wtptzmdi.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri, 20 May 2005 22:13:45 +0200") References: <87wtptzmdi.fsf@wheatstone.g10code.de> Message-ID: || On Fri, 20 May 2005 22:13:45 +0200 || Werner Koch wrote: wk> we had sometimes serious problems in gpg storing keys on the card wk> as well as other failures. I have now figured out the faulty wk> bit. The patch below should fix it. Applying this patch to my version of GPG 1.4.1, I can now decrypt without the pcscd, running a SCM 335 with firmware 5.14. This seems to have been the major problem. Regards, Georg -- Georg C. F. Greve Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : /pipermail/attachments/20050523/7cd9ec2e/attachment.pgp From wk at gnupg.org Mon May 23 22:08:41 2005 From: wk at gnupg.org (Werner Koch) Date: Mon May 23 22:06:05 2005 Subject: Latest changes to scdaemon In-Reply-To: <87acmsabjb.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 18 May 2005 15:50:16 +0200") References: <87acmsabjb.fsf@wheatstone.g10code.de> Message-ID: <87hdgtwvqu.fsf@wheatstone.g10code.de> On Wed, 18 May 2005 15:50:16 +0200, Werner Koch said: > This change is a prerequisite to allow peaceful coexistence of the > standalong gpg 1.4 and the gpg-agent with ssh-support. It is anyway a Done. The CVS versions of gnupg 1.9 and gpg 1.4 should not work nicely together. Not much tested so far and I still need to ifdef some things to build for W32. Shalom-Salam, Werner From gnupg at F-Streibelt.de Mon May 23 21:59:39 2005 From: gnupg at F-Streibelt.de (Florian Streibelt) Date: Mon May 23 22:53:09 2005 Subject: 1.4.1: patch to delete all non self-signatures Message-ID: <4292362B.6080403@F-Streibelt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, in preparation to a key signing party I had been confronted with the task to automatically handle keys send in via Email and to give the attendees the possibility to download a small keyring of all the participants keys. To get a small keyring for download I tried to non-interactively delete all signatures off the keys sent in, except the self-signatures. I found no easy and quick solution for this, so I wrote a small patch that adds two commands to the key-edit menu. a) 'uidall' that selects all user ids in the key I would have implemented 'uid *' - but I have just limited C knowledge and was in a hurry to get the script done... b) 'delallsigs' that deletes all signatures on the key that are not self-signatures. I have also modified a helper function check_one_sig that does not print out anything on screen during the check - I am not interested in 300 signature-details scrolling by while deleting them... Maybe there are more people out there that need such funcionality, I don't know - but it is a good way to get a small pubkey for an export. I would be very happy if this functionality could be integrated into the official release - at least point b, point a should really work like "uid *"... The patch is available at: http://bilge.fb12.tu-berlin.de/~mutax/ cheers, Florian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCkjYpO46kH4L2EkARAqJKAJ9b8Flrnp5mYixPdRhD/XeqLiM/6wCfW2I+ 4YNGodsuk6weKzMFlFGCocY= =4pJi -----END PGP SIGNATURE----- From wk at gnupg.org Tue May 24 09:48:22 2005 From: wk at gnupg.org (Werner Koch) Date: Tue May 24 09:46:03 2005 Subject: 1.4.1: patch to delete all non self-signatures In-Reply-To: <4292362B.6080403@F-Streibelt.de> (Florian Streibelt's message of "Mon, 23 May 2005 21:59:39 +0200") References: <4292362B.6080403@F-Streibelt.de> Message-ID: <87sm0duks9.fsf@wheatstone.g10code.de> On Mon, 23 May 2005 21:59:39 +0200, Florian Streibelt said: > I would be very happy if this functionality could be integrated into the > official release - at least point b, point a should really work like "uid *"... I have not looked at it but the proper way to handle this is by using export options to exclude certain signatures from the output. Thanks, Werner From M.Lutzer at gmx.de Sat May 21 12:29:13 2005 From: M.Lutzer at gmx.de (Jan) Date: Tue May 24 12:59:20 2005 Subject: incompatibility with PGP 8.1? Message-ID: <428F0D79.1020200@gmx.de> I retrieved a mail which was encrypted by PGP 8.1. GnuPG was not able to decrypt it. The mail looked like this: -----BEGIN PGP MESSAGE----- Version: PGP 8.1 - nicht f?r kommerzielle Nutzung lizenziert: www.pgp.com qANQR1DBwE4D2qSkrGK7WCsQBAC/dchXqpHqcgJ5L6qZy4O4nrU3psI50zcVS4SN [...some more lines...] -----END PGP MESSAGE----- To be able to decrypt the mail I had to remove the third line: -----BEGIN PGP MESSAGE----- Version: PGP 8.1 - nicht f?r kommerzielle Nutzung lizenziert: qANQR1DBwE4D2qSkrGK7WCsQBAC/dchXqpHqcgJ5L6qZy4O4nrU3psI50zcVS4SN [...some more lines...] -----END PGP MESSAGE----- Maybe PGP is not standard compliant but anyway it would be great to decrypt PGP messages. Best regards, Jan From kg at office.fsfeurope.org Mon May 23 16:35:39 2005 From: kg at office.fsfeurope.org (Karsten Gerloff) Date: Tue May 24 12:59:23 2005 Subject: smartcard use with sylpheed-claws In-Reply-To: <87ekbyxqd1.fsf@wheatstone.g10code.de> References: <20050519164110.5cc0c424@gerloffium.fsfeurope.org> <87ekbyxqd1.fsf@wheatstone.g10code.de> Message-ID: <20050523163539.7aabc3fb@gerloffium.fsfeurope.org> On Mon, 23 May 2005 11:07:22 +0200 Werner Koch wrote: > On Thu, 19 May 2005 16:41:10 +0200, Karsten Gerloff said: > > > The problem seems to be that the PIN request is not working; > > sylpheed-claws simply does not ask for a PIN at the point where it > [...] > > Use gpg-agent. There should be a Debian package for it. Unfortunately, this is not working. Sylpheed-claws calls up the GPG agent just fine - as long as there are no keys on the card (I am using my card for subkeys). If there are keys on the card, sylpheed-claws acts like it does when the wrong passphrase is entered (it displays a catch-all error message). How do you think this can be solved? Best regards Karsten -- Karsten Gerloff Free Software Foundation Europe (http://www.fsfeurope.org) Office t. ++49-700-FSFEUROPE Join the Fellowship and protect your Freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050523/bb455081/attachment.pgp From patrick at mozilla-enigmail.org Tue May 24 11:34:46 2005 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Tue May 24 13:03:41 2005 Subject: Getting SmartCard key info Message-ID: Hello is there any way to find out if a secret key (or subkey) is on a smart card when using "gpg --with-colons --list-secret-keys" ? The thing is that gpg --list-secret-keys tells me the required card serial number, while I don't see anything in the --with-colons mode. -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050524/2a4c27d9/signature.pgp From wk at gnupg.org Tue May 24 18:27:46 2005 From: wk at gnupg.org (Werner Koch) Date: Tue May 24 18:26:04 2005 Subject: Getting SmartCard key info In-Reply-To: (Patrick Brunschwig's message of "Tue, 24 May 2005 11:34:46 +0200") References: Message-ID: <871x7wsi65.fsf@wheatstone.g10code.de> On Tue, 24 May 2005 11:34:46 +0200, Patrick Brunschwig said: > The thing is that gpg --list-secret-keys tells me the required card > serial number, while I don't see anything in the --with-colons mode. I need to add this. Shalom-Salam, Werner From gnupg at F-Streibelt.de Tue May 24 20:32:38 2005 From: gnupg at F-Streibelt.de (Florian Streibelt) Date: Tue May 24 20:28:22 2005 Subject: 1.4.1: patch to delete all non self-signatures In-Reply-To: <87sm0duks9.fsf@wheatstone.g10code.de> References: <4292362B.6080403@F-Streibelt.de> <87sm0duks9.fsf@wheatstone.g10code.de> Message-ID: <42937346.8010902@F-Streibelt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, okay - then sorry for that - I have overseen export-minimal in the man-page :( - but googled some hours - obviously using the wrong keywords. Florian Werner Koch schrieb: > On Mon, 23 May 2005 21:59:39 +0200, Florian Streibelt said: > > >>I would be very happy if this functionality could be integrated into the >>official release - at least point b, point a should really work like "uid *"... > > > I have not looked at it but the proper way to handle this is by using > export options to exclude certain signatures from the output. > > Thanks, > > Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCk3NDO46kH4L2EkARAlGeAKDWEKb22XrlPE5rbZ9PYe1ZUg0UuACfWBxZ ZXWxiDPhbubzMbQD6GXR5V0= =h7WC -----END PGP SIGNATURE----- From wk at gnupg.org Wed May 25 08:44:25 2005 From: wk at gnupg.org (Werner Koch) Date: Wed May 25 08:41:06 2005 Subject: incompatibility with PGP 8.1? In-Reply-To: <428F0D79.1020200@gmx.de> (M.Lutzer@gmx.de's message of "Sat, 21 May 2005 12:29:13 +0200") References: <428F0D79.1020200@gmx.de> Message-ID: <87k6lnreie.fsf@wheatstone.g10code.de> On Sat, 21 May 2005 12:29:13 +0200, Jan said: > -----BEGIN PGP MESSAGE----- > Version: PGP 8.1 - nicht f?r kommerzielle Nutzung lizenziert: > www.pgp.com That is a problem with the software used to send this mail. It did a line break where it should not. An OpenPGP header line consists of a keyword, a colon and the value. Your second line is not valid and thus gpg assumes that the message has been garbled. Salam-Shalom, Werner From wk at gnupg.org Wed May 25 08:46:58 2005 From: wk at gnupg.org (Werner Koch) Date: Wed May 25 08:46:02 2005 Subject: smartcard use with sylpheed-claws In-Reply-To: <20050523163539.7aabc3fb@gerloffium.fsfeurope.org> (Karsten Gerloff's message of "Mon, 23 May 2005 16:35:39 +0200") References: <20050519164110.5cc0c424@gerloffium.fsfeurope.org> <87ekbyxqd1.fsf@wheatstone.g10code.de> <20050523163539.7aabc3fb@gerloffium.fsfeurope.org> Message-ID: <87fywbree5.fsf@wheatstone.g10code.de> On Mon, 23 May 2005 16:35:39 +0200, Karsten Gerloff said: > my card for subkeys). If there are keys on the card, sylpheed-claws acts > like it does when the wrong passphrase is entered (it displays a > catch-all error message). How do you think this can be solved? Run Sylpheed as $ GPGME_DEBUG=5:/tmp/foo.log sylpheed and send me foo.log by private mail. Thanks, Werner From wk at gnupg.org Tue May 31 09:19:14 2005 From: wk at gnupg.org (Werner Koch) Date: Tue May 31 14:35:52 2005 Subject: Getting SmartCard key info In-Reply-To: (Patrick Brunschwig's message of "Tue, 24 May 2005 11:34:46 +0200") References: Message-ID: <8764wz7thp.fsf@wheatstone.g10code.de> On Tue, 24 May 2005 11:34:46 +0200, Patrick Brunschwig said: > Hello > is there any way to find out if a secret key (or subkey) is on a smart > card when using "gpg --with-colons --list-secret-keys" ? > The thing is that gpg --list-secret-keys tells me the required card > serial number, while I don't see anything in the --with-colons mode. Hmm, it works for me: $ gpg -K --fixed-list-mode --with-colons heine sec::1024:1:586B85BE114A05E1:1116949944::::::scESCA:::D2760001240101010001000003470000: uid:::::1116949944::6C83E6B54DD67DA7119882A92708B085B0324B23::Heinrich Heine : ssb::1024:1:7CF434FA0521AD19:1116949976::::::a:::D2760001240101010001000003470000: ssb::1024:1:2D1D6B157FE2DF37:1116950005::::::e:::D2760001240101010001000003470000: Note that this is the full AID and not just the serialno part. From doc/DETAILS: 15. Field Used in sec/sbb to print the serial number of a token (internal protect mode 1002) or a '#' if that key is a simple stub (internal protect mode 1001) --fixed-list-mode ist important and should in fact be used by all applications. It is available since version 1.0.5 and does not anymore merge the first UID with the PUB line. Salam-Shalom, Werner From wk at gnupg.org Tue May 31 14:27:33 2005 From: wk at gnupg.org (Werner Koch) Date: Tue May 31 14:55:25 2005 Subject: [Announce] First release candidate for GnuPG 1.4.2 available Message-ID: <873bs360ne.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From folkert at vanheusden.com Tue May 31 15:05:46 2005 From: folkert at vanheusden.com (Folkert van Heusden) Date: Tue May 31 15:01:25 2005 Subject: [Announce] First release candidate for GnuPG 1.4.2 available In-Reply-To: <873bs360ne.fsf@wheatstone.g10code.de> References: <873bs360ne.fsf@wheatstone.g10code.de> Message-ID: <20050531130544.GA30725@vanheusden.com> Hi, Does this version also include the more robust keyring handling? I'm talking about that problem where gpg would bail out if it encountered invalid key-data. On Tue, May 31, 2005 at 02:27:33PM +0200, Werner Koch wrote: > Hi! > > We are pleased to announce the availability of a release candidate for > the forthcoming 1.4.2 version of gnupg: > > ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.2rc1.tar.bz2 (2808k) > ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.2rc1.tar.bz2.sig > > A binary for MS Windows is not available because we did no MS Windows > specific changes. Expect such a binary with the next release > candidate in about 2 weeks. A diff file is also available but pretty > large (800k) due to the changed address of the FSF and updated > translations. > > Please try it out and report any problems to the gnupg-devel or > gnupg-users list (http://www.gnupg.org/documentation/mailing-lists.html). > > Checksums are: > > e6c2a39dd3cc4919698ae62c1b52abff0f3888b7 gnupg-1.4.2rc1.tar.bz2 > 7578be7d9e397781219e9e84bd20d22113e3329b gnupg-1.4.1-1.4.2rc1.diff.bz2 > > > Noteworthy changes since 1.4.1: > > * New command "verify" in the card-edit menu to display > the Private-DO-3. The Admin command has been enhanced to take > the optional arguments "on", "off" and "verify". The latter may > be used to verify the Admin Pin without modifying data; this > allows displaying the Private-DO-4 with the "list" command. > > * Rewrote large parts of the card code to optionally make use of a > running gpg-agent. If --use-agent is being used and a gpg-agent > with enabled scdaemon is active, gpg will now divert all card > operations to that daemon. This is required because both, > scdaemon and gpg require exclusive access to the card reader. By > delegating the work to scdaemon, both can peacefully coexist and > scdaemon is able to control the use of the reader. Note that > this requires at least gnupg 1.9.17. > > * Fixed a couple of problems with the card reader. > > * Command completion is now available in the --edit-key and > --card-edit menus. Filename completion is available at all > filename prompts. Note that completion is only available if the > system provides a readline library. > > * New experimental HKP keyserver helper that uses the cURL > library. It is enabled via the configure option --with-libcurl > like the other (also experimental) cURL helpers. > > > > Happy Hacking, > > David, Timo, Werner > > > -- > Werner Koch > The GnuPG Experts http://g10code.com > Free Software Foundation Europe http://fsfeurope.org > Join the Fellowship and protect your Freedom! http://www.fsfe.org > _______________________________________________ > Gnupg-announce mailing list > Gnupg-announce@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-announce > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel Folkert van Heusden -- Auto te koop, zie: http://www.vanheusden.com/daihatsu.php Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden. -------------------------------------------------------------------- UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) a try, it brings monitoring logfiles to a different level! See http://vanheusden.com/multitail/features.html for a feature-list. -------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.com! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 282 bytes Desc: Digital signature Url : /pipermail/attachments/20050531/1b71344d/attachment.pgp From wk at gnupg.org Tue May 31 15:37:24 2005 From: wk at gnupg.org (Werner Koch) Date: Tue May 31 15:35:58 2005 Subject: [Announce] First release candidate for GnuPG 1.4.2 available In-Reply-To: <20050531130544.GA30725@vanheusden.com> (Folkert van Heusden's message of "Tue, 31 May 2005 15:05:46 +0200") References: <873bs360ne.fsf@wheatstone.g10code.de> <20050531130544.GA30725@vanheusden.com> Message-ID: <87fyw34iuj.fsf@wheatstone.g10code.de> On Tue, 31 May 2005 15:05:46 +0200, Folkert van Heusden said: > Does this version also include the more robust keyring handling? I'm > talking about that problem where gpg would bail out if it encountered > invalid key-data. You mean the "MPI crosses packet boundary"? Yes, this will skip the key now. Shalom-Salam, Werner From beebe at math.utah.edu Tue May 31 18:38:14 2005 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue May 31 21:04:33 2005 Subject: gnupg-1.4.2rc1 build feedback: standards conformance Message-ID: For several years, Sun Solaris has had a section in "man 5 standards" on the conformance to various language and O/S interface standards. At Solaris 10, there are 13 separate specifications, but until recently, I've not had the machine resources to do builds in each one of them. That situation changed last week, and I've just done that for the gnupg-1.4.2rc1 test release. The more conformant that software is to standards, the more likely it is to be easily ported to new platforms. Here is a snippet of the end of "man 5 standards" on Solaris 10: >> ... >> Specification Compiler/Flags Feature Test Macros >> 1989 ANSI C and 1990 ISO C c89 none >> 1999 ISO C c99 none >> SVID3 cc -Xt -xc99=none none >> POSIX.1-1990 c89 _POSIX_SOURCE >> POSIX.1-1990 and c89 _POSIX_SOURCE and >> POSIX.2-1992 POSIX_C_SOURCE=2 >> C-Language >> Bindings Option >> POSIX.1b-1993 c89 _POSIX_C_SOURCE=199309L >> POSIX.1c-1996 c89 _POSIX_C_SOURCE=199506L >> POSIX.1-2001 c99 _POSIX_C_SOURCE=200112L >> POSIX.1c-1996 c89 _POSIX_C_SOURCE=199506L >> CAE XPG3 cc -Xa -xc99=none _XOPEN_SOURCE >> >> CAE XPG4 c89 _XOPEN_SOURCE and >> _XOPEN_VERSION=4 >> SUS (CAE XPG4v2) c89 _XOPEN_SOURCE and >> (includes XNS4) _XOPEN_SOURCE_EXTENDED=1 >> SUSv2 (includes XNS5) c89 _XOPEN_SOURCE=500 >> SUSv3 c99 _XOPEN_SOURCE=600 >> >> For platforms supporting the LP64 (64-bit) programming environment, >> SUSv2-conforming LP64 applications using XNS5 library calls should be >> built with command lines of the form: >> >> c89 $(getconf XBS5_LP64_OFF64_CFLAGS) -D_XOPEN_SOURCE=500 \ >> $(getconf XBS5_LP64_OFF64_LDFLAGS) foo.c -o foo \ >> $(getconf XBS5_LP64_OFF64_LIBS) -lxnet >> >> Similar SUSv3-conforming LP64 applications should be built with command >> lines of the form: >> >> c99 $(getconf POSIX_V6_LP64_OFF64_CFLAGS) -D_XOPEN_SOURCE=600 \ >> $(getconf POSIX_V6_LP64_OFF64_LDFLAGS) foo.c -o foo \ >> $(getconf POSIX_V6_LP64_OFF64_LIBS) -lxnet >> ... Notice that the POSIX.1c-1996 line is duplicated, so there are 13, not 14, levels. To these, I added the two 64-bit flavors, replacing the getconf calls with their actual returned strings. Of the 15 builds on Solaris 10 SPARC, seven passed all of the tests, and eight failed, most from the same cause. There are also several type mismatch warnings; I summarize them below. ============================================================ Machinetype: Sun Ultra Enterprise 450/400 (4 CPUs, 400 MHz UltraSPARC II, 4GB); Solaris 10 Remote c89 version: cc: Sun C 5.7 Patch 117836-02 2005/03/23 Remote c99 version: cc: Sun C 5.7 Patch 117836-02 2005/03/23 Remote cc version: cc: Sun C 5.7 Patch 117836-02 2005/03/23 Remote CC version: CC: Sun C++ 5.7 Patch 117830-02 2005/03/30 Remote gcc version: gcc (GCC) 3.3 Remote g++ version: g++ (GCC) 3.3 Configure environment: CC=/opt/SUNWspro/bin/c89 CFLAGS="-D_POSIX_SOURCE -I/usr/local/include" CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-I/usr/local/include" LDFLAGS="-R/usr/local/lib -L/usr/local/lib" /opt/SUNWspro/bin/c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../intl -I/usr/local/include -D_POSIX_SOURCE -I/usr/local/include -c miscutil.c "miscutil.c", line 255: warning: argument #1 is incompatible with prototype: prototype: pointer to const char : "../include/util.h", line 193 argument : pointer to const unsigned char /opt/SUNWspro/bin/c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../intl -I/usr/local/include -D_POSIX_SOURCE -I/usr/local/include -c strgutil.c "strgutil.c", line 291: warning: assignment type mismatch: pointer to const unsigned char "=" pointer to const char "strgutil.c", line 291: warning: assignment type mismatch: pointer to const unsigned char "=" pointer to const char "strgutil.c", line 293: warning: assignment type mismatch: pointer to const char "=" pointer to const unsigned char "strgutil.c", line 298: warning: assignment type mismatch: pointer to const unsigned char "=" pointer to const char "strgutil.c", line 298: warning: assignment type mismatch: pointer to const unsigned char "=" pointer to const char "strgutil.c", line 310: warning: assignment type mismatch: pointer to const unsigned char "=" pointer to const char "strgutil.c", line 310: warning: assignment type mismatch: pointer to const unsigned char "=" pointer to const char "strgutil.c", line 312: warning: assignment type mismatch: pointer to const char "=" pointer to const unsigned char "strgutil.c", line 317: warning: assignment type mismatch: pointer to const unsigned char "=" pointer to const char "strgutil.c", line 317: warning: assignment type mismatch: pointer to const unsigned char "=" pointer to const char "strgutil.c", line 685: warning: assignment type mismatch: pointer to const unsigned char "=" pointer to const char "strgutil.c", line 692: warning: assignment type mismatch: pointer to unsigned char "=" pointer to char "strgutil.c", line 692: warning: assignment type mismatch: pointer to const unsigned char "=" pointer to const char "strgutil.c", line 719: warning: assignment type mismatch: pointer to const unsigned char "=" pointer to const char "strgutil.c", line 808: warning: assignment type mismatch: pointer to const unsigned char "=" pointer to const char "strgutil.c", line 813: warning: argument #1 is incompatible with prototype: prototype: pointer to char : "/usr/include/iso/stdio_iso.h", line 210 argument : pointer to unsigned char "strgutil.c", line 839: warning: argument #1 is incompatible with prototype: prototype: pointer to char : "/usr/include/iso/stdio_iso.h", line 210 argument : pointer to unsigned char "strgutil.c", line 882: warning: argument #1 is incompatible with prototype: prototype: pointer to char : "/usr/include/iso/stdio_iso.h", line 210 argument : pointer to unsigned char "strgutil.c", line 892: warning: argument #1 is incompatible with prototype: prototype: pointer to char : "/usr/include/iso/stdio_iso.h", line 210 argument : pointer to unsigned char "strgutil.c", line 895: warning: argument #1 is incompatible with prototype: prototype: pointer to char : "/usr/include/iso/stdio_iso.h", line 210 argument : pointer to unsigned char "strgutil.c", line 952: warning: argument #1 is incompatible with prototype: prototype: pointer to char : "/usr/include/iso/stdio_iso.h", line 210 argument : pointer to unsigned char "strgutil.c", line 968: warning: argument #1 is incompatible with prototype: prototype: pointer to char : "/usr/include/iso/stdio_iso.h", line 210 argument : pointer to unsigned char "strgutil.c", line 1005: warning: assignment type mismatch: pointer to const char "=" pointer to unsigned char "strgutil.c", line 1040: warning: return value type mismatch source='ttyio.c' object='ttyio.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../scripts/depcomp \ /opt/SUNWspro/bin/c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../intl -I/usr/local/include -D_POSIX_SOURCE -I/usr/local/include -c ttyio.c "ttyio.c", line 105: warning: improper pointer/integer combination: op "=" "ttyio.c", line 354: warning: argument #1 is incompatible with prototype: prototype: pointer to const char : "../include/util.h", line 193 argument : pointer to const unsigned char /opt/SUNWspro/bin/c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../intl -I/usr/local/include -D_POSIX_SOURCE -I/usr/local/include -c memory.c argparse.c", line 869: warning: argument #1 is incompatible with prototype: prototype: pointer to const char : "/usr/include/iso/stdio_iso.h", line 222 argument : pointer to const unsigned char /opt/SUNWspro/bin/c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../intl -I/usr/local/include -D_POSIX_SOURCE -I/usr/local/include -c iobuf.c "iobuf.c", line 630: warning: assignment type mismatch: pointer to char "=" pointer to unsigned char "iobuf.c", line 709: warning: argument #2 is incompatible with prototype: prototype: pointer to unsigned char : "../include/iobuf.h", line 115 argument : pointer to char "iobuf.c", line 740: warning: assignment type mismatch: pointer to char "=" pointer to unsigned char "iobuf.c", line 755: warning: argument #2 is incompatible with prototype: prototype: pointer to unsigned char : "../include/iobuf.h", line 120 argument : pointer to char "iobuf.c", line 762: warning: argument #2 is incompatible with prototype: prototype: pointer to unsigned char : "../include/iobuf.h", line 120 argument : pointer to char "iobuf.c", line 828: warning: argument #2 is incompatible with prototype: prototype: pointer to unsigned char : "../include/iobuf.h", line 120 argument : pointer to char "iobuf.c", line 1592: warning: assignment type mismatch: pointer to unsigned char "=" pointer to char "iobuf.c", line 2079: warning: assignment type mismatch: pointer to char "=" pointer to unsigned char "iobuf.c", line 2088: warning: assignment type mismatch: pointer to unsigned char "=" pointer to char "iobuf.c", line 2108: warning: assignment type mismatch: pointer to unsigned char "=" pointer to char /opt/SUNWspro/bin/c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../intl -I/usr/local/include -D_POSIX_SOURCE -I/usr/local/include -c dotlock.c "dotlock.c", line 328: incomplete struct/union/enum timeval: tv "dotlock.c", line 334: undefined struct/union member: tv_sec "dotlock.c", line 335: undefined struct/union member: tv_usec c89: acomp failed for dotlock.c ============================================================ Configure environment: CC=/opt/SUNWspro/bin/c89 CFLAGS="-D_POSIX_SOURCE -D_POSIX_C_SOURCE=2 -I/usr/local/include" CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-I/usr/local/include" LDFLAGS="-R/usr/local/lib -L/usr/local/lib" /opt/SUNWspro/bin/c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../intl -I/usr/local/include -D_POSIX_SOURCE -D_POSIX_C_SOURCE=2 -I/usr/local/include -c dotlock.c "dotlock.c", line 328: incomplete struct/union/enum timeval: tv ============================================================ Configure environment: CC=/opt/SUNWspro/bin/c89 CFLAGS="-D_POSIX_C_SOURCE=199309L -I/usr/local/include" CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-I/usr/local/include" LDFLAGS="-R/usr/local/lib -L/usr/local/lib" /opt/SUNWspro/bin/c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../intl -I/usr/local/include -D_POSIX_C_SOURCE=199309L -I/usr/local/include -c dotlock.c 2108: warning: assignment type mismatch: pointer to unsigned char "=" pointer to char "dotlock.c", line 328: incomplete struct/union/enum timeval: tv "dotlock.c", line 334: improper member use: tv_sec "dotlock.c", line 335: undefined struct/union member: tv_usec c89: acomp failed for dotlock.c ============================================================ Configure environment: CC=/opt/SUNWspro/bin/c89 CFLAGS="-D_POSIX_C_SOURCE=199506L -I/usr/local/include" CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-I/usr/local/include" LDFLAGS="-R/usr/local/lib -L/usr/local/lib" /opt/SUNWspro/bin/c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../intl -I/usr/local/include -D_POSIX_C_SOURCE=199506L -I/usr/local/include -c dotlock.c "dotlock.c", line 328: make[2]: Leaving directory `/local/build/posix.1c-1996/gnupg-1.4.2rc1/util' ============================================================ Configure environment: CC=/opt/SUNWspro/bin/cc CFLAGS="-Xa -xc99=none -D_XOPEN_SOURCE -I/usr/local/include" CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-I/usr/local/include" LDFLAGS="-R/usr/local/lib -L/usr/local/lib" /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../intl -I/usr/local/include -Xa -xc99=none -D_XOPEN_SOURCE -I/usr/local/include -c dotlock.c "dotlock.c", line 328: incomplete struct/union/enum timeval: tv "dotlock.c", line 334: undefined struct/union member: tv_sec "dotlock.c", line 335: undefined struct/union member: tv_usec ============================================================ Configure environment: CC=/opt/SUNWspro/bin/c89 CFLAGS="-D_XOPEN_SOURCE -D_XOPEN_VERSION=4 -I/usr/local/include" CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-I/usr/local/include" LDFLAGS="-R/usr/local/lib -L/usr/local/lib" /opt/SUNWspro/bin/c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../intl -I/usr/local/include -D_XOPEN_SOURCE -D_XOPEN_VERSION=4 -I/usr/local/include -c dotlock.c "dotlock.c", line 328: incomplete struct/union/enum timeval: tv "dotlock.c", line 334: undefined struct/union member: tv_sec "dotlock.c", line 335: undefined struct/union member: tv_usec c89: acomp failed for dotlock.c ============================================================ Configure environment: CC=/opt/SUNWspro/bin/c89 CFLAGS="-xarch=generic64 -D_XOPEN_SOURCE=500 -I/usr/local/include" CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-I/usr/local/include" LDFLAGS="-xarch=generic64 -R/usr/local/lib -L/usr/local/lib" /opt/SUNWspro/bin/c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -xarch=generic64 -D_XOPEN_SOURCE=500 -I/usr/local/include -c _mpih-add1.s /opt/SUNWspro/prod/bin/fbe: "_mpih-add1.s", line 59: error: detect global register use not covered .register pseudo-op /opt/SUNWspro/prod/bin/fbe: "_mpih-add1.s", line 62: error: detect global register use not covered .register pseudo-op ...many more such messages... ============================================================ Configure environment: CC=/opt/SUNWspro/bin/c99 CFLAGS="-xarch=generic64 -D_XOPEN_SOURCE=600 -I/usr/local/include" CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-I/usr/local/include" LDFLAGS="-xarch=generic64 -R/usr/local/lib -L/usr/local/lib" /opt/SUNWspro/bin/c99 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -xarch=generic64 -D_XOPEN_SOURCE=600 -I/usr/local/include -c _mpih-add1.s /opt/SUNWspro/prod/bin/fbe: "_mpih-add1.s", line 59: error: detect global register use not covered .register pseudo-op /opt/SUNWspro/prod/bin/fbe: "_mpih-add1.s", line 62: error: detect global register use not covered .register pseudo-op ...many more such messages... ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From beebe at math.utah.edu Tue May 31 18:24:09 2005 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue May 31 23:04:32 2005 Subject: gnupg-1.4.2rc1 build feedback Message-ID: I just did build attempts for gnupg-1.4.2rc1 in 21 build environments on that many flavors of Unix. Of them, 17 succeeded and reported "All 25 tests passed". Three of the four failures seem to have a common cause, and the other is specific to one platform: ============================================================ Machinetype: SGI Origin/200-4 (180 MHz) (4 CPUs); IRIX 6.5 Remote c89 version: MIPSpro Compilers: Version 7.3.1.3m Configure environment: CC=c89 CXX=CC CFLAGS=-I/usr/local/include CXXFLAGS=-I/usr/local/include LDFLAGS=-Wl,-rpath,/usr/local/libn32 c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../intl -I/usr/local/include -I/usr/local/include -c memrchr.c cc-3316 c89: ERROR File = memrchr.c, Line = 36 The expression must be a pointer to a complete object type. const unsigned char *start=s,*end=s+n-1; ^ ============================================================ Machinetype: DEC Alpha 4100-5/466 (4 21164 EV5 CPUs, 466 MHz, 2GB RAM); OSF/1 4.0F Remote cc version: DEC C V5.9-005 on Digital UNIX V4.0 (Rev. 1229) Configure environment: CC=cc CFLAGS="-ieee -I/usr/local/include" CXX=cxx CXXFLAGS="-ieee -I/usr/local/include" LDFLAGS="-Wl,-rpath,/usr/local/lib -Wl,-oldstyle_liblookup -L/usr/local/lib" FC=f77 F77=f77 cc -std1 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../intl -I/usr/local/include -ieee -I/usr/local/include -w -c memrchr.c cc: Error: memrchr.c, line 36: In the initializer for end, "s" and "n" cannot be added. (noadd) ============================================================ Machinetype: Sun Ultra Enterprise 450/400 (4 CPUs, 400 MHz); Solaris 7 Remote cc version: cc: WorkShop Compilers 5.0 98/12/15 C 5.0 Configure environment: CC=cc CFLAGS=-I/usr/local/include CXX=CC CXXFLAGS=-I/usr/local/include LDFLAGS="-R/usr/local/lib -L/usr/local/lib" cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../intl -I/usr/local/include -I/usr/local/include -c memrchr.c line 36: cannot do pointer arithmetic on operand of unknown size "memrchr.c", line 36: cannot do pointer arithmetic on operand of unknown size ============================================================ Machinetype: Compaq AlphaServer DS20 Sierra/667 (2 EV67 21264 CPUs, 667 MHz, 1MB RAM); OSF/1 5.1 Remote c89 version: Compaq C V6.3-028 on Compaq Tru64 UNIX V5.1 (Rev. 732) Configure environment: CC=c89 CFLAGS="-ieee -I$HOME/alpha/local/include" CXX=cxx CXXFLAGS="-ieee -I$HOME/alpha/local/include" LDFLAGS="-L$HOME/alpha/local/lib -Wl,-rpath,$HOME/alpha/local/lib -Wl,-oldstyle_liblookup" c89 -E -I.. -I../include -DHAVE_CONFIG_H mpih-mul1.S | grep -v '^#' > _mpih-mul1.s make: *** [mpih-mul1.o] Error 1 The problem here is that with a .S file, c89 does not run the preprocessor, so grep fails because it has no input. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From dshaw at jabberwocky.com Tue May 31 23:55:38 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Tue May 31 23:51:55 2005 Subject: gnupg-1.4.2rc1 build feedback In-Reply-To: References: Message-ID: <20050531215538.GB2783@jabberwocky.com> On Tue, May 31, 2005 at 10:24:09AM -0600, Nelson H. F. Beebe wrote: > I just did build attempts for gnupg-1.4.2rc1 in 21 build environments > on that many flavors of Unix. Of them, 17 succeeded and reported "All > 25 tests passed". Three of the four failures seem to have a common > cause, and the other is specific to one platform: Thanks for testing! Can you try this patch for the memrchr.c error? David -------------- next part -------------- Index: memrchr.c =================================================================== RCS file: /cvs/gnupg/gnupg/util/memrchr.c,v retrieving revision 1.2 diff -u -r1.2 memrchr.c --- memrchr.c 31 May 2005 08:38:45 -0000 1.2 +++ memrchr.c 31 May 2005 21:46:16 -0000 @@ -33,7 +33,9 @@ void * memrchr(const void *s, int c, size_t n) { - const unsigned char *start=s,*end=s+n-1; + const unsigned char *start=s,*end=s; + + end+=n-1; while(end>=start) { From ml_sergico at virgilio.it Tue May 31 10:30:21 2005 From: ml_sergico at virgilio.it (ml_sergico@virgilio.it) Date: Thu Jun 9 10:43:17 2005 Subject: c++ version of gpgme Message-ID: <4293BCE20000E4CD@ims5c.cp.tin.it> Dear all, I was searching around to find if there is some c++ implementation/wrapper of the gpgme library. Someone know of some project related. I read some on the mailing list archive but can't find any reference to the project code page... Thank's a lot Sergio From bogus@does.not.exist.com Tue May 31 14:33:46 2005 From: bogus@does.not.exist.com () Date: Sat Jul 2 06:56:33 2005 Subject: No subject Message-ID: granularity, so I imagine the same problems would persist, but thanks for pointing that out. > For a future version of the OpenPGP message format it might make sense > to change the the format to something like E_{KeyN}(K|X) with X being > the total number of keys used to encrypt the session key or better a > hash of all the public keys used. It seems the problem is that "Key-Privacy" was never defined for multiple recipients. Bellare et. al. orginally defined this notion. http://www-cse.ucsd.edu/users/mihir/papers/anonenc.html I have been talking about this with Adam Barth and Dan Boneh. I think the solution is to come up with a solution to a proper definition. I believe it should be pretty reasonable to do both. > Do you want to raise this problem with the OpenPGP WG? I think that would be a good place to go. I wanted to check my understanding of things over here first. I presume I should just shoot them an email like I did to you? Thanks again, Brent