From cloos at jhcloos.com Mon Nov 1 21:21:44 2010 From: cloos at jhcloos.com (James Cloos) Date: Mon, 01 Nov 2010 16:21:44 -0400 Subject: GnuPG 2.1 beta released In-Reply-To: <878w1kyubf.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 27 Oct 2010 09:21:40 +0200") References: <87ocagzzh9.fsf@vigenere.g10code.de> <1288120324.4076.103.camel@yamato.local> <878w1kyubf.fsf@vigenere.g10code.de> Message-ID: >>>>> "WK" == Werner Koch writes: WK> However, /tmp or TMPDIR is not anymore used by default. We start WK> gpg-agent on demand and for that we need to use a fixed socket name. Which is "${HOME}/S.gpg-agent" in 2.1 beta. That may not be the best place. It probably should be in a well-known .foobar subdirectory. Maybe in ~/.gnupg? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From wk at gnupg.org Tue Nov 2 08:50:55 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Nov 2010 08:50:55 +0100 Subject: GnuPG 2.1 beta released In-Reply-To: (James Cloos's message of "Mon, 01 Nov 2010 16:21:44 -0400") References: <87ocagzzh9.fsf@vigenere.g10code.de> <1288120324.4076.103.camel@yamato.local> <878w1kyubf.fsf@vigenere.g10code.de> Message-ID: <87hbg0upsw.fsf@vigenere.g10code.de> On Mon, 1 Nov 2010 21:21, cloos at jhcloos.com said: > Which is "${HOME}/S.gpg-agent" in 2.1 beta. It is "${HOME}/.gnupg/S.gpg-agent" by default. If you change the home directory of GnuPG either using the envvar GNUPGHOME or the option --homedir it will be in that directory. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From cloos at jhcloos.com Tue Nov 2 21:27:06 2010 From: cloos at jhcloos.com (James Cloos) Date: Tue, 02 Nov 2010 16:27:06 -0400 Subject: GnuPG 2.1 beta released In-Reply-To: <87hbg0upsw.fsf@vigenere.g10code.de> (Werner Koch's message of "Tue, 02 Nov 2010 08:50:55 +0100") References: <87ocagzzh9.fsf@vigenere.g10code.de> <1288120324.4076.103.camel@yamato.local> <878w1kyubf.fsf@vigenere.g10code.de> <87hbg0upsw.fsf@vigenere.g10code.de> Message-ID: >>>>> "WK" == Werner Koch writes: WK> It is "${HOME}/.gnupg/S.gpg-agent" by default. If you change the WK> home directory of GnuPG either using the envvar GNUPGHOME or the WK> option --homedir it will be in that directory. D?Oh! I read homedir as $HOME and not as $HOME/.gnupg. I should have remembered otherwise. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From j.scott.edwards.nwos at gmail.com Thu Nov 4 20:28:43 2010 From: j.scott.edwards.nwos at gmail.com (J. Scott Edwards) Date: Thu, 4 Nov 2010 13:28:43 -0600 Subject: Advice on incorporating GPG into a project Message-ID: Hello, I made a couple of inquiries here about incorporating GPG signatures into my project 4 or 5 years ago (my how time files!), but then I decided to leave the signature stuff out of my prototype until the project was further along. Now that I'm starting work on the next phase, I have been thinking about the signature thing again. I was wondering if anyone would be willing to advise me on how to do it. It is not putting signatures on files, but putting them on objects. It would be nice to discuss it with the whole list, but I didn't want to create too much traffic. Thanks -Scott From gniibe at fsij.org Tue Nov 9 07:13:24 2010 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 09 Nov 2010 15:13:24 +0900 Subject: Gnuk version 0.4 In-Reply-To: <4CC24E38.9080700@fsij.org> References: <4CC24E38.9080700@fsij.org> Message-ID: <4CD8E684.8020409@fsij.org> Gnuk is a software for USB Token which follows OpenPGP card specification v2.0. I released version 0.4 of Gnuk at: http://www.gniibe.org/oitoite/gnuk/ Major changes are: * Added DfuSe host program (DfuSe: Device Firmware Upgrade STMicro Extension) * Improvement on Flash ROM usage * Bug fixes. 2010-10-23, NIIBE Yutaka wrote: > Unfortunately, it seems (for me) that there is no good Free Software > tool which supports DFU of STM32. Perhaps, I will need to write a DFU > tool by myself. I wrote the tool because I found that there is no good software even in the proprietary software world. There is a severe bug in DfuSe tool on Windows which stops Gnuk development (or any "real" development). When the file to be loaded includes a page filled by 0xff, DfuSe tool on Windows fails to update flash ROM on target board. Because of this bug, you could write Gnuk to your target board only once. Now, with the tool in Gnuk, you can update the flash ROM again. Please visit at http://www.fsij.org/gnuk/ for Gnuk news. Now, it has index to access all entries. P.S. I will talk about Gnuk at FOSS Asia: http://fossasia.org/ -- From wk at gnupg.org Wed Nov 10 13:54:12 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Nov 2010 13:54:12 +0100 Subject: GnuPG support Message-ID: <87oc9xwd8r.fsf@vigenere.g10code.de> Hi! GnuPG features a new experimental tool called G13. It is designed as a key management tool for disc encryption. The actual encryption is done using a backend. I hacked this tool about a year ago using EncFS as its first backend. Unfortunately I forgot that we need a patched version of EncFS to make it work [1]. Now that I released GnuPG 2.1.0beta1, which announced the existence of that tool, Daiki Ueno wanted to check it out and figured that it does not work due to the missing support in EncFS. The feature I added is the option --annotate. This option prints additional strings like $PROMPT$ create_mount_point $PROMPT$ new_passwd $STATUS$ fuse_main_start so that the controlling g13 tools knows what to do. Using this annotation is much easier and more robust than trying to parse the strings EncFS usually prints. I'd very much appreciate if you can merge this patch. I attach the old one for 1.5 and one for 1.7.3. Shalom-Salam, Werner [1] It was for a lesser known prototype project which uses its own Debian repo. Thus we all used a patched version for our tests. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: encfs-1.7.3_annotate.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: encfs-1.5_annotate.diff URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From gniibe at fsij.org Thu Nov 11 01:48:32 2010 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 11 Nov 2010 09:48:32 +0900 Subject: scdaemon sends SIGUSR2 to foreground gpg-agent Message-ID: <4CDB3D60.9030609@fsij.org> Hi, Using Gnuk, I found a small problem at the interaction between scdaemon and gpg-agent. I am using gnupg2-2.0.14 (on Debian) and reading its source, and reading the code gnupg-2.1.0beta1/agent/gpg-agent.c too. When we run gpg-agent in background, no problem. In the function handle_connections (agent/gpg-agent.c), it setups SIG_IGN for SIGUSR2. # As we use gpg-agent in background, we don't see any problem usually. Invoked as foreground, gpg-agent does nothing for setup for SIGUSR2. When there is no gpg-agent, it will be spawned with "--server" (foreground). Then, when scdaemon will find Gnuk Token, it sends SIGUSR2 to gpg-agent. Thus, gpg-agent will be killed, and it results "IPC write error". Scdaemon should not send SIGUSR2 to foreground gpg-agent, or, gpg-agent would setup SIG_IGN for SIGUSR2, even if it runs foreground. Here is the interaction log: ----- $ gpg2 --card-edit can't connect to `/home/gniibe/.gnupg/S.gpg-agent': No such file or directory Application ID ...: D276000124010200F517000000010000 Version ..........: 2.0 Manufacturer .....: unknown Serial number ....: 00000001 Name of cardholder: Yutaka Niibe Language prefs ...: ja Sex ..............: male URL of public key : http://www.gniibe.org/gniibe.asc Login data .......: gniibe Signature PIN ....: forced Key attributes ...: 2048R 2048R 2048R Max. PIN lengths .: 127 127 127 PIN retry counter : 3 3 3 Signature counter : 2 Signature key ....: 1241 24BD 3B48 62AF 7A0A 42F1 00B4 5EBD 4CA7 BABE created ....: 2010-10-15 06:46:33 Encryption key....: 42E1 E805 4E6F 1F30 26F2 DC79 79A7 9093 0842 39CF created ....: 2010-10-15 06:46:33 Authentication key: B4D9 7142 C42D 6802 F5F7 4E70 9C33 B6BA 5BB0 65DC created ....: 2010-10-22 06:06:36 General key info..: pub 2048R/4CA7BABE 2010-10-15 NIIBE Yutaka sec> 2048R/4CA7BABE created: 2010-10-15 expires: never card-no: F517 00000001 ssb> 2048R/084239CF created: 2010-10-15 expires: never card-no: F517 00000001 ssb> 2048R/5BB065DC created: 2010-10-22 expires: never card-no: F517 00000001 Command> scdaemon[7182]: updating slot 0 status: 0x0000->0x0007 (0->1) scdaemon[7182]: sending signal 12 to client 7181 scdaemon[7182]: scdaemon (GnuPG) 2.0.14 stopped gpg: OpenPGP card not available: IPC write error Command> -- From wk at gnupg.org Thu Nov 11 15:34:19 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Nov 2010 15:34:19 +0100 Subject: scdaemon sends SIGUSR2 to foreground gpg-agent In-Reply-To: <4CDB3D60.9030609@fsij.org> (NIIBE Yutaka's message of "Thu, 11 Nov 2010 09:48:32 +0900") References: <4CDB3D60.9030609@fsij.org> Message-ID: <87k4kkudxw.fsf@vigenere.g10code.de> On Thu, 11 Nov 2010 01:48, gniibe at fsij.org said: > Scdaemon should not send SIGUSR2 to foreground gpg-agent, or, > gpg-agent would setup SIG_IGN for SIGUSR2, even if it runs foreground. I see. Should be easy to fix. Let me see ... Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Nov 11 15:55:07 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Nov 2010 15:55:07 +0100 Subject: scdaemon sends SIGUSR2 to foreground gpg-agent In-Reply-To: <4CDB3D60.9030609@fsij.org> (NIIBE Yutaka's message of "Thu, 11 Nov 2010 09:48:32 +0900") References: <4CDB3D60.9030609@fsij.org> Message-ID: <87fwv7vrjo.fsf@vigenere.g10code.de> Hi, > Scdaemon should not send SIGUSR2 to foreground gpg-agent, or, > gpg-agent would setup SIG_IGN for SIGUSR2, even if it runs foreground. I will commit a fix to trunk and 2.0. The patch below is against trunk. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: x URL: From gniibe at fsij.org Sun Nov 14 12:53:36 2010 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sun, 14 Nov 2010 20:53:36 +0900 Subject: Signing with SHA256 by Smartcard? Message-ID: <4CDFCDC0.1060603@fsij.org> I am trying to use Gnuk USB Token for Debian Developers, who requires SHA256. Today, I found that current Gnuk only supports digital signing for SHA-1 DigestInfo. So, I fixed to support SHA256 DigestInfo. But, it seems that GnuPG does not support SHA256 DigestInfo for SmartCard well. Yes, the function cmd_pksign in scd/command.c has support of option like: --hash=XXX. But, caller side function agent_card_pksign in agent/call-scd.c doesn't use this option at all. Don't we need to fix agent/call-scd.c? -- From flameeyes at gmail.com Sun Nov 14 13:28:11 2010 From: flameeyes at gmail.com (Diego Elio =?ISO-8859-1?Q?Petten=F2?=) Date: Sun, 14 Nov 2010 13:28:11 +0100 Subject: Signing with SHA256 by Smartcard? In-Reply-To: <4CDFCDC0.1060603@fsij.org> References: <4CDFCDC0.1060603@fsij.org> Message-ID: <1289737691.21509.46.camel@yamato.local> Il giorno dom, 14/11/2010 alle 20.53 +0900, NIIBE Yutaka ha scritto: > > But, it seems that GnuPG does not support SHA256 DigestInfo for > SmartCard > well. Yes, the function cmd_pksign in scd/command.c has support of > option like: --hash=XXX. But, caller side function agent_card_pksign > in agent/call-scd.c doesn't use this option at all. > I can get SHA-2 functions signing fine with a patched GnuPG 2.0.16; the 2.0.16 release is not working, but you can get either the trunk or the following patch to do the trick: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-crypt/gnupg/files/gnupg-2.0.16-opengpgv2-sha2.patch?revision=1.1&view=markup -- Diego Elio Petten? ? ?Flameeyes? http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ From petr.uzel at suse.cz Mon Nov 15 13:27:43 2010 From: petr.uzel at suse.cz (Petr Uzel) Date: Mon, 15 Nov 2010 13:27:43 +0100 Subject: dirmngr: GPLv2+, some files GPLv3+ Message-ID: <20101115122743.GA31709@foxbat.suse.cz> Hello GnuPG developers, Novell legal team found some inconsistencies in dirmngr licensing: https://bugzilla.novell.com/show_bug.cgi?id=652989 Quoting the report: ========================= The license of dirmngr claims to be GPLv2+. In the package the files dirmngr-1.0.2.tar.bz2/dirmngr-1.0.2/doc/yat2m.c dirmngr-1.0.2.tar.bz2/dirmngr-1.0.2/src/b64dec.c were found which are licensed under the GPLv3+. In the case of doc/yat2m.c it looks as though the GPLv3 applies only to a standalone utility for converting text documents from one form into another and so probably don't have an effect on the rest of the package. However, the file src/b64dec.c may cause the entire resulting binary to be licensed under the GPLv3. Could you please comment on whether this is an intentional inclusion of GPLv3 by upstream? If so, we would need to look at the nature of interaction of the GPLv3 file with the rest of the package. In any event, the presence of the GPLv3 file should be clearly noted in the spec file (License: GPLv2+;GPLv3+) and a copy of the GPLv3 should be included with the source (this should be done anyway because of the standalone doc tool). ========================= As far as I understand, the src/b64dec.c was imported from GnuPG, which is GPLv3. Shouldn't dirmngr license be switched to GPLv3 ? Regards, Petr -- Petr Uzel IRC: ptr_uzl @ freenode -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mailinglisten at hauke-laging.de Mon Nov 15 14:11:12 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 15 Nov 2010 14:11:12 +0100 Subject: translation error for designated revorkers in German Message-ID: <201011151411.13311.mailinglisten@hauke-laging.de> Hello, gpg (GnuPG) 2.0.15 start cmd:> gpg --local-user 2D6AAED6 --edit-key 50595A3B [...] Dieser Schl?ssel k?nnte durch DSA mit Schl?ssel 0x6EE8B8B8 [?] widerrufen worden sein Dieser Schl?ssel k?nnte durch DSA mit Schl?ssel 0x864E37E7 [?] widerrufen worden sein start cmd:> LC_ALL=C gpg --local-user 2D6AAED6 --edit-key 50595A3B [...] This key may be revoked by DSA key 0x6EE8B8B8 [?] This key may be revoked by DSA key 0x864E37E7 [?] The German output would be "may have been revoked" instead of "may be revoked". That is quite confusing, especially for people not familiar with the feature of an designated revoker (like me then...). Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Mon Nov 15 17:29:27 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 15 Nov 2010 11:29:27 -0500 Subject: translation error for designated revorkers in German In-Reply-To: <201011151411.13311.mailinglisten@hauke-laging.de> References: <201011151411.13311.mailinglisten@hauke-laging.de> Message-ID: <4CE15FE7.4060405@fifthhorseman.net> On 11/15/2010 08:11 AM, Hauke Laging wrote: > Hello, > > gpg (GnuPG) 2.0.15 > > start cmd:> gpg --local-user 2D6AAED6 --edit-key 50595A3B > [...] > Dieser Schl?ssel k?nnte durch DSA mit Schl?ssel 0x6EE8B8B8 [?] widerrufen > worden sein > Dieser Schl?ssel k?nnte durch DSA mit Schl?ssel 0x864E37E7 [?] widerrufen > worden sein > > > start cmd:> LC_ALL=C gpg --local-user 2D6AAED6 --edit-key 50595A3B > [...] > This key may be revoked by DSA key 0x6EE8B8B8 [?] > This key may be revoked by DSA key 0x864E37E7 [?] > > > The German output would be "may have been revoked" instead of "may be > revoked". That is quite confusing, especially for people not familiar with the > feature of an designated revoker (like me then...). frankly, the english is ambiguous as well. I suspect this should say something like "DSA Key 0xDEADBEEF is able to revoke this key" instead. I note also that RFC 4880 appears to allow designated revokers to revoke *any* signature made by the target key, not just its self-sigs; that's not adequately conveyed by any of the above variants. Maybe: "DSA key 0xDEADBEEF is able to revoke this key and any of its signatures" ? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Mon Nov 15 18:56:45 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 15 Nov 2010 18:56:45 +0100 Subject: translation error for designated revokers in German In-Reply-To: <4CE15FE7.4060405@fifthhorseman.net> References: <201011151411.13311.mailinglisten@hauke-laging.de> <4CE15FE7.4060405@fifthhorseman.net> Message-ID: <201011151856.52298.mailinglisten@hauke-laging.de> Am Montag 15 November 2010 17:29:27 schrieb Daniel Kahn Gillmor: > frankly, the english is ambiguous as well. I suspect this should say > something like "DSA Key 0xDEADBEEF is able to revoke this key" instead. > > I note also that RFC 4880 appears to allow designated revokers to revoke > *any* signature made by the target key, not just its self-sigs; that's > not adequately conveyed by any of the above variants. Maybe: "DSA key > 0xDEADBEEF is able to revoke this key and any of its signatures" ? As "designated revoker" seems to be the usual term for this I would use that in the gpg message. Such hints are not required to explain details IMHO. "DSA Key 0xDEADBEEF is a designated revoker for this key." What this means exactly can and should be looked up in the documentation. This way the message can be constant even if the technical behaviour changes. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From dshaw at jabberwocky.com Mon Nov 15 20:38:19 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 15 Nov 2010 14:38:19 -0500 Subject: translation error for designated revorkers in German In-Reply-To: <4CE15FE7.4060405@fifthhorseman.net> References: <201011151411.13311.mailinglisten@hauke-laging.de> <4CE15FE7.4060405@fifthhorseman.net> Message-ID: <2F5C2B1A-2D1F-4032-940D-085486DD7D4B@jabberwocky.com> On Nov 15, 2010, at 11:29 AM, Daniel Kahn Gillmor wrote: > On 11/15/2010 08:11 AM, Hauke Laging wrote: >> Hello, >> >> gpg (GnuPG) 2.0.15 >> >> start cmd:> gpg --local-user 2D6AAED6 --edit-key 50595A3B >> [...] >> Dieser Schl?ssel k?nnte durch DSA mit Schl?ssel 0x6EE8B8B8 [?] widerrufen >> worden sein >> Dieser Schl?ssel k?nnte durch DSA mit Schl?ssel 0x864E37E7 [?] widerrufen >> worden sein >> >> >> start cmd:> LC_ALL=C gpg --local-user 2D6AAED6 --edit-key 50595A3B >> [...] >> This key may be revoked by DSA key 0x6EE8B8B8 [?] >> This key may be revoked by DSA key 0x864E37E7 [?] >> >> >> The German output would be "may have been revoked" instead of "may be >> revoked". That is quite confusing, especially for people not familiar with the >> feature of an designated revoker (like me then...). > > frankly, the english is ambiguous as well. I suspect this should say > something like "DSA Key 0xDEADBEEF is able to revoke this key" instead. That is correct. This message comes up when GPG sees that a designated revoker is present on the key. It is not intended to make a statement on whether the designated revoker has actually issued a revocation. David From wk at gnupg.org Mon Nov 15 20:51:48 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Nov 2010 20:51:48 +0100 Subject: dirmngr: GPLv2+, some files GPLv3+ In-Reply-To: <20101115122743.GA31709@foxbat.suse.cz> (Petr Uzel's message of "Mon, 15 Nov 2010 13:27:43 +0100") References: <20101115122743.GA31709@foxbat.suse.cz> Message-ID: <87pqu6s6uj.fsf@vigenere.g10code.de> On Mon, 15 Nov 2010 13:27, petr.uzel at suse.cz said: > The license of dirmngr claims to be GPLv2+. In the package the files > dirmngr-1.0.2.tar.bz2/dirmngr-1.0.2/doc/yat2m.c > dirmngr-1.0.2.tar.bz2/dirmngr-1.0.2/src/b64dec.c were found which are licensed > under the GPLv3+. In the case of doc/yat2m.c it looks as though the GPLv3 Well, that is possible. I see what I can do about it. > As far as I understand, the src/b64dec.c was imported from GnuPG, which is > GPLv3. > > Shouldn't dirmngr license be switched to GPLv3 ? Dirmngr development has stopped because dirmngr is now a part of GnuPG proper. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From petr.uzel at suse.cz Tue Nov 16 13:42:36 2010 From: petr.uzel at suse.cz (Petr Uzel) Date: Tue, 16 Nov 2010 13:42:36 +0100 Subject: dirmngr: GPLv2+, some files GPLv3+ In-Reply-To: <87pqu6s6uj.fsf@vigenere.g10code.de> References: <20101115122743.GA31709@foxbat.suse.cz> <87pqu6s6uj.fsf@vigenere.g10code.de> Message-ID: <20101116124236.GC27037@foxbat.suse.cz> On Mon, Nov 15, 2010 at 08:51:48PM +0100, Werner Koch wrote: > On Mon, 15 Nov 2010 13:27, petr.uzel at suse.cz said: > > > The license of dirmngr claims to be GPLv2+. In the package the files > > dirmngr-1.0.2.tar.bz2/dirmngr-1.0.2/doc/yat2m.c > > dirmngr-1.0.2.tar.bz2/dirmngr-1.0.2/src/b64dec.c were found which are licensed > > under the GPLv3+. In the case of doc/yat2m.c it looks as though the GPLv3 > > Well, that is possible. I see what I can do about it. > > > As far as I understand, the src/b64dec.c was imported from GnuPG, which is > > GPLv3. > > > > Shouldn't dirmngr license be switched to GPLv3 ? > > Dirmngr development has stopped because dirmngr is now a part of GnuPG > proper. Thank you for the reply. Regards, Petr -- Petr Uzel IRC: ptr_uzl @ freenode -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From wk at gnupg.org Tue Nov 16 14:37:30 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Nov 2010 14:37:30 +0100 Subject: dirmngr: GPLv2+, some files GPLv3+ In-Reply-To: <87pqu6s6uj.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 15 Nov 2010 20:51:48 +0100") References: <20101115122743.GA31709@foxbat.suse.cz> <87pqu6s6uj.fsf@vigenere.g10code.de> Message-ID: <87bp5pe6ed.fsf@gnupg.org> On Mon, 15 Nov 2010 20:51, wk at gnupg.org said: >> under the GPLv3+. In the case of doc/yat2m.c it looks as though the GPLv3 > > Well, that is possible. I see what I can do about it. I changed the doc files and the output of --version to make clear that it is under GPLv3+. Done in the repo only because I don't think that we will do another release. Distributions may pick up these changes. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Thu Nov 18 08:11:34 2010 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 18 Nov 2010 16:11:34 +0900 Subject: scdaemon: once error, no success any more Message-ID: <4CE4D1A6.7060500@fsij.org> Hi, I am using GnuPG 2.0.14 in Debian (gnupg2 2.0.14-2). I am reading the code of SVN trunk (revision 5485). When I mistakenly invoke 'gpg --card-status' with no token inserted, it fails. Then, I insert Gnuk Token, but 'gpg --card-status' or any card access do not get success any more. It seems that there is no way for scdaemon to recover from failure. A patch like following improves the situation. Index: scd/command.c =================================================================== --- scd/command.c (revision 5485) +++ scd/command.c (working copy) @@ -305,7 +305,11 @@ { if (apdu_reset (slot)) { +#if 0 slot_table[slot].reset_failed = 1; +#else + slot_table[slot].valid = 0; +#endif } application_notify_card_reset (slot); } @@ -394,7 +398,11 @@ /* Try to open the reader. */ if (ss->slot == -1) - ss->slot = apdu_open_reader (opt.reader_port); + { + ss->slot = apdu_open_reader (opt.reader_port); + if (ss->slot == -1) + ss->valid = 0; + } /* Return the slot_table index. */ return 0; -- From ans at immerda.ch Sun Nov 28 20:45:09 2010 From: ans at immerda.ch (Ans) Date: Sun, 28 Nov 2010 20:45:09 +0100 Subject: key lookup strategies Message-ID: <4CF2B145.8000409@immerda.ch> Hi I recently discovered that the keylookup in gpg has some funny behaviors. If i have in my keyring two keys for: foo at bar.com, oo at bar.com and foo happens to be listet before oo. When i do: gpg --encrypt -r oo at bar.com it selects the key for foo at bar.com instead of oo at bar.com I know that it uses the first key to which the pattern applies and that i could force the correct lookup using -r "" but still it seems somehow strange. wouldn't it be better to prefer exact matches before partial ones or present a selection-dialogue when using the --encrypt option? Because now it just takes any key, which happens to match first. cheers and thanks for the good work, ans. From wk at gnupg.org Mon Nov 29 12:15:33 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Nov 2010 12:15:33 +0100 Subject: key lookup strategies In-Reply-To: <4CF2B145.8000409@immerda.ch> (ans@immerda.ch's message of "Sun, 28 Nov 2010 20:45:09 +0100") References: <4CF2B145.8000409@immerda.ch> Message-ID: <87y68c4bze.fsf@vigenere.g10code.de> On Sun, 28 Nov 2010 20:45, ans at immerda.ch said: > I know that it uses the first key to which the pattern applies and that > i could force the correct lookup using -r "" but still it > seems somehow strange. As stated in the manual the default is a substring search and thus you get what you asked for. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Mon Nov 29 18:15:24 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 29 Nov 2010 18:15:24 +0100 Subject: Renaming AES to AES-128 Message-ID: <201011291815.27991.bernhard@intevation.de> What about renaming "AES" to "AES-128" in libgcrypt? Currently a user cannot see to what keylength AES refers to and some might believe it could be 256. So there is a potential for confusion which is something a security aware software should avoid of course. The code is in: http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/tags/libgcrypt-1.4.4/cipher/rijndael.c?revision=1383&root=Libgcrypt&view=markup AES128 and AES-128 already exist as aliases for "AES". Opinions? Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Nov 29 21:01:28 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Nov 2010 21:01:28 +0100 Subject: Renaming AES to AES-128 In-Reply-To: <201011291815.27991.bernhard@intevation.de> (Bernhard Reiter's message of "Mon, 29 Nov 2010 18:15:24 +0100") References: <201011291815.27991.bernhard@intevation.de> Message-ID: <87pqtn527b.fsf@vigenere.g10code.de> On Mon, 29 Nov 2010 18:15, bernhard at intevation.de said: > AES128 and AES-128 already exist as aliases for "AES". Right, in one direction. Libgcrypt happily accepts AES-128 as an alias for AES. However if we map the internal identifier back to a name we need to pich one and that happens to be "AES" for 9 years now. Changing this is an ABI break and thus not justified. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From smujohnson at gmail.com Mon Nov 29 21:31:28 2010 From: smujohnson at gmail.com (smu johnson) Date: Mon, 29 Nov 2010 12:31:28 -0800 Subject: Renaming AES to AES-128 In-Reply-To: <201011291815.27991.bernhard@intevation.de> References: <201011291815.27991.bernhard@intevation.de> Message-ID: Although I have read Werner's comments, I also think this is a great idea. The same with Blowfish for GnuPG which is uses 128 bit keys, and Twofish with 256. CAMELLIA128 has its blocksize next to it, but not the others. In addition, as you noticed, the namings where only 2 of the 3 Rijndael ciphers have the bitsize in: AES, AES196, AES256 looks a bit ramshackle and slapped together. I am not a fan of this inconsistency either. On Mon, Nov 29, 2010 at 9:15 AM, Bernhard Reiter wrote: > What about renaming "AES" to "AES-128" in libgcrypt? > Currently a user cannot see to what keylength AES refers to and some > might believe it could be 256. So there is a potential for confusion > which is something a security aware software should avoid of course. > > The code is in: > > http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/tags/libgcrypt-1.4.4/cipher/rijndael.c?revision=1383&root=Libgcrypt&view=markup > > AES128 and AES-128 already exist as aliases for "AES". > > Opinions? > > Bernhard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ans at immerda.ch Tue Nov 30 11:23:11 2010 From: ans at immerda.ch (Ans) Date: Tue, 30 Nov 2010 11:23:11 +0100 Subject: key lookup strategies In-Reply-To: <87y68c4bze.fsf@vigenere.g10code.de> References: <4CF2B145.8000409@immerda.ch> <87y68c4bze.fsf@vigenere.g10code.de> Message-ID: <4CF4D08F.1000105@immerda.ch> Hi >> I know that it uses the first key to which the pattern applies and that >> i could force the correct lookup using -r "" but still it >> seems somehow strange. > > As stated in the manual the default is a substring search and thus you > get what you asked for. Ok, i see that. But the strange thing is not that it does a substring search. The strange thing is that, when i do "gpg --encrypt -r oo at bar" (and "-r" apparently stands for *receipient*, not "search string") it just picks the first match and encrypts the mail with this key. It doesn't even say: "Warning: there were 6 matches, i'm now picking a random (*) key from those six, even though one would fit perfectly..." no it just silently takes one, which is quite strange as a user-experience. You might easily end up using the wrong key if you are not particularly careful. (or if you are using another tool to talk to gpg, which does not quote email adresses. that's how i found out...). cheers ans (*) well not random, but since i cannot influence the ordering on my keyring there's not much difference. From bernhard at intevation.de Tue Nov 30 14:40:37 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 30 Nov 2010 14:40:37 +0100 Subject: Renaming AES to AES-128 In-Reply-To: <87pqtn527b.fsf@vigenere.g10code.de> References: <201011291815.27991.bernhard@intevation.de> <87pqtn527b.fsf@vigenere.g10code.de> Message-ID: <201011301440.41070.bernhard@intevation.de> Am Montag, 29. November 2010 21:01:28 schrieb Werner Koch: > Libgcrypt happily accepts AES-128 as an alias for AES. ?However if we > map the internal identifier back to a name we need to pich one and that > happens to be "AES" for 9 years now. ?Changing this is an ABI break and > thus not justified. Leaving the primary identifier like it was, is a source of confusion which also has a cost. What is the cost and consequences of the ABI change? We could keep "AES" as an alias for backwards compatibility and mark it as deprecated so it will go away after X years. Could there be software that would still stumble then? -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From John at Mozilla-Enigmail.org Tue Nov 30 17:06:13 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Tue, 30 Nov 2010 10:06:13 -0600 Subject: key lookup strategies In-Reply-To: <4CF4D08F.1000105@immerda.ch> References: <4CF2B145.8000409@immerda.ch> <87y68c4bze.fsf@vigenere.g10code.de> <4CF4D08F.1000105@immerda.ch> Message-ID: <4CF520F5.5010304@Mozilla-Enigmail.org> Ans wrote: > Hi > >>> I know that it uses the first key to which the pattern applies and that >>> i could force the correct lookup using -r "" but still it >>> seems somehow strange. >> >> As stated in the manual the default is a substring search and thus you >> get what you asked for. > > Ok, i see that. But the strange thing is not that it does a substring > search. The strange thing is that, when i do "gpg --encrypt -r oo at bar" > (and "-r" apparently stands for *recipient*, not "search string") it > just picks the first match and encrypts the mail with this key. Actually, the syntax is -r . That name may be a fingerprint, a long or short Key ID, or a search string. A fuller explanation of the different ways to specify an ID is in the gpg man page near the bottom. For example, specifies an exact match on the email address instead of the default case-insensitive substring match. > It doesn't even say: "Warning: there were 6 matches, i'm now picking a > random (*) key from those six, even though one would fit perfectly..." > no it just silently takes one, which is quite strange as a user-experience. It is documented behavior that with multiple matching keys for signing or encryption, GnuPG will use the first usable key it finds in the keyring for the given purpose. If you wish to use a specific key, it is best to select it by the hexadecimal key ID or fingerprint. > (*) well not random, but since i cannot influence the ordering on my > keyring there's not much difference. Well, you can, but it's rather a bother. At present, keys are stored in the order in which they are imported. A key ring is just a serial collection of key packets. This behavior is subject to change in future versions. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 499 bytes Desc: OpenPGP digital signature URL: