From john.marshall at riverwillow.com.au Thu Jul 2 15:42:46 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Thu, 2 Jul 2009 23:42:46 +1000 Subject: pgp.mit.edu upgrading to SKS Message-ID: <20090702134246.GS996@rwpc12.mby.riverwillow.net.au> It might be of more than passing interest to readers of this list to know that pgp.mit.edu migrated from PKS 0.9.6 to SKS 1.1.0 today. -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From wk at gnupg.org Thu Jul 2 16:45:52 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Jul 2009 16:45:52 +0200 Subject: pgp.mit.edu upgrading to SKS In-Reply-To: <20090702134246.GS996@rwpc12.mby.riverwillow.net.au> (John Marshall's message of "Thu, 2 Jul 2009 23:42:46 +1000") References: <20090702134246.GS996@rwpc12.mby.riverwillow.net.au> Message-ID: <87zlbn6t3z.fsf@wheatstone.g10code.de> On Thu, 2 Jul 2009 15:42, john.marshall at riverwillow.com.au said: > It might be of more than passing interest to readers of this list to > know that pgp.mit.edu migrated from PKS 0.9.6 to SKS 1.1.0 today. Really great. This should finally fix one of the major problems with the keyservers. Now lets see whether the minor SKS bugs will be fixed ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Fri Jul 3 00:28:00 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 2 Jul 2009 18:28:00 -0400 Subject: pgp.mit.edu upgrading to SKS In-Reply-To: <87zlbn6t3z.fsf@wheatstone.g10code.de> References: <20090702134246.GS996@rwpc12.mby.riverwillow.net.au> <87zlbn6t3z.fsf@wheatstone.g10code.de> Message-ID: <8154EB35-8407-46F4-839C-F0922D35AAEF@jabberwocky.com> On Jul 2, 2009, at 10:45 AM, Werner Koch wrote: > On Thu, 2 Jul 2009 15:42, john.marshall at riverwillow.com.au said: > >> It might be of more than passing interest to readers of this list to >> know that pgp.mit.edu migrated from PKS 0.9.6 to SKS 1.1.0 today. > > Really great. This should finally fix one of the major problems with > the keyservers. Indeed. Now we just need to lean on the few remaining PKS installations and get them switch, or even just shut down altogether. I hate to reduce the number of keyservers out there, but at this point, we have a lot of subkey-safe servers, and losing a few non-safe ones isn't the end of the world. David From arfrever.fta at gmail.com Sun Jul 5 04:40:03 2009 From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 5 Jul 2009 04:40:03 +0200 Subject: pinentry-0.7.6: Ctrl+V doesn't work with pinentry-qt4 Message-ID: <200907050440.08807.Arfrever.FTA@gmail.com> I noticed that Ctrl+V doesn't work with new pinentry-qt4 program, but it works with Qt-3-based pinentry-qt. -- Arfrever Frehtes Taifersar Arahesis -------------- 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 dkg at fifthhorseman.net Mon Jul 6 23:52:59 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 06 Jul 2009 17:52:59 -0400 Subject: updating default digest preferences Message-ID: <4A52723B.1040004@fifthhorseman.net> Hi folks-- with new versions of gpg pending, is there any chance of getting the default key preferences updated, as referenced here: https://bugs.g10code.com/gnupg/issue1057 Are there problems with that patch that are keeping it from being applied? Are there objections to including stronger preference indicators in new keys? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Jul 7 11:00:47 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 07 Jul 2009 11:00:47 +0200 Subject: scim and pinentry-gtk2 In-Reply-To: <4A3AE108.8010905@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "19 Jun 2009 02:51:20 +0200") References: <47BDF11A.8010500@rlworkman.net> <87hcfvg8wu.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47E09E50.8040106@rlworkman.net> <87myo5wkg3.wl%marcus.brinkmann@ruhr-uni-bochum.de> <87myo45rkb.fsf@wheatstone.g10code.de> <4A3AE108.8010905@ruhr-uni-bochum.de> Message-ID: <87fxd827gg.fsf@wheatstone.g10code.de> On Fri, 19 Jun 2009 02:51, marcus.brinkmann at ruhr-uni-bochum.de said: > GTK_IM_MODULE used by gtk to select gtk input modules (eg "scim-bridge") > XMODIFIERS used by Xlib to select X input modules (eg "@im=SCIM") > QT_IM_MODUL used by Qt to select qt input modules (eg "xim") > > The fun is that we need to pass through all three variables, because we don't > know which backend the pinentry actually uses. That was really a lot work. I had to rewrite the entire passing of environment variables code in GnuPG. It is in SVN r 5064. I did some quick tests using a pinentry-wrapper and could verify that GTK+ shows that Scim is active. I hope that there are no regressions regarding the passing of locale information and other environment variables. Running a complete test on all combinations of command line args, environment variables and Assuan options is way too time consuming, thus I hope for the best. If you want to add more environment variables; this is now pretty easy: Add them to the list in common/session-env.c. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Wed Jul 8 10:07:31 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 08 Jul 2009 10:07:31 +0200 Subject: scim and pinentry-gtk2 In-Reply-To: <20090707130627.69553d5c@liberty.rlwhome.lan> (Robby Workman's message of "Tue, 7 Jul 2009 13:06:27 -0500") References: <47BDF11A.8010500@rlworkman.net> <87hcfvg8wu.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47E09E50.8040106@rlworkman.net> <87myo5wkg3.wl%marcus.brinkmann@ruhr-uni-bochum.de> <87myo45rkb.fsf@wheatstone.g10code.de> <4A3AE108.8010905@ruhr-uni-bochum.de> <87fxd827gg.fsf@wheatstone.g10code.de> <20090707130627.69553d5c@liberty.rlwhome.lan> Message-ID: <87prcby4vw.fsf@wheatstone.g10code.de> On Tue, 7 Jul 2009 20:06, rw at rlworkman.net said: > 13.0 release out the door, but I'll try to pull svn and test this as > soon as possible... I have not yet used Scim or any other IM, thus I only checked whether Gtk+ detects that. I checked this by passing the -e option to Pinentry (via a wrapper); this options shows an additional entry field. What I don't understand is how Scim can help entering the passphrase given that a right click on the passphrase entry doesn't show the selection module. Do we need a special Pinentry tool, or did I just missed something? In case Scim works with the regular Pinentry; we will need a way to disable this: By design Pinentry shall limit the exposure of the passphrase to as least code/memory as possible - now if it would be passed back and forth to Scim this is not anymore the case. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bernhard at intevation.de Wed Jul 8 15:39:03 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 8 Jul 2009 15:39:03 +0200 Subject: new pinentry release with qt4 support? In-Reply-To: <4A45E3EE.3090501@ruhr-uni-bochum.de> References: <4A45E3EE.3090501@ruhr-uni-bochum.de> Message-ID: <200907081539.06997.bernhard@intevation.de> Am Samstag, 27. Juni 2009 11:18:38 schrieb Marcus Brinkmann: > Rex Dieter wrote: > >> Simply go to the qt4 directory and execute moc manually: > >> > >> moc pinentrydialog.h > pinentrydialog.moc > >> moc qsecurelineedit.h > qsecurelineedit.moc > > > > Eww... that's far from ideal. ?This will likely trip up most folks > > building the qt4 frontend, hopefully a better solution will come along > > soon. > > > > > > *cough* cmake? ?*cough* ?:) > > If you can't say it without coughing, it ain't gonna happen :) > > If you know how to improve the configure checks, you know where to send > patches. ?Heck, if it's possible to run cmake from configure that could > even be an option, too. ?But the i586-mingw32msvc cross-compilation case > needs to work (that is _our_ requirement). ?Apart from that, my only idea > is to remove pinentry-qt(3), which could make writing configure checks > easier. We must keep pinentry-qt3, has KDE35 is still the stable and recommended version in many distributions. > It's true that we spoiled the most simple case, but we just don't have the > resources to cover all the cases, and the help from people who know what > the qt folks are up to is required here (but they are not interested in > autoconf :-/). Qt folks are trying to be nice as well. If you can summarize the problem they'll sure help it to a solution. Without diving into it too much it looks like adding a manual run for these two files is not too problematic, is it? Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.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 Jul 8 15:57:42 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 8 Jul 2009 15:57:42 +0200 Subject: gpgsm: Cipher default: 3DES, because of OL2003 and Outlook2007 In-Reply-To: <200902061820.51760.bernhard@intevation.de> References: <200902061820.51760.bernhard@intevation.de> Message-ID: <200907081557.46441.bernhard@intevation.de> Am Freitag, 6. Februar 2009 18:20:51 schrieb Bernhard Reiter: > It seems that Outlook 2003 cannot deal with AES encrypted > S/MIME emails and even spits out some error message which is unhelpful. > At least in German is says something about an ID not found. The German message, btw, is: Dieses Element kann nicht ge?ffnet werden. Der Name Ihrer digitalen ID konnte im zugrunde liegenden Sicherheitssystem nicht gefunden werden. While they mean that the encryption algorithm is not supported by the crypto backend. Note that some versions of Outlook 2007 (OL2007) also do _not_ support AES. One that does _not_: MS Office Outlook 2007 (12.0.6504.5000) SP2 MSO (12.0.6425.1000) Windows XP Prof. 2002 SP3 One that _does_ AES: Outlook 2007 (12.0.6316.5000) SP1 MSO (12.0.6320.5000) Microsoft Windows Vista Business 6.0.6000 Build 6000 > So the default for gpgsm should be 3DES. > (For 2.0.10 is was changed to AES, and this causes us to detect the > interoperability problem.) The default was changed for good to 3DES in the gnupg 2.0.11 release. > Note, to find out the default encryption cipher, you could use the > command: gpgconf --list-options gpgsm > (or the internal version gpgsm --gpgconf-list ) Note that some versions of gnupg, e.g. 2.0.9-svn4835-0kk3 will show a wrong default via gpgconf --list-options . They show '"3DES', but use 'AES'. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.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 Jul 9 09:45:23 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 09 Jul 2009 09:45:23 +0200 Subject: updating default digest preferences In-Reply-To: <4A52723B.1040004@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 06 Jul 2009 17:52:59 -0400") References: <4A52723B.1040004@fifthhorseman.net> Message-ID: <87vdm2uwoc.fsf@wheatstone.g10code.de> On Mon, 6 Jul 2009 23:52, dkg at fifthhorseman.net said: > with new versions of gpg pending, is there any chance of getting the > default key preferences updated, as referenced here: Done a bit different for 2.0; the default hash algo order is now: SHA-256, SHA-1, SHA-384, SHA-512, SHA-224. Ordering SHA-1 before SHA-384 might be viewed as a bit strange; it is done because we expect that soon enough SHA-3 will be available and at that point there should be no more need for SHA-384 etc. Anyway this order is just a default and can easily be changed by a config option. I also changed the Q parameter for 2048 bit DSA keys: Is is now 256 so that a full SHA-256 is used and people won't wonder whether SHA-224 or a truncated SHA-256 will be used. In non-expert mode DSA-2 keys are rounded towards a multiple of 1024. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dkg at fifthhorseman.net Thu Jul 9 16:18:19 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 09 Jul 2009 10:18:19 -0400 Subject: updating default digest preferences In-Reply-To: <87vdm2uwoc.fsf@wheatstone.g10code.de> References: <4A52723B.1040004@fifthhorseman.net> <87vdm2uwoc.fsf@wheatstone.g10code.de> Message-ID: <4A55FC2B.80807@fifthhorseman.net> On 07/09/2009 03:45 AM, Werner Koch wrote: > On Mon, 6 Jul 2009 23:52, dkg at fifthhorseman.net said: > >> with new versions of gpg pending, is there any chance of getting the >> default key preferences updated, as referenced here: > > Done a bit different for 2.0; the default hash algo order is now: > > SHA-256, SHA-1, SHA-384, SHA-512, SHA-224. Great news, thank you Werner! > Ordering SHA-1 before SHA-384 might be viewed as a bit strange; it is > done because we expect that soon enough SHA-3 will be available and at > that point there should be no more need for SHA-384 etc. Anyway this > order is just a default and can easily be changed by a config option. I'm not certain i understand this logic. doesn't the same reasoning apply in both directions? That is, when SHA-3 is finalized in 2012, won't it obsolete both SHA-384 *and* SHA-1? Since SHA-1 is assumed to be present in the list by every RFC 4880 client, the only thing this preference ordering does is that it precludes the use of stronger digests by every client that respects the ordering. It seems to me like the defaults should prefer the strongest known digest that the implementation is capable of supporting. If other implementations can't produce the stronger digests, they would fall back to weaker ones with no problem, right? I don't see the advantage of deprecating these other stronger digests now. Are there computational or efficiency issues that i'm unaware of? Can you explain more? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From daniel at danm.de Fri Jul 10 00:50:19 2009 From: daniel at danm.de (Daniel Mueller) Date: Fri, 10 Jul 2009 00:50:19 +0200 Subject: GPGME API documentation licence question Message-ID: <20090710005019.77975bb4@torax> Hello, I am currently working on a .NET binding library for GPGME. The number of classes, methods etc. came to a point where documentation might be useful. Since the .NET library provides a subset of GPGME's API functions, the documentation is nearly the same. There are only a few .NET specific changes and additional information. I would like to ask you whether I am allowed to copy & paste the relevant parts from GPGME's info pages (API docs). Inside gpgme's docs directory I found a file that announces the content as GPLv3+, is that correct? Furthermore I found three different authors (through the Changelog file): * Marcus Brinkmann * Moritz Schulte * Werner Koch Would it be sufficient to place a COPYING file inside my doc directory (Licence: GPLv3) and an AUTHORS file that contains the origin? The .NET binding library[2] itself will be licenced as LGPL v2.1. Thank you, Daniel [1] http://www.danm.de/docs/gpgme-sharp/index.html [2] http://www.danm.de/files/src/csharp/gpgme-sharp/ -- Daniel Mueller http://www.danm.de Berlin, Germany OpenPGP: F9F982C1 From wk at gnupg.org Fri Jul 10 09:05:42 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 Jul 2009 09:05:42 +0200 Subject: GPGME API documentation licence question In-Reply-To: <20090710005019.77975bb4@torax> (Daniel Mueller's message of "Fri, 10 Jul 2009 00:50:19 +0200") References: <20090710005019.77975bb4@torax> Message-ID: <87r5wpxbjt.fsf@wheatstone.g10code.de> On Fri, 10 Jul 2009 00:50, daniel at danm.de said: > changes and additional information. I would like to ask you whether I > am allowed to copy & paste the relevant parts from GPGME's info pages > (API docs). Sure, that is the whole point of Free Software. > Inside gpgme's docs directory I found a file that announces the content > as GPLv3+, is that correct? Furthermore I found three different Right. The AUTHORS files also states this: License (software): LGPLv2.1+ License (manual): GPLv3+ > authors (through the Changelog file): > * Marcus Brinkmann > * Moritz Schulte > * Werner Koch They are employed by my company and thus legally you only need to credit g10 Code. Just add our copyright line from the texi file into your documentation. > Would it be sufficient to place a COPYING file inside my doc > directory (Licence: GPLv3) and an AUTHORS file that contains the > origin? The .NET binding library[2] itself will be licenced as LGPL > v2.1. That is okay. It is actually the same scheme we use. BTW, we are interested in distributing language bindings as part of gpgme; see the lang/ directory. Please let me know if you are interested. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Fri Jul 10 09:10:35 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 Jul 2009 09:10:35 +0200 Subject: updating default digest preferences In-Reply-To: <4A55FC2B.80807@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 09 Jul 2009 10:18:19 -0400") References: <4A52723B.1040004@fifthhorseman.net> <87vdm2uwoc.fsf@wheatstone.g10code.de> <4A55FC2B.80807@fifthhorseman.net> Message-ID: <87my7dxbbo.fsf@wheatstone.g10code.de> On Thu, 9 Jul 2009 16:18, dkg at fifthhorseman.net said: > preference ordering does is that it precludes the use of stronger > digests by every client that respects the ordering. You may use personal preferences to change that. SHA-384/512 is not widely enough supported and of no use for an average user. > deprecating these other stronger digests now. Are there computational > or efficiency issues that i'm unaware of? Can you explain more? SHA-256 and SHA-1 are supported by hardware - the others are not. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dkg at fifthhorseman.net Fri Jul 10 17:17:57 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 10 Jul 2009 11:17:57 -0400 Subject: updating default digest preferences In-Reply-To: <87my7dxbbo.fsf@wheatstone.g10code.de> References: <4A52723B.1040004@fifthhorseman.net> <87vdm2uwoc.fsf@wheatstone.g10code.de> <4A55FC2B.80807@fifthhorseman.net> <87my7dxbbo.fsf@wheatstone.g10code.de> Message-ID: <4A575BA5.7060209@fifthhorseman.net> On 07/10/2009 03:10 AM, Werner Koch wrote: > On Thu, 9 Jul 2009 16:18, dkg at fifthhorseman.net said: > >> preference ordering does is that it precludes the use of stronger >> digests by every client that respects the ordering. > > You may use personal preferences to change that. SHA-384/512 is not > widely enough supported and of no use for an average user. 5-year-old (or older) clients that do not support larger digests would simply look through the list of preferences until they find one that they do support, so i'm not sure why widespread support of an algorithm should influence its placement in the advertised preferences. Your proposed preference list seems to contain the statement: "If you support SHA-512 but not SHA-256, please use the even weaker default digest (SHA-1) instead of SHA-512". While it would be an odd client that meets those criteria, it seems even odder to request such a downgrade (especially given that the preference list is being generated with a tool that has supported SHA-512 for many years now). If a client is capable of using SHA-512, why *wouldn't* the average user want it to prefer that over SHA-1? >> deprecating these other stronger digests now. Are there computational >> or efficiency issues that i'm unaware of? Can you explain more? > > SHA-256 and SHA-1 are supported by hardware - the others are not. I have no specialized hardware that i'm aware of that calculates SHA-1 or SHA-256 sums when i verify or create OpenPGP signatures with GnuPG. I suspect that most users GnuPG are in the same situation. In that case, wouldn't it make sense for the minority subset who *do* have such hardware to change their advertised digest preferences, rather than making that choice the standard for every other user? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From daniel at danm.de Fri Jul 10 22:05:26 2009 From: daniel at danm.de (Daniel Mueller) Date: Fri, 10 Jul 2009 22:05:26 +0200 Subject: GPGME API documentation licence question In-Reply-To: <87r5wpxbjt.fsf@wheatstone.g10code.de> References: <20090710005019.77975bb4@torax> <87r5wpxbjt.fsf@wheatstone.g10code.de> Message-ID: <20090710220526.263ad7d1@torax> On Fri, 10 Jul 2009 09:05:42 +0200 Werner Koch wrote: > Right. The AUTHORS files also states this: > License (software): LGPLv2.1+ > License (manual): GPLv3+ > [..] > Just add our copyright line from the texi file into > your documentation. Okay, will do so. > BTW, we are interested in distributing language bindings as part of > gpgme; see the lang/ directory. Please let me know if you are > interested. Thanks for the info. But since I'm the only user/tester I wouldn't call the .NET binding lib "mature" at the moment. Maybe this will change when I start to replace the "To be added." lines in the documentation with real content ;-) bye, Daniel -- Daniel Mueller http://www.danm.de Berlin, Germany OpenPGP: F9F982C1 From daniel.leidert.spam at gmx.net Thu Jul 16 12:48:26 2009 From: daniel.leidert.spam at gmx.net (Daniel Leidert) Date: Thu, 16 Jul 2009 12:48:26 +0200 Subject: Debian bug#191137: Interoperability problem with pgp 2.6.3i Message-ID: <1247741306.5922.30.camel@leidi> Hi, May you comment on the following report [1] please, which I will fully quote. I don't know, if this is still relevant and I would like to know, how to treat the report (e.g. close it or not with/without action). So here is the report: > PGP 2.6.3i has some stupid bugs where it doesn't check the type encoded > in the packet tag but checks the value of the byte directly. For example: > > #define CTB_CERT_PUBKEY CTB_BYTE(CTB_CERT_PUBKEY_TYPE,1) > /* CTB_CERT_PUBKEY len16 timestamp userID mpi(n) mpi(e) crc16 */ > > and so it only accepts pubkey with 16-bit lengths. gnupg is generating > a pubkey with 8-bit lengths in some circumstances. > > It might be the case that this isn't relevant; I'm investigating adding > support for v4 keys to the pgp 2.6 codebase and it's a v4 key that's > using an 8-bit length. Maybe gnupg is more careful when encoding a v3 key. Can you comment on this please? [1] http://bugs.debian.org/191137 Regards, Daniel From daniel.leidert.spam at gmx.net Thu Jul 16 12:52:40 2009 From: daniel.leidert.spam at gmx.net (Daniel Leidert) Date: Thu, 16 Jul 2009 12:52:40 +0200 Subject: Debian bug#191137: Interoperability problem with pgp 2.6.3i In-Reply-To: <1247741306.5922.30.camel@leidi> References: <1247741306.5922.30.camel@leidi> Message-ID: <1247741560.5922.31.camel@leidi> Am Donnerstag, den 16.07.2009, 12:48 +0200 schrieb Daniel Leidert: > Hi, > > May you comment on the following report [1] please, which I will fully > quote. I don't know, if this is still relevant and I would like to know, > how to treat the report (e.g. close it or not with/without action). > > So here is the report: > > > PGP 2.6.3i has some stupid bugs where it doesn't check the type encoded > > in the packet tag but checks the value of the byte directly. For example: > > > > #define CTB_CERT_PUBKEY CTB_BYTE(CTB_CERT_PUBKEY_TYPE,1) > > /* CTB_CERT_PUBKEY len16 timestamp userID mpi(n) mpi(e) crc16 */ > > > > and so it only accepts pubkey with 16-bit lengths. gnupg is generating > > a pubkey with 8-bit lengths in some circumstances. > > > > It might be the case that this isn't relevant; I'm investigating adding > > support for v4 keys to the pgp 2.6 codebase and it's a v4 key that's > > using an 8-bit length. Maybe gnupg is more careful when encoding a v3 key. > > Can you comment on this please? Is this maybe already considered when using --pgp2? > [1] http://bugs.debian.org/191137 Regards, Daniel From wk at gnupg.org Thu Jul 16 14:45:54 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Jul 2009 14:45:54 +0200 Subject: Debian bug#191137: Interoperability problem with pgp 2.6.3i In-Reply-To: <1247741560.5922.31.camel@leidi> (Daniel Leidert's message of "Thu, 16 Jul 2009 12:52:40 +0200") References: <1247741306.5922.30.camel@leidi> <1247741560.5922.31.camel@leidi> Message-ID: <87my74ssn1.fsf@wheatstone.g10code.de> On Thu, 16 Jul 2009 12:52, daniel.leidert.spam at gmx.net said: Hi, First of all PGP 2 is dead. The only reason it is still used is to allow decryption of old IDEA encrypted messages. PGP2 is not an OpenPGP application and thus compatibility with GnuPG is limited. You can't expect that PGP 2 groks OpenPGP messages. GnuPG 1.2 is also very old, thus I suggest to close the bug. >> > It might be the case that this isn't relevant; I'm investigating adding >> > support for v4 keys to the pgp 2.6 codebase and it's a v4 key that's >> > using an 8-bit length. Maybe gnupg is more careful when encoding a v3 key. I don't understand the problem. If someone is going to add v4 support to GPG 2, s/he need to add v4 support and that specifies different ways of encoding a length. The actual problem is a bit more complicated because the computation of a fingerprint requires a certain header format and one can't simply use the length from the header. See g10/keyid.c:hash_public_key. >> [1] http://bugs.debian.org/191137 I suggest to close this bug. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Fri Jul 17 11:26:21 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jul 2009 11:26:21 +0200 Subject: 1024-3072 bit OpenPGP cards Message-ID: <877hy78xtu.fsf@wheatstone.g10code.de> Hi, I talked with David about the new OpenPGP card and how to solve a surprising behaviour. A little background: The new v2 specification of the card explicitly allows different key sizes for the card. It is even possible to change the key size from the factory default (this deletes an existing key). This is an optional feature announced through the card's capabilities mechanism. It is a boolean flag telling whether changing the key size is possible. What the card doesn't tell is the range of the allowed key sizes and how the keys are internally represented; if you select an invalid size or bad parameters the card will simply reject it. Thus before changing the key size you need to check with the vendor what sizes are supported. I recently enhanced the "keytocard" command to change the key size of the card to match the size of the key to be written to the card. That is a nice and much desirable feature. In the past, if you tried to use the "keytocard" command, it failed if the sizes didn't match. So far so good. Now for the surprise: If you later generate new keys (gpg --edit-key; admin, generate) these keys are created with the current key sizes of the card. For example: if you recently wrote a 1024 bit authentication key to the card, you would create 3 keys: 2048, 2048 and 1024). David suggested to always ask the user for the key size (in case the card supports changing the key size at all). The problem is that we don't know what key sizes the card supports: The one card implementation currently available supports 1024 to 3072bit RSA [1]. We know that but we can't tell without looking at the specs of the concrete card. There are a few other vendors which may support other key sizes or the chip of the card is replaced and with that the supported key sizes; it is entirely possible that you are restricted to certain sizes, e.g. 1024 and 2048 but no 1536 or any other odd number. If we would always ask for the key size the user would be surprised as well if he selects a certain size and finally ends up with an error message that the key could not be created. Note that we don't have a way to figure out a default size and set the card back to that before keys are generated. I see a few possibilities: 1) Keep it as it is. This will work without surprises unless the user once wrote different sized keys to the card. 2) Always ask for the key size and use as default the current size. Show a warning notice if the user entered a different size. 3) Same as 2 but do this only with --expert. 4) Add a new command "keysize" to manually set the keysize for each key. Print a warning notice before key generation if the key sizes of the card are not all the same and tell the user about the keysize command. 5) Other suggestions? Salam-Shalom, Werner [1] Actually 4096 but due to internal data structure limitations in GnuPG it is currently limited to 3072. -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Fri Jul 17 13:56:14 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 17 Jul 2009 13:56:14 +0200 Subject: 1024-3072 bit OpenPGP cards In-Reply-To: <877hy78xtu.fsf@wheatstone.g10code.de> References: <877hy78xtu.fsf@wheatstone.g10code.de> Message-ID: <4A6066DE.40703@ruhr-uni-bochum.de> Werner Koch wrote: > Note that we don't have a way to figure out a default size and set the > card back to that before keys are generated. Can't we include a list of allowed keysizes based on card revision/manufacturer? Thanks, Marcus From wk at gnupg.org Fri Jul 17 15:03:54 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jul 2009 15:03:54 +0200 Subject: 1024-3072 bit OpenPGP cards In-Reply-To: <4A6066DE.40703@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "17 Jul 2009 13:56:14 +0200") References: <877hy78xtu.fsf@wheatstone.g10code.de> <4A6066DE.40703@ruhr-uni-bochum.de> Message-ID: <87ocrj796t.fsf@wheatstone.g10code.de> On Fri, 17 Jul 2009 13:56, marcus.brinkmann at ruhr-uni-bochum.de said: > Can't we include a list of allowed keysizes based on card revision/manufacturer? A manufacturer is free to change the implementation or hardware. One reason that ZeitControl does not like to tell us the used chip might be to change the chip without getting into trouble with some legal departments. The manufacturer id is similar to the vendor assigned MAC address blocks of ethernet cards. It allows them to assign serial number without a centralized authority. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Fri Jul 17 20:05:43 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 17 Jul 2009 14:05:43 -0400 Subject: 1024-3072 bit OpenPGP cards In-Reply-To: <877hy78xtu.fsf@wheatstone.g10code.de> References: <877hy78xtu.fsf@wheatstone.g10code.de> Message-ID: <336F8479-81D7-4186-97B8-4220FC93185B@jabberwocky.com> On Jul 17, 2009, at 5:26 AM, Werner Koch wrote: > 1) Keep it as it is. This will work without surprises unless the user > once wrote different sized keys to the card. > > 2) Always ask for the key size and use as default the current size. > Show a warning notice if the user entered a different size. > > 3) Same as 2 but do this only with --expert. > > 4) Add a new command "keysize" to manually set the keysize for each > key. Print a warning notice before key generation if the key sizes > of the card are not all the same and tell the user about the > keysize > command. > > 5) Other suggestions? My feeling is #2 is the best answer. I'd do it with the current size (whatever it is) of the signing key slot being used as the default for all three slots (it it reasonable to assume that if slot #1 can handle a particular size, then slots #2 and #3 can also handle it?) Prompt for the key size, and if it is not the same as the default, then print out a message something like: You have requested a key size of %u. Note that not all cards can handle all key sizes. GnuPG will attempt to create your key, but if the card rejects it, you may need to try a different key size. Please consult your card documentation for more information. Then try and generate the key. If it fails, the user has been prepared for that possibility. This makes the user experience of generating a key on a card as close as possible to generating a key normally. David From lion at lion.leolix.org Sat Jul 18 11:54:05 2009 From: lion at lion.leolix.org (Philipp Schafft) Date: Sat, 18 Jul 2009 11:54:05 +0200 Subject: 1024-3072 bit OpenPGP cards In-Reply-To: <877hy78xtu.fsf@wheatstone.g10code.de> References: <877hy78xtu.fsf@wheatstone.g10code.de> Message-ID: <20090718095406.E94877AADD@priderock.keep-cool.org> reflum, On Fri, 2009-07-17 at 11:26 +0200, Werner Koch wrote: > 2) Always ask for the key size and use as default the current size. > Show a warning notice if the user entered a different size. > > 3) Same as 2 but do this only with --expert. > > 4) Add a new command "keysize" to manually set the keysize for each > key. Print a warning notice before key generation if the key sizes > of the card are not all the same and tell the user about the keysize > command. I vote for 3+4: while using --expert you get asked every time, this is good for experts as they know the problems. But as --expert is normaly the wrong way^(TM) there need to be a better way to set it, even without --expert. This may be done by a additioal command (btw. I would use something including 'card' in the command name). -- Philipp. (Rah of PH2) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From patrick at mozilla-enigmail.org Sat Jul 18 18:36:05 2009 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Sat, 18 Jul 2009 18:36:05 +0200 Subject: Required patches for the OpenPG card v2.0 In-Reply-To: <87hby6vrun.fsf@wheatstone.g10code.de> References: <87hby6vrun.fsf@wheatstone.g10code.de> Message-ID: Werner Koch wrote: > Unfortunately I realized too late that 2.0.12 still had bugs with the > new OpenPGP card[1]. Without actual hardware testing stuff is a bit > hard; I had 2 engineering samples during development and we swapped card > back and forth to squash the bugs in the card's firmware while also > hacking gnupg. Thus some things got not tested for 2.0.12. > > Find attached 2 patches against GnuPG 2.0.12 to fix the card problem as > well as an unlrealted Windows-only problem. These patches are already > in the Gpg4win 2.0.0rc1 installer currently being copied to the servers. > > GnuPG 1.4 does not yet support the v2 cards. I plan to backport the > code from 2.0 in the next week and then it should not take too long to > get 1.4.10 out. If you don't want to wait: gpg2 is the perfect version > for the desktop or laptop ;-) Hello Werner, I finally found the time to test the latest version of gpg2 (incl. your patches). I noticed an important difference between gpg 1.4.9 and 2.0.12: when I have the wrong card inserted (e.g. for decryption), gpg 1.4.9 responds with these status messages: [GNUPG:] ENC_TO 12A7990DF2541241 1 0 [GNUPG:] CARDCTRL 3 D2760001240101010001000000460000 [GNUPG:] CARDCTRL 1 D2760001240102000005000000700000 [GNUPG:] SC_OP_FAILURE [GNUPG:] BEGIN_DECRYPTION [GNUPG:] DECRYPTION_FAILED Version 2.0.12+ only responds with this: [GNUPG:] ENC_TO 12A7990DF2541241 1 0 [GNUPG:] BEGIN_DECRYPTION [GNUPG:] DECRYPTION_FAILED [GNUPG:] END_DECRYPTION Could you add the missing status messages to gpg2 ? Thanks, Patrick From arothe at phosco.info Mon Jul 20 17:19:55 2009 From: arothe at phosco.info (=?utf-8?b?QW5kcsOp?= Rothe) Date: Mon, 20 Jul 2009 17:19:55 +0200 Subject: Sign a mail Message-ID: <20090720171955.29252e6an106kqv4@horde.phosco.info> Hello! I try to send emails from an application, which should be signed with gpg. But I'm not sure, which part of the mail is used for signing. A PGP/MIME mail consists of: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------248101390272" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------248101390272 Content-Type: multipart/mixed; boundary="----=_Part_0_22676229.1248101390164" This is a multi-part message in MIME format ------=_Part_0_22676229.1248101390164 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is a test. ------=_Part_0_22676229.1248101390164 Content-Type: image/jpeg; name=image001.jpg Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=image001.jpg **some image data** ------=_Part_0_22676229.1248101390164-- --------------248101390272 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature Content-Disposition: attachment -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: not valid iEtEABEIAAYFAkpkhA4ACgkQIAQxWaS9SwJgcgCgqx5/ejuMjr3RtAMUCHZ2kmax XEgAn2qZkveAbxrwv0ZYSEpxiNcQEhDY =XqNu -----END PGP SIGNATURE----- --------------248101390272-- I use the lines (inclusive) from Content-Type: multipart/mixed; to ------=_Part_0_22676229.1248101390164-- to sign the mail. But always I get an invalid signature. Has anyone an idea? Thanks a lot Andre From wk at gnupg.org Mon Jul 20 19:27:42 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Jul 2009 19:27:42 +0200 Subject: Sign a mail In-Reply-To: <20090720171955.29252e6an106kqv4@horde.phosco.info> (=?utf-8?Q?=22Andr=C3=A9?= Rothe"'s message of "Mon, 20 Jul 2009 17:19:55 +0200") References: <20090720171955.29252e6an106kqv4@horde.phosco.info> Message-ID: <87ws634641.fsf@wheatstone.g10code.de> On Mon, 20 Jul 2009 17:19, arothe at phosco.info said: > I try to send emails from an application, which should be signed with > gpg. But I'm not sure, which part of the mail is used for signing. RFC-3156 has good examples. > Content-Type: multipart/mixed; > > to > > ------=_Part_0_22676229.1248101390164-- > > to sign the mail. But always I get an invalid signature. Has anyone an idea? The mime parts ends at --------------248101390272-- also recall that the CR,LF right before this boundary line is part of the boundary and NOT part of the signed data. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Mon Jul 20 19:57:43 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 20 Jul 2009 13:57:43 -0400 Subject: 1024-3072 bit OpenPGP cards In-Reply-To: <20090718095406.E94877AADD@priderock.keep-cool.org> References: <877hy78xtu.fsf@wheatstone.g10code.de> <20090718095406.E94877AADD@priderock.keep-cool.org> Message-ID: <51607D42-EB63-48B2-8587-4C3CF26562E7@jabberwocky.com> On Jul 18, 2009, at 5:54 AM, Philipp Schafft wrote: > reflum, > > On Fri, 2009-07-17 at 11:26 +0200, Werner Koch wrote: >> 2) Always ask for the key size and use as default the current size. >> Show a warning notice if the user entered a different size. >> >> 3) Same as 2 but do this only with --expert. >> >> 4) Add a new command "keysize" to manually set the keysize for each >> key. Print a warning notice before key generation if the key >> sizes >> of the card are not all the same and tell the user about the >> keysize >> command. > > I vote for 3+4: > while using --expert you get asked every time, this is good for > experts > as they know the problems. But as --expert is normaly the wrong > way^(TM) > there need to be a better way to set it, even without --expert. This > may > be done by a additioal command (btw. I would use something including > 'card' in the command name). My problem with a "keysize" command (#4) is that it makes key generation into two steps. First the user must run "keysize", and set the size they want (and if the size isn't supported, they will get an error). Then they must generate the key. #2 just combines the "keysize" and "generate" functions into a single command, as people are used to from regular key generation. David From wk at gnupg.org Mon Jul 20 19:56:37 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Jul 2009 19:56:37 +0200 Subject: 1024-3072 bit OpenPGP cards In-Reply-To: <20090718095406.E94877AADD@priderock.keep-cool.org> (Philipp Schafft's message of "Sat, 18 Jul 2009 11:54:05 +0200") References: <877hy78xtu.fsf@wheatstone.g10code.de> <20090718095406.E94877AADD@priderock.keep-cool.org> Message-ID: <87ocrf44ru.fsf@wheatstone.g10code.de> On Sat, 18 Jul 2009 11:54, lion at lion.leolix.org said: > be done by a additioal command (btw. I would use something including > 'card' in the command name). Not required because that would be a command in the --card-edit menu. Meanwhile I tend to implement option 2 and may add an additional "keysize" command. The latter might be useful to quickly delete all keys from the card without requiring the time to generate new keys. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From arothe at phosco.info Mon Jul 20 21:42:18 2009 From: arothe at phosco.info (=?utf-8?b?QW5kcsOp?= Rothe) Date: Mon, 20 Jul 2009 21:42:18 +0200 Subject: Sign a mail In-Reply-To: <87ws634641.fsf@wheatstone.g10code.de> References: <20090720171955.29252e6an106kqv4@horde.phosco.info> <87ws634641.fsf@wheatstone.g10code.de> Message-ID: <20090720214218.13914yq76a5bc2v4@horde.phosco.info> Werner, Thank you for your answer. I have read the RFC 3156, but the examples are not very helpful to me. Werner Koch wrote: > RFC-3156 has good examples. > > >> Content-Type: multipart/mixed; >> >> to >> >> ------=_Part_0_22676229.1248101390164-- >> >> to sign the mail. But always I get an invalid signature. Has anyone an idea? > > The mime parts ends at > > --------------248101390272-- > Hm, I think, this line is the end of the enclosing MIME part, but the part I have to sign is the content part of the PGP/MIME structure (the inner boundaries). RFC 3156 says, I have to include the inner boundaries into the signed content, but should I include also the last CR+LF? Is it necessary to encode the parts of the signed content with quoted-printable? I use gpg --charset utf8 -a --batch --no-tty --digest-algo sha256 -s -b -a -t -u 0xA4BD4B02 --no-use-agent as the signature creation command, but I'm not sure with the -t. > also recall that the CR,LF right before this boundary line is part of > the boundary and NOT part of the signed data. There are two CR+LFs between the inner boundary and the next outer boundary... Encryption and PGP/MIME is very simple to produce, but the signature alone has cost a weekend till now. Sorry, but I don't know, whom I could ask Andre From wk at gnupg.org Tue Jul 21 09:39:08 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 21 Jul 2009 09:39:08 +0200 Subject: Sign a mail In-Reply-To: <20090720214218.13914yq76a5bc2v4@horde.phosco.info> (=?utf-8?Q?=22Andr=C3=A9?= Rothe"'s message of "Mon, 20 Jul 2009 21:42:18 +0200") References: <20090720171955.29252e6an106kqv4@horde.phosco.info> <87ws634641.fsf@wheatstone.g10code.de> <20090720214218.13914yq76a5bc2v4@horde.phosco.info> Message-ID: <87fxcq4h9f.fsf@wheatstone.g10code.de> On Mon, 20 Jul 2009 21:42, arothe at phosco.info said: > inner boundaries). RFC 3156 says, I have to include the inner > boundaries into the signed content, but should I include also the last Here is a slighly modified example: +-- First column v Mime-Version: 1.0 Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5; protocol="application/pgp-signature" --bar & Content-Type: text/plain; charset=iso-8859-1 & Content-Transfer-Encoding: quoted-printable & & =A1Hola! & & Did you know that talking to yourself is a sign of senility? & & It's generally a good idea to encode lines that begin with & From=20because some mail transport agents will insert a greater- & than (>) sign, thus invalidating the signature. & & Also, in some cases it might be desirable to encode any =20 & trailing whitespace that occurs on lines in order to ensure =20 & that the message signature is not invalidated when passing =20 & a gateway that modifies such whitespace (like BITNET). =20 & & me --bar Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- [...] --bar-- surprisingly denotes the RFC822 required CR, LF. [...] Is stuff I don't show. & denotes the signed text. You create the signature over all the lines marked with &. As you can see the line after the last &-marked line is not part of the signed text; it is part of the boundary in the following line. Now this is a plain single item message. If you want to sign another multipart MIME message, you do it straightforward: Replace the Content-Type line after the first "--bar" boundary with the new content-type, for example: Content-Type: multipart/mixed; boundary=foo; and include this line in the signature, the last line of this mime container will be --foo-- which is also included in the signed data. After that you will continue with --bar Content-Type: application/pgp-signature which is not anymore part of the signed text. > CR+LF? Is it necessary to encode the parts of the signed content with > quoted-printable? I use That depends on the content. RFC-3156 gives very specific rules on how to do that. Make sure the signed data is 7-bit. > as the signature creation command, but I'm not sure with the -t. The -t is fine, but not required if you follow the rules: Note: Implementations can either generate "signatures of a canonical text document" or "signatures of a binary document", as defined in [1]. The restrictions on the signed material put forth in section 3 and in this section will make sure that the various MIC algorithm variants specified in [1] and [5] will all produce the same result. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From arothe at phosco.info Tue Jul 21 11:33:31 2009 From: arothe at phosco.info (=?utf-8?b?QW5kcsOp?= Rothe) Date: Tue, 21 Jul 2009 11:33:31 +0200 Subject: Sign a mail In-Reply-To: <87fxcq4h9f.fsf@wheatstone.g10code.de> References: <20090720171955.29252e6an106kqv4@horde.phosco.info> <87ws634641.fsf@wheatstone.g10code.de> <20090720214218.13914yq76a5bc2v4@horde.phosco.info> <87fxcq4h9f.fsf@wheatstone.g10code.de> Message-ID: <20090721113331.13712dhq8httltvk@horde.phosco.info> Werner, Thanks a lot - it works! The only thing I have changed is the -t option. All other things I had implemented as you have described. The complete document is a canonical text document, because I have encoded it just before I start gpg. I have sucessfully tested it with Evolution. >> as the signature creation command, but I'm not sure with the -t. > > The -t is fine, but not required if you follow the rules: > > Note: Implementations can either generate "signatures of a > canonical text document" or "signatures of a binary document", as > defined in [1]. The restrictions on the signed material put forth > in section 3 and in this section will make sure that the various > MIC algorithm variants specified in [1] and [5] will all produce > the same result. Best regards Andre From wk at gnupg.org Wed Jul 22 16:57:08 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Jul 2009 16:57:08 +0200 Subject: Required patches for the OpenPG card v2.0 In-Reply-To: (Patrick Brunschwig's message of "Sat, 18 Jul 2009 18:36:05 +0200") References: <87hby6vrun.fsf@wheatstone.g10code.de> Message-ID: <87my6w22bf.fsf@wheatstone.g10code.de> On Sat, 18 Jul 2009 18:36, patrick at mozilla-enigmail.org said: > have the wrong card inserted (e.g. for decryption), gpg 1.4.9 responds > with these status messages: > > [GNUPG:] ENC_TO 12A7990DF2541241 1 0 > [GNUPG:] CARDCTRL 3 D2760001240101010001000000460000 > [GNUPG:] CARDCTRL 1 D2760001240102000005000000700000 > [GNUPG:] SC_OP_FAILURE > [GNUPG:] BEGIN_DECRYPTION > [GNUPG:] DECRYPTION_FAILED > > > Version 2.0.12+ only responds with this: > [GNUPG:] ENC_TO 12A7990DF2541241 1 0 > [GNUPG:] BEGIN_DECRYPTION > [GNUPG:] DECRYPTION_FAILED > [GNUPG:] END_DECRYPTION Yo used 1.4.9 without scdaemon support; if you would have used it with gpg-agent/scdaemon, the output would be similar to: [GNUPG:] ENC_TO 10B671F6860B1CFE 1 0 [GNUPG:] CARDCTRL 3 [GNUPG:] SC_OP_FAILURE [GNUPG:] BEGIN_DECRYPTION [GNUPG:] DECRYPTION_FAILED [GNUPG:] END_DECRYPTION Thus the CARDCTRL 1 is also missing. I changed gpg2 to emit: [GNUPG:] ENC_TO 10B671F6860B1CFE 1 0 [GNUPG:] CARDCTRL 3 D2760001240101010001000003470000 [GNUPG:] SC_OP_FAILURE [GNUPG:] BEGIN_DECRYPTION [GNUPG:] DECRYPTION_FAILED [GNUPG:] END_DECRYPTION Which is basically the same. It just adds the s/n of the current card to CARDCTRL 3. The question now is what to do with the cardctrl values used on a standalone gpg: CARDCTRL 1 = Request insertion of a card. Serialnumber may be given to request a specific card. CARDCTRL 2 = Request removal of a card. With scdaemon handling all access to the cards, including the PIN question, it would make sense to have scdaemon ask for inserting the right card as well. To allow for a bit of unattended operation this needs to be suppressed if --batrch is given to gpg. Do you see any problem with such an approach? Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From patrick at mozilla-enigmail.org Thu Jul 23 08:50:48 2009 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Thu, 23 Jul 2009 08:50:48 +0200 Subject: Required patches for the OpenPG card v2.0 In-Reply-To: <87my6w22bf.fsf@wheatstone.g10code.de> References: <87hby6vrun.fsf@wheatstone.g10code.de> <87my6w22bf.fsf@wheatstone.g10code.de> Message-ID: <4A680848.6030603@mozilla-enigmail.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Werner Koch wrote: > On Sat, 18 Jul 2009 18:36, patrick at mozilla-enigmail.org said: > >> have the wrong card inserted (e.g. for decryption), gpg 1.4.9 responds >> with these status messages: >> >> [GNUPG:] ENC_TO 12A7990DF2541241 1 0 >> [GNUPG:] CARDCTRL 3 D2760001240101010001000000460000 >> [GNUPG:] CARDCTRL 1 D2760001240102000005000000700000 >> [GNUPG:] SC_OP_FAILURE >> [GNUPG:] BEGIN_DECRYPTION >> [GNUPG:] DECRYPTION_FAILED >> >> >> Version 2.0.12+ only responds with this: >> [GNUPG:] ENC_TO 12A7990DF2541241 1 0 >> [GNUPG:] BEGIN_DECRYPTION >> [GNUPG:] DECRYPTION_FAILED >> [GNUPG:] END_DECRYPTION > > Yo used 1.4.9 without scdaemon support; if you would have used it with > gpg-agent/scdaemon, the output would be similar to: > > [GNUPG:] ENC_TO 10B671F6860B1CFE 1 0 > [GNUPG:] CARDCTRL 3 > [GNUPG:] SC_OP_FAILURE > [GNUPG:] BEGIN_DECRYPTION > [GNUPG:] DECRYPTION_FAILED > [GNUPG:] END_DECRYPTION > > Thus the CARDCTRL 1 is also missing. I changed gpg2 to emit: > > [GNUPG:] ENC_TO 10B671F6860B1CFE 1 0 > [GNUPG:] CARDCTRL 3 D2760001240101010001000003470000 > [GNUPG:] SC_OP_FAILURE > [GNUPG:] BEGIN_DECRYPTION > [GNUPG:] DECRYPTION_FAILED > [GNUPG:] END_DECRYPTION > > Which is basically the same. It just adds the s/n of the current card > to CARDCTRL 3. > > The question now is what to do with the cardctrl values used on a > standalone gpg: > > CARDCTRL 1 = Request insertion of a card. Serialnumber may be given > to request a specific card. > CARDCTRL 2 = Request removal of a card. > > With scdaemon handling all access to the cards, including the PIN > question, it would make sense to have scdaemon ask for inserting the > right card as well. To allow for a bit of unattended operation this > needs to be suppressed if --batrch is given to gpg. Do you see any > problem with such an approach? I think that would be a good approach. - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBSmgIRncOpHodsOiwAQiDcQgAjGYxwPe0PHfSXPU9R1su+aDYFIvvSJXp KjYO+dPAhPk38Zu1vANth+DRBXICn18NEzbMEpXGfx46bz5ePMP5i8wl4ixsfCpn SlGnhg6XvK+5ZaA7BVpjZ09de78W1F2Unj7DbG22Myd2N7BEK5fqfFA7qdcGAsfx adcf565ybeZaZik0EDJpiGUDC94mGYg/CBtA08ByRoAEUOP+gmn+tmkw7CmsfERC r+gY/I/xuF6xpTCWNqbOkiQ9bimTyvut8DFyi0cIX2RyZ41Q4IW/kGqRthr5FUUI 03PIfa8sw+n4lkAXDH1S1KxwdlC19Fx5Ma7Oh2OlRbpqItSty3NPRg== =DwNY -----END PGP SIGNATURE----- From dshaw at JABBERWOCKY.COM Mon Jul 27 16:34:12 2009 From: dshaw at JABBERWOCKY.COM (David Shaw) Date: Mon, 27 Jul 2009 10:34:12 -0400 Subject: IT Department having the secure key. In-Reply-To: <4A6D9D96.30108@fifthhorseman.net> References: <24668288.post@talk.nabble.com> <20090727103317.GD20991@ask> <4A6D9D96.30108@fifthhorseman.net> Message-ID: <9DEE055F-90E7-414C-9E9F-B6203E87063E@jabberwocky.com> On Jul 27, 2009, at 8:29 AM, Daniel Kahn Gillmor wrote: >> And: You can only encrypt the files for one key. So only one user >> will have >> access to the files (owns the files), as long as you don't share >> the keys. For >> example you can introduce company wide keys or deparmtement keys >> and distribute >> them to anyone, who should have access. > > You actually can encrypt files to more than one OpenPGP key, so that > anyone holding any of the recipient keys can decrypt the data. Maybe > this approach would be useful for the OP? > > If, as IT administrator, you have the opportunity to configure your > users' ~/.gnupg/gpg.conf, you could add a line like > > recipient 0xDEADBEEFDEADBEEF > > to specify that all encryptions will automatically be encrypted to a > key > that you retain for the kind of emergency recovery scenarios you > describe. I'd use "encrypt-to" instead of "recipient", but basically, yes, that will work. It's a reasonably common solution for the problem. This is similar in effect to PGP.com's additional decryption key (the ADK has better granularity as it works on a per-key basis, but the concept is the same). However, note that this (and the ADK) both are only really effective with an honest user. If a user wants to manipulate their key to remove the ADK (which is trivial) or edit their gpg.conf to remove the extra encrypt-to line, then you'd need a more central (and not under user control) way to guard against trouble. For example, if we're just talking about email, you could tweak your mail server to check to see if the extra recipient was present and if not, reject the message, etc. I believe the PGP folks have some variant of this ability, but you'd have to ask them for the details. David From anon4321 at comcast.net Tue Jul 28 19:35:20 2009 From: anon4321 at comcast.net (anon4321 at comcast.net) Date: Tue, 28 Jul 2009 17:35:20 +0000 (UTC) Subject: Minor bug in --pgp6 option Message-ID: <1208576093.6696741248802520723.JavaMail.root@sz0115a.westchester.pa.mail.comcast.net> I checked the source of gnppg 1.4.9 and? 2.0.12 and both seem to be missing some settings when the --pgp6 option is used. In the if statement at line 3089 of the 2.0.12 version of?g10\gpg.c, some options don't seem to be set as described in the manual: else if (PGP6) { opt.escape_from=1; opt.force_v3_sigs=1; opt.ask_sig_expire=0; } else if (PGP7) { opt.escape_from=1; opt.force_v3_sigs=1; opt.ask_sig_expire=0; } The manual describes the --pgp6 and --pgp7 options as: --pgp6 Set up all options to be as PGP 6 compliant as possible. This restricts you to the ciphers IDEA (if the IDEA plugin is installed), 3DES, and CAST5, the hashes MD5, SHA1 and RIPEMD160, and the compression algorithms none and ZIP. This also disables ?throw-keyids, and making signatures with signing subkeys as PGP 6 does not understand signatures made by signing subkeys. This option implies ? --disable-mdc --no-sk-comment --escape-from-lines --force-v3-sigs ?. --pgp7 Set up all options to be as PGP 7 compliant as possible. This is identical to ? --pgp6 ? except that MDCs are not disabled, and the list of allowable ciphers is expanded to add AES128, AES192, AES256, and TWOFISH. So from the manual, the if statement should at least be: else if (PGP6) { opt.disable_mdc=1;?? /* Bug fix. */ opt.escape_from=1; opt.force_v3_sigs=1; opt.ask_sig_expire=0; } else if (PGP7) { opt.escape_from=1; opt.force_v3_sigs=1; opt.ask_sig_expire=0; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From amul.shah at fnis.com Tue Jul 28 20:37:09 2009 From: amul.shah at fnis.com (Amul Shah) Date: Tue, 28 Jul 2009 14:37:09 -0400 Subject: [PATCH] libgpgme header change to fix compilation issues on AIX, z/OS and HP-UX Message-ID: <4A6F4555.40604@fnis.com> This patch applies to libgpgme 1.1.8 and fixes compilation issues on AIX 5.3, HP-UX (11.31 IA64) and z/OS R10. I successfully tested (./configure && make && make check) the compilation of libgpgme 1.1.8 on Ubuntu 8.04 x86_64 with the fix. This work was done by Karthik K of s7software. Thanks, Amul Shah --- diff -purN gpgme-1.1.8.orig/src/version.c gpgme-1.1.8.new/src/version.c --- gpgme-1.1.8.orig/src/version.c Tue Nov 18 12:20:14 2008 +++ gpgme-1.1.8.new/src/version.c Thu Apr 30 14:02:49 2009 @@ -22,6 +22,7 @@ #if HAVE_CONFIG_H #include #endif +#include #include #include #include _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ From marcus.brinkmann at ruhr-uni-bochum.de Wed Jul 29 16:34:53 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 29 Jul 2009 16:34:53 +0200 Subject: [PATCH] libgpgme header change to fix compilation issues on AIX, z/OS and HP-UX In-Reply-To: <4A6F4555.40604@fnis.com> References: <4A6F4555.40604@fnis.com> Message-ID: <4A705E0D.2070903@ruhr-uni-bochum.de> Amul Shah wrote: > This patch applies to libgpgme 1.1.8 and fixes compilation issues on AIX > 5.3, HP-UX (11.31 IA64) and z/OS R10. > > I successfully tested (./configure && make && make check) the > compilation of libgpgme 1.1.8 on Ubuntu 8.04 x86_64 with the fix. > > This work was done by Karthik K of s7software. It's already in gpgme 1.2.0. Thanks, Marcus From amul.shah at fnis.com Wed Jul 29 18:43:44 2009 From: amul.shah at fnis.com (Amul Shah) Date: Wed, 29 Jul 2009 12:43:44 -0400 Subject: [PATCH] libgpgme header change to fix compilation issues on AIX, z/OS and HP-UX In-Reply-To: <4A705E0D.2070903@ruhr-uni-bochum.de> References: <4A6F4555.40604@fnis.com> <4A705E0D.2070903@ruhr-uni-bochum.de> Message-ID: <4A707C40.7050700@fnis.com> On 07/29/2009 10:34 AM, Marcus Brinkmann wrote: > Amul Shah wrote: > >> This patch applies to libgpgme 1.1.8 and fixes compilation issues on AIX >> 5.3, HP-UX (11.31 IA64) and z/OS R10. >> >> I successfully tested (./configure && make && make check) the >> compilation of libgpgme 1.1.8 on Ubuntu 8.04 x86_64 with the fix. >> >> This work was done by Karthik K of s7software. >> > > It's already in gpgme 1.2.0. > > Thanks, > Marcus > > Marcus, Thanks for the heads up. I didn't think to check the subversion repo for the latest sources. You probably know this already, the downloads page links gpgme 1.1.8. thanks, Amul _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ueno at unixuser.org Thu Jul 30 05:07:40 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Thu, 30 Jul 2009 12:07:40 +0900 Subject: [PATCH] ncursesw support for pinentry-curses Message-ID: <3bce76e1-453e-4e49-8e48-3ddbcca52979@broken.deisui.org> Hi, Currently pinentry-curses cannot handle multibyte characters and messages from gpg-agent are garbled under multibyte locales (such as ja_JP.UTF-8). For example: -------------- next part -------------- A non-text attachment was scrubbed... Name: pinentry-ncursesw-before.png Type: image/png Size: 8963 bytes Desc: not available URL: -------------- next part -------------- The attached patch addresses this issue with the help of ncursesw. With this patch, the message in the above example will be rendered correctly: -------------- next part -------------- A non-text attachment was scrubbed... Name: pinentry-ncursesw-after.png Type: image/png Size: 9709 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pinentry-ncursesw.diff Type: text/x-diff Size: 11109 bytes Desc: not available URL: -------------- next part -------------- Regards, -- Daiki Ueno From lionel at mamane.lu Thu Jul 30 12:32:35 2009 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Thu, 30 Jul 2009 12:32:35 +0200 Subject: Poldi bug report: version of the GPL Message-ID: <20090730103235.GB5457@capsaicin.mamane.lu> Hi, The file COPYING is version 2 of the GPL, but a pseudo-random sampling of .c/.h files in the source says GNU GPL v3 or later, thus v2 not allowed. -- Lionel From lionel at mamane.lu Thu Jul 30 12:51:36 2009 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Thu, 30 Jul 2009 12:51:36 +0200 Subject: Poldi bug report: absence of DISables (not ENables) x509 support Message-ID: <20090730105136.GA5801@capsaicin.mamane.lu> --- configure.ac~ 2008-08-08 01:50:15.000000000 +0200 +++ configure.ac 2009-07-30 12:47:50.000000000 +0200 @@ -245,7 +245,7 @@ if test "$have_ksba" = "no"; then AC_MSG_NOTICE([[ *** -*** libksba not found, building with X.509 authentication support. +*** libksba not found, building without X.509 authentication support. *** libksba can be retrieved from: *** URL FIXME *** (at least version $NEED_KSBA_VERSION (API $NEED_KSBA_API) is required). -- Lionel From wk at gnupg.org Thu Jul 30 15:58:28 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 Jul 2009 15:58:28 +0200 Subject: Adding support for z/OS in gnupg and related libraries In-Reply-To: <4A7097AB.9080705@fnis.com> (Amul Shah's message of "Wed, 29 Jul 2009 14:40:43 -0400") References: <4A7097AB.9080705@fnis.com> Message-ID: <87k51qqnln.fsf@wheatstone.g10code.de> On Wed, 29 Jul 2009 20:40, amul.shah at fnis.com said: > Please excuse the cross-post. Some of the hoops that I jumped through gnupg-devel is fine. We can drop gcrypt-devel. > gnupg 1.4.9 > libgpg-errors 1.7 > libgcrypt 1.4.4 > libgpgme 1.1.8 Is there a reason why you work on 1.4.x and libgcrypt? Libgcrypt is only required for 2.x. > Services. The platform's native character encoding (aka code page or > code set) is not ASCII, but EBCDIC. The US dialect of EBCDIC is FWIW, once upon a time gpg had some limited support for EBCDIC but that was later dropped. > USS program are compiled as 31bit EBCDIC with no Unicode capabilities. What does USS mean in this context? > autotools is weak. Where I wanted to build shared libraries, I compiled > archives. I unpacked the archives and converted them to shared libs Support for shared libraries needs to be added to libtool; that is a wrapper to abstarct the building of shared libs. It is quite possible that it does not yet support zOS - I have not checked. > Configuration options: > ./configure CC=xlc CFLAGS="-qchars=signed -qascii -q64 -qlanglvl=extc99 > -qexportall -qrent -qnocsect -W l,DLL -D_XOPEN_SOURCE=600 > -D_ENHANCED_ASCII_EXT=0xFFFFFFFF -D_IEEEV1_COMPATIBILITY > -D_OPEN_MSGQ_EXT" LD=xlc LDFLAGS="-qascii -q64 -W l,DLL" CXX=xlc++ > --enable-shared --prefix=/usr/local In general those required options should go into configure.ac. We can test there for the zOS and apply specific options. What is the reason that you used CC=xls? Is there another C compiler which can't be used? The configure script should be able to detect the compiler. > There is an issue with the xlc configuration that defaults to picking up > include files from '.' (current working directory) and /usr/include > before picking up command line options. Since the z/OS system has two > headers with the same name as headers in libgcrypt, we link them into Doesn't xlc support the -I option? "-I ." should pick up the packages header files first. > -- gnupg-1.4.9 > Apply the attached patch gnupg-1.4.9.patch which applies to gnupg > 1.4.9. I will need help migrating this to the v2 line of gnupg Is your target GnuPG-1.4 or GnuPG-2? If at all possible I would suggest to target GnuPG-2. > Configuration options: > ./configure CC=xlc CFLAGS="-qchars=signed -qascii -q64 -qlanglvl=extc99 > -qexportall -qrent -qnocsect -W l,DLL -D_XOPEN_SOURCE=600 > -D_ENHANCED_ASCII_EXT=0xFFFFFFFF -D_IEEEV1_COMPATIBILITY > -D_OPEN_MSGQ_EXT" LD=xlc LDFLAGS="-qascii -q64 -W l,DLL" CXX=xlc++ > --without-pth --without-libassuan --without-ksba --prefix=/usr/local The --without-* options are not needed but they don't harm for 1.4. --prefix=/usr/local is anyway the default. > -- Generating Shared Libs from archives Weel, we need to look into libtool. > diff -purN gnupg-1.4.9.orig/checks/conventional-mdc.test gnupg-1.4.9.working-20090430/checks/conventional-mdc.test > --- gnupg-1.4.9.orig/checks/conventional-mdc.test Tue Oct 23 04:53:20 2007 > +++ gnupg-1.4.9.working-20090430/checks/conventional-mdc.test Wed Apr 29 16:29:29 2009 > @@ -9,8 +9,10 @@ for ciph in `all_cipher_algos`; do > # *BSD's dd can't cope with a count of 0 > if test "$i" = "0"; then > : >z > + chtag -tc ISO8859-1 z This is a platform specific tool. It needs to be changed to a shell fucntion which figures out the the latform and calls it only if needed. Not a big deal. > diff -purN gnupg-1.4.9.orig/g10/gpg.c gnupg-1.4.9.working-20090430/g10/gpg.c > --- gnupg-1.4.9.orig/g10/gpg.c Thu Mar 20 05:06:43 2008 > +++ gnupg-1.4.9.working-20090430/g10/gpg.c Thu Apr 30 13:02:17 2009 > @@ -18,6 +18,7 @@ > * along with this program; if not, see . > */ > > +#include "platform_pragma.h" > #include This platform_pragma.h file should be included by config.h so that there is no need to chnage all source files. config.h is created by configure. > --- gnupg-1.4.9.orig/g10/Makefile.in Wed Mar 26 13:30:47 2008 > +++ gnupg-1.4.9.working-20090430/g10/Makefile.in Thu Apr 30 10:05:30 2009 Don't chnage Makefile.in; the source is Makefile.am. > clean-generic: > + rm -f *.dbg *.x This is done using a CLEAN target in Makefile.am > +/* platform_pragma.h - platform specific pragmas > + * Copyright (C) 2009 Fidelity Information Services, Inc One imortant point to get your code into GnuPG. We require copyright assignments to the FSF. We should discuss the terms off-list. > diff -purN gnupg-1.4.9.orig/intl/bindtextdom.c gnupg-1.4.9.working-20090430/intl/bindtextdom.c > --- gnupg-1.4.9.orig/intl/bindtextdom.c Tue Oct 23 05:25:01 2007 > +++ gnupg-1.4.9.working-20090430/intl/bindtextdom.c Mon Apr 27 14:38:32 2009 These are files installed from the gettext package. It is possible to change that in GnuPG but the next time we update the gettext stuff it will be lost. Thus it needs to be integrated into gettext proper. > +int zos_getpccsid(int fd) > +{ The GNU project uses a different indendation; The important part is to align the function name to the first column: int zos_getpccsid(int fd) { > diff -purN gnupg-1.4.9.orig/util/Makefile.in gnupg-1.4.9.working-20090430/util/Makefile.in Well, Makefile.am ;-) > diff -pruN libgcrypt-1.4.4.orig/src/ath.c libgcrypt-1.4.4.new/src/ath.c > --- libgcrypt-1.4.4.orig/src/ath.c Wed Sep 3 06:04:42 2008 > +++ libgcrypt-1.4.4.new/src/ath.c Thu Apr 30 11:16:28 2009 > @@ -30,6 +30,9 @@ > # include > #endif > #include > +#if defined(__MVS__) > +#include > +#endif This is better handled using a configure test. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From lionel at mamane.lu Thu Jul 30 19:46:27 2009 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Thu, 30 Jul 2009 19:46:27 +0200 Subject: Poldi bug report: quieter, better prompts Message-ID: <20090730174627.GB12475@capsaicin.mamane.lu> Poldi is quite chatty in the PAM conversation, even when not in debug mode. This patch cuts on that. It is mainly justified by the fact that xscreensaver requires a positive user action (click "OK" button) for every conv_tell, so I don't what any more than necessary / useful. I've also tweaked the prompts I left in non-debug mode, and inserted some helpful-for-the-user error messages in the PAM dialog. --- poldi-0.4.1.orig/src/pam/pam_poldi.c +++ poldi-0.4.1/src/pam/pam_poldi.c @@ -480,12 +480,12 @@ { if (ctx->debug) log_msg_debug (ctx->loghandle, _("Waiting for card for user `%s'..."), pam_username); - conv_tell (ctx->conv, _("Waiting for card for user `%s'..."), pam_username); + conv_tell (ctx->conv, _("Insert authentication card for user `%s'"), pam_username); } else { if (ctx->debug) log_msg_debug (ctx->loghandle, _("Waiting for card...")); - conv_tell (ctx->conv, _("Waiting for card...")); + conv_tell (ctx->conv, _("Insert authentication card")); } --- poldi-0.4.1.orig/src/pam/auth-method-localdb/auth-localdb.c +++ poldi-0.4.1/src/pam/auth-method-localdb/auth-localdb.c @@ -117,10 +117,12 @@ username = username_desired; if (ctx->debug) - log_msg_debug (ctx->conv, - _("Trying authentication as user `%s'..."), username); - conv_tell (ctx->conv, - _("Trying authentication as user `%s'..."), username); + { + log_msg_debug (ctx->conv, + _("Trying authentication as user `%s'..."), username); + conv_tell (ctx->conv, + _("Trying authentication as user `%s'..."), username); + } /* Verify (again) that the given account is associated with the serial number. */ @@ -128,12 +130,14 @@ if (err) { if (ctx->debug) - log_msg_debug (ctx->loghandle, - _("Serial number %s is not associated with user %s"), - ctx->cardinfo.serialno, username); - conv_tell (ctx->conv, - _("Serial number %s is not associated with user %s"), - ctx->cardinfo.serialno, username); + { + log_msg_debug (ctx->loghandle, + _("Serial number %s is not associated with user %s"), + ctx->cardinfo.serialno, username); + conv_tell (ctx->conv, + _("Serial number %s is not associated with user %s"), + ctx->cardinfo.serialno, username); + } err = gcry_error (GPG_ERR_INV_NAME); goto out; } --- poldi-0.4.1.orig/src/pam/auth-support/getpin-cb.c +++ poldi-0.4.1/src/pam/auth-support/getpin-cb.c @@ -81,9 +81,12 @@ Shouldn't they be done in scdaemon itself? -mo */ if (strlen (buffer) < 6) /* FIXME? is it really minimum of 6 bytes? */ - log_msg_error (ctx->loghandle, _("invalid PIN")); + { + log_msg_error (ctx->loghandle, _("PIN too short")); + conv_tell(ctx->conv, "%s", _("PIN too short")); + } else if (!all_digitsp (buffer)) log_msg_error (ctx->loghandle, _("invalid characters in PIN")); else break; } @@ -235,7 +241,7 @@ err = query_user (ctx, info_frobbed, buf, maxbuf); else /* Use string which is more user friendly. */ - err = query_user (ctx, _("||Please enter the PIN"), buf, maxbuf); + err = query_user (ctx, _("Please enter the PIN: "), buf, maxbuf); } else { @@ -254,7 +260,7 @@ if (info_frobbed) err = keypad_mode_enter (ctx, info_frobbed); else - err = keypad_mode_enter (ctx, _("||Please enter the PIN")); + err = keypad_mode_enter (ctx, _("Please enter the PIN: ")); } else err = gpg_error (GPG_ERR_INV_VALUE); /* FIXME: must signal -- Lionel From lionel at mamane.lu Thu Jul 30 19:49:34 2009 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Thu, 30 Jul 2009 19:49:34 +0200 Subject: Poldi bug report: allow non-digit PIN Message-ID: <20090730174934.GC12475@capsaicin.mamane.lu> My OpenPGP smartcard has non-digits in its PIN, so it needs poldi to allow that. Note: you may want to also remove the all_digitsp function. --- poldi-0.4.1.orig/src/pam/auth-support/getpin-cb.c +++ poldi-0.4.1/src/pam/auth-support/getpin-cb.c @@ -85,5 +88,3 @@ - else if (!all_digitsp (buffer)) - log_msg_error (ctx->loghandle, _("invalid characters in PIN")); else break; } -- Lionel From lionel at mamane.lu Thu Jul 30 19:51:14 2009 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Thu, 30 Jul 2009 19:51:14 +0200 Subject: Poldi bug report: better default config file Message-ID: <20090730175113.GD12475@capsaicin.mamane.lu> Default configuration file good for production use, not for one developer's machine. --- poldi-0.4.1.orig/conf/poldi.conf.skel +++ poldi-0.4.1/conf/poldi.conf.skel @@ -5,10 +5,10 @@ auth-method localdb # Specify the log file: -log-file /home/moritz/logs/poldi.txt +log-file /var/log/poldi # Enable debugging messages -debug +# debug # Specify SCDaemon executable scdaemon-program /usr/bin/scdaemon -- Lionel From lionel at mamane.lu Thu Jul 30 19:58:43 2009 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Thu, 30 Jul 2009 19:58:43 +0200 Subject: Poldi bug report: better scdaemon handling Message-ID: <20090730175843.GE12475@capsaicin.mamane.lu> - don't clutter the display with scdaemon stderr - use a global configuration file for scdaemon --- poldi-0.4.1.orig/conf/Makefile.am +++ poldi-0.4.1/conf/Makefile.am @@ -33,5 +33,11 @@ install -m 644 -T $(top_srcdir)/conf/poldi.conf.skel \ $(DESTDIR)$(POLDI_CONF_DIRECTORY)/poldi.conf; \ fi + if test -e $(DESTDIR)$(POLDI_CONF_DIRECTORY)/scdaemon.conf; then \ + echo "$(DESTDIR)$(POLDI_CONF_DIRECTORY)/scdaemon.conf exists, doing nothing here"; \ + else \ + install -m 644 -T $(top_srcdir)/conf/scdaemon.conf.skel \ + $(DESTDIR)$(POLDI_CONF_DIRECTORY)/scdaemon.conf; \ + fi -EXTRA_DIST = poldi.conf.skel users.skel README.keys +EXTRA_DIST = poldi.conf.skel users.skel scdaemon.conf.skel README.keys --- poldi-0.4.1.orig/src/scd/scd.c +++ poldi-0.4.1/src/scd/scd.c @@ -326,7 +326,7 @@ fallback: spawn a new scdaemon. */ const char *pgmname; - const char *argv[3]; + const char *argv[6]; int no_close_list[3]; int i; @@ -352,7 +352,13 @@ argv[0] = pgmname; argv[1] = "--server"; - argv[2] = NULL; + argv[2] = "--options"; + argv[3] = "/etc/poldi/scdaemon.conf"; + if (flags & SCD_FLAG_VERBOSE) + argv[4] = "-v"; + else + argv[4] = NULL; + argv[5] = NULL; i=0; @@ -362,7 +368,8 @@ if (log_get_fd () != -1) no_close_list[i++] = log_get_fd (); #endif - no_close_list[i++] = fileno (stderr); + if (flags & SCD_FLAG_VERBOSE) + no_close_list[i++] = fileno (stderr); no_close_list[i] = -1; /* connect to the agent and perform initial handshaking */ -- Lionel From lionel at mamane.lu Thu Jul 30 19:38:36 2009 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Thu, 30 Jul 2009 19:38:36 +0200 Subject: Poldi bug report: hangs indefinitely when no card inserted Message-ID: <20090730173836.GA12475@capsaicin.mamane.lu> If poldi is configured in the PAM stack, there is a reader, but no card inserted, poldi waits indefinitely for a card. In a scenario where authentication is poldi or unix (try smartcard, if failure, use traditional UNIX password), if the user has no card with him, this keeps him from authenticating. --- poldi-0.4.1.orig/src/pam/pam_poldi.c +++ poldi-0.4.1/src/pam/pam_poldi.c @@ -491,5 +491,5 @@ - err = wait_for_card (ctx->scd, 0); + err = wait_for_card (ctx->scd, 3); if (err) { log_msg_error (ctx->loghandle, -- Lionel From lionel at mamane.lu Thu Jul 30 20:16:00 2009 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Thu, 30 Jul 2009 20:16:00 +0200 Subject: Poldi feature suggestion Message-ID: <20090730181600.GA13159@capsaicin.mamane.lu> --- poldi-0.4.1.orig/TODO +++ poldi-0.4.1/TODO @@ -2,6 +2,9 @@ * allow for Dirmngr to be started on demand (in pipe mode) (NO <- Why?!) Low priority: +* allow user to skip card authentication without submitting a wrong + PIN to the card, e.g. by entering an empty PIN? Return + PAM_CRED_INSUFFICIENT in that case? PAM_AUTHINFO_UNAVAIL? PAM_AUTH_ERR? * figure out what exactly the dependencies on the OpenPGP smartcard are. * improve doc * work on MIGRATION text - don't clutter the display with scdaemon stderr - use a global configuration file for scdaemon -- Lionel From lionel at mamane.lu Thu Jul 30 20:41:35 2009 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Thu, 30 Jul 2009 20:41:35 +0200 Subject: Poldi bug report: better scdaemon handling In-Reply-To: <20090730175843.GE12475@capsaicin.mamane.lu> References: <20090730175843.GE12475@capsaicin.mamane.lu> Message-ID: <20090730184135.GA13623@capsaicin.mamane.lu> On Thu, Jul 30, 2009 at 07:58:43PM +0200, Lionel Elie Mamane wrote: > - don't clutter the display with scdaemon stderr > - use a global configuration file for scdaemon I just realised that diff does not handle empty files. I had created an empty "conf/scdaemon.conf.skel" file. Just put "#" in it to make it non-empty or even better a real skeleton. Possibly the gnupg2 sources actually contain a good skeleton you can just copy? -- Lionel From dshaw at jabberwocky.com Fri Jul 31 06:46:45 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 31 Jul 2009 00:46:45 -0400 Subject: Minor bug in --pgp6 option In-Reply-To: <1208576093.6696741248802520723.JavaMail.root@sz0115a.westchester.pa.mail.comcast.net> References: <1208576093.6696741248802520723.JavaMail.root@sz0115a.westchester.pa.mail.comcast.net> Message-ID: <4ABFC8B3-1C33-44D8-9A1B-805253CD167B@jabberwocky.com> On Jul 28, 2009, at 1:35 PM, anon4321 at comcast.net wrote: > I checked the source of gnppg 1.4.9 and 2.0.12 and both seem to be > missing some settings when the --pgp6 option is used. Thanks for the report. It will be fixed in the next version. David From kevhilton at gmail.com Fri Jul 31 07:09:18 2009 From: kevhilton at gmail.com (Kevin Hilton) Date: Fri, 31 Jul 2009 00:09:18 -0500 Subject: GPG SVN Compilation Errors - cygwin Message-ID: <96c450350907302209o57872c1ar572eaaa5ed21383@mail.gmail.com> gpg2 svn version 5102 Receiving following errors trying to compile: (I'm open to suggestions) and thanks for help!: /usr/local/lib/libgcrypt.a(pubkey.o): In function `_gcry_pk_encrypt': /home/admin/src/libgcrypt/cipher/pubkey.c:1656: undefined reference to `_stpcpy' /usr/local/lib/libgcrypt.a(pubkey.o): In function `_gcry_pk_sign': /home/admin/src/libgcrypt/cipher/pubkey.c:1889: undefined reference to `_stpcpy' /usr/local/lib/libgcrypt.a(pubkey.o): In function `_gcry_pk_genkey': /home/admin/src/libgcrypt/cipher/pubkey.c:2220: undefined reference to `_stpcpy' /home/admin/src/libgcrypt/cipher/pubkey.c:2230: undefined reference to `_stpcpy' /usr/local/lib/libgcrypt.a(libgcrypt_la-global.o): In function `parse_version_nu mber': /home/admin/src/libgcrypt/src/global.c:170: undefined reference to `__imp____cty pe_ptr__' /home/admin/src/libgcrypt/src/global.c:170: undefined reference to `__imp____cty pe_ptr__' /usr/local/lib/libgcrypt.a(libgcrypt_la-sexp.o): In function `_gcry_sexp_dump': /home/admin/src/libgcrypt/src/sexp.c:96: undefined reference to `__imp____ctype_ ptr__' /usr/local/lib/libgcrypt.a(libgcrypt_la-sexp.o): In function `sexp_sscan': /home/admin/src/libgcrypt/src/sexp.c:1162: undefined reference to `__imp____ctyp e_ptr__' /usr/local/lib/libgcrypt.a(libgcrypt_la-sexp.o): In function `_gcry_sexp_sprint' : /home/admin/src/libgcrypt/src/sexp.c:1802: undefined reference to `_stpcpy' /usr/local/lib/libgcrypt.a(libgcrypt_la-ath.o): In function `_gcry_ath_mutex_des troy': /home/admin/src/libgcrypt/src/ath.c:173: undefined reference to `___assert_func' /usr/local/lib/libgcrypt.a(libgcrypt_la-ath.o): In function `_gcry_ath_mutex_loc k': /home/admin/src/libgcrypt/src/ath.c:193: undefined reference to `___assert_func' /usr/local/lib/libgcrypt.a(libgcrypt_la-ath.o): In function `_gcry_ath_mutex_unl ock': /home/admin/src/libgcrypt/src/ath.c:213: undefined reference to `___assert_func' collect2: ld returned 1 exit status make[3]: *** [t-convert.exe] Error 1 make[3]: Leaving directory `/home/admin/src/gpg2/common' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/admin/src/gpg2/common' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/admin/src/gpg2' make: *** [all] Error 2 -- Kevin Hilton From wk at gnupg.org Fri Jul 31 10:00:11 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 31 Jul 2009 10:00:11 +0200 Subject: GPG SVN Compilation Errors - cygwin In-Reply-To: <96c450350907302209o57872c1ar572eaaa5ed21383@mail.gmail.com> (Kevin Hilton's message of "Fri, 31 Jul 2009 00:09:18 -0500") References: <96c450350907302209o57872c1ar572eaaa5ed21383@mail.gmail.com> Message-ID: <87zlalp9is.fsf@wheatstone.g10code.de> On Fri, 31 Jul 2009 07:09, kevhilton at gmail.com said: > gpg2 svn version 5102 > > Receiving following errors trying to compile: (I'm open to > suggestions) and thanks for help!: > > /usr/local/lib/libgcrypt.a(pubkey.o): In function `_gcry_pk_encrypt': > /home/admin/src/libgcrypt/cipher/pubkey.c:1656: undefined reference to `_stpcpy' > make[3]: *** [t-convert.exe] Error 1 > make[3]: Leaving directory `/home/admin/src/gpg2/common' The configure script of libgcrypt found that the stpcpy function is available but when linked to the t-convert.exe test program it can't find it. Maybe stpcpy is not required for linkint t-convert and somehow ld does not get it that it libgcrypt needs stpcpy. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From kevhilton at gmail.com Fri Jul 31 23:50:06 2009 From: kevhilton at gmail.com (Kevin Hilton) Date: Fri, 31 Jul 2009 16:50:06 -0500 Subject: GPGME Compilation Questions Message-ID: <96c450350907311450w15ad951l9d16f1b376e0e69f@mail.gmail.com> Yet more cygwin errors trying this time to compile gpgme: gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt.exe t-en crypt.o ../../src/.libs/libgpgme.a /usr/lib/libgpg-error.dll.a -L/usr/lib /usr/ lib/libintl.dll.a /usr/lib/libiconv.dll.a t-encrypt.o: In function `print_data': /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:58: undefined referenc e to `_gpgme_data_seek' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:62: undefined referenc e to `_gpgme_data_read' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:60: undefined referenc e to `_gpgme_err_code_from_errno' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:60: undefined referenc e to `_gpgme_err_code_from_errno' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:60: undefined referenc e to `_gpgme_strerror' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:60: undefined referenc e to `_gpgme_err_code_from_errno' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:60: undefined referenc e to `_gpgme_strsource' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:64: undefined referenc e to `_gpgme_err_code_from_errno' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:64: undefined referenc e to `_gpgme_err_code_from_errno' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:64: undefined referenc e to `_gpgme_strerror' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:64: undefined referenc e to `_gpgme_err_code_from_errno' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:64: undefined referenc e to `_gpgme_strsource' t-encrypt.o: In function `init_gpgme': /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:106: undefined referen ce to `_gpgme_check_version' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:108: undefined referen ce to `_gpgme_set_locale' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:110: undefined referen ce to `_gpgme_set_locale' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:113: undefined referen ce to `_gpgme_engine_check_version' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:114: undefined referen ce to `_gpgme_strerror' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-support.h:114: undefined referen ce to `_gpgme_strsource' t-encrypt.o: In function `main': /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:48: undefined referenc e to `_gpgme_new' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:50: undefined referenc e to `_gpgme_set_armor' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:52: undefined referenc e to `_gpgme_data_new_from_mem' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:55: undefined referenc e to `_gpgme_data_new' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:58: undefined referenc e to `_gpgme_get_key' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:61: undefined referenc e to `_gpgme_get_key' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:65: undefined referenc e to `_gpgme_op_encrypt' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:67: undefined referenc e to `_gpgme_op_encrypt_result' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:76: undefined referenc e to `_gpgme_key_unref' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:77: undefined referenc e to `_gpgme_key_unref' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:78: undefined referenc e to `_gpgme_data_release' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:79: undefined referenc e to `_gpgme_data_release' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:80: undefined referenc e to `_gpgme_release' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:49: undefined referenc e to `_gpgme_strerror' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:49: undefined referenc e to `_gpgme_strsource' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:53: undefined referenc e to `_gpgme_strerror' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:53: undefined referenc e to `_gpgme_strsource' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:56: undefined referenc e to `_gpgme_strerror' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:56: undefined referenc e to `_gpgme_strsource' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:60: undefined referenc e to `_gpgme_strerror' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:60: undefined referenc e to `_gpgme_strsource' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:63: undefined referenc e to `_gpgme_strerror' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:63: undefined referenc e to `_gpgme_strsource' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:66: undefined referenc e to `_gpgme_strerror' /cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg/t-encrypt.c:66: undefined referenc e to `_gpgme_strsource' collect2: ld returned 1 exit status make[3]: *** [t-encrypt.exe] Error 1 make[3]: Leaving directory `/cygdrive/c/temp/fwknop/gpgme-1.1.8/tests/gpg' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/cygdrive/c/temp/fwknop/gpgme-1.1.8/tests' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/c/temp/fwknop/gpgme-1.1.8' make: *** [all] Error 2 -- Kevin Hilton