From patrick at mozilla-enigmail.org Wed Dec 1 12:56:11 2010 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Wed, 01 Dec 2010 12:56:11 +0100 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: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 30.11.10 11:23, 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 *receipient*, not "search string") it > just picks the first match and encrypts the mail with this key. Yes, "-r" stands for "recipient" -- but the _parameter_ you specify to "-r" is a search string, not an exact match (the same rules apply e.g. to -u). Thus you receive what you've asked for. > 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...). You should ask the author of the "tool" to change the behavior. - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBTPY32Mk25cDiHiw+AQgdoAf+LSv5zdveyYpUAeq1zbeFX85HSrDuyF4X YyIiYrtosGP0LxdzgYuDo5RTMXISqOfTUmOJ4u4IaN3FDlfGCuX6kdcgzF/7EE7L q2DMnC3Ll9rc+Fgn27GMWJazzmUpvlkmEEJGKUIluo9aKnOipJNtbyER1wmbCqI3 dwSu6wVXcttgOhH+4SYTmncjpDJwANlQ2RCF7RAtj51z5HT/ReBDTtJ84Uvjnbjj UhQErtuwAmDbwfwgUu03OwnJ7kKO98J/iWNH+pVn5XZKw6vPvgtO0Tirwm8gp8Ke B5n7CAQPl6vkwP/1Eh4qtVbYE74IlWuFH9FeLHvV28zHumgYLPAhOg== =YupI -----END PGP SIGNATURE----- From wk at gnupg.org Thu Dec 2 12:32:47 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Dec 2010 12:32:47 +0100 Subject: key lookup strategies In-Reply-To: <4CF4D08F.1000105@immerda.ch> (ans@immerda.ch's message of "Tue, 30 Nov 2010 11:23:11 +0100") References: <4CF2B145.8000409@immerda.ch> <87y68c4bze.fsf@vigenere.g10code.de> <4CF4D08F.1000105@immerda.ch> Message-ID: <87ipzc2yw0.fsf@vigenere.g10code.de> On Tue, 30 Nov 2010 11:23, ans at immerda.ch said: > 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 That is why all serious tools using gpg run a key listing first to check whether there are multiple matches for a key and in that case present a selection dialog. It is not GPG's task to do that; you are not forced to use a substring search: it is just an option. You may use a complete email and then you will get a key matching this email and that key should be usable for the task. We may eventually add a warning that multiple keys match but we can't can't add another prompt to select between these. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Dec 2 12:40:24 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Dec 2010 12:40:24 +0100 Subject: Renaming AES to AES-128 In-Reply-To: <201011301440.41070.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 30 Nov 2010 14:40:37 +0100") References: <201011291815.27991.bernhard@intevation.de> <87pqtn527b.fsf@vigenere.g10code.de> <201011301440.41070.bernhard@intevation.de> Message-ID: <87eia02yjb.fsf@vigenere.g10code.de> On Tue, 30 Nov 2010 14:40, bernhard at intevation.de said: > 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? Debian alone lists 225 packages depending on libgcrypt. And there are for sure many more users. All these packages would need a rebuild and the maintainers need to go over it to figure out whether the change may affect them. You don't change an ABI if there is not a serious reason to do that. Those who want to list "AES-128" instead of AES may easily use a wrapper like const char * cipher_algo_name (int algo) { if (algo == GCRY_CIPHER_AES) return "AES-128"; else return gcry_cipher_algo_name (algo); } > deprecated so it will go away after X years. Could there be software that > would still stumble then? We can't know. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From flameeyes at gmail.com Thu Dec 2 14:41:20 2010 From: flameeyes at gmail.com (Diego Elio =?ISO-8859-1?Q?Petten=F2?=) Date: Thu, 02 Dec 2010 14:41:20 +0100 Subject: Renaming AES to AES-128 In-Reply-To: <87eia02yjb.fsf@vigenere.g10code.de> References: <201011291815.27991.bernhard@intevation.de> <87pqtn527b.fsf@vigenere.g10code.de> <201011301440.41070.bernhard@intevation.de> <87eia02yjb.fsf@vigenere.g10code.de> Message-ID: <1291297280.4756.50.camel@yamato.local> Il giorno gio, 02/12/2010 alle 12.40 +0100, Werner Koch ha scritto: > > Debian alone lists 225 packages depending on libgcrypt. And there are > for sure many more users. All these packages would need a rebuild and > the maintainers need to go over it to figure out whether the change > may > affect them. > I'll add: Gentoo users will have to rebuild them themselves, and so would FreeBSD ports users, Arch source-based users, and so on so forth. May I suggest to simply schedule this to be applied next time has to be broken for more serious issues? -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From wk at gnupg.org Thu Dec 2 15:53:12 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Dec 2010 15:53:12 +0100 Subject: gpg --list-config change ahead Message-ID: <8762vc2plz.fsf@vigenere.g10code.de> Hi, In response to Bernhard's question I changed GnuPG 2.1 to print "AES128" instead of just "AES". There is one little problem: shall we do this also for the --list-config option? It will now print $ gpg2 --list-config --with-colons ciphername cfg:ciphername:3DES;CAST5;BLOWFISH;AES128;AES192;AES256;[...] instead of $ gpg2 --list-config --with-colons ciphername cfg:ciphername:3DES;CAST5;BLOWFISH;AES;AES192;AES256;[...] Does anyone expect a real problem with this change? I think the most popular user is Enigmail - any problem to expect? Note that GPG still accepts "AES" as input (as well as "AES128" and "AES-128"); only the way we print the name changed. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From daniel at danm.de Thu Dec 2 14:22:10 2010 From: daniel at danm.de (Daniel Mueller) Date: Thu, 2 Dec 2010 14:22:10 +0100 Subject: GPGME - omit gpg-agent / pinentry passphrase dialog Message-ID: <20101202142210.630175bf@torax> Hello, is it somehow possible to omit the (configured) gpg-agent / pinentry when using libgpgme? I know that I can turn it off by editing gpg.conf (The use-agent option). In some applications I would like to use my own passphrase callback (gpgme_passphrase_cb_t) function, e.g.: - When doing advanced key editing. - When running a program as a service (Windows or Linux daemon) without any user interaction. (The program can impersonate as a different user in order to access his personal data/files). - Automated key generation / management & key signing. I could imagine that you do not want this for security reasons. If so, I'd be happy to hear your opinion and/or suggestions how to disable gpg-agent / pinentry (on Linux and Windows GPG4WIN). Thanks! Daniel -- Daniel Mueller http://danm.de Berlin, Germany OpenPGP: F9F982C1 From dshaw at jabberwocky.com Thu Dec 2 16:42:36 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 2 Dec 2010 10:42:36 -0500 Subject: Renaming AES to AES-128 In-Reply-To: References: <201011291815.27991.bernhard@intevation.de> Message-ID: <2B25CBCC-B016-4042-8D98-2BF6F8664A5F@jabberwocky.com> On Nov 29, 2010, at 3:31 PM, smu johnson wrote: > 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. It's historical - those are the names used by the RFC. User presentation of the underlying ciphers is pretty much up to the implementation, and so can (and do) vary somewhat. For example, GnuPG has a cipher called CAST5. PGP calls it CAST (no "5"). PGP calls a 256-bit AES "AES-256" while GnuPG calls it "AES256" (no hyphen), etc. Making a change like this in GnuPG is easier than for a library like libgcrypt. David From ans at immerda.ch Thu Dec 2 17:10:04 2010 From: ans at immerda.ch (Ans) Date: Thu, 02 Dec 2010 17:10:04 +0100 Subject: key lookup strategies In-Reply-To: <87ipzc2yw0.fsf@vigenere.g10code.de> References: <4CF2B145.8000409@immerda.ch> <87y68c4bze.fsf@vigenere.g10code.de> <4CF4D08F.1000105@immerda.ch> <87ipzc2yw0.fsf@vigenere.g10code.de> Message-ID: <4CF7C4DC.4030103@immerda.ch> Hi > That is why all serious tools using gpg run a key listing first to check > whether there are multiple matches for a key and in that case present a > selection dialog. It is not GPG's task to do that; you are not forced > to use a substring search: it is just an option. You may use a complete > email and then you will get a key matching this email and that key > should be usable for the task. Thanks to all for the explanations. It makes sense to me now and it's also documented correctly. > We may eventually add a warning that multiple keys match but we can't > can't add another prompt to select between these. That would be a nice feature, I think. cheers, Ans From dshaw at jabberwocky.com Thu Dec 2 17:16:07 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 2 Dec 2010 11:16:07 -0500 Subject: gpg --list-config change ahead In-Reply-To: <8762vc2plz.fsf@vigenere.g10code.de> References: <8762vc2plz.fsf@vigenere.g10code.de> Message-ID: On Dec 2, 2010, at 9:53 AM, Werner Koch wrote: > Hi, > > In response to Bernhard's question I changed GnuPG 2.1 to print "AES128" > instead of just "AES". There is one little problem: shall we do this > also for the --list-config option? It will now print > > $ gpg2 --list-config --with-colons ciphername > cfg:ciphername:3DES;CAST5;BLOWFISH;AES128;AES192;AES256;[...] > > instead of > > $ gpg2 --list-config --with-colons ciphername > cfg:ciphername:3DES;CAST5;BLOWFISH;AES;AES192;AES256;[...] > > Does anyone expect a real problem with this change? I think the most > popular user is Enigmail - any problem to expect? I wonder if it might be worthwhile outputting something like:\ cfg:ciphername:3DES;CAST5;BLOWFISH;AES;AES128;AES192;[...] That is, list both AES and AES128. After all, they are both valid cipher names - they just happen to be the same cipher. A front-end that just uses this list of strings as possible ciphers would automatically do the right thing here (albeit having two cipher names that do the same thing). David From wk at gnupg.org Thu Dec 2 18:14:29 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Dec 2010 18:14:29 +0100 Subject: Renaming AES to AES-128 In-Reply-To: <1291297280.4756.50.camel@yamato.local> ("Diego Elio =?utf-8?Q?Petten=C3=B2=22's?= message of "Thu, 02 Dec 2010 14:41:20 +0100") References: <201011291815.27991.bernhard@intevation.de> <87pqtn527b.fsf@vigenere.g10code.de> <201011301440.41070.bernhard@intevation.de> <87eia02yjb.fsf@vigenere.g10code.de> <1291297280.4756.50.camel@yamato.local> Message-ID: <871v602j2i.fsf@vigenere.g10code.de> On Thu, 2 Dec 2010 14:41, flameeyes at gmail.com said: > May I suggest to simply schedule this to be applied next time has to be > broken for more serious issues? We don't hope that this will ever be the case. In fact, even if we are going to change the way a function works we will be able to keep the old function as well as the new one (cf. symbol versioning ala glibc). At least on real OSes. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Dec 2 18:18:39 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Dec 2010 18:18:39 +0100 Subject: GPGME - omit gpg-agent / pinentry passphrase dialog In-Reply-To: <20101202142210.630175bf@torax> (Daniel Mueller's message of "Thu, 2 Dec 2010 14:22:10 +0100") References: <20101202142210.630175bf@torax> Message-ID: <87wrns14b4.fsf@vigenere.g10code.de> On Thu, 2 Dec 2010 14:22, daniel at danm.de said: > is it somehow possible to omit the (configured) gpg-agent / pinentry > when using libgpgme? I know that I can turn it off by editing gpg.conf > (The use-agent option). No, that is not possible. Look at the 2.1 beta and you will see why: gpg-agent is now a mandatory part of gpg because it is used for all public key operations involving a secret key. If you want to use your own pinentry, you may do so: We provide envvars passed to the pinentry which can be set by the application to convey information to the pinentry. Such a pinentry may then loop back to the application. gpg-preset-passphrase(1) is another option to control passphrase entry. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Dec 2 18:25:04 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Dec 2010 18:25:04 +0100 Subject: gpg --list-config change ahead In-Reply-To: (David Shaw's message of "Thu, 2 Dec 2010 11:16:07 -0500") References: <8762vc2plz.fsf@vigenere.g10code.de> Message-ID: <87sjyg140f.fsf@vigenere.g10code.de> On Thu, 2 Dec 2010 17:16, dshaw at jabberwocky.com said: > That is, list both AES and AES128. After all, they are both valid cipher names - they just happen to be the same cipher. A front-end that just uses this list of strings as possible ciphers would automatically do the right thing here (albeit having two cipher names that do the same thing). I was pondering this too. It might however also raise user questions. Tools should be safe, though. The other option is to keep using AES here and have tools using --list-config translate it to AES128 (or AES-128). OTOH, there are some changes in 2.1 where tools may run into problems as well; for example the now ignored secring.gpg. And more changes which, in theory, are not user visible are too come soon. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From daniel at danm.de Thu Dec 2 21:59:36 2010 From: daniel at danm.de (Daniel Mueller) Date: Thu, 2 Dec 2010 21:59:36 +0100 Subject: GPGME - omit gpg-agent / pinentry passphrase dialog In-Reply-To: <87wrns14b4.fsf@vigenere.g10code.de> References: <20101202142210.630175bf@torax> <87wrns14b4.fsf@vigenere.g10code.de> Message-ID: <20101202215936.38c4f9ff@torax> On Thu, 02 Dec 2010 18:18:39 +0100 Werner Koch wrote: Thanks for your fast answer! > gpg-preset-passphrase(1) is another option > to control passphrase entry. Hey, this sounds like an appropriate solution. Does GPGME provide any functions that will help me to interact with gpg-agent and call gpg-preset-passphrase? (I haven't see such a function in GPGME's info page). I'd rather use libgpgme for ALL GnuPG related tasks instead of calling gpg-preset-passphrase directly from my application. It would be really nice if I could provide a list with (keyid,passwd) pairs to libgpgme. bye, Daniel -- Daniel Mueller http://danm.de Berlin, Germany OpenPGP: F9F982C1 From wk at gnupg.org Thu Dec 2 23:34:30 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Dec 2010 23:34:30 +0100 Subject: GPGME - omit gpg-agent / pinentry passphrase dialog In-Reply-To: <20101202215936.38c4f9ff@torax> (Daniel Mueller's message of "Thu, 2 Dec 2010 21:59:36 +0100") References: <20101202142210.630175bf@torax> <87wrns14b4.fsf@vigenere.g10code.de> <20101202215936.38c4f9ff@torax> Message-ID: <87k4jr2495.fsf@vigenere.g10code.de> On Thu, 2 Dec 2010 21:59, daniel at danm.de said: > functions that will help me to interact with gpg-agent and call > gpg-preset-passphrase? (I haven't see such a function in GPGME's info No; the idea behind gpg-preset-passphrase is to enable server applications to do an appropriate startup initialization (e.g. boot time prompt). It is not designed to work with arbitrary applications. In general it is questionable to rely on passphrases to protect a secret key while at the same time storing the passphrase somewhere else to mimic a passphrase entry. Better don't use a passphrase then. In case the goal is to have an interactive application with an integrated passphrase dialog, I suggest a loop back pinentry. That might even be a more or less standard pinentry with its top window embedded in the application. Or for web applications use the PINENTRY_USER_DATA envvar to pass the required state around. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From flameeyes at gmail.com Fri Dec 3 00:55:37 2010 From: flameeyes at gmail.com (Diego Elio =?ISO-8859-1?Q?Petten=F2?=) Date: Fri, 03 Dec 2010 00:55:37 +0100 Subject: Renaming AES to AES-128 In-Reply-To: <871v602j2i.fsf@vigenere.g10code.de> References: <201011291815.27991.bernhard@intevation.de> <87pqtn527b.fsf@vigenere.g10code.de> <201011301440.41070.bernhard@intevation.de> <87eia02yjb.fsf@vigenere.g10code.de> <1291297280.4756.50.camel@yamato.local> <871v602j2i.fsf@vigenere.g10code.de> Message-ID: <1291334137.4756.107.camel@yamato.local> Il giorno gio, 02/12/2010 alle 18.14 +0100, Werner Koch ha scritto: > > We don't hope that this will ever be the case. In fact, even if we > are > going to change the way a function works we will be able to keep the > old > function as well as the new one (cf. symbol versioning ala glibc). At > least on real OSes. > Yes and no? symbol versioning is not as perfect as we'd like all to be, from time to time an ABI break can have its advantages. And don't be overconfident that "real OSes" mean glibc? > -- 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 wk at gnupg.org Thu Dec 9 18:07:20 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 09 Dec 2010 18:07:20 +0100 Subject: [Encfs-users] GnuPG support In-Reply-To: (Valient Gough's message of "Tue, 7 Dec 2010 01:24:05 -0800") References: <87oc9xwd8r.fsf@vigenere.g10code.de> Message-ID: <87tyimswmv.fsf@gnupg.org> On Tue, 7 Dec 2010 10:24, valient at gmail.com said: > Hi. I've checked in your change, although it didn't all apply > automatically, so hopefully the result is correct - see below. It looks good. I have not done any test because g13 development is currently a bit stalled; I'll test it before doing a new betat release. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Fri Dec 10 17:05:17 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 10 Dec 2010 17:05:17 +0100 Subject: de.po minifox Message-ID: <201012101705.23780.bernhard@intevation.de> -- 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: de.po-r5487.diff Type: text/x-diff Size: 388 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3696 bytes Desc: not available URL: From bernhard at intevation.de Fri Dec 10 18:11:38 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 10 Dec 2010 18:11:38 +0100 Subject: Renaming AES to AES-128 In-Reply-To: <87eia02yjb.fsf@vigenere.g10code.de> References: <201011291815.27991.bernhard@intevation.de> <201011301440.41070.bernhard@intevation.de> <87eia02yjb.fsf@vigenere.g10code.de> Message-ID: <201012101811.42299.bernhard@intevation.de> Am Donnerstag, 2. Dezember 2010 12:40:24 schrieb Werner Koch: > On Tue, 30 Nov 2010 14:40, bernhard at intevation.de said: > > 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? > > Debian alone lists 225 packages depending on libgcrypt. And there are > for sure many more users. All these packages would need a rebuild and > the maintainers need to go over it to figure out whether the change may > affect them. Can you explain briefly to me, why they would need a rebuild and why ABI usage is really broken? I mean applications with use gcry_cipher_open(x,GCRY_CIPHER_AES,..) and this will just continue to work. Okay gcry_cipher_algo_name(GCRY_CIPHER_AES) would return "AES-128" instead of "AES", but does this really warrant a rebuild? The index number just stays the same. > You don't change an ABI if there is not a serious reason to do that. > > Those who want to list "AES-128" instead of AES may easily use a wrapper > like > > const char * > cipher_algo_name (int algo) > { > if (algo == GCRY_CIPHER_AES) > return "AES-128"; > else > return gcry_cipher_algo_name (algo); > } So we could do this for gpg2 --version? > > deprecated so it will go away after X years. Could there be software that > > would still stumble then? > > We can't know. The list of supported algos will evolve over time, why not change the behaviour here? -- 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 rjh at sixdemonbag.org Fri Dec 10 19:37:03 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 10 Dec 2010 13:37:03 -0500 Subject: Renaming AES to AES-128 In-Reply-To: <201012101811.42299.bernhard@intevation.de> References: <201011291815.27991.bernhard@intevation.de> <201011301440.41070.bernhard@intevation.de> <87eia02yjb.fsf@vigenere.g10code.de> <201012101811.42299.bernhard@intevation.de> Message-ID: <4D02734F.30008@sixdemonbag.org> On 12/10/10 12:11 PM, Bernhard Reiter wrote: > Okay gcry_cipher_algo_name(GCRY_CIPHER_AES) would return "AES-128" > instead of "AES", but does this really warrant a rebuild? The index number > just stays the same. The problem is we don't know how many third-party apps are hardwired to expect "AES" instead of "AES-128." I suspect the answer is "a lot more than we think." From wk at gnupg.org Fri Dec 10 20:53:30 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 Dec 2010 20:53:30 +0100 Subject: Renaming AES to AES-128 In-Reply-To: <4D02734F.30008@sixdemonbag.org> (Robert J. Hansen's message of "Fri, 10 Dec 2010 13:37:03 -0500") References: <201011291815.27991.bernhard@intevation.de> <201011301440.41070.bernhard@intevation.de> <87eia02yjb.fsf@vigenere.g10code.de> <201012101811.42299.bernhard@intevation.de> <4D02734F.30008@sixdemonbag.org> Message-ID: <874oalflqd.fsf@vigenere.g10code.de> On Fri, 10 Dec 2010 19:37, rjh at sixdemonbag.org said: > The problem is we don't know how many third-party apps are hardwired to > expect "AES" instead of "AES-128." I suspect the answer is "a lot more > than we think." In particular interpretive languages often prefer the use of strings to identifiers. Thus a if algo = "AES" then keysize = 128 would fail. In any case I changed the human readable output and that should fix the problems some people have with the way the algorithm name is printed. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Mon Dec 13 01:19:54 2010 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 13 Dec 2010 09:19:54 +0900 Subject: Gnuk version 0.5 Message-ID: <4D0566AA.7040001@fsij.org> Gnuk version 0.5 is out. Highlights are: * New board support: STM32 part of "STM8S Discovery" We can buy it at 750JPY in Japan (10USD or so internationally?). I think that it is most cheap board for Gnuk. * Better interoperability * In-stock GPG ccid-driver * Although in-stock GPG ccid-driver doesn't support extended APDU level exchange (and chaining), it is now possible for Gnuk to do digital signing. * GPG4WIN * Gnuk works somehow now. * Bug fixes: * Digital signing for SHA224/SHA256/SHA384/SHA512 digestInfo is now possible. (It only worked for SHA1) * Digital signing multiple times with single authentication is now possible. Enjoy, -- From angelarifb at gmail.com Mon Dec 13 20:35:06 2010 From: angelarifb at gmail.com (Eugene Zola) Date: Mon, 13 Dec 2010 21:35:06 +0200 Subject: Post positive reviews Message-ID: Google?s Huge Change and How it affects you. ? Anyone can now post bad reviews and kill your rank. ? We post good reviews and improve your rank. ? We post good reviews to keep others from killing your rank. Google: Judge, Jury and Online Shopping Executioner Google rank is based on reviews of your business? Google Statement: "...in the last few days we developed an algorithmic solution which detects the merchant from the Times article along with hundreds of other merchants that, in our opinion, provide an extremely poor user experience. The algorithm we incorporated into our search rankings represents an initial solution to this issue, and Google users are now getting a better experience as a result." This means that anyone can write bad reviews about your business and lower your ranking. We knew that getting good reviews and not getting bad reviews was always important. Now it is a must to have good reviews for your business to keep the rank safe or to improve rank with Google. We post positive reviews for your company. We have the experience and ability to post hundreds of positive reviews that are all unique content and posted on unique IP addresses. Visit www.postpositivereviews.com for more information. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Wed Dec 15 10:06:17 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 15 Dec 2010 10:06:17 +0100 Subject: Renaming AES to AES-128 In-Reply-To: <874oalflqd.fsf@vigenere.g10code.de> References: <201011291815.27991.bernhard@intevation.de> <4D02734F.30008@sixdemonbag.org> <874oalflqd.fsf@vigenere.g10code.de> Message-ID: <201012151006.20891.bernhard@intevation.de> Am Freitag, 10. Dezember 2010 20:53:30 schrieb Werner Koch: > On Fri, 10 Dec 2010 19:37, rjh at sixdemonbag.org said: > > The problem is we don't know how many third-party apps are hardwired to > > expect "AES" instead of "AES-128." ?I suspect the answer is "a lot more > > than we think." They SHOULD use the algorithm id, I presume. Maybe we can make this a stronger requirement or recommendation for the future. I something believe that we should be able to change the string representation without major problems at least at major revisions. Third party applications would then need to adjust. > In particular interpretive languages often prefer the use of strings to > identifiers. ?Thus a > ? if algo = "AES" then keysize = 128 > would fail. This makes two assumptions that this code should not do, once it does not use the algo id and secondly it uses internal knowledge of what this string will lead do, aka guessing the keysize. I believe a lot of the design should be done that frontends to not do too much guessing here, otherwise they will have to expect to change sooner or later. > In any case I changed the human readable output and that should fix the > problems some people have with the way the algorithm name is printed. Wonderful! 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 bernhard at intevation.de Wed Dec 15 10:14:59 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 15 Dec 2010 10:14:59 +0100 Subject: gpg --list-config change ahead In-Reply-To: <8762vc2plz.fsf@vigenere.g10code.de> References: <8762vc2plz.fsf@vigenere.g10code.de> Message-ID: <201012151015.00112.bernhard@intevation.de> Am Donnerstag, 2. Dezember 2010 15:53:12 schrieb Werner Koch: > In response to Bernhard's question I changed GnuPG 2.1 to print "AES128" > instead of just "AES". ?There is one little problem: shall we do this > also for the --list-config option? ?It will now print > > ? $ gpg2 --list-config --with-colons ciphername > ? cfg:ciphername:3DES;CAST5;BLOWFISH;AES128;AES192;AES256;[...] I wonder: Shouldn't this be accessible by gpgconf as well? If it should not, at least a hint in the documentation of gpgconf would be nice, I was reading this lately to see if I could find out all the valid values for some of the options that gpgconf can set. So the hint would have been useful to me. -- 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 bernhard at intevation.de Wed Dec 15 10:18:31 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 15 Dec 2010 10:18:31 +0100 Subject: gpg --list-config change ahead In-Reply-To: <87sjyg140f.fsf@vigenere.g10code.de> References: <8762vc2plz.fsf@vigenere.g10code.de> <87sjyg140f.fsf@vigenere.g10code.de> Message-ID: <201012151018.32325.bernhard@intevation.de> Am Donnerstag, 2. Dezember 2010 18:25:04 schrieb Werner Koch: > On Thu, ?2 Dec 2010 17:16, dshaw at jabberwocky.com said: > > That is, list both AES and AES128. ?After all, they are both valid cipher > > names - they just happen to be the same cipher. ?A front-end that just > > uses this list of strings as possible ciphers would automatically do the > > right thing here (albeit having two cipher names that do the same thing). > > I was pondering this too. ?It might however also raise user questions. > Tools should be safe, though. If one alias is listed, all aliases should be listed. If we list the aliases, ideally they would be marked as aliases for the primary name. So right now, I'd say that AES128 should only be listed as new primary name and the list should only have primary names. > The other option is to keep using AES > here and have tools using --list-config translate it to AES128 (or > AES-128). I'd rather do the change. -- 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 rjh at sixdemonbag.org Wed Dec 15 14:45:32 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 15 Dec 2010 08:45:32 -0500 Subject: Renaming AES to AES-128 In-Reply-To: <201012151006.20891.bernhard@intevation.de> References: <201011291815.27991.bernhard@intevation.de> <4D02734F.30008@sixdemonbag.org> <874oalflqd.fsf@vigenere.g10code.de> <201012151006.20891.bernhard@intevation.de> Message-ID: <4D08C67C.10208@sixdemonbag.org> On 12/15/2010 4:06 AM, Bernhard Reiter wrote: > They SHOULD use the algorithm id, I presume. Unfortunately, in engineering SHOULD means, "it is important I do it, and equally important I expect nobody else will." You can't make the world conform to a SHOULD, only a MUST, and even then it can be hard. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From wk at gnupg.org Wed Dec 15 19:58:03 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 15 Dec 2010 19:58:03 +0100 Subject: gpg --list-config change ahead In-Reply-To: <201012151015.00112.bernhard@intevation.de> (Bernhard Reiter's message of "Wed, 15 Dec 2010 10:14:59 +0100") References: <8762vc2plz.fsf@vigenere.g10code.de> <201012151015.00112.bernhard@intevation.de> Message-ID: <87wrnadft0.fsf@vigenere.g10code.de> On Wed, 15 Dec 2010 10:14, bernhard at intevation.de said: > I wonder: Shouldn't this be accessible by gpgconf as well? No, gpgconf uses its own configuration subsystem. --list-config is mainly for enigmail. Newer tools shall use gpgconf; gpgme has support for it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Thu Dec 16 09:35:40 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 16 Dec 2010 09:35:40 +0100 Subject: gpg --list-config change ahead In-Reply-To: <87wrnadft0.fsf@vigenere.g10code.de> References: <8762vc2plz.fsf@vigenere.g10code.de> <201012151015.00112.bernhard@intevation.de> <87wrnadft0.fsf@vigenere.g10code.de> Message-ID: <201012160935.44476.bernhard@intevation.de> Am Mittwoch, 15. Dezember 2010 19:58:03 schrieb Werner Koch: > On Wed, 15 Dec 2010 10:14, bernhard at intevation.de said: > > I wonder: Shouldn't this be accessible by gpgconf as well? > > No, gpgconf uses its own configuration subsystem. ?--list-config is > mainly for enigmail. ?Newer tools shall use gpgconf; gpgme has support > for it. Okay, how do I find out the list of possible parameters to show with gpgconf then? 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 Thu Dec 16 19:08:16 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Dec 2010 19:08:16 +0100 Subject: gpg --list-config change ahead In-Reply-To: <201012160935.44476.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 16 Dec 2010 09:35:40 +0100") References: <8762vc2plz.fsf@vigenere.g10code.de> <201012151015.00112.bernhard@intevation.de> <87wrnadft0.fsf@vigenere.g10code.de> <201012160935.44476.bernhard@intevation.de> Message-ID: <87hbedd20f.fsf@vigenere.g10code.de> On Thu, 16 Dec 2010 09:35, bernhard at intevation.de said: > Okay, how do I find out the list of possible parameters to show > with gpgconf then? We talked about this in the past. To accomplish this we need to define more types in gpgconf. This can be done but someone needs to do it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From patrick at mozilla-enigmail.org Fri Dec 17 11:24:01 2010 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Fri, 17 Dec 2010 11:24:01 +0100 Subject: gpg --list-config change ahead In-Reply-To: <87wrnadft0.fsf@vigenere.g10code.de> References: <8762vc2plz.fsf@vigenere.g10code.de> <201012151015.00112.bernhard@intevation.de> <87wrnadft0.fsf@vigenere.g10code.de> Message-ID: On 15.12.10 19:58, Werner Koch wrote: > On Wed, 15 Dec 2010 10:14, bernhard at intevation.de said: > >> I wonder: Shouldn't this be accessible by gpgconf as well? > > No, gpgconf uses its own configuration subsystem. --list-config is > mainly for enigmail. Newer tools shall use gpgconf; gpgme has support > for it. Enigmail does not use "ciphername", so I don't see a problem with changing its contents. -Patrick From smujohnson at gmail.com Thu Dec 23 19:26:33 2010 From: smujohnson at gmail.com (smu johnson) Date: Thu, 23 Dec 2010 10:26:33 -0800 Subject: Block cipher mode? Message-ID: Hi, I was wondering what anyone thought of including which block cipher mode gpg uses in the -v[erbose] mode. My guess is it's using CBC, but without digging up the source and finding out for myself and asking here, who can say? I didn't find it in the FAQ, either. Since -v tells you which ciphers it uses, eg. "gpg: RSA/TWOFISH encrypted for: ", it doesn't seem too out of place to add the mode there either. Any thoughts? -- smu johnson -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.leidert.spam at gmx.net Fri Dec 31 13:00:33 2010 From: daniel.leidert.spam at gmx.net (Daniel Leidert) Date: Fri, 31 Dec 2010 13:00:33 +0100 Subject: Issues with the change to git - typos and errors cloning the repository Message-ID: <1293796833.4153.4.camel@haktar.wgdd.de> Hi, This is to report some issues I observe trying to get the source code: (1) The git clone command fails git clone git://git.gnupg.org/gnupg.git Cloning into gnupg... fatal: The remote end hung up unexpectedly (2) The site http://git.gnupg.org/ says: got clone git://git.gnupg.org/foo.git ^ Note the typo: s/got/git. (3) http://git.gnupg.org/cgi-bin/gitweb.cgi says "cvs.gnupg.org Git ...". Why does the title say "cvs.gnupg.org" and not git.g.o? Regards, Daniel From wk at gnupg.org Fri Dec 31 17:37:00 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 31 Dec 2010 17:37:00 +0100 Subject: Issues with the change to git - typos and errors cloning the repository In-Reply-To: <1293796833.4153.4.camel@haktar.wgdd.de> (Daniel Leidert's message of "Fri, 31 Dec 2010 13:00:33 +0100") References: <1293796833.4153.4.camel@haktar.wgdd.de> Message-ID: <87zkrl99w3.fsf@vigenere.g10code.de> On Fri, 31 Dec 2010 13:00, daniel.leidert.spam at gmx.net said: > git clone git://git.gnupg.org/gnupg.git > Cloning into gnupg... > fatal: The remote end hung up unexpectedly git-daemon-export-ok was missing for that repo. I just fixed it. I'll take care of the other problems next year. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.