From wk at gnupg.org Fri Jul 1 12:18:41 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Jul 1 12:16:21 2005 Subject: Possible chosen-ciphertext attack on receiver anonymity In-Reply-To: (Brent Waters's message of "Thu, 30 Jun 2005 10:16:01 -0700 (PDT)") References: Message-ID: <87d5q26d8e.fsf@wheatstone.g10code.de> On Thu, 30 Jun 2005 10:16:01 -0700 (PDT), Brent Waters said: > can tell if the other was the other receiver. Suppose Bob suspects > Alice was the other receiver. Then he can create a ciphertext: > (C1,C'')=E_{KeyAlice}(K)E_K(NewMessage) > and send this to Alice, if Alice responds to this in a meaningful way > she was the other receiver. NewMessage could be something simple like That is correct. The message or the session key K don't depend on the public keys used. It is trivial possible to add new E_{keyN}(K) to an OpenPGP message. A simple way for a client to avoid the attack is by keeeping a list of seen session keys; they should be random and thus a duplicated one will be suspicious. It is not really practical to implement such a feature. In fact the --throw-keyid feature is not intended to hide the keys between the set of recipients but to keep the recipients secret for outsiders. Its main use is with anonymous remailers: An implementation MAY accept or use a Key ID of zero as a "wild card" or "speculative" Key ID. In this case, the receiving implementation would try all available private keys, checking for a valid decrypted session key. This format helps reduce traffic analysis of messages. I know that some folks are using the --hidden-encrypt-to feature (to hide selected recipients) for their private archive copy of a mail. 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. Do you want to raise this problem with the OpenPGP WG? Salam-Shalom, Werner From bwaters at theory.Stanford.EDU Sat Jul 2 07:00:17 2005 From: bwaters at theory.Stanford.EDU (Brent Waters) Date: Sat Jul 2 06:56:32 2005 Subject: Possible chosen-ciphertext attack on receiver anonymity In-Reply-To: <87d5q26d8e.fsf@wheatstone.g10code.de> References: <87d5q26d8e.fsf@wheatstone.g10code.de> Message-ID: > A simple way for a client to avoid the attack is by keeeping a list of > seen session keys; they should be random and thus a duplicated one > will be suspicious. It is not really practical to implement such a > feature. > > In fact the --throw-keyid feature is not intended to hide the keys > between the set of recipients but to keep the recipients secret for > outsiders. Its main use is with anonymous remailers: Thanks for clarifying that. The context in which I was originally interested in this is when there are BCC recipients on encrypted email. In this case one wants the semantics that different BCC recipients cannot learn of each other. Also, it is not clear that just because two people can receieve the same message they should know each others' identities. > I know that some folks are using the --hidden-encrypt-to feature (to > hide selected recipients) for their private archive copy of a mail. From wk at gnupg.org Sat Jul 2 14:00:10 2005 From: wk at gnupg.org (Werner Koch) Date: Sat Jul 2 14:01:17 2005 Subject: Possible chosen-ciphertext attack on receiver anonymity In-Reply-To: (Brent Waters's message of "Fri, 1 Jul 2005 22:00:17 -0700 (PDT)") References: <87d5q26d8e.fsf@wheatstone.g10code.de> Message-ID: <873bqx1kqd.fsf@wheatstone.g10code.de> On Fri, 1 Jul 2005 22:00:17 -0700 (PDT), Brent Waters said: > Thanks for clarifying that. The context in which I was originally > interested in this is when there are BCC recipients on encrypted The usual way to handle this is by sending separate mails. Even with key-privacy the recipients would notice that there might be a BCCed address. IIRC, Mutt does exactly this. > 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. Fur other reasons (Mister/Zuccherato) a new way of encrypting message is anyway planned for the future. Adding key-privacy then won't be that problematic. > understanding of things over here first. I presume I should just shoot > them an email like I did to you? Yes. Shalom-Salam, Werner From messtic at oreka.com Sat Jul 2 19:28:42 2005 From: messtic at oreka.com (Alain Bench) Date: Sat Jul 2 20:47:00 2005 Subject: Possible chosen-ciphertext attack on receiver anonymity In-Reply-To: <873bqx1kqd.fsf@wheatstone.g10code.de> References: <87d5q26d8e.fsf@wheatstone.g10code.de> <873bqx1kqd.fsf@wheatstone.g10code.de> Message-ID: <20050702172841.GA11949@oreka.com> Hello Werner, On Saturday, July 2, 2005 at 2:00:10 PM +0200, Werner Koch wrote: > On Fri, 1 Jul 2005 22:00:17 -0700 (PDT), Brent Waters said: >> BCC recipients on encrypted email. > The usual way to handle this is by sending separate mails. Even with > key-privacy the recipients would notice that there might be a BCCed > address. IIRC, Mutt does exactly this. Unfortunately Mutt sends to all recipients, To, Cc, and Bcc, one common mail encrypted to all of them (plus eventually to Fcc outbox key). All recipients can see who was Bcced (and sender's storage key). This was reported as a privacy bug (see Mutt bug #1090), and there were discussions about sending one common mail to To+Cc plus one copy to each Bcc. But nothing changed so far. Bye! Alain. -- When you post a new message, beginning a new topic, use the "mail" or "post" or "new message" functions. When you reply or followup, use the "reply" or "followup" functions. Do not do the one for the other, this breaks or hijacks threads. From wk at gnupg.org Sat Jul 2 21:23:41 2005 From: wk at gnupg.org (Werner Koch) Date: Sat Jul 2 21:21:24 2005 Subject: Possible chosen-ciphertext attack on receiver anonymity In-Reply-To: <20050702172841.GA11949@oreka.com> (Alain Bench's message of "Sat, 02 Jul 2005 19:28:42 +0200 (CEST)") References: <87d5q26d8e.fsf@wheatstone.g10code.de> <873bqx1kqd.fsf@wheatstone.g10code.de> <20050702172841.GA11949@oreka.com> Message-ID: <87mzp5yptu.fsf@wheatstone.g10code.de> On Sat, 02 Jul 2005 19:28:42 +0200 (CEST), Alain Bench said: > This was reported as a privacy bug (see Mutt bug #1090), and there > were discussions about sending one common mail to To+Cc plus one copy to > each Bcc. But nothing changed so far. Thanks for the update. I only remembered that we had a long discussion quite some time ago and for some reasons I thought this was changed in Mutt. It is possible that this has been addressed in Kmail but I am not sure about this, either. Salam-Shalom, Werner From rpaulo at NetBSD.org Mon Jul 4 16:09:54 2005 From: rpaulo at NetBSD.org (Rui Paulo) Date: Mon Jul 4 17:05:57 2005 Subject: libgpgme.so problem when linked to libpthread Message-ID: <20050704140954.GA29479@neutron.internal.fnop.net> Hi, While investigating a supposed pthread problem under NetBSD with the help of Nathan Williams, he noticed that our pkg infrastructure, pkgsrc, is linking libgpgme.so with libpthread.so, event that should only happen with libgpgme-pthread.so. This causes the problem described under PR#30414 [1]. I'm new to gpgme code, but seems like if libgpgme.so isn't linked with pthread (which should be the correct way), ath_* calls get translated to no-ops or to their libc counterpart (recvmsg, sendmsg, etc). While there is a problem with pkgsrc, I would like to know your opinion about this problem, as it may happen under other systems or package infrastructures. Thanks in advance. [1] http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=30414 -- Rui Paulo From messtic at oreka.com Tue Jul 5 14:42:34 2005 From: messtic at oreka.com (Alain Bench) Date: Tue Jul 5 14:56:11 2005 Subject: Possible chosen-ciphertext attack on receiver anonymity In-Reply-To: <87mzp5yptu.fsf@wheatstone.g10code.de> References: <87d5q26d8e.fsf@wheatstone.g10code.de> <873bqx1kqd.fsf@wheatstone.g10code.de> <20050702172841.GA11949@oreka.com> <87mzp5yptu.fsf@wheatstone.g10code.de> Message-ID: <20050705124234.GB27586@oreka.com> On Saturday, July 2, 2005 at 9:23:41 PM +0200, Werner Koch wrote: > On Sat, 02 Jul 2005 19:28:42 +0200 (CEST), Alain Bench said: >> sending one common mail to To+Cc plus one copy to each Bcc. > this has been addressed in Kmail Confirmed, allegedly since 3 years. Bye! Alain. -- Mutt 1.2.5 users: Do us all a favour, set in_reply_to="%i" in muttrc, so threading is not messed up by silly mail servers. Everybody: Let's burn silly iPlanet mail servers. Dump ashes to trashcan. And void trashcan. From sworley at chkno.net Wed Jul 6 00:02:41 2005 From: sworley at chkno.net (Scott Worley) Date: Wed Jul 6 01:01:24 2005 Subject: noecho before prompt Message-ID: <55770.192.168.1.10.1120600961.squirrel@chkno.net> "Enter passphrase:" is a contract with the user. It means, "It's safe to type now." The attached patch ensures this condition. -------------- next part -------------- A non-text attachment was scrubbed... Name: noecho-before-prompt.patch Type: text/x-patch Size: 973 bytes Desc: not available Url : /pipermail/attachments/20050705/50d73a1e/noecho-before-prompt-0001.bin From sean.sieger at gmail.com Wed Jul 6 04:16:49 2005 From: sean.sieger at gmail.com (Sean Sieger) Date: Wed Jul 6 04:16:35 2005 Subject: CVS GnuPG Message-ID: <87vf3optke.fsf@gmail.com> I have tried installing GnuPG to no avail. Do you have a second to look at my log? -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log.gz Type: application/octet-stream Size: 18656 bytes Desc: config.log Url : /pipermail/attachments/20050705/5b3c5683/config.log.obj -------------- next part -------------- -- Sean Sieger From fw at deneb.enyo.de Wed Jul 6 16:37:08 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed Jul 6 17:18:10 2005 Subject: CAN-2005-2096 - zlib issue Message-ID: <87irzoj90r.fsf@deneb.enyo.de> FreeBSD has just released a security advisory regarding zlib: http://lists.freebsd.org/pipermail/freebsd-announce/2005-July/001009.html Patch is expected to appear under: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-05:16/zlib.patch You might want to update the bundled copy of zlib in GnuPG. From npcole at yahoo.co.uk Wed Jul 6 23:59:46 2005 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Thu Jul 7 00:55:46 2005 Subject: signatures, key ids etc. Message-ID: <20050706215946.94572.qmail@web25404.mail.ukl.yahoo.com> As I read 2440 (and the output of gpg), only the Key ID of the key that signed a key is stored with the signature. The chance of two keys with the same ID is lower than the chance of two with the same fingerprint, so I was wondering why the fingerprint was not stored. Is there any way that a user would be able to tell, in the theoretical case that two keys with the same ID were on his keyring, which had made a signature? Best, N. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com From dshaw at jabberwocky.com Thu Jul 7 23:40:22 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Jul 7 23:36:26 2005 Subject: CAN-2005-2096 - zlib issue In-Reply-To: <87irzoj90r.fsf@deneb.enyo.de> References: <87irzoj90r.fsf@deneb.enyo.de> Message-ID: <20050707214022.GD19854@jabberwocky.com> On Wed, Jul 06, 2005 at 04:37:08PM +0200, Florian Weimer wrote: > FreeBSD has just released a security advisory regarding zlib: > > http://lists.freebsd.org/pipermail/freebsd-announce/2005-July/001009.html > > Patch is expected to appear under: > > ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-05:16/zlib.patch > > You might want to update the bundled copy of zlib in GnuPG. The bundled zlib is GnuPG is 1.1.4. To my understanding, it is not vulnerable. The problem is only on zlib 1.2 and later. David From dshaw at jabberwocky.com Thu Jul 7 23:43:59 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Jul 7 23:39:58 2005 Subject: CVS GnuPG In-Reply-To: <87vf3optke.fsf@gmail.com> References: <87vf3optke.fsf@gmail.com> Message-ID: <20050707214359.GB20652@jabberwocky.com> On Tue, Jul 05, 2005 at 10:16:49PM -0400, Sean Sieger wrote: > I have tried installing GnuPG to no avail. > > Do you have a second to look at my log? Please define "to no avail". What did you do? What happened when you did it? The log doesn't show any of that. David From dshaw at jabberwocky.com Thu Jul 7 23:47:30 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Jul 7 23:43:32 2005 Subject: signatures, key ids etc. In-Reply-To: <20050706215946.94572.qmail@web25404.mail.ukl.yahoo.com> References: <20050706215946.94572.qmail@web25404.mail.ukl.yahoo.com> Message-ID: <20050707214730.GD20652@jabberwocky.com> On Wed, Jul 06, 2005 at 10:59:46PM +0100, Nicholas Cole wrote: > As I read 2440 (and the output of gpg), only the Key > ID of the key that signed a key is stored with the > signature. The chance of two keys with the same ID is > lower than the chance of two with the same > fingerprint, so I was wondering why the fingerprint > was not stored. History. Way back when, only the key ID was stored. > Is there any way that a user would be able to tell, in > the theoretical case that two keys with the same ID > were on his keyring, which had made a signature? Sure - it'll only verify correctly with one of them :) David From wk at gnupg.org Fri Jul 8 09:32:02 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Jul 8 09:31:07 2005 Subject: noecho before prompt In-Reply-To: <55770.192.168.1.10.1120600961.squirrel@chkno.net> (Scott Worley's message of "Tue, 5 Jul 2005 15:02:41 -0700 (PDT)") References: <55770.192.168.1.10.1120600961.squirrel@chkno.net> Message-ID: <87r7e9u51p.fsf@wheatstone.g10code.de> On Tue, 5 Jul 2005 15:02:41 -0700 (PDT), Scott Worley said: > "Enter passphrase:" is a contract with the user. It means, "It's safe > to type now." Would you mind to elaborate on the problem and the proposes solution? Salam-Shalom, Werner From berndj at prism.co.za Fri Jul 8 09:53:28 2005 From: berndj at prism.co.za (Bernd Jendrissek) Date: Fri Jul 8 10:27:27 2005 Subject: noecho before prompt In-Reply-To: <87r7e9u51p.fsf@wheatstone.g10code.de> References: <55770.192.168.1.10.1120600961.squirrel@chkno.net> <87r7e9u51p.fsf@wheatstone.g10code.de> Message-ID: <20050708075328.GI4759@prism.co.za> On Fri, Jul 08, 2005 at 09:32:02AM +0200, Werner Koch wrote: > On Tue, 5 Jul 2005 15:02:41 -0700 (PDT), Scott Worley said: > > "Enter passphrase:" is a contract with the user. It means, "It's > > safe to type now." > > Would you mind to elaborate on the problem and the proposes solution? Presumably the concern is that gpg may get scheduled out after showing the prompt, but before setting noecho, and that it may remain scheduled out for long enough for a user to type some characters, which the kernel dutifully echoes. Evil Eve happens to walk past, and sees that Alice's passphrase starts with "Bo", and suddenly it becomes feasible to crack her passphrase, and John (the password-cracking program, not another crypto actor! :) finds it in two months of CPU time instead of in 10 years. (Never mind that John would have found "Bob" in about 400 CPU cycles.) -- I have neither the need, the time, or the inclination to put words into your mouth. You are perfectly capable of damaging your reputation without any help from me. --Richard Heathfield roasts a troll in comp.lang.c From npcole at yahoo.co.uk Fri Jul 8 12:19:54 2005 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Fri Jul 8 12:15:54 2005 Subject: signatures, key ids etc. In-Reply-To: <20050707214730.GD20652@jabberwocky.com> Message-ID: <20050708101955.6247.qmail@web25408.mail.ukl.yahoo.com> --- David Shaw wrote: [snip] > > Is there any way that a user would be able to > tell, in > > the theoretical case that two keys with the same > ID > > were on his keyring, which had made a signature? > > Sure - it'll only verify correctly with one of them > :) :-) well indeed. But have also discovered via the source that --no-sigs-cache causes the fingerprint of the signing key to be given in the --with-colons output. :) Sorry to answer own question! Best, N. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com From patrick at mozilla-enigmail.org Fri Jul 8 18:55:39 2005 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Fri Jul 8 19:43:13 2005 Subject: Accessing gpgkeys_* fails on Windows Message-ID: <42CEB00B.9080101@mozilla-enigmail.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just noticed that gpg 1.4.2rc2 is not able to find gpgkeys_hkp.exe. I have installed GnuPG using the Windows installer, but to a non-default directory (E:\GnuPG\GnuPG). According to the debug log, gpg is looking for gpgkeys_hkp in c:\lib; but that directory doesn't exist: gpg: DBG: expanding string "c:\lib\gnupg\gpgkeys_hkp -o "%o" "%i"" I looked into the source code and I could imagine the reason to be DISABLE_KEYSERVER_PATH not being enabled. Is this correct? - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2rc2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCzrAI2KgHx8zsInsRAs1QAJ9vP92foClfMG2rcVQKOBRtbdfFjwCgvv98 p0u+tj/Buy/pPJaRL3QCzPI= =tkUD -----END PGP SIGNATURE----- From sworley at chkno.net Fri Jul 8 21:48:16 2005 From: sworley at chkno.net (Scott Worley) Date: Fri Jul 8 21:44:13 2005 Subject: noecho before prompt In-Reply-To: <20050708075328.GI4759@prism.co.za> References: <55770.192.168.1.10.1120600961.squirrel@chkno.net> <87r7e9u51p.fsf@wheatstone.g10code.de> <20050708075328.GI4759@prism.co.za> Message-ID: <54450.192.168.1.10.1120852096.squirrel@chkno.net> >>> "Enter passphrase:" is a contract with the user. It means, "It's >>> safe to type now." >> >> Would you mind to elaborate on the problem and the proposes solution? > > Presumably the concern is that gpg may get scheduled out after showing > the prompt, but before setting noecho, and that it may remain scheduled > out for long enough for a user to type some characters, which the kernel > dutifully echoes. Evil Eve happens to walk past, and sees that Alice's > passphrase starts with "Bo", and suddenly it becomes feasible to crack > her passphrase, and John (the password-cracking program, not another > crypto actor! :) finds it in two months of CPU time instead of in 10 > years. Also, consider the case where the user is not human. For example, expect (the tcl tool) can respond very quickly to the prompt and responds with the entire passphrase in one write(). One can argue that expect is not the ideal interface to gpg. From dshaw at jabberwocky.com Sat Jul 9 00:01:25 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Jul 8 23:57:39 2005 Subject: Accessing gpgkeys_* fails on Windows In-Reply-To: <42CEB00B.9080101@mozilla-enigmail.org> References: <42CEB00B.9080101@mozilla-enigmail.org> Message-ID: <20050708220125.GE23974@jabberwocky.com> On Fri, Jul 08, 2005 at 06:55:39PM +0200, Patrick Brunschwig wrote: > I just noticed that gpg 1.4.2rc2 is not able to find gpgkeys_hkp.exe. I > have installed GnuPG using the Windows installer, but to a non-default > directory (E:\GnuPG\GnuPG). > According to the debug log, gpg is looking for gpgkeys_hkp in c:\lib; > but that directory doesn't exist: > gpg: DBG: expanding string "c:\lib\gnupg\gpgkeys_hkp -o "%o" "%i"" > > I looked into the source code and I could imagine the reason to be > DISABLE_KEYSERVER_PATH not being enabled. Is this correct? This is an interesting situation. The code was compiled with one path, but installed under a different one. What happens if you stick "exec-path e:\GnuPG\GnuPG" in your gpg.conf file? David From patrick at mozilla-enigmail.org Sat Jul 9 12:49:31 2005 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Sat Jul 9 12:45:38 2005 Subject: Accessing gpgkeys_* fails on Windows In-Reply-To: <20050708220125.GE23974__37719.4916749888$1120860296$gmane$org@jabberwocky.com> References: <42CEB00B.9080101@mozilla-enigmail.org> <20050708220125.GE23974__37719.4916749888$1120860296$gmane$org@jabberwocky.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw wrote: > On Fri, Jul 08, 2005 at 06:55:39PM +0200, Patrick Brunschwig wrote: > >>I just noticed that gpg 1.4.2rc2 is not able to find gpgkeys_hkp.exe. I >>have installed GnuPG using the Windows installer, but to a non-default >>directory (E:\GnuPG\GnuPG). >>According to the debug log, gpg is looking for gpgkeys_hkp in c:\lib; >>but that directory doesn't exist: >>gpg: DBG: expanding string "c:\lib\gnupg\gpgkeys_hkp -o "%o" "%i"" >> >>I looked into the source code and I could imagine the reason to be >>DISABLE_KEYSERVER_PATH not being enabled. Is this correct? > > > This is an interesting situation. The code was compiled with one > path, but installed under a different one. > > What happens if you stick "exec-path e:\GnuPG\GnuPG" in your gpg.conf > file? In this case, gpgkeys_* is found correctly. - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2rc2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCz6u72KgHx8zsInsRAiPvAKDibmnMfcQxyRzUpHVJp0XNC/FHtQCbBSH7 ZJHoj/Zi+JQx3rm13PHgD4Q= =f3ob -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Sat Jul 9 22:09:06 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Sat Jul 9 22:05:20 2005 Subject: Accessing gpgkeys_* fails on Windows In-Reply-To: References: <42CEB00B.9080101@mozilla-enigmail.org> <20050708220125.GE23974__37719.4916749888$1120860296$gmane$org@jabberwocky.com> Message-ID: <20050709200906.GB24250@jabberwocky.com> On Sat, Jul 09, 2005 at 12:49:31PM +0200, Patrick Brunschwig wrote: > David Shaw wrote: > > On Fri, Jul 08, 2005 at 06:55:39PM +0200, Patrick Brunschwig wrote: > > > >>I just noticed that gpg 1.4.2rc2 is not able to find gpgkeys_hkp.exe. I > >>have installed GnuPG using the Windows installer, but to a non-default > >>directory (E:\GnuPG\GnuPG). > >>According to the debug log, gpg is looking for gpgkeys_hkp in c:\lib; > >>but that directory doesn't exist: > >>gpg: DBG: expanding string "c:\lib\gnupg\gpgkeys_hkp -o "%o" "%i"" > >> > >>I looked into the source code and I could imagine the reason to be > >>DISABLE_KEYSERVER_PATH not being enabled. Is this correct? > > > > > > This is an interesting situation. The code was compiled with one > > path, but installed under a different one. > > > > What happens if you stick "exec-path e:\GnuPG\GnuPG" in your gpg.conf > > file? > > In this case, gpgkeys_* is found correctly. Good. I'm not sure what the best answer for this is. GPG needs to know what the path is to the gpgkeys_* programs since they may not be in your $PATH. Unfortunately, by installing it in a different directory, the default path no longer points to the right place. Perhaps the right answer is to have the Windows installer append the "exec-path" to the gpg.conf file at install time for people who don't put GPG in the default place. David From fw at deneb.enyo.de Sun Jul 10 23:54:54 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun Jul 10 23:50:37 2005 Subject: CAN-2005-2096 - zlib issue In-Reply-To: <20050707214022.GD19854@jabberwocky.com> (David Shaw's message of "Thu, 7 Jul 2005 17:40:22 -0400") References: <87irzoj90r.fsf@deneb.enyo.de> <20050707214022.GD19854@jabberwocky.com> Message-ID: <87y88etjgx.fsf@deneb.enyo.de> * David Shaw: > The bundled zlib is GnuPG is 1.1.4. To my understanding, it is not > vulnerable. The problem is only on zlib 1.2 and later. Thanks for looking into this. I should have checked the version of the included copy; sorry for the noise. From marcus.brinkmann at ruhr-uni-bochum.de Mon Jul 11 15:07:43 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Jul 11 15:04:44 2005 Subject: libgpgme.so problem when linked to libpthread In-Reply-To: <20050704140954.GA29479@neutron.internal.fnop.net> References: <20050704140954.GA29479@neutron.internal.fnop.net> Message-ID: <87hdf17aow.wl@ulysses.g10code.de> At Mon, 4 Jul 2005 15:09:54 +0100, Rui Paulo wrote: > While investigating a supposed pthread problem under NetBSD with the > help of Nathan Williams, he noticed that our pkg infrastructure, pkgsrc, > is linking libgpgme.so with libpthread.so, event that should only > happen with libgpgme-pthread.so. > > This causes the problem described under PR#30414 [1]. > > I'm new to gpgme code, but seems like if libgpgme.so isn't linked with > pthread (which should be the correct way), ath_* calls get translated to > no-ops or to their libc counterpart (recvmsg, sendmsg, etc). > While there is a problem with pkgsrc, I would like to know your opinion > about this problem, as it may happen under other systems or package > infrastructures. There are two sides to this issue. The correct way is to link against gpgme-pthread if you are using pthread, and against gpgme, if you are not. Assuming that you don't link libgpgme against pthread, this should fix all the problems you see. The other issue is why it fails in the way it does, and this is more complicated. There is some backwards-compatibility support in GPGME, which allows pthread-using programs to just link against libgpgme, and it should work. This is done with weak symbols. However, this requires that you get the linking order right, and probably some other things. I have another report that it breaks on GNU/Hurd, so maybe it only works on GNU/Linux. If you check the GPGME NEWS file, you will see that this legacy support is obsoleted and deprecated, and will be removed. I could do this in the next release. However, this would not help much: You would use a non-thread safe GPGME in a threaded application, calling for even more subtle and difficult to understand bugs than the one you were seeing. I hope this information helps you. I don't know what pkgsrc does to get libgpgme linked with pthread. This is definitely bogus. It is correct that only libgpgme-pthread should be directly linked with pthread. Thanks, Marcus From mail at joachim-breitner.de Fri Jul 15 12:33:51 2005 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri Jul 15 13:37:12 2005 Subject: PIN caching with gnupg-1.4.2-rc2 and gpg-agent 1.9.17 Message-ID: <1121423631.10696.4.camel@localhost.localdomain> Hi, I just installed the newest versios of gnupg and gpg-agent. When I sign a file with gnupg, daemon running, no scdaemon, it seems as if gnupg asks the agent to ask me for the pin, but talks itself to the card. When I repeat that, the agent obviously has already cached the PIN and I don't have to enter it again. So far so good. When I do enable scdaemon (using pcscd), signing works as well, but the PIN does not seem to be cached: I have to enter it again. Also, with scdaemon, there might be problems with other programs using the smartcard, e.g. HBCI, but also libpam-poldi. Haven't investigated that though. A different issue: If the card is not inserted, gpg will ask to insert the card on the prompt, expecting a keypress. This breaks usage with e.g. evolution. IMHO, gnupg should just wait for the card to be inserted, or for some timeout to run out, but not require user interaction on the console. If user interaction, then via the gpg-daemon, just like PIN entries. I'm using it now without the scdaemon, otherwise everythings seems to be ok, 'though I have not put thorough testing in it yet. Greetings from DebConf, Helsinki, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: joachimbreitner@amessage.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 310 bytes Desc: This is a digitally signed message part Url : /pipermail/attachments/20050715/14c529ca/attachment.pgp From mail at joachim-breitner.de Fri Jul 15 15:12:54 2005 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri Jul 15 15:15:15 2005 Subject: More agent problems Message-ID: <1121433174.10882.3.camel@localhost.localdomain> Hi, when I have the daemon running, used my PIN already, so that it is cached, and I want to change the card PIN, it seems that the daemon is answering the "New PIN?" question for me - with my old PIN, thus giving me after entering the new PIN once a "PINs do not match" error. IMHO, the daemons cache should not be used when doing --card-edit, but it is still nice to have the daemon use pinentry to get the pins. Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: joachimbreitner@amessage.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 310 bytes Desc: This is a digitally signed message part Url : /pipermail/attachments/20050715/507ac6b6/attachment.pgp From mail at joachim-breitner.de Fri Jul 15 15:24:36 2005 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri Jul 15 15:28:58 2005 Subject: And while I'm at it: no_sync not implemented? Message-ID: <1121433876.10882.6.camel@localhost.localdomain> Hi, last thing for now: Is no_sync not yet implemented? At least I can't find anything in the code indicating that, only code to read the flag. Any chance that that feature makes make it into 1.4.2 Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 310 bytes Desc: This is a digitally signed message part Url : /pipermail/attachments/20050715/804aad9f/attachment.pgp From dshaw at jabberwocky.com Fri Jul 15 15:43:46 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Jul 15 16:41:02 2005 Subject: CAN-2005-2096 - zlib issue In-Reply-To: <87y88etjgx.fsf@deneb.enyo.de> References: <87irzoj90r.fsf@deneb.enyo.de> <20050707214022.GD19854@jabberwocky.com> <87y88etjgx.fsf@deneb.enyo.de> Message-ID: <20050715134346.GA11191@jabberwocky.com> On Sun, Jul 10, 2005 at 11:54:54PM +0200, Florian Weimer wrote: > * David Shaw: > > > The bundled zlib is GnuPG is 1.1.4. To my understanding, it is not > > vulnerable. The problem is only on zlib 1.2 and later. > > Thanks for looking into this. I should have checked the version of > the included copy; sorry for the noise. I'm glad you posted. I had checked zlib, but a second look to double check (particularly on a security problem) is always good. Plus, it got the information to the mailing list, which I had neglected to do :) David From radus at smartpost.ro Fri Jul 15 17:23:07 2005 From: radus at smartpost.ro (Radu Spineanu) Date: Fri Jul 15 17:54:19 2005 Subject: gpgme and static keys Message-ID: <42D7D4DB.3060002@smartpost.ro> Hello I want to create a program (using gpgme) that encrypts small ammounts of data using a static public key. I read the documentation and all i found were examples using local keyrings, however that's too much for what i need. The user should dump his public key in a directory, and the program would detect it and use that to encrypt the data, without importing it. Is something like this possible ? Thanks, Radu From marcus.brinkmann at ruhr-uni-bochum.de Sun Jul 17 14:34:05 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sun Jul 17 15:12:19 2005 Subject: gpgme and static keys In-Reply-To: <42D7D4DB.3060002@smartpost.ro> References: <42D7D4DB.3060002@smartpost.ro> Message-ID: <873bqdoblu.wl@ulysses.g10code.de> At Fri, 15 Jul 2005 18:23:07 +0300, Radu Spineanu wrote: > I want to create a program (using gpgme) that encrypts small ammounts of > data using a static public key. > > I read the documentation and all i found were examples using local > keyrings, however that's too much for what i need. > > The user should dump his public key in a directory, and the program > would detect it and use that to encrypt the data, without importing it. > > Is something like this possible ? No. But you can create a new temporary home directory for gnupg (like the user's .gnupg directory), reconfigure the engine with gpgme_set_engine (only available in the CVS version of GPGME), and then import the key. After you are done using this configuration, you could clear the temporary home directory. Of course, this is not particularly efficient, so if you have lots of operations, you probably want to keep the home directory around. Thanks, Marcus From dragonheart at gentoo.org Sat Jul 2 04:25:00 2005 From: dragonheart at gentoo.org (Daniel) Date: Mon Jul 18 17:33:54 2005 Subject: gnupg-1.4.1 compile failure when homedir is faked. Message-ID: <200507021027.21805.dragonheart@gentoo.org> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050702/d5d366fc/attachment-0001.pgp From bryce at bnichols.org Mon Jul 11 20:08:53 2005 From: bryce at bnichols.org (Bryce Nichols) Date: Mon Jul 18 17:33:58 2005 Subject: verifying signatures when GNUPGHOME is on a read-only filesystem Message-ID: I would like to use gnupg to verify signatures when $GNUPGHOME is on a read-only filesystem. Using --lock-never and --no-auto-check-trustdb allows this except that the code that opens the trust database (in the file ${GNUPGHOME}/trustdb.gpg typically) will conclude it's a fatal error if the file cannot be opened read-write, unless the errorcode was only EACCES. Therefore, to make this work for my situation (where the errorcode is EROFS), I've applied the following patch to the 1.4.1 version of GnuPG: diff -ur gnupg-1.4.1/g10/tdbio.c gnupg-1.4.1.new/g10/tdbio.c --- gnupg-1.4.1/g10/tdbio.c 2004-10-14 03:11:56.000000000 -0400 +++ gnupg-1.4.1.new/g10/tdbio.c 2005-07-11 13:24:57.000000000 -0400 @@ -591,7 +591,7 @@ log_fatal( _("can't lock `%s'\n"), db_name ); #endif /* __riscos__ */ db_fd = open (db_name, O_RDWR | MY_O_BINARY ); - if (db_fd == -1 && errno == EACCES) { + if (db_fd == -1 && (errno == EACCES || errno == EROFS)) { db_fd = open (db_name, O_RDONLY | MY_O_BINARY ); if (db_fd != -1) log_info (_("NOTE: trustdb not writable\n")); This may not be the "right" solution to the problem, but it works for me. Perhaps a better way to do this is to add a flag that is explicitly for working with a strictly read-only $GNUPGHOME. Or maybe --no-auto-check-trustdb should enable the behavior (it's still needed anyways for the verification to succeed on a read-only mounted filesystem). Thank you, Bryce From sclodic at teaser.fr Sat Jul 16 16:11:34 2005 From: sclodic at teaser.fr (Stephane Clodic) Date: Mon Jul 18 17:34:00 2005 Subject: GnuPG-1.4.2rc2 trouble with "clean" function ??? (missing signature) Message-ID: <20050716141134.GG84049@qube.teaser.fr> (please Cc me as I'm not subscribed to the devel mailing-list) Hello, Since many months, my (public avaliable) GPG key 0xC007255B has a valid signature from 0x9C851DF1 % gpg --list-sigs 0xC007255B [snip] uid Stephane Clodic (France-Teaser) [snip] sig 1 P 0x9C851DF1 2004-11-07 ImperialViolet Email Verifier (This is an automatic system which signs keys after verifying an email address. See http://www.imperialviolet.org/keyverify.html) Signature policy: http://www.imperialviolet.org/keyverify.html With GnuPG-1.4.1 (compiled from sources) this signature is fine. With GnuPG-1.4.2rc2 (also compiled from sources) and after using "clean" function (from --edit), the 0x9C851DF1 signature is no more valid ! I tried a import command with 1.4.2rc2 % gpg --verbose --import tmp/keyverify gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: pub 1024D/0xC007255B 2001-10-29 Stephane Clodic (France-Teaser) gpg: removing signature from 0xC007255B on uid "Stephane Clodic (France-Teaser) ": superceded gpg: removing signature from 0xC007255B on uid "Stephane Clodic ": superceded gpg: removing signature from 0xC007255B on uid "Stephane Clodic ": superceded gpg: removing signature from 0x9C851DF1 on uid "Stephane Clodic (France-Teaser) ": invalid [snip] As you can see, 0x9C851DF1's signature is removed as seen invalid (I add "import-options import-clean-sigs import-clean-uids" in my ~/.gnupg/gpg.conf before the import) I could use pgpdump on tmp/keyverify file or my pubkey file but the output mean absolutely nothing to me :)) Could someone explain why this signature become invalid with 1.4.2rc2 ? Thank you for your help. Regards NB : You can get my key from http://www.teaser.fr/~sclo/sclo.gpg or http://pgpkeys.telering.at/pks/lookup?op=get&search=0xCD5A896DC007255B (with some garbage :/) -- Stephane Clodic France Teaser From wk at gnupg.org Mon Jul 18 18:27:58 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Jul 18 19:42:25 2005 Subject: verifying signatures when GNUPGHOME is on a read-only filesystem In-Reply-To: (Bryce Nichols's message of "Mon, 11 Jul 2005 14:08:53 -0400 (EDT)") References: Message-ID: <87oe90w035.fsf@wheatstone.g10code.de> On Mon, 11 Jul 2005 14:08:53 -0400 (EDT), Bryce Nichols said: > was only EACCES. Therefore, to make this work for my situation (where > the errorcode is EROFS), I've applied the following patch to the 1.4.1 Changed. > This may not be the "right" solution to the problem, but it works for > me. Perhaps a better way to do this is to add a flag that is Basically this is right. I only added an #ifdef EROFS block. Thanks, Werner From wk at gnupg.org Mon Jul 18 18:21:24 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Jul 18 19:42:33 2005 Subject: noecho before prompt In-Reply-To: <20050708075328.GI4759@prism.co.za> (Bernd Jendrissek's message of "Fri, 8 Jul 2005 09:53:28 +0200") References: <55770.192.168.1.10.1120600961.squirrel@chkno.net> <87r7e9u51p.fsf@wheatstone.g10code.de> <20050708075328.GI4759@prism.co.za> Message-ID: <87slycw0e3.fsf@wheatstone.g10code.de> On Fri, 8 Jul 2005 09:53:28 +0200, Bernd Jendrissek said: > Presumably the concern is that gpg may get scheduled out after showing > the prompt, but before setting noecho, and that it may remain scheduled > out for long enough for a user to type some characters, which the kernel Ah right. I only looked at the diff and could not grasp it from there, so I asked. Fixed in CVS. Thanks for pointing out and explaining, Werner From kfitzner at excelcia.org Mon Jul 18 04:58:16 2005 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Mon Jul 18 19:43:01 2005 Subject: [Announce] GPGee (GnuPG Explorer Extension) version 1.1.1 released Message-ID: <87mzok3b7c.fsf@wheatstone.g10code.de> Hello all, I have released version 1.1.1 of GPGee. This is a minor update to 1.1 to answer a couple user requests. Changes are: - Configuration entry added to set the way encryption Key IDs are displayed for subkeys. Encryption subkeys used to be displayed showing their subkey key ID. Now the default is to display the key ID of the parent key. This brings GPGee in line with most other GnuPG front ends. A configuration entry has been added so that (the very few) people who prefer the old behavior can still have it. - The length of time it takes for the sign/encrypt window to appear has been further reduced for people with very large keyrings. GPGee 1.1.1 installer and source are available from http://gpgee.excelcia.org For those that aren't familliar with GPGee, it is a GnuPG Explorer Extension for Windows. It adds GnuPG sign/encrypt/verify/decrypt support to the Windows explorer right-click context menu. See the web site above for a fuller list of features. Kurt Fitzner [reposted by moderator] _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From patrick at mozilla-enigmail.org Mon Jul 18 20:35:21 2005 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Mon Jul 18 21:12:28 2005 Subject: Accessing gpgkeys_* fails on Windows In-Reply-To: <20050709200906.GB24250__22345.3014310964$1120939891$gmane$org@jabberwocky.com> References: <42CEB00B.9080101@mozilla-enigmail.org> <20050708220125.GE23974__37719.4916749888$1120860296$gmane$org@jabberwocky.com> <20050709200906.GB24250__22345.3014310964$1120939891$gmane$org@jabberwocky.com> Message-ID: David Shaw wrote: > On Sat, Jul 09, 2005 at 12:49:31PM +0200, Patrick Brunschwig wrote: > >>David Shaw wrote: >> >>>On Fri, Jul 08, 2005 at 06:55:39PM +0200, Patrick Brunschwig wrote: >>> >>> >>>>I just noticed that gpg 1.4.2rc2 is not able to find gpgkeys_hkp.exe. I >>>>have installed GnuPG using the Windows installer, but to a non-default >>>>directory (E:\GnuPG\GnuPG). >>>>According to the debug log, gpg is looking for gpgkeys_hkp in c:\lib; >>>>but that directory doesn't exist: >>>>gpg: DBG: expanding string "c:\lib\gnupg\gpgkeys_hkp -o "%o" "%i"" >>>> >>>>I looked into the source code and I could imagine the reason to be >>>>DISABLE_KEYSERVER_PATH not being enabled. Is this correct? >>> >>> >>>This is an interesting situation. The code was compiled with one >>>path, but installed under a different one. >>> >>>What happens if you stick "exec-path e:\GnuPG\GnuPG" in your gpg.conf >>>file? >> >>In this case, gpgkeys_* is found correctly. > > > Good. I'm not sure what the best answer for this is. GPG needs to > know what the path is to the gpgkeys_* programs since they may not be > in your $PATH. Unfortunately, by installing it in a different > directory, the default path no longer points to the right place. > Perhaps the right answer is to have the Windows installer append the > "exec-path" to the gpg.conf file at install time for people who don't > put GPG in the default place. In case there is no exec-path entry in gpg.conf, would it not be easier to check in the Windows registry for the path where gpg is installed? -Patrick From wk at gnupg.org Tue Jul 19 07:55:53 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Jul 19 07:56:20 2005 Subject: Accessing gpgkeys_* fails on Windows In-Reply-To: (Patrick Brunschwig's message of "Mon, 18 Jul 2005 20:35:21 +0200") References: <42CEB00B.9080101@mozilla-enigmail.org> <20050708220125.GE23974__37719.4916749888$1120860296$gmane$org@jabberwocky.com> <20050709200906.GB24250__22345.3014310964$1120939891$gmane$org@jabberwocky.com> Message-ID: <87d5pfuyom.fsf@wheatstone.g10code.de> On Mon, 18 Jul 2005 20:35:21 +0200, Patrick Brunschwig said: > In case there is no exec-path entry in gpg.conf, would it not be easier > to check in the Windows registry for the path where gpg is installed? I think this is better. I'll change it to use HKLM\Software\GNU\GnuPG:Install Directory because this is where the installer stores the leyserver helpers. Shalom-Salam, Werner From wk at gnupg.org Tue Jul 19 13:11:07 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Jul 19 13:11:20 2005 Subject: More agent problems In-Reply-To: <1121433174.10882.3.camel@localhost.localdomain> (Joachim Breitner's message of "Fri, 15 Jul 2005 16:12:54 +0300") References: <1121433174.10882.3.camel@localhost.localdomain> Message-ID: <871x5vrqyc.fsf@wheatstone.g10code.de> On Fri, 15 Jul 2005 16:12:54 +0300, Joachim Breitner said: > when I have the daemon running, used my PIN already, so that it is > cached, and I want to change the card PIN, it seems that the daemon is > answering the "New PIN?" question for me - with my old PIN, thus giving > me after entering the new PIN once a "PINs do not match" error. I must have overlooked one place where we need to flush the cache. Thanks, Werner From wk at gnupg.org Tue Jul 19 13:48:23 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Jul 19 13:46:24 2005 Subject: PIN caching with gnupg-1.4.2-rc2 and gpg-agent 1.9.17 In-Reply-To: <1121423631.10696.4.camel@localhost.localdomain> (Joachim Breitner's message of "Fri, 15 Jul 2005 13:33:51 +0300") References: <1121423631.10696.4.camel@localhost.localdomain> Message-ID: <87slybqans.fsf@wheatstone.g10code.de> On Fri, 15 Jul 2005 13:33:51 +0300, Joachim Breitner said: > When I sign a file with gnupg, daemon running, no scdaemon, it seems as > if gnupg asks the agent to ask me for the pin, but talks itself to the > card. When I repeat that, the agent obviously has already cached the PIN > and I don't have to enter it again. So far so good. Yes, in this case gpg-agent is only used to cache the PIN/passphrase. > When I do enable scdaemon (using pcscd), signing works as well, but the > PIN does not seem to be cached: I have to enter it again. I also noticed that and looking for a solution. Actually the card should cache the PIN and thus no gpg-agent caching is involved at all. However any RESET to the card will let the card forget the PIN. Now, when a connection to the gpg-agent/scdaemon terminates a reset is send down to the card handlers. It seems that this is a full reset down to the card instead of a mere connection cleanup. > Also, with scdaemon, there might be problems with other programs using > the smartcard, e.g. HBCI, but also libpam-poldi. Haven't investigated > that though. I already talked with Moritz about this. In general it should not happen because gpg-agent is started after a successful login and poldi needs then to relinquish control over the card reader. The problem seems to be any PAM access later on (e.g. su). We might need to watch out for a running scdaemon and utilize it the same way as gpg does it. > A different issue: If the card is not inserted, gpg will ask to insert > the card on the prompt, expecting a keypress. This breaks usage with > e.g. evolution. IMHO, gnupg should just wait for the card to be > inserted, or for some timeout to run out, but not require user > interaction on the console. If user interaction, then via the > gpg-daemon, just like PIN entries. Hmmm, this should not happen when calling gpg with --batch: if (rc && !opt.batch) { write_status_text (STATUS_CARDCTRL, "1"); did_shutdown = !!apdu_shutdown_reader (slot); if ( cpr_get_answer_okay_cancel ("cardctrl.insert_card.okay", _("Please insert the card and hit return or enter 'c' to cancel: "), 1) ) Even without that the answer expected to such a prompt should be Return (i.e. sending an empty line to --command-fd). Well of course, the default answer is not very satisfying as this will lead to an unifinite loop. The correct solution for Evo would be to use --batch or interpret the status messages and supply appropriate answers. As a workaround I will add a retry limit to gpg 1.4.2. The new option "--limit-card-insert-tries N" must then be set to a positive value to enable this. A value of 1 won't issue the prompt, 0 (the default) will emit the current behaviour. Shalom-Salam, Werner From wk at gnupg.org Tue Jul 19 14:10:28 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Jul 19 14:11:19 2005 Subject: And while I'm at it: no_sync not implemented? In-Reply-To: <1121433876.10882.6.camel@localhost.localdomain> (Joachim Breitner's message of "Fri, 15 Jul 2005 16:24:36 +0300") References: <1121433876.10882.6.camel@localhost.localdomain> Message-ID: <87mzojq9mz.fsf@wheatstone.g10code.de> On Fri, 15 Jul 2005 16:24:36 +0300, Joachim Breitner said: > last thing for now: Is no_sync not yet implemented? At least I can't > find anything in the code indicating that, only code to read the flag. > Any chance that that feature makes make it into 1.4.2 Probably not. Sorry. Salam-Shalom, Werner From torduninja at mail.pf Wed Jul 20 00:34:07 2005 From: torduninja at mail.pf (Maxine Brandt) Date: Wed Jul 20 01:08:31 2005 Subject: Accessing gpgkeys_* fails on Windows Message-ID: <42DD7FDF.9010002@mail.pf> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Mon, 18 Jul 2005 20:35:21 +0200, Werner Koch wrote: >> In case there is no exec-path entry in gpg.conf, would it not be easier >> to check in the Windows registry for the path where gpg is installed? > > I think this is better. I'll change it to use > HKLM\Software\GNU\GnuPG:Install Directory > because this is where the installer stores the leyserver helpers. Yes, but we still need the exec-path option for portable removable-medium use. Salut Maxine - -- PGP/GPG keys: http://www.torduninja.tk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2rc2 (MingW32) iQDVAwUBQt1/3Xb9Q+bq34mOAQPUMgX9E+UqPzJk86F2ESqbNUvB5Yjufumnn2Om b3cfQh3zMbfXoZLJsaCrk/wfO9fIrldDwcZ+w0clRZ+9kFIAUZ7kVoOlMqzXm7Tw 59AFKRo5iTpla5PPab8GvquarnuroFoxd7WgVZbDqOna8JyELVszu4mpSEFK4a2w sTgjJvrvkrgoCUmwNMNGN+2DDaLVd43h+aVkpVQlruyuyLUNoAfCIHGKhsEampVe THCBvF486xw7OZpoECQyYhA2FPwj619r =WnXx -----END PGP SIGNATURE----- -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.2/52 - Release Date: 19-Jul-05 From wk at gnupg.org Wed Jul 20 11:09:17 2005 From: wk at gnupg.org (Werner Koch) Date: Wed Jul 20 11:06:16 2005 Subject: Accessing gpgkeys_* fails on Windows In-Reply-To: <42DD7FDF.9010002@mail.pf> (Maxine Brandt's message of "Tue, 19 Jul 2005 12:34:07 -1000") References: <42DD7FDF.9010002@mail.pf> Message-ID: <87oe8xq1xe.fsf@wheatstone.g10code.de> On Tue, 19 Jul 2005 12:34:07 -1000, Maxine Brandt said: > Yes, but we still need the exec-path option for portable removable-medium > use. I will look into GetModuleFileName to retrieve the name of the program used to create the process and use that filename to construct the name of the helper application. This way we get the same semantics as with DLLs. Salam-Shalom, Werner From wk at gnupg.org Wed Jul 20 20:25:45 2005 From: wk at gnupg.org (Werner Koch) Date: Wed Jul 20 20:26:15 2005 Subject: Accessing gpgkeys_* fails on Windows In-Reply-To: <87oe8xq1xe.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 20 Jul 2005 11:09:17 +0200") References: <42DD7FDF.9010002@mail.pf> <87oe8xq1xe.fsf@wheatstone.g10code.de> Message-ID: <8764v5mj12.fsf@wheatstone.g10code.de> On Wed, 20 Jul 2005 11:09:17 +0200, Werner Koch said: > I will look into GetModuleFileName to retrieve the name of the program > used to create the process and use that filename to construct the name > of the helper application. This way we get the same semantics as with > DLLs. Works fine for me. Shalom-Salam, Werner From greg at turnstep.com Wed Jul 20 20:25:21 2005 From: greg at turnstep.com (Greg Sabino Mullane) Date: Wed Jul 20 21:21:18 2005 Subject: Show signer's uid in packet output Message-ID: <51f8817c031a66f6d9c829bd1378777e@biglumber.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NotDashEscaped: You need GnuPG to verify this message Small patch to implement signer's uid in parse-packet. Yes, I came across someone actually using it! :) -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200507201421 https://www.biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 diff -c -r1.118 parse-packet.c *** parse-packet.c 18 Jun 2005 11:49:50 -0000 1.118 --- parse-packet.c 20 Jul 2005 18:10:07 -0000 *************** *** 928,935 **** for( i=0; i < length; i++ ) fprintf (listfp, " %02X", buffer[i] ); break; ! case SIGSUBPKT_SIGNERS_UID: ! p = "signer's user ID"; break; case SIGSUBPKT_REVOC_REASON: if( length ) { --- 928,941 ---- for( i=0; i < length; i++ ) fprintf (listfp, " %02X", buffer[i] ); break; ! case SIGSUBPKT_SIGNERS_UID: ! if(!length) ! p="[invalid signer's user ID subpacket]"; ! else { ! fputs("signer's user ID: \"", listfp ); ! print_string( listfp, buffer, length, '"' ); ! fputs("\"", listfp ); ! } break; case SIGSUBPKT_REVOC_REASON: if( length ) { -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkLelqQACgkQvJuQZxSWSshiHACfRqJ5ZJzN2u+r9sHfhXEy2kvi uuIAoJn7ubUlMN7gK591a/IzL7Tj7V+G =a2sI -----END PGP SIGNATURE----- From greg at turnstep.com Thu Jul 21 20:05:14 2005 From: greg at turnstep.com (Greg Sabino Mullane) Date: Thu Jul 21 20:01:08 2005 Subject: Extra paren in keylist.c Message-ID: <1d48bb15e86ab297d6bc4366bc3f19ba@biglumber.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NotDashEscaped: You need GnuPG to verify this message Very minor extra parens patch in keylist.c: *************** *** 789,795 **** else if(pk->has_expired) { printf(" ["); ! printf(_("expired: %s)"),expirestr_from_pk(pk)); printf("]"); } else if(pk->expiredate) --- 790,796 ---- else if(pk->has_expired) { printf(" ["); ! printf(_("expired: %s"),expirestr_from_pk(pk)); printf("]"); } else if(pk->expiredate) -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkLf41sACgkQvJuQZxSWSsjA/gCfQIDMLRTdoVOZfzSwJ+ExlDIk w88An0uaFlFSawPBRH/58PwvCcF1YqnM =pw7k -----END PGP SIGNATURE----- From wk at gnupg.org Fri Jul 22 12:03:23 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Jul 22 12:01:20 2005 Subject: gpgme_cancel() does not stop gpg process from finishing asynchronous call In-Reply-To: <87r7fks7dk.wl@ulysses.g10code.de> (Marcus Brinkmann's message of "Fri, 03 Jun 2005 00:48:07 +0200") References: <4249E9EF.8050504@katehok.ac93.org> <871x9dwzap.wl@ulysses.g10code.de> <425E5932.7080600@katehok.ac93.org> <425E69C3.90508@katehok.ac93.org> <87r7hdv4w9.wl@ulysses.g10code.de> <425E82E3.5040308@katehok.ac93.org> <425E97EF.9020006@katehok.ac93.org> <87is2ovr1h.wl@ulysses.g10code.de> <42618BBC.8080300@katehok.ac93.org> <87pswts98b.fsf@wheatstone.g10code.de> <87r7fks7dk.wl@ulysses.g10code.de> Message-ID: <87u0inf990.fsf@wheatstone.g10code.de> On Fri, 03 Jun 2005 00:48:07 +0200, Marcus Brinkmann said: >> The only way to implement this in a safe way is by introducing a >> new option to gpg to do this. gpgme may then look at the gpg's >> versions and decide whether to use this option. Marcus, what do you >> think, shall I add such an option to gpg 1.4.2? > Sounds like a good idea, if there is still time. Or just to the next > version, it doesn't seem to be that urgent to me. Just added the option --exit-on-status-write-error: This option will cause write errors on the status FD to immediately terminate the process. That should in fact be the default but it never worked this way and thus we need an option to enable this, so that the change won't break applications which close their end of a status fd connected pipe too early. Using this option along with --enable-progress-filter may be used to cleanly cancel long running gpg operations. Shalom-Salam, Werner From wk at gnupg.org Fri Jul 22 12:12:57 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Jul 22 12:11:17 2005 Subject: Extra paren in keylist.c In-Reply-To: <1d48bb15e86ab297d6bc4366bc3f19ba@biglumber.com> (Greg Sabino Mullane's message of "Thu, 21 Jul 2005 18:05:14 -0000") References: <1d48bb15e86ab297d6bc4366bc3f19ba@biglumber.com> Message-ID: <87mzoff8t2.fsf@wheatstone.g10code.de> On Thu, 21 Jul 2005 18:05:14 -0000, Greg Sabino Mullane said: > ! printf(_("expired: %s)"),expirestr_from_pk(pk)); > ! printf(_("expired: %s"),expirestr_from_pk(pk)); Fortunately we have another string like the fixed one, so this fix won't break translations. Thanks, Werner From dshaw at jabberwocky.com Fri Jul 22 14:31:55 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Jul 22 14:28:03 2005 Subject: Show signer's uid in packet output In-Reply-To: <51f8817c031a66f6d9c829bd1378777e@biglumber.com> References: <51f8817c031a66f6d9c829bd1378777e@biglumber.com> Message-ID: <20050722123155.GB5108@jabberwocky.com> On Wed, Jul 20, 2005 at 06:25:21PM -0000, Greg Sabino Mullane wrote: > > > Small patch to implement signer's uid in parse-packet. Yes, > I came across someone actually using it! :) I'd rather not apply this just yet. There is currently a bit of discussion on the ietf-openpgp list as to what signer's uid actually means and what format it has. Once that is nailed down, I'll add it to parse-packet. David From dshaw at jabberwocky.com Fri Jul 22 14:34:53 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Jul 22 14:30:51 2005 Subject: Extra paren in keylist.c In-Reply-To: <87mzoff8t2.fsf@wheatstone.g10code.de> References: <1d48bb15e86ab297d6bc4366bc3f19ba@biglumber.com> <87mzoff8t2.fsf@wheatstone.g10code.de> Message-ID: <20050722123453.GC5108@jabberwocky.com> On Fri, Jul 22, 2005 at 12:12:57PM +0200, Werner Koch wrote: > On Thu, 21 Jul 2005 18:05:14 -0000, Greg Sabino Mullane said: > > > ! printf(_("expired: %s)"),expirestr_from_pk(pk)); > > > ! printf(_("expired: %s"),expirestr_from_pk(pk)); > > Fortunately we have another string like the fixed one, so this fix > won't break translations. Good. That typo has been in since October: all versions of 1.4.x have it. I'm surprised nobody noticed before! I've fixed it. David From zander at kde.org Sat Jul 23 13:37:38 2005 From: zander at kde.org (Thomas Zander) Date: Sat Jul 23 13:34:36 2005 Subject: gpg-agent env-vars Message-ID: <200507231337.43529.zander@kde.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have the problem that an email client wants to access the gpg-agent and therefor should have some environment variables. Problem is that many (KDE among others) env-scripts don't make this easy. Besides hard-to-debug packaging issues the current memory-only way of storing the gpg-agent connection information makes it impossible to provide the user with a setup wizard or other client to make using the agent easier. I was thinking that if ssh-agent would write a standardised file with the env-variables it now prints on stdout; the various clients could read that file. Standardisation was proposed to be done from the mail-client; but I don't like that. I would get ugly if multiple clients try to do it and do it differently. Not to mention what distros might think of making it even harder to package things. So; what about changing gpg-agent to make it effectively does this; (umask 077 && gpg-agent > ~/.gpg-agent) Small change making a lot of dependencies a lot easier since now starting kmail or mutt can read that file and access the agent without problems. Naturally this means clients can also start the agent mid-session so a re-login is not needed anymore. I'd like to hear opinions. Are there more people who expressed a need to solve this? Is this a good solution? etc. - -- Thomas Zander -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFC4iwHCojCW6H2z/QRAvVkAKDQLw3LOmRZgx0JynadKEdPxEST3QCeNLUg JGjDsq0X0bIdurdGJys2iOA= =I9sH -----END PGP SIGNATURE----- From sithtracy at yahoo.com Sat Jul 23 17:56:17 2005 From: sithtracy at yahoo.com (Tracy D. Bossong) Date: Sat Jul 23 18:52:16 2005 Subject: textmode encryption strips trailing blanks Message-ID: <20050723155618.78753.qmail@web51705.mail.yahoo.com> I encrypt data files that are to be loaded onto a OS/390 mainframe that need to be fixed block files (there are trailing blanks/spaces). These are removed by gpg 1.4.1 (WIN32). This does not happen with McAfee e-Business Server v8.0 for Windows. The only sequence I was able to get them to remain was adding --rfc1991 to the encryption, but I believe that disables the textmode option. Is this a bug that will be remedied in v1.4.2? Thanks, Tracy Bossong sithtracy@yahoo.com - key id 0x85415C2A From dshaw at jabberwocky.com Sat Jul 23 20:05:27 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Sat Jul 23 20:39:40 2005 Subject: textmode encryption strips trailing blanks In-Reply-To: <20050723155618.78753.qmail@web51705.mail.yahoo.com> References: <20050723155618.78753.qmail@web51705.mail.yahoo.com> Message-ID: <20050723180527.GB13965@jabberwocky.com> On Sat, Jul 23, 2005 at 08:56:17AM -0700, Tracy D. Bossong wrote: > I encrypt data files that are to be loaded onto a > OS/390 mainframe that need to be fixed block files > (there are trailing blanks/spaces). These are removed > by gpg 1.4.1 (WIN32). This does not happen with > McAfee e-Business Server v8.0 for Windows. The only > sequence I was able to get them to remain was adding > --rfc1991 to the encryption, but I believe that > disables the textmode option. Is this a bug that will > be remedied in v1.4.2? You've been caught by a recent change in the OpenPGP specification. To get what you want, set --no-rfc2440-text as well as --textmode. In a future version of GnuPG, --no-rfc2440-text will be the default. David From laurent.pinchart at skynet.be Mon Jul 25 17:10:42 2005 From: laurent.pinchart at skynet.be (Laurent Pinchart) Date: Mon Jul 25 17:42:19 2005 Subject: Smart card interface, OpenSC and OpenCT Message-ID: <200507251710.42908.laurent.pinchart@skynet.be> Hi everybody, I'm (slowly) working on getting the Belgian eID card supported as a mean of signing electronic data. My goal is to add signing support to my e-mail client (KMail). After some experiments with a smart card reader, I wrote an OpenCT driver and was about to get my hands in the OpenSC code when I found out that GnuPG doesn't use OpenSC anymore. Could anyone tell me why that decision has been made ? What's the official and prefered way to interface a smart card reader in GnuPG ? Is it PC/SC ? What about readers with a pin pad ? Zetes (the company that developped the Belgian eID software) contributed LGPLed code to OpenSC to support the eID card. Should this code be ported to GnuPG ? I have no prior experience with the GnuPG code base, and was under the impression that OpenSC was the defacto standard for smart card access under GNU/Linux. I'd be very grateful if any of you could give me some information to get all that clear in my mind. Laurent Pinchart From wk at gnupg.org Tue Jul 26 07:41:58 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Jul 26 07:41:16 2005 Subject: Smart card interface, OpenSC and OpenCT In-Reply-To: <200507251710.42908.laurent.pinchart@skynet.be> (Laurent Pinchart's message of "Mon, 25 Jul 2005 17:10:42 +0200") References: <200507251710.42908.laurent.pinchart@skynet.be> Message-ID: <87k6jeyvh5.fsf@wheatstone.g10code.de> On Mon, 25 Jul 2005 17:10:42 +0200, Laurent Pinchart said: > Could anyone tell me why that decision has been made ? What's the * OpenSC is a huge and complex library with an ever changing API and often hidden ABI changes. It just makes too much trouble. * It requires your application to use pthreads which conflicts with the use of another threading library; GNU Pth in our case. This is the actual show stopper. * We only need to _read_ PKCS#15 structures and not to _create_ them. This was actually pretty easy to implement and took me only a few days. Still not complete due to the lack of test cards (aside of a self-created pkcs15 card I do have only one other card (Dienstausweis des BMI). * OpenSC may only be used by LGPL software because it makes use of OpenSSL. It is possible to disable this by losing some functionality; no distribution does it. > prefered way to interface a smart card reader in GnuPG ? Is it PC/SC ? What > about readers with a pin pad ? Either direct access via the interanl CCID driver or by PC/SC or ctAPI. Adding OpenCT support won't be a problem. > Zetes (the company that developped the Belgian eID software) contributed > LGPLed code to OpenSC to support the eID card. Should this code be ported to > GnuPG ? AFAIK, the card is a PKCS#15 one so in theory signing should already work with gpgsm. A textcard would definitley be helpful. Shalom-Salam, Werner From laurent.pinchart at skynet.be Tue Jul 26 13:38:25 2005 From: laurent.pinchart at skynet.be (Laurent Pinchart) Date: Tue Jul 26 13:34:17 2005 Subject: Smart card interface, OpenSC and OpenCT In-Reply-To: <87k6jeyvh5.fsf@wheatstone.g10code.de> References: <200507251710.42908.laurent.pinchart@skynet.be> <87k6jeyvh5.fsf@wheatstone.g10code.de> Message-ID: <200507261338.25429.laurent.pinchart@skynet.be> > * OpenSC is a huge and complex library with an ever changing API and > often hidden ABI changes. It just makes too much trouble. I understand that. Floating APIs/ABIs are very painful. > * It requires your application to use pthreads which conflicts with > the use of another threading library; GNU Pth in our case. This is > the actual show stopper. Now, that's bad. How are applications/libraries supposed to cooperate when different threading libraries are used ? > * We only need to _read_ PKCS#15 structures and not to _create_ them. > This was actually pretty easy to implement and took me only a few > days. Still not complete due to the lack of test cards (aside of a > self-created pkcs15 card I do have only one other card > (Dienstausweis des BMI). So we only need a small subset of what OpenSC provides. Ok. > * OpenSC may only be used by LGPL software because it makes use of > OpenSSL. It is possible to disable this by losing some > functionality; no distribution does it. Right. libopensc only requires OpenSSL for the GPK-4000 and Oberthur cards. It can be disabled at compile time, in which case sc_pkcs15_wrap_data and sc_pkcs15_unwrap_data won't be available. > > prefered way to interface a smart card reader in GnuPG ? Is it PC/SC ? > > What about readers with a pin pad ? > > Either direct access via the interanl CCID driver or by PC/SC or > ctAPI. Adding OpenCT support won't be a problem. OpenCT is (in my opinion) a cleaner API than PC/SC (which was designed for Microsoft Windows). I'd rather see the CCID readers supported through OpenCT and/or PC/SC than directly by GnuPG, as OpenCT and PC/SC can share a reader between separate applications. Any opinion about that ? > > Zetes (the company that developped the Belgian eID software) contributed > > LGPLed code to OpenSC to support the eID card. Should this code be ported > > to GnuPG ? > > AFAIK, the card is a PKCS#15 one so in theory signing should already > work with gpgsm. A textcard would definitley be helpful. The card is a PKCS#15 with a few differences: * The SELECT FILE doesn't return any FCI, so the file size isn't know. This doesn't seem to matter as GnuPG doesn't use the FCI. On a side note, iso7816_read_binary doesn't handle status bytes 6Cxx (Wrong Le field). Shouldn't it reissue the READ BINARY command with Le=xx ? * The NonRep key needs a VERIFY PIN before each time it is used for a signature. Zetes enforced that by popping a GUI window up every time a signature was made. I don't like that solution, and it seems that GnuPG performs the VERIFY command before every signature anyway. Could anyone confirm that ? My main concern here is to make sure that distributions can integrate smart card support in an easy and flexible way. This means that smart card readers must be managed by a single application/framework/daemon/whatever, namely PC/SC or OpenCT. Different applications can then communicate with the card, either directly (like GnuPG) or using a library (libopensc) with a higher-level API. Comments are appreciate. Feel free to prove me wrong where I'm wrong :-) Laurent Pinchart From laurent.pinchart at skynet.be Tue Jul 26 14:09:28 2005 From: laurent.pinchart at skynet.be (Laurent Pinchart) Date: Tue Jul 26 14:05:20 2005 Subject: Smart card interface, OpenSC and OpenCT In-Reply-To: <87k6jeyvh5.fsf@wheatstone.g10code.de> References: <200507251710.42908.laurent.pinchart@skynet.be> <87k6jeyvh5.fsf@wheatstone.g10code.de> Message-ID: <200507261409.28244.laurent.pinchart@skynet.be> > AFAIK, the card is a PKCS#15 one so in theory signing should already > work with gpgsm. A textcard would definitley be helpful. There's probably something I haven't understood, but scd/card-p15.c (CVS from two days ago) depends on OpenSC, and you just told me that GnuPG can't use OpenSC. Laurent Pinchart From wk at gnupg.org Tue Jul 26 14:33:41 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Jul 26 14:31:16 2005 Subject: Smart card interface, OpenSC and OpenCT In-Reply-To: <200507261409.28244.laurent.pinchart@skynet.be> (Laurent Pinchart's message of "Tue, 26 Jul 2005 14:09:28 +0200") References: <200507251710.42908.laurent.pinchart@skynet.be> <87k6jeyvh5.fsf@wheatstone.g10code.de> <200507261409.28244.laurent.pinchart@skynet.be> Message-ID: <873bq1ycey.fsf@wheatstone.g10code.de> On Tue, 26 Jul 2005 14:09:28 +0200, Laurent Pinchart said: > There's probably something I haven't understood, but scd/card-p15.c (CVS from > two days ago) depends on OpenSC, and you just told me that GnuPG can't use > OpenSC. It just has not been deleted from the CVS. That file is not used anymore. I'll reply to your other mail later. Shalom-Salam, Werner From wk at gnupg.org Tue Jul 26 17:25:28 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Jul 26 17:26:17 2005 Subject: Charset encoding of passphrase In-Reply-To: (Patrick Brunschwig's message of "Thu, 09 Jun 2005 17:00:27 +0200") References: Message-ID: <87ek9lwpw7.fsf@wheatstone.g10code.de> On Thu, 09 Jun 2005 17:00:27 +0200, Patrick Brunschwig said: > My question is: do I have to encode the passphrase in utf-8 or does it > need to be encoded in the charset of the command prompt (in this case > Windows-850), or yet something else? It should be the same encoding as used when creating the passphrase. The data is taken verbatim and not interpreted except for the native LF character to indicate the end of the passphrase string. In general I'd suggest using utf-8 but this depends on the system. > When I enter a passphrase with e.g. ? on the Windows command line (no > charset in gpg.conf set), I can't find the correct encoding in Enigmail Stick to plain ASCII ? Salam-Shalom, Werner From laurent.pinchart at skynet.be Wed Jul 27 10:21:37 2005 From: laurent.pinchart at skynet.be (Laurent Pinchart) Date: Wed Jul 27 10:22:03 2005 Subject: Smart card interface, why so many daemons ? Message-ID: <200507271021.37723.laurent.pinchart@skynet.be> Hi everybody, I've been trying (unsuccessfully so far) to get the Belgian eID card working with GnuPG. As I'm getting a better understanding of the way GnuPG handles smart cards, a question arises: why so many daemons ? Using PC/SC, gpgsm requires the following daemons to be running (or starts them if they are not running): - PC/SC - pcsc-wrapper (not really a daemon here, but a separate process) - scdaemon - gpg-agent My question is, why so many of them ? PC/SC is needed, but I don't see the point in pcsc-wrapper, and I'm not sure about scdaemon either. I understand the argument that, for security reasons, GnuPG can't be made a library, but will stay a separate process (with gpgme helping to communicate with that process). Are there security issues with scdaemon and pcsc-wrapper ? Any info about the reasons smart card support has been architectured that way are welcome. Laurent Pinchart From wk at gnupg.org Wed Jul 27 09:53:27 2005 From: wk at gnupg.org (Werner Koch) Date: Wed Jul 27 11:09:02 2005 Subject: [Announce] GnuPG 1.4.2 released Message-ID: <87sly0sn0o.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 christianbiere at gmx.de Thu Jul 28 18:34:20 2005 From: christianbiere at gmx.de (Christian Biere) Date: Thu Jul 28 19:30:17 2005 Subject: Update of key impossible due to duplicate ID Message-ID: <20050728163208.GB935@cyclonus> Hi, I've tried to ask the guys who run pgpkeys.mit.edu about this issue but got no reply. The same problem occurs with other servers that run the same keyserver software. Is this an issue with GnuPG itself or a bug in the keyserver software? Anyone who uses these servers to get update for my public key from these servers, won't get one. Here's my problem: I've tried to update my public key at pgpkeys.mit.edu several times but it always returns a broken(?) key with a "duplicate ID". The keyserver at blackhole.pca.dfn.de doesn't have this problem. # # Retrieving the key from blackhole.pca.dfn.de works: # $ gpg --recv-key 7A3220C7 gpg: requesting key 7A3220C7 from hkp server blackhole.pca.dfn.de gpg: key 7A3220C7: public key "Christian Biere " imported gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: Total number processed: 1 gpg: imported: 1 $ gpg --fingerprint 7A3220C7 pub 1024D/7A3220C7 2002-04-10 [expires: 2006-01-05] Key fingerprint = D952 6F9B 37E4 801A 5F9E 79AE D0A4 22C7 7A32 20C7 uid Christian Biere sub 2048R/18F1C2E1 2003-11-17 [expires: 2006-01-05] # # Retrieving the key from pgpkeys.mit.edu causes a warning: # $ gpg --keyserver x-hkp://pgpkeys.mit.edu --recv-key 7A3220C7 gpg: requesting key 7A3220C7 from hkp server pgpkeys.mit.edu gpg: key 7A3220C7: duplicated user ID detected - merged gpg: key 7A3220C7: public key "Christian Biere " imported gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: Total number processed: 1 gpg: imported: 1 # # The sub key is missing: # $ gpg --fingerprint 7A3220C7 pub 1024D/7A3220C7 2002-04-10 [expires: 2006-01-05] Key fingerprint = D952 6F9B 37E4 801A 5F9E 79AE D0A4 22C7 7A32 20C7 uid Christian Biere -- Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : /pipermail/attachments/20050728/f5ba915d/attachment.pgp From dshaw at jabberwocky.com Thu Jul 28 20:08:46 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Jul 28 20:04:44 2005 Subject: Update of key impossible due to duplicate ID In-Reply-To: <20050728163208.GB935@cyclonus> References: <20050728163208.GB935@cyclonus> Message-ID: <20050728180846.GC16810@jabberwocky.com> On Thu, Jul 28, 2005 at 06:34:20PM +0200, Christian Biere wrote: > I've tried to ask the guys who run pgpkeys.mit.edu about this issue > but got no reply. The same problem occurs with other servers that > run the same keyserver software. Is this an issue with GnuPG itself > or a bug in the keyserver software? Anyone who uses these servers > to get update for my public key from these servers, won't get one. > > Here's my problem: > > I've tried to update my public key at pgpkeys.mit.edu several times > but it always returns a broken(?) key with a "duplicate ID". The > keyserver at blackhole.pca.dfn.de doesn't have this problem. It's a keyserver issue. blackhole.pca.dfn.de is running SKS, which is more or less bug free. pgp.mit.edu is running PKS which has some problems. One of those problems is that it can duplicate user IDs sometimes. This is annoying but harmless, and GnuPG will unduplicate them automatically. More serious is that it cannot handle subkeys properly. David From wk at gnupg.org Fri Jul 29 10:02:30 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Jul 29 10:01:45 2005 Subject: GnuPG has switched to Subversion Message-ID: <874qaem44p.fsf@wheatstone.g10code.de> Hi! I have justed finished switching GnuPG from CVS to Subversion. Instructions for using anonymous access are pretty simple: * To checkout the 1.4 branch into a directory named gnupg14 do: svn co svn://cvs.gnupg.org/gnupg/trunk gnupg14 * To checkout the 1.9 branch into gnupg19: svn co svn://cvs.gnupg.org/gnupg/branches/GNUPG-1-9-BRANCH gnupg19 * To check out released version X.Y.Z into directory foo-X.Y.Z: svn co svn://cvs.gnupg.org/gnupg/tags/VX-Y-Z foo-X.Y.Z The file README.CVS has been renamed to README.SVN but its content didn't changed in substance. The old CVS archive is still online but will be taken offline in a couple of weeks. Happy hacking, Werner From kfitzner at excelcia.org Sat Jul 30 00:29:18 2005 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Sat Jul 30 14:08:59 2005 Subject: [Announce] GPGee version 1.1.2 - Important Security Update Message-ID: <42EAADBE.901@excelcia.org> 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 zander at kde.org Fri Jul 22 20:04:03 2005 From: zander at kde.org (Thomas Zander) Date: Tue Aug 9 13:26:25 2005 Subject: gpg-agent env-vars Message-ID: <200507221912.04874.zander@kde.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have the problem that an email client wants to access the gpg-agent and therefor should have some environment variables. Problem is that many (KDE among others) env-scripts don't make this easy. Besides hard-to-debug packaging issues the current memory-only way of storing the gpg-agent connection information makes it impossible to provide the user with a setup wizard or other client to make using the agent easier. I was thinking that if ssh-agent would write a standardised file with the env-variables it now prints on stdout; the various clients could read that file. Standardisation was proposed to be done from the mail-client; but I don't like that. I would get ugly if multiple clients try to do it and do it differently. Not to mention what distros might think of making it even harder to package things. So; what about changing gpg-agent to make it effectively does this; (umask 077 && gpg-agent > ~/.gpg-agent) Small change making a lot of dependencies a lot easier since now starting kmail or mutt can read that file and access the agent without problems. Naturally this means clients can also start the agent mid-session so a re-login is not needed anymore. I'd like to hear opinions. Are there more people who expressed a need to solve this? Is this a good solution? etc. ps. please cc answers as I am not subscribed. - -- Thomas Zander -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFC4SjkCojCW6H2z/QRAmJzAKDLcrLI5idplSUvtJetA3Es6UBcuwCeODF9 KpzMV1Q0AjvvL5IhIWo4VQQ= =8+W2 -----END PGP SIGNATURE----- From gmachala at charter.net Mon Jul 25 00:08:44 2005 From: gmachala at charter.net (greg) Date: Tue Aug 9 13:26:34 2005 Subject: gnupg minor bug found Message-ID: <200507241534.39492.gmachala@charter.net> I found a small issue in command-ssh.c when trying to compile kde3.4 line 1991 had 2 semicolons after it and my gcc 3.2 complained about it. I don't know for sure why. Just thought I'd pass it along.