From Wyllys.Ingersoll at Sun.COM Tue Dec 1 21:57:47 2009 From: Wyllys.Ingersoll at Sun.COM (Wyllys Ingersoll) Date: Tue, 01 Dec 2009 15:57:47 -0500 Subject: [PATCH] - gpgme mkstatus Message-ID: <4B15834B.3010908@sun.com> gpgme mkstatus should use "gawk" instead of "awk". On some platforms (Solaris), awk and gawk are not the same and only 'gawk' will work correctly. Attached is a patch. -Wyllys Ingersoll -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mkstatus.patch URL: From Wyllys.Ingersoll at Sun.COM Tue Dec 1 22:00:40 2009 From: Wyllys.Ingersoll at Sun.COM (Wyllys Ingersoll) Date: Tue, 01 Dec 2009 16:00:40 -0500 Subject: [PATCH] - pinentry pinentry-curses.c Message-ID: <4B1583F8.9080507@sun.com> pinentry-curses.c has a switch statement that looks for characters like "\t" and "\e", it should use numerical values for these constants, different compilers intepret the characters differently which results in unexpected behavior. Attached is a patch against the source from the pinentry-0.7.6 tarball. -Wyllys Ingersoll -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pinentry-curses.c.patch URL: From Wyllys.Ingersoll at Sun.COM Tue Dec 1 21:56:03 2009 From: Wyllys.Ingersoll at Sun.COM (Wyllys Ingersoll) Date: Tue, 01 Dec 2009 15:56:03 -0500 Subject: [PATCH] - gpgme gpgconf.c Message-ID: <4B1582E3.9010409@sun.com> There is a minor bug in gpgme/src/gpgconf.c which causes it to fail to compile with some compilers. gpgme_conf_arg_release is declared a "void" function but it is currently coded to return the results of _gpgme_conf_arg_release The patch attached is against the tarball from 1.1.8: -Wyllys Ingersoll Sun Microsystems, Inc. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gpgconf.c.patch URL: From Wyllys.Ingersoll at Sun.COM Tue Dec 1 22:03:15 2009 From: Wyllys.Ingersoll at Sun.COM (Wyllys Ingersoll) Date: Tue, 01 Dec 2009 16:03:15 -0500 Subject: [PATCH] - pinentry secmem/util.c Message-ID: <4B158493.1000106@sun.com> Attached is a patch for the pinentry secmem/util.c file. The TEMP_FAILURE_RETRY macro uses "__extension__" which is unsupported on some compilers and will cause the build to fail. I'm not sure it is necessary or helpful in the first place. -Wyllys Ingersoll -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: util.c.patch URL: From wk at gnupg.org Wed Dec 2 09:02:59 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Dec 2009 09:02:59 +0100 Subject: [PATCH] - gpgme mkstatus In-Reply-To: <4B15834B.3010908@sun.com> References: <4B15834B.3010908@sun.com> Message-ID: <874oo9vm4s.wl%wk@gnupg.org> > gpgme mkstatus should use "gawk" instead of "awk". On some platforms (Solaris), > awk and gawk are not the same and only 'gawk' will work correctly. Can you point out the gawk specific suff we use? The script is intended to work with a POSIX or other commonly used awk. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 2 09:06:01 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Dec 2009 09:06:01 +0100 Subject: [PATCH] - pinentry pinentry-curses.c In-Reply-To: <4B1583F8.9080507@sun.com> References: <4B1583F8.9080507@sun.com> Message-ID: <873a3tvlzq.wl%wk@gnupg.org> Hi! On Tue, 01 Dec 2009 16:00:40 -0500, Wyllys Ingersoll wrote: > pinentry-curses.c has a switch statement that looks for > characters like "\t" and "\e", it should use numerical values > for these constants, different compilers intepret the characters > differently which results in unexpected behavior. I agree that \e is a non-standard extension and should be replace. However \t is a TAB and that is the same on all ASCII based systems. Right, we don't care about EBCDIC. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 2 09:14:46 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Dec 2009 09:14:46 +0100 Subject: [PATCH] - pinentry secmem/util.c In-Reply-To: <4B158493.1000106@sun.com> References: <4B158493.1000106@sun.com> Message-ID: <871vjdvll5.wl%wk@gnupg.org> Hi! I removed it: * secmem/util.c: Re-indent function names. (TEMP_FAILURE_RETRY): Remove because it is non-portable. (xwrite): Open code the EINTR retry. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Wed Dec 2 14:59:51 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 2 Dec 2009 14:59:51 +0100 Subject: [PATCH] - gpgme gpgconf.c In-Reply-To: <4B1582E3.9010409@sun.com> References: <4B1582E3.9010409@sun.com> Message-ID: <4B1672D7.2090806@ruhr-uni-bochum.de> Wyllys Ingersoll wrote: > There is a minor bug in gpgme/src/gpgconf.c which causes it to fail to compile with > some compilers. gpgme_conf_arg_release is declared a "void" function but it is > currently coded to return the results of _gpgme_conf_arg_release Werner put it in, thanks for reporting it. Marcus From Wyllys.Ingersoll at Sun.COM Wed Dec 2 18:07:59 2009 From: Wyllys.Ingersoll at Sun.COM (Wyllys Ingersoll) Date: Wed, 02 Dec 2009 12:07:59 -0500 Subject: [PATCH] - gpgme mkstatus In-Reply-To: <874oo9vm4s.wl%wk@gnupg.org> References: <4B15834B.3010908@sun.com> <874oo9vm4s.wl%wk@gnupg.org> Message-ID: <4B169EEF.1010307@sun.com> Werner Koch wrote: >> gpgme mkstatus should use "gawk" instead of "awk". On some platforms (Solaris), >> awk and gawk are not the same and only 'gawk' will work correctly. > > Can you point out the gawk specific suff we use? The script is > intended to work with a POSIX or other commonly used awk. > > > Shalom-Salam, > > Werner > I get the following error when building with the standard 'awk' (/usr/bin/awk) in Solaris: ./mkstatus < ./gpgme.h > status-table.h awk: syntax error near line 3 awk: bailing out near line 3 The "awk" statement in mkstatus looks like this: awk ' /GPGME_STATUS_ENTER/ { okay = 1 } !okay { next } /}/ { exit 0 } /GPGME_STATUS_[A-Za-z_]*/ { sub (/,/, "", $1); printf " { \"%s\", %s },\n", substr($1,14), $1 } ' | sort The standard Solaris awk doesn't like the "!okay" expression. That is easy enough to fix, change it to "okay == 0" and it doesn't complain. However, that exposes a larger issue with Solaris /usr/bin/awk - it doesn't support the "sub" statement. Switching to 'gawk' is the easiest fix. -Wyllys From wk at gnupg.org Thu Dec 3 10:54:32 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Dec 2009 10:54:32 +0100 Subject: Change s2k count? In-Reply-To: References: Message-ID: <87hbs8tmav.wl%wk@gnupg.org> On Mon, 30 Nov 2009 10:29:08 -0500, David Shaw wrote: > There are a number of factors: obviously we must take care with the > setting here - too high and it can make decrypting with a passphrase > (either a secret key decryption or a passphrase protected message) I don't consider the latter a real problem. If you use symmetric only encryption it is very likely that you are working in a custom environment which is for example needed to take care about key management. In that case you can setup a non-default s2k count. In the rare case that you receive symmetric only message, you got the key by, say, phone and conveying the key takes some time anyway. Thus an extra delay on a small device should not be too troublesome. For passphrase protected secret keys, passphrase caching helps to avoid delays. > It could be argued that cell phone usage actually needs the iterated > hash even more as typing a long high-entropy passphrase is extremely > difficult on a cell phone. I doubt that keeping highly confidential keys on a smartphone is a good idea at all. On most devices (notable exception is the Neo Freerunner) you don't entirely control the device due to malware and the phone system operator's ability to gain access to it. > dropping. If 65536 was the right value for 11 years ago, we > probably could do with a brief discussion on whether we should raise > it for today (and if so, how much). I agree. I heard that PGP measures the performance during key generation and selects the S2K count depending on that value. Most people are using their keys on just one machine and thus it would fit their needs. If they are switching to another hardware they can easily change the passphrase and thus use a new S2K count. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at JABBERWOCKY.COM Thu Dec 3 16:58:02 2009 From: dshaw at JABBERWOCKY.COM (David Shaw) Date: Thu, 3 Dec 2009 10:58:02 -0500 Subject: Change s2k count? In-Reply-To: <87hbs8tmav.wl%wk@gnupg.org> References: <87hbs8tmav.wl%wk@gnupg.org> Message-ID: <63678113-A8FB-4555-9B8C-EFA3C10D80CD@JABBERWOCKY.COM> On Dec 3, 2009, at 4:54 AM, Werner Koch wrote: > I doubt that keeping highly confidential keys on a smartphone is a > good idea at all. On most devices (notable exception is the Neo > Freerunner) you don't entirely control the device due to malware and > the phone system operator's ability to gain access to it. Not wise, I agree. But people do keep all sorts of stuff on their phone. I seem to recall that the Blackberry has an OpenPGP client that keeps keys locally (if someone knows one way or the other for sure, please jump in). >> dropping. If 65536 was the right value for 11 years ago, we >> probably could do with a brief discussion on whether we should raise >> it for today (and if so, how much). > > I agree. I heard that PGP measures the performance during key > generation and selects the S2K count depending on that value. Most > people are using their keys on just one machine and thus it would fit > their needs. If they are switching to another hardware they can > easily change the passphrase and thus use a new S2K count. PGP calculates whatever count your computer can do in 1/10 of a second and uses that. It seems like a reasonable solution to me. If someone explicitly sets a --s2k-count, we'll use what they set. If they don't, we can do the 1/10-second calculation. David From dkg at fifthhorseman.net Thu Dec 3 17:46:03 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 03 Dec 2009 11:46:03 -0500 Subject: Change s2k count? In-Reply-To: <63678113-A8FB-4555-9B8C-EFA3C10D80CD@JABBERWOCKY.COM> References: <87hbs8tmav.wl%wk@gnupg.org> <63678113-A8FB-4555-9B8C-EFA3C10D80CD@JABBERWOCKY.COM> Message-ID: <4B17EB4B.2090204@fifthhorseman.net> On 12/03/2009 10:58 AM, David Shaw wrote: > PGP calculates whatever count your computer can do in 1/10 of > a second and uses that. It seems like a reasonable solution to > me. If someone explicitly sets a --s2k-count, we'll use what > they set. If they don't, we can do the 1/10-second calculation. I like the elegance of this solution, but couldn't this calculation be confounded by other load on the processor? For example, if i'm generating a new key (or changing a passphrase) while also encoding video, it would be a shame if gpg were to pick a too-low value. I suppose i'm suggesting that it would be important to check times(2) instead of gettimeofday(2) (on POSIX systems, anyway, i dunno about win32), but also that it would be good to retain a lower-bound as a sanity check (perhaps the current value could be a lower-bound unless explicitly specified by the user). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu Dec 3 18:06:03 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 3 Dec 2009 12:06:03 -0500 Subject: Change s2k count? In-Reply-To: <4B17EB4B.2090204@fifthhorseman.net> References: <87hbs8tmav.wl%wk@gnupg.org> <63678113-A8FB-4555-9B8C-EFA3C10D80CD@JABBERWOCKY.COM> <4B17EB4B.2090204@fifthhorseman.net> Message-ID: On Dec 3, 2009, at 11:46 AM, Daniel Kahn Gillmor wrote: > On 12/03/2009 10:58 AM, David Shaw wrote: >> PGP calculates whatever count your computer can do in 1/10 of >> a second and uses that. It seems like a reasonable solution to >> me. If someone explicitly sets a --s2k-count, we'll use what >> they set. If they don't, we can do the 1/10-second calculation. > > I like the elegance of this solution, but couldn't this calculation be > confounded by other load on the processor? For example, if i'm > generating a new key (or changing a passphrase) while also encoding > video, it would be a shame if gpg were to pick a too-low value. > > I suppose i'm suggesting that it would be important to check times(2) > instead of gettimeofday(2) (on POSIX systems, anyway, i dunno about > win32), but also that it would be good to retain a lower-bound as a > sanity check (perhaps the current value could be a lower-bound unless > explicitly specified by the user). There will of course be a lower bound (probably should be larger than 65536, actually). David From rjh at sixdemonbag.org Thu Dec 3 21:48:25 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 03 Dec 2009 15:48:25 -0500 Subject: Change s2k count? In-Reply-To: <4B17EB4B.2090204@fifthhorseman.net> References: <87hbs8tmav.wl%wk@gnupg.org> <63678113-A8FB-4555-9B8C-EFA3C10D80CD@JABBERWOCKY.COM> <4B17EB4B.2090204@fifthhorseman.net> Message-ID: <4B182419.8000105@sixdemonbag.org> Daniel Kahn Gillmor wrote: > I like the elegance of this solution, but couldn't this calculation be > confounded by other load on the processor? For example, if i'm > generating a new key (or changing a passphrase) while also encoding > video, it would be a shame if gpg were to pick a too-low value. As you said, there's an easy fix. Why check times/gettimeofday when the lower-bound method works just as well? The point is not to get asymptotically as high a count as possible. The point is to get enough of a count to slow down brute forcers. From dkg at fifthhorseman.net Thu Dec 3 22:05:50 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 03 Dec 2009 16:05:50 -0500 Subject: Change s2k count? In-Reply-To: <4B182419.8000105@sixdemonbag.org> References: <87hbs8tmav.wl%wk@gnupg.org> <63678113-A8FB-4555-9B8C-EFA3C10D80CD@JABBERWOCKY.COM> <4B17EB4B.2090204@fifthhorseman.net> <4B182419.8000105@sixdemonbag.org> Message-ID: <4B18282E.108@fifthhorseman.net> On 12/03/2009 03:48 PM, Robert J. Hansen wrote: > The point is not to get asymptotically as high a count as possible. The > point is to get enough of a count to slow down brute forcers. actually, i think getting as high a count as possible is a good goal, based on a few assumptions: 0) we're talking about secret key material, which is to be symmetrically-encrypted with the user's passphrase. 1) such secret key material is very rarely legitimately transferred between machines. 2) a delay of 0.1 seconds between passphrase entry and access to the secret key is an acceptable delay in the case of legitimate use of the key. 3) if the encrypted key is somehow transferred off the machine, we want it to be as expensive as possible to brute force the symmetric encryption. So i think the machine profiling step (using times, *not* gettimeofday) to get an acceptable upper-bound is a quite reasonable thing to have in place by default for key passphrase S2K usage. I'm not so sure it makes sense for symmetrically-encrypted messages other than secret key material, though, since the above assumptions don't necessarily hold. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Dec 3 22:26:01 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 03 Dec 2009 16:26:01 -0500 Subject: Change s2k count? In-Reply-To: <4B18282E.108@fifthhorseman.net> References: <87hbs8tmav.wl%wk@gnupg.org> <63678113-A8FB-4555-9B8C-EFA3C10D80CD@JABBERWOCKY.COM> <4B17EB4B.2090204@fifthhorseman.net> <4B182419.8000105@sixdemonbag.org> <4B18282E.108@fifthhorseman.net> Message-ID: <4B182CE9.20107@sixdemonbag.org> Daniel Kahn Gillmor wrote: > actually, i think getting as high a count as possible is a good goal, > based on a few assumptions: By the same reasoning, everyone should be using RSA-4096 for their keys. > 0) we're talking about secret key material, which is to be > symmetrically-encrypted with the user's passphrase. Yep. > 1) such secret key material is very rarely legitimately transferred > between machines. Yep. > 2) a delay of 0.1 seconds between passphrase entry and access to the > secret key is an acceptable delay in the case of legitimate use of the key. Substitute in "a delay of 0.1 seconds for each encryption/decryption" and this applies. > 3) if the encrypted key is somehow transferred off the machine, we want > it to be as expensive as possible to brute force the symmetric encryption. Substitute in "we want it to be as expensive as possible to brute force the encrypted message" and this applies. ... Of course, not everyone should be using RSA-4096. 2k keys are appropriate for the overwhelming majority of users. The point is not to get the highest numbers possible. The point is to satisfy the conditions of the local security policy. From wk at gnupg.org Fri Dec 4 12:00:42 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Dec 2009 12:00:42 +0100 Subject: Change s2k count? In-Reply-To: <87hbs8tmav.wl%wk@gnupg.org> References: <87hbs8tmav.wl%wk@gnupg.org> Message-ID: <878wdjt351.wl%wk@gnupg.org> On Thu, 03 Dec 2009 10:54:32 +0100, Werner Koch wrote: > For passphrase protected secret keys, passphrase caching helps to > avoid delays. That is of course a wrong statement. Passphrase caching does not help because the passphrase is cached and not the derived protection key. In this light a 100ms delay is too long. I sometimes get messages with wildcard keyids. Thus gpg needs to do a couple of trial decryption and for say 5 available secret keys, this adds up to 500ms - definitely too long for quickly browsing your mails. With gpg-agent we could implement a different way of caching but first we need to integrate gpg2 better with gpg-agent. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Dec 4 15:49:49 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Dec 2009 15:49:49 +0100 Subject: Read-only keyring and the keybox Message-ID: <874oo6u73m.wl%wk@gnupg.org> Hi! Complaints about multiple keyrings are an old topic but one we eventually need to solve. Daniel Leidert recently opened a bug for it listing several threads in the Debian BTS [1]. Below is my comment. I'd really like to move forward on this issue. It will be quite some work. I need to see how fast I can accomplish it while not having a project to financial backing the development. These bug reports are sometimes mixing two different issues: The debian-keyring and r/o keyrings for other purposes. The debian keyring is afaik used with gpgv and has the special property that all keys in it are fully trusted. In short: It is a set of keys only to be used by gpgv. Thus the issue is how to create this keyring. Currently I suggest to use gpg --export LIST-OF-KEYIDS to create it. In some distance future a little conversion tool might be required to convert the OpenPGP transport format for keys into the database format used by gpgv. The bottom line is that I don't see that as an issue and the Debian readme seems to support this point of view. The other issue is that of multiple keyrings. Over the years we tried several approaches to get it right but none of them worked reliable. The problem is the usual one of keeping two databases in sync. Aggravated by the requirement to keep some of them read-only but still allowing to update them somehow. Approaches like preferring the writable one over the read-only one work in theory but will lead to administrative headaches. We will never be sure which keyblock is actually used. (I had a similar problem today with VPATH builds where two different header files, both are created from the same source, provoked a bug in certain environments - not particular easy to understand what was going on) What I plan with GnuPG 2.1 is to rework the keyring situation by replacing keyrings it with a new format (keybox). This new format allows to keep meta data and also will boost key access times. This will make it possible to flag keys as read-only or allow updates only with a new options set. I am actually working on 2.1. However, before we implement such extravagant feature it will be wetter to collect real world use cases. We should do this on gnupg-devel at . One such use case might be to automatically import certain keys into the keybox for future use. This is basically the idea of reading the writable keyring first and only then the read-only ring (write-on-demand). The solution I have in mind is to import such read-only keys using the established --auth-key-locate feature. Shalom-Salam, Werner [1] https://bugs.g10code.com/gnupg/issue1129 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jharris at widomaker.com Sat Dec 5 17:53:54 2009 From: jharris at widomaker.com (Jason Harris) Date: Sat, 5 Dec 2009 12:53:54 -0400 Subject: Read-only keyring and the keybox In-Reply-To: <874oo6u73m.wl%wk@gnupg.org> References: <874oo6u73m.wl%wk@gnupg.org> Message-ID: <20091205165354.GA61315@laptop.lan> On Fri, Dec 04, 2009 at 03:49:49PM +0100, Werner Koch wrote: > Complaints about multiple keyrings are an old topic but one we > eventually need to solve. Daniel Leidert recently opened a bug for it FWIW, I had difficulties with multiple and/or read-only keyrings until --primary-keyring was introduced, which has been a great improvement. > These bug reports are sometimes mixing two different issues: The > debian-keyring and r/o keyrings for other purposes. > The other issue is that of multiple keyrings. Over the years we tried > several approaches to get it right but none of them worked reliable. > The problem is the usual one of keeping two databases in sync. > Aggravated by the requirement to keep some of them read-only but still > allowing to update them somehow. Approaches like preferring the > writable one over the read-only one work in theory but will lead to > administrative headaches. We will never be sure which keyblock is > actually used. (I had a similar problem today with VPATH builds where It is a pain to manually/administratively ensure no key is used from or kept in multiple keyrings, but that is generally what I have done. Given that any GPG process should only be using one trustdb.gpg at a time, I think it is acceptable to merge (in memory) all key material found in multiple keyrings, recalculate trust/trustdb.gpg "stuff," and proceed as though only one keyring held all the key material. When it is necessary to update a key on disk, the --primary-keyring or first available writable keyring wins. (Non-exportable data must remain in the file(s) in which it was found. New non-exportable data must only be written to --primary-keyring.) Speeding up finding one or more copies of all desired keys in one or more keyrings is a separate issue (addressed below). > What I plan with GnuPG 2.1 is to rework the keyring situation by > replacing keyrings it with a new format (keybox). This new format > allows to keep meta data and also will boost key access times. This > will make it possible to flag keys as read-only or allow updates only I think metadata is excellent, but GPG will always run into files holding key material that are themselves marked read-only, no-change, append-only, etc. at the OS level. Marking all keys in a keybox file internally as read-only will be accompanied in a belt-and- suspenders approach by also marking the file unchangeable at the OS level by users who are sufficiently paranoid. > with a new options set. I am actually working on 2.1. However, > before we implement such extravagant feature it will be wetter to > collect real world use cases. We should do this on gnupg-devel at . > > One such use case might be to automatically import certain keys into > the keybox for future use. This is basically the idea of reading the > writable keyring first and only then the read-only ring > (write-on-demand). The solution I have in mind is to import such > read-only keys using the established --auth-key-locate feature. Rather than introducing a new format (keybox) for actual key material or requiring that separate indices be kept for each keyring (.gpg and .gpgidx?), why not add the needed metadata to trustdb.gpg or some other single, suitable (and always-writable) file/database? When the metadata and actual file sizes and file mtimes match for all specified keyrings, and the combinations of offset, size/length, fingerprint, and overall hash match the key(s) found in each file for all keys being actively used, no further scanning of the specified key files or updating of the centralized metadata need be done. (When a file holding key material has changed in any detectable way (depending on one's threat model), rescan the entire file and update the central metadata store for that file. (Add a command-line flag to rescan one or all specified keyrings or to delete and rebuild all metadata if the file size + file mtime method is not enough for the sufficiently paranoid.)) -- Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it? jharris at widomaker.com _|_ web: http://keyserver.kjsl.com/~jharris/ Got photons? (TM), (C) 2004 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 313 bytes Desc: not available URL: From ml at mareichelt.de Sun Dec 6 22:00:40 2009 From: ml at mareichelt.de (markus reichelt) Date: Sun, 6 Dec 2009 22:00:40 +0100 Subject: Read-only keyring and the keybox In-Reply-To: <874oo6u73m.wl%wk@gnupg.org> References: <874oo6u73m.wl%wk@gnupg.org> Message-ID: <20091206210040.GD20989@tatooine.rebelbase.local> * Werner Koch wrote: > Complaints about multiple keyrings are an old topic but one we > eventually need to solve. While you are at it, would it be possible to also address the issue of using multiple smartcards? -- left blank, right bald -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From yhuelf at gmail.com Sun Dec 6 23:16:04 2009 From: yhuelf at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBZaHVlbA==?=) Date: Sun, 6 Dec 2009 23:16:04 +0100 Subject: new contributor? Message-ID: Hello, I recently graduate from Grenoble university (France), where I attended a M Sc in Mathematics and Cryptology. I would like to contribute to GNU PG project, and one of my former teacher told me you may need help for the ECDSA test. If it is the case, or if you need help somewhere else, please let me know. I will do my best to be useful and to not get (too much) in the way. BR, Fr?d?ric Yhuel PS I've tried to subscribe to gcrypt-devel mailing list, but it seems that the sever doesn't accept gmail addresses. From wk at gnupg.org Mon Dec 7 10:54:23 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Dec 2009 10:54:23 +0100 Subject: Read-only keyring and the keybox In-Reply-To: <20091206210040.GD20989@tatooine.rebelbase.local> References: <874oo6u73m.wl%wk@gnupg.org> <20091206210040.GD20989@tatooine.rebelbase.local> Message-ID: <87tyw3rtww.wl%wk@gnupg.org> On Sun, 6 Dec 2009 22:00:40 +0100, markus reichelt wrote: > While you are at it, would it be possible to also address the issue > of using multiple smartcards? What do you mean by that? Support for several readers? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sergi at calcurco.cat Tue Dec 8 11:48:34 2009 From: sergi at calcurco.cat (=?ISO-8859-1?Q?Sergi_Blanch_i_Torn=E9?=) Date: Tue, 8 Dec 2009 11:48:34 +0100 Subject: new contributor? In-Reply-To: References: Message-ID: <80e2a3c40912080248x70b9d213hbf6ca62656bc3b4d@mail.gmail.com> Hi Fr?d?ric, I thing this thread is better to have it in the gcrypt list. Can I ask you for some help in the elliptic curve encryption? The implementation of the future standart [1] is giving me some implementations headaches. Also the mathematical primitives over the finite fields can be optimized because in elliptic curves we use a shorter field, but we call them many more times. About how to manage your contribution, I am not the good one to answer you. As far as I know, you there are some types of agreements that can help in how will be your contribution. Finally, only say good luck and book some time to develop! /Sergi. [1] http://tools.ietf.org/html/draft-jivsov-openpgp-ecc-03 2009/12/6 Fr?d?ric Yhuel : > Hello, > > I recently graduate from Grenoble university (France), where I > attended a M Sc in Mathematics and Cryptology. I would like to > contribute to GNU PG project, and one of my former teacher told me you > may need help for the ECDSA test. If it is the case, or if you need > help somewhere else, please let me know. I will do my best to be > useful and to not get (too much) in the way. > > BR, > Fr?d?ric Yhuel > > PS I've tried to subscribe to gcrypt-devel mailing list, but it seems > that the sever doesn't accept gmail addresses. > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From Wyllys.Ingersoll at Sun.COM Tue Dec 8 20:12:10 2009 From: Wyllys.Ingersoll at Sun.COM (Wyllys Ingersoll) Date: Tue, 08 Dec 2009 14:12:10 -0500 Subject: gpgconf --list-dirs correct? Message-ID: <4B1EA50A.4010004@sun.com> The gpgconf --list-dirs command tacks on "gnupg" to the end of the preconfigured libdir and datadir pathnames, is this correct? For example: $ gpgconf --list-dirs sysconfdir:/usr/etc/gnupg bindir:/usr/bin libexecdir:/usr/libexec libdir:/usr/lib/gnupg ^^^^^^ datadir:/usr/share/gnupg ^^^^^^ localedir:/usr/share/locale dirmngr-socket:/var/run/dirmngr/socket ... -Wyllys Ingersoll From ml at mareichelt.de Tue Dec 8 23:24:06 2009 From: ml at mareichelt.de (markus reichelt) Date: Tue, 8 Dec 2009 23:24:06 +0100 Subject: Read-only keyring and the keybox In-Reply-To: <87tyw3rtww.wl%wk@gnupg.org> References: <874oo6u73m.wl%wk@gnupg.org> <20091206210040.GD20989@tatooine.rebelbase.local> <87tyw3rtww.wl%wk@gnupg.org> Message-ID: <20091208222406.GA5030@tatooine.rebelbase.local> * Werner Koch wrote: > On Sun, 6 Dec 2009 22:00:40 +0100, markus reichelt wrote: > > While you are at it, would it be possible to also address the > > issue of using multiple smartcards? > > What do you mean by that? Support for several readers? That would be nice too. But I think it's more important to be able to use multiple smartcards per user - with the same reader. F.e. http://wiki.fsfe.org/Card_howtos/Card_with_subkeys_using_backups states under "Known problems" that "[...] GPG will look for the first key in the keyring to decrypt things." What a hassle to set up a smartcard subsequently. It would be nice to have some option like "--cardkey fingerprint" to pass to gnupg in order to achieve that. I realize that a new format like keybox is not really necessary to accomplish that, but while you are brainstorming a major pillar of gnupg it's worth mentioning, in my book. Maybe it's even as simple as adapting gnupg's check for secret keys present in the (primary) keyring to just look for a cardreader with inserted card. Don't know, I haven't dived into the depths of the source code. Oh, why I'm advocating to use the fingerprint instead of the short keyid above: I've come across a case where fetching a key via the usual gpg --recv-keys 0xdeadbeef method yielded 2 matching keys (if you must know, check for 0x76B8337A on subkeys.pgp.net). Needless to say that the wrong key was used in operation (that could have been attributed just as well to my setup) but people expect to get a single key, not each key matching the shortid format. So, to make a rather verbose story short: Please adapt documentation accordingly. -- left blank, right bald -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From wk at gnupg.org Wed Dec 9 11:33:39 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Dec 2009 11:33:39 +0100 Subject: gpgconf --list-dirs correct? In-Reply-To: <4B1EA50A.4010004@sun.com> References: <4B1EA50A.4010004@sun.com> Message-ID: <87zl5sqvwc.fsf@vigenere.g10code.de> On Tue, 08 Dec 2009 14:12:10 -0500, Wyllys Ingersoll wrote: > The gpgconf --list-dirs command tacks on "gnupg" to the end of > the preconfigured libdir and datadir pathnames, is this correct? Yes. These are the gnupg specific directories. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 9 11:32:05 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Dec 2009 11:32:05 +0100 Subject: Read-only keyring and the keybox In-Reply-To: <20091208222406.GA5030@tatooine.rebelbase.local> References: <874oo6u73m.wl%wk@gnupg.org> <20091206210040.GD20989@tatooine.rebelbase.local> <87tyw3rtww.wl%wk@gnupg.org> <20091208222406.GA5030@tatooine.rebelbase.local> Message-ID: <871vj4saje.fsf@vigenere.g10code.de> > F.e. http://wiki.fsfe.org/Card_howtos/Card_with_subkeys_using_backups > states under "Known problems" that "[...] GPG will look for the first > key in the keyring to decrypt things." What a hassle to set up a > smartcard subsequently. That is simply not true. An OpenPGP message describes the key to be used for decrytion by including the long key id in the message. This keyid is then used to lookup the key. If it happens to be on a smartcard, the smartcard is used. The problems you may have is with messages also including keys with wildcard keyids (--throw-keyids). In that case there is no well defined order of keys to try. See this comment in g10/mainproc.c: /* FIXME: Store this all in a list and process it later so that we can prioritize what key to use. This gives a better user experience if wildcard keyids are used. */ It has nothing to do with the smartcards. > Oh, why I'm advocating to use the fingerprint instead of the short > keyid above: I've come across a case where fetching a key via the > usual gpg --recv-keys 0xdeadbeef method yielded 2 matching keys (if > you must know, check for 0x76B8337A on subkeys.pgp.net). Of course there are duplicated keyids out in th ewild; use the long keyid in your conf file or - as you say - the fingerprint. > Needless to say that the wrong key was used in operation (that could > have been attributed just as well to my setup) but people expect to > get a single key, not each key matching the shortid format. So, to > make a rather verbose story short: Please adapt documentation > accordingly. I don't understand this. Key selection is matter of the mailer and not of GPG. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From Wyllys.Ingersoll at Sun.COM Wed Dec 9 16:29:29 2009 From: Wyllys.Ingersoll at Sun.COM (Wyllys Ingersoll) Date: Wed, 09 Dec 2009 10:29:29 -0500 Subject: gpgconf --list-dirs correct? In-Reply-To: <87zl5sqvwc.fsf@vigenere.g10code.de> References: <4B1EA50A.4010004@sun.com> <87zl5sqvwc.fsf@vigenere.g10code.de> Message-ID: <4B1FC259.6060201@sun.com> Werner Koch wrote: > On Tue, 08 Dec 2009 14:12:10 -0500, Wyllys Ingersoll wrote: > >> The gpgconf --list-dirs command tacks on "gnupg" to the end of >> the preconfigured libdir and datadir pathnames, is this correct? > > Yes. These are the gnupg specific directories. > > > Salam-Shalom, > > Werner > Why is "libdir" reporting /usr/lib/gnupg ? There is no such directory. I'm just confused because when I ran the "configure" script to build the package, I specify "--libdir=/usr/lib". Who is the consumer or the "--list-dirs" output? Thanks, -Wyllys From wk at gnupg.org Wed Dec 9 18:04:45 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Dec 2009 18:04:45 +0100 Subject: gpgconf --list-dirs correct? In-Reply-To: <4B1FC259.6060201@sun.com> References: <4B1EA50A.4010004@sun.com> <87zl5sqvwc.fsf@vigenere.g10code.de> <4B1FC259.6060201@sun.com> Message-ID: <87pr6oqdsi.fsf@vigenere.g10code.de> > Why is "libdir" reporting /usr/lib/gnupg ? There is no such directory. $ ls /usr/local/lib/gnupg gpg-protect-tool pcsc-wrapper However, this depends on your system. > Who is the consumer or the "--list-dirs" output? It is basically internal to GnuPG. It is an interface to internal functions. Don't care about it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Dec 11 17:48:02 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 11 Dec 2009 17:48:02 +0100 Subject: [Announce] Libgcrypt 1.4.5 released Message-ID: <87bpi5qwxp.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.4.5. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.4.5: * Fixed minor memory leak in DSA key generation. * No more switching to FIPS mode if /proc/version is not readable. * Fixed a sigill during Padlock detection on old CPUs. * Fixed a hang on some W2000 machines. * Boosted SHA-512 performance by 30% on ia32 boxes and gcc 4.3; SHA-256 went up by 25%. Source code is hosted at the GnuPG FTP server and its mirrors as listed at . On the primary server the source file and its digital signature is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.5.tar.bz2 (1121k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.5.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.5.tar.gz (1386k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.5.tar.gz.sig Alternativley you may upgrade version 1.4.4 using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.4-1.4.5.diff.bz2 (93k) The SHA-1 checksums are: ef7ecbd3a03a7978094366bcd1257b3654608d28 libgcrypt-1.4.5.tar.bz2 8d83a60ca55f2ea40b5d5bc99463905b7a1dcb56 libgcrypt-1.4.5.tar.gz 5307e361da5232cd771c300adddc69e57f0e366d libgcrypt-1.4.4-1.4.5.diff.bz2 For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. Note that this version is from the stable branch; the current development version is available at . Improving Libgcrypt is costly, but you can help! We are looking for organizations that find Libgcrypt useful and wish to contribute back. You can contribute by reporting bugs, improve the software [2], order extensions or support or more general by donating money to the Free Software movement (e.g. ). Commercial support contracts for Libgcrypt are available [3], and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company, is currently funding Libgcrypt development. We are always looking for interesting development projects. Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] See . [2] Note that copyright assignments to the FSF are required. [3] See the service directory at . -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Mon Dec 14 20:20:18 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 Dec 2009 20:20:18 +0100 Subject: Change s2k count? In-Reply-To: References: Message-ID: <87y6l5pdl9.fsf@vigenere.g10code.de> Hi! I just implemented the dynamic S2K count for gpg-agent protected keys; i.e. for gpgsm. Similar to gpg we used used 65536 here. The changes are in the 2.0 branch and in the trunk. The plan for gpg is to move the secret keys to the gpg-agent key storage and thus they will automatically take advantage of the new feature. You may test it using this command: $ ./gpg-protect-tool --s2k-calibration -vv gpg-protect-tool: S2K calibration: 65536 -> 0ms gpg-protect-tool: S2K calibration: 131072 -> 0ms gpg-protect-tool: S2K calibration: 262144 -> 0ms gpg-protect-tool: S2K calibration: 524288 -> 10ms gpg-protect-tool: S2K calibration: 1048576 -> 20ms gpg-protect-tool: S2K calibration: 2097152 -> 50ms gpg-protect-tool: S2K calibration: 4194304 -> 90ms gpg-protect-tool: S2K calibration: 8388608 -> 170ms gpg-protect-tool: S2K calibration: 4933632 iterations for 90ms Note that this iteration count may not be mapped to the OpenPGP 1 byte value. The future secret-key export command requires to enter the passphrase anyway (we use a slightly different protection scheme) and thus we can re-protect it for export. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sms at antinode.info Mon Dec 14 21:33:01 2009 From: sms at antinode.info (Steven M. Schweda) Date: Mon, 14 Dec 2009 14:33:01 -0600 (CST) Subject: GnuPG 1.4.10 v. VMS Message-ID: <09121414330116_20207B64@antinode.info> A VMS edition of GnuPG 1.4.10 should be available near: http://antinode.org/dec/sw/gnupg.html It's not tested any better than ever, but some simple things seem to work, and complaints are always welcome. As usual, VMS-related changes are described in the release notes: http://antinode.org/ftp/gnupg/gnupg-1_4_10a_vms/vms_notes.txt As always, if anyone wants to incorporate any of these changes into the main stream, I'd be happy to answer any related questions. (Or if you'd like a list of the DEC/Compaq/HP C compiler's residual complaints...) ------------------------------------------------------------------------ Steven M. Schweda sms at antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 From wk at gnupg.org Tue Dec 15 10:32:40 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 15 Dec 2009 10:32:40 +0100 Subject: GnuPG 1.4.10 v. VMS In-Reply-To: <09121414330116_20207B64@antinode.info> References: <09121414330116_20207B64@antinode.info> Message-ID: <87ws0opop3.fsf@vigenere.g10code.de> Hi, It seems to be .info and not .org: On Mon, 14 Dec 2009 14:33:01 -0600 (CST), Steven M Schweda wrote: > http://antinode.org/dec/sw/gnupg.html http://antinode.info/dec/sw/gnupg.html > http://antinode.org/ftp/gnupg/gnupg-1_4_10a_vms/vms_notes.txt http://antinode.info/ftp/gnupg/gnupg-1_4_10a_vms/vms_notes.txt > the main stream, I'd be happy to answer any related questions. (Or if > you'd like a list of the DEC/Compaq/HP C compiler's residual > complaints...) I'll check out the comments. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sms at antinode.info Tue Dec 15 11:13:59 2009 From: sms at antinode.info (Steven M. Schweda) Date: Tue, 15 Dec 2009 04:13:59 -0600 (CST) Subject: GnuPG 1.4.10 v. VMS Message-ID: <09121504135987_20204E27@antinode.info> From: Werner Koch > It seems to be .info and not .org: Oops. Old habits die hard. SMS. From wk at gnupg.org Mon Dec 21 18:58:19 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Dec 2009 18:58:19 +0100 Subject: [Announce] GnuPG 2.0.14 released Message-ID: <87my1cqkec.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.14. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data, create digital signatures, help authenticating using Secure Shell and to provide a framework for public key cryptography. It includes an advanced key management facility and is compliant with the OpenPGP and S/MIME standards. GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.10) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. GnuPG is distributed under the terms of the GNU General Public License (GPL version 3). GnuPG-2 works best on GNU/Linux or *BSD systems. What's New =========== * The default for --include-cert is now to include all certificates in the chain except for the root certificate. * Numerical values may now be used as an alternative to the debug-level keywords. * The GPGSM --audit-log feature is now more complete. * GPG now supports DNS lookups for SRV, PKA and CERT on W32. * New GPGSM option --ignore-cert-extension. * New and changed passphrases are now created with an iteration count requiring about 100ms of CPU work. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.14 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the FTP server and its mirrors you should find the following files in the gnupg/ directory: gnupg-2.0.14.tar.bz2 (3889k) gnupg-2.0.14.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.13-2.0.14.diff.bz2 (42k) A patch file to upgrade a 2.0.13 GnuPG source tree. This patch does not include updates of the language files. Note, that we don't distribute gzip compressed tarballs for GnuPG-2. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-2.0.14.tar.bz2 you would use this command: gpg --verify gnupg-2.0.14.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a keyserver like gpg --recv-key 1CE0C630 The distribution key 1CE0C630 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-2.0.14.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.14.tar.bz2 and check that the output matches the first line from the following list: cc5e4637f37f5bc82b00c73fc094ddadb7401821 gnupg-2.0.14.tar.bz2 cad88a7f3653479df41ddb7956b9f8a0ff6f2185 gnupg-2.0.13-2.0.14.diff.bz2 Internationalization ==================== GnuPG comes with support for 27 languages. Due to a lot of new and changed strings many translations are not entirely complete. Jedi, Maxim Britov, Jaime Su?rez and Nilg?n Belma Bug?ner have been kind enough to go over their translations and thus the Chinese, German, Russian, Spanish, and Turkish translations are pretty much complete. Documentation ============= We are currently working on an installation guide to explain in more detail how to configure the new features. As of now the chapters on gpg-agent and gpgsm include brief information on how to set up the whole thing. Please watch the GnuPG website for updates of the documentation. In the meantime you may search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. KDE's KMail is the most prominent user of GnuPG-2. In fact it has been developed along with the KMail folks. Mutt users might want to use the configure option "--enable-gpgme" and "set use_crypt_gpgme" in ~/.muttrc to make use of GnuPG-2 to enable S/MIME in addition to a reworked OpenPGP support. The manual is also available online in HTML format at http://www.gnupg.org/documentation/manuals/gnupg/ and in Portable Document Format at http://www.gnupg.org/documentation/manuals/gnupg.pdf . Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, order extensions or support or more general by donating money to the Free Software movement (e.g. http://www.fsfeurope.org/help/donate.en.html). Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. The GnuPG service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP Digital Signature URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From fhimpe at telenet.be Fri Dec 25 23:34:48 2009 From: fhimpe at telenet.be (Frederik Himpe) Date: Fri, 25 Dec 2009 23:34:48 +0100 Subject: test suite fails when run in chroot Message-ID: <1261780488.8337.4.camel@Anastacia> When I build gnupg2 2.0.14 on Mandriva Cooker, everything builds fine and the test suite succeeds. However, when running the same in a clean build chroot, the test suite fails: FAIL: genkey1024.test FAIL: conventional.test 3DES FAIL: conventional-mdc.test It seems that the $srcdir environment variable, as used by these tests, is not set: sh -x ./genkey1024.test + . /defs.inc ./genkey1024.test: line 11: /defs.inc: No such file or directory Any idea how it's possible that this variable is not set? -- Frederik Himpe From stefanxe at gmx.net Tue Dec 29 00:19:47 2009 From: stefanxe at gmx.net (Stefan Xenon) Date: Tue, 29 Dec 2009 00:19:47 +0100 Subject: problems with scute Message-ID: <4B393D13.3050608@gmx.net> Hi! I installed GPG4Win which includes a Scute module for Firefox. Unfortunately it does not recognize my OpenPGP Card out of the box. According to the Scute documentation there is some preparation required: http://www.scute.org/scute.html/Certificate-Preparation.html#Certificate-Preparation . But the required script gpgsm-gencert.sh is not included in GPG4win and would not run on Windows because it is a Linux shell script. Is the described preparation still required and if yes, how to do this on Windows? Also I did a quick search on Linux (Debian, Ubuntu) and it seems that there is no package available. Is this true so that I would need to use the source package on Linux? Thanks for your help! Stefan From stefanxe at gmx.net Tue Dec 29 00:27:57 2009 From: stefanxe at gmx.net (Stefan Xenon) Date: Tue, 29 Dec 2009 00:27:57 +0100 Subject: OpenPGP card v1 does not support digest algorithm SHA256 Message-ID: <4B393EFD.5090209@gmx.net> Hi! With GnuPG 1.4.10 I tried to generate a new key on an OpenPGP Card v1 which results in the following error message: gpg: generating new key gpg: please wait while key is being generated ... gpg: key generation completed (24 seconds) gpg: card does not support digest algorithm SHA256 gpg: signing failed: invalid argument gpg: make_keysig_packet failed: invalid argument Key generation failed: invalid argument Maybe GnuPG wants to use SHA256 but the card v1 doesn't support it? Regards Stefan From dshaw at jabberwocky.com Tue Dec 29 01:42:13 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 28 Dec 2009 19:42:13 -0500 Subject: OpenPGP card v1 does not support digest algorithm SHA256 In-Reply-To: <4B393EFD.5090209@gmx.net> References: <4B393EFD.5090209@gmx.net> Message-ID: On Dec 28, 2009, at 6:27 PM, Stefan Xenon wrote: > Hi! > With GnuPG 1.4.10 I tried to generate a new key on an OpenPGP Card v1 > which results in the following error message: > > gpg: generating new key > gpg: please wait while key is being generated ... > gpg: key generation completed (24 seconds) > gpg: card does not support digest algorithm SHA256 > gpg: signing failed: invalid argument > gpg: make_keysig_packet failed: invalid argument > Key generation failed: invalid argument > > Maybe GnuPG wants to use SHA256 but the card v1 doesn't support it? The v1 card only supports SHA-1 and RIPEMD/160. You don't give your full command, but I presume you have something like "cert-digest-algo sha256" in your gpg.conf or on the command line. That isn't doable with a v1 card. David From stefanxe at gmx.net Tue Dec 29 10:09:13 2009 From: stefanxe at gmx.net (Stefan Xenon) Date: Tue, 29 Dec 2009 10:09:13 +0100 Subject: OpenPGP card v1 does not support digest algorithm SHA256 In-Reply-To: References: <4B393EFD.5090209@gmx.net> Message-ID: <4B39C739.9080800@gmx.net> > You don't give your full command, but I presume you have something like > "cert-digest-algo sha256" in your gpg.conf or on the command line. That > isn't doable with a v1 card. I started generating new keys as usual: gpg2 --card-edit / admin / generate and went through the menu with the default values. Also I did not modify my gpg.conf manually. I assume gpg2 uses SHA256 by default but should have an exception for version 1 cards because they don't support the algorithm. From stefanxe at gmx.net Tue Dec 29 10:11:02 2009 From: stefanxe at gmx.net (Stefan Xenon) Date: Tue, 29 Dec 2009 10:11:02 +0100 Subject: socket problem with gpg-connect-agent In-Reply-To: <87ab0juzgr.fsf@vigenere.g10code.de> References: <35780835.6856351253867593937.JavaMail.root@zimbra7-e1.priv.proxad.net> <87ab0juzgr.fsf@vigenere.g10code.de> Message-ID: <4B39C7A6.7030101@gmx.net> Hi! When using gpg-connect-agent on Ubuntu Linux the following error appears: can't connect to `/home/me/.gnupg/S.gpg-agent': No such file or directory gpg-connect-agent: can't connect to the agent: IPC "connect" Aufruf fehlgeschlagen I found out that the script gpg-agent-start.sh proposed at http://www.linuxquestions.org/questions/linux-security-4/gpg-gpg-agent-cant-connect-to-root.gnupgs.gpg-agent-611843/ solves the problem for me. But I am wondering why gpg-connect-agent does not work out of the box? Is the package maintainer responsible or what is the reason? Regards Stefan From dshaw at jabberwocky.com Tue Dec 29 23:28:06 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 29 Dec 2009 17:28:06 -0500 Subject: OpenPGP card v1 does not support digest algorithm SHA256 In-Reply-To: <4B39C739.9080800@gmx.net> References: <4B393EFD.5090209@gmx.net> <4B39C739.9080800@gmx.net> Message-ID: <4113256C-7FE9-40B6-9BD0-C33BC468ABFA@jabberwocky.com> On Dec 29, 2009, at 4:09 AM, Stefan Xenon wrote: >> You don't give your full command, but I presume you have something like >> "cert-digest-algo sha256" in your gpg.conf or on the command line. That >> isn't doable with a v1 card. > > I started generating new keys as usual: gpg2 --card-edit / admin / > generate and went through the menu with the default values. Also I did > not modify my gpg.conf manually. > > I assume gpg2 uses SHA256 by default but should have an exception for > version 1 cards because they don't support the algorithm. No. gpg1 and gpg2 both use SHA1 by default. The only way you can get SHA256 as a cert digest is if you either use DSA2 (which the cards don't use, as they are RSA only), or if you specifically configure for it. I'd double check your gpg.conf. Also note that in your original email, you indicated you were using gpg 1.4.10. David From marcus.brinkmann at ruhr-uni-bochum.de Wed Dec 30 23:50:07 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 30 Dec 2009 23:50:07 +0100 Subject: problems with scute In-Reply-To: <4B393D13.3050608@gmx.net> References: <4B393D13.3050608@gmx.net> Message-ID: <4B3BD91F.3080307@ruhr-uni-bochum.de> Stefan Xenon wrote: > Hi! > I installed GPG4Win which includes a Scute module for Firefox. > Unfortunately it does not recognize my OpenPGP Card out of the box. > According to the Scute documentation there is some preparation required: > http://www.scute.org/scute.html/Certificate-Preparation.html#Certificate-Preparation > . But the required script gpgsm-gencert.sh is not included in GPG4win > and would not run on Windows because it is a Linux shell script. That scute is included is an unofficial feature at this point. > Is the described preparation still required and if yes, how to do this > on Windows? Try "gpgsm --gen-key" which has the same functionality as the script. > Also I did a quick search on Linux (Debian, Ubuntu) and it seems that > there is no package available. Is this true so that I would need to use > the source package on Linux? Yes. Thanks, Marcus From stefanxe at gmx.net Thu Dec 31 20:29:28 2009 From: stefanxe at gmx.net (Stefan Xenon) Date: Thu, 31 Dec 2009 20:29:28 +0100 Subject: key generation failed on card Message-ID: <4B3CFB98.4030909@gmx.net> I compiled GnuPG 2.0.14 on Ubuntu 9.10 (using libgcrypt 1.4.4). When generating a key on an OpenPGP card v2 it fails right after entering "generate" and tells me "IPC Schreibfehler" (IPC write error). Any help is really appreciated! Stefan