From kristo at no-log.org Tue Jul 1 00:40:42 2008 From: kristo at no-log.org (Kristo) Date: Tue, 01 Jul 2008 00:40:42 +0200 Subject: sending interactive passwords In-Reply-To: <87prpzbdpk.fsf@wheatstone.g10code.de> References: <4867DF70.9060607@san.rr.com> <48681EAE.5030208@san.rr.com> <48683D60.4010604@san.rr.com> <87prpzbdpk.fsf@wheatstone.g10code.de> Message-ID: <486960EA.9060801@no-log.org> Hi, I'm not sure I'm talking about exactly the same thing, but I'm using GnuPG 1.4.7 on window$ and gpg-agent does not work, nor pinentry. I'd like to use them so I can have different passphrases for different keys and remember them. I saw that 1.4.9 binary is available but I don't see its release notes on the site. Is the gpg-agent + pinentry issue solved in the 1.4.9 version ? And, can I install the 1.4.9 without uninstalling the 1.4.7 ? Thanks a lot Chris Werner Koch a ecrit le 30/06/2008 09:10 : > On Mon, 30 Jun 2008 03:56, adamm at san.rr.com said: > > >> I just discovered --command-fd. It's pretty poorly documented, but it >> seems to do the trick. Excellent! Sorry for the "unnecessary" posts, >> but I searched the archives and didn't find a solution. >> > > Or use gpg-agent - it does that all automagically for you. > > > Shalom-Salam, > > Werner > > From wk at gnupg.org Tue Jul 1 08:28:52 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 01 Jul 2008 08:28:52 +0200 Subject: sending interactive passwords In-Reply-To: <486960EA.9060801@no-log.org> (kristo@no-log.org's message of "Tue, 01 Jul 2008 00:40:42 +0200") References: <4867DF70.9060607@san.rr.com> <48681EAE.5030208@san.rr.com> <48683D60.4010604@san.rr.com> <87prpzbdpk.fsf@wheatstone.g10code.de> <486960EA.9060801@no-log.org> Message-ID: <877ic69kyj.fsf@wheatstone.g10code.de> On Tue, 1 Jul 2008 00:40, kristo at no-log.org said: > I'm not sure I'm talking about exactly the same thing, but I'm using > GnuPG 1.4.7 on window$ and gpg-agent does not work, nor pinentry. It will not work. Use GnuPG-2 instead (2.0.9 or later); it is available as a Beta version from the www.gpg4win.org download page. gpg2 is even installed as gpg with that installer. > Is the gpg-agent + pinentry issue solved in the 1.4.9 version ? There is no need to use 1.4.9 and gpg-agent. > And, can I install the 1.4.9 without uninstalling the 1.4.7 ? In theory yes, but it does not make any sense. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From rjh at sixdemonbag.org Tue Jul 1 09:30:41 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 01 Jul 2008 02:30:41 -0500 Subject: sending interactive passwords In-Reply-To: <877ic69kyj.fsf@wheatstone.g10code.de> References: <4867DF70.9060607@san.rr.com> <48681EAE.5030208@san.rr.com> <48683D60.4010604@san.rr.com> <87prpzbdpk.fsf@wheatstone.g10code.de> <486960EA.9060801@no-log.org> <877ic69kyj.fsf@wheatstone.g10code.de> Message-ID: <4869DD21.5080809@sixdemonbag.org> Werner Koch wrote: > It will not work. Use GnuPG-2 instead (2.0.9 or later); it is available > as a Beta version from the www.gpg4win.org download page. Werner, it was just a couple of months ago you were saying GnuPG 2.x was in a release state for Windows. Am I misremembering? Or is this just a beta of 2.0.9, and 2.0.8 is still considered the stable version? From wk at gnupg.org Tue Jul 1 12:24:10 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 01 Jul 2008 12:24:10 +0200 Subject: sending interactive passwords In-Reply-To: <4869DD21.5080809@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 01 Jul 2008 02:30:41 -0500") References: <4867DF70.9060607@san.rr.com> <48681EAE.5030208@san.rr.com> <48683D60.4010604@san.rr.com> <87prpzbdpk.fsf@wheatstone.g10code.de> <486960EA.9060801@no-log.org> <877ic69kyj.fsf@wheatstone.g10code.de> <4869DD21.5080809@sixdemonbag.org> Message-ID: <87k5g59a2d.fsf@wheatstone.g10code.de> On Tue, 1 Jul 2008 09:30, rjh at sixdemonbag.org said: > Werner, it was just a couple of months ago you were saying GnuPG 2.x was > in a release state for Windows. Am I misremembering? Or is this just > a beta of 2.0.9, and 2.0.8 is still considered the stable version? Right. GnuPG 2.0.9 is pretty stable on Windows. There is one last change which will go into 2.0.10: The equivalent of /etc/gnupg as changed on Windows from the installation directory to %CSIDL_COMMON_APPDATA%/GNU/etc/gnupg. That change is already available in 2.0.10 snapshot as included in the mentioned gpg4win beta. The new feature in 2.0.10 will be: * New keyserver helper gpg2keys_kdns as generic DNS CERT lookup. Run with --help for a short description. Requires the ADNS library. * New mechanisms "local" and "nodefault" for --auto-key-locate [gpg]. Fixed a few problems with this option. * [W32] Initialized the socket subsystem for all keyserver helpers. * [W32] The sysconf directory has been moved from a subdirectory of the installation directory to %CSIDL_COMMON_APPDATA%/GNU/etc/gnupg. * New gpg2 command --locate-keys. * New gpg2 options --with-sig-list and --with-sig-check. * Made gpgsm's --output option work with --export-secret-key-p12. * gpg-connect-agent accepts commands given as command line arguments. * The gpg2 option --fixed-list-mode is now implicitly used and obsolete. * New control statement %ask-passphrase for the unattended key generation of gpg2. * gpgsm now uses AES by default. FWIW: We also found and fixed a race condition in GPGME when using gpgme. Not all file descriptors were closed when executing gpg or gpgsm; under certain circumstances this could lead to hanging processes. Easy to fix under Unix (fork(2) rocks!) - hard to get by on Windows: Marcus had to write a wrapper and to rewrite the invocation of gpg/gpgsm. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From daniel.leidert.spam at gmx.net Tue Jul 1 22:30:36 2008 From: daniel.leidert.spam at gmx.net (Daniel Leidert) Date: Tue, 01 Jul 2008 22:30:36 +0200 Subject: Gnupg (1.4.9) Errors in german translation In-Reply-To: <87bq1sd0r8.fsf@wheatstone.g10code.de> References: <48556180.8080706@hammernoch.net> <20080616173131.83260@gmx.net> <4856ADD0.3080601@hammernoch.net> <87bq1sd0r8.fsf@wheatstone.g10code.de> Message-ID: <1214944236.3676.5.camel@localhost> Am Montag, den 23.06.2008, 10:16 +0200 schrieb Werner Koch: > On Mon, 16 Jun 2008 20:15, ludwig at hammernoch.net said: > > > I corrected de.po. from 1.4.9 and created the patch against > > STABLE-BRANCH-1-4, so it was mostly the inverted patch from issue916. > > Commited to 4791. Attached is another minor typo fix for the German translation. Regards, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg.diff Type: text/x-patch Size: 419 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg_1_4.diff Type: text/x-patch Size: 419 bytes Desc: not available URL: From daniel.leidert.spam at gmx.net Tue Jul 1 23:10:42 2008 From: daniel.leidert.spam at gmx.net (Daniel Leidert) Date: Tue, 01 Jul 2008 23:10:42 +0200 Subject: Gnupg (1.4.9) Errors in german translation In-Reply-To: <1214944236.3676.5.camel@localhost> References: <48556180.8080706@hammernoch.net> <20080616173131.83260@gmx.net> <4856ADD0.3080601@hammernoch.net> <87bq1sd0r8.fsf@wheatstone.g10code.de> <1214944236.3676.5.camel@localhost> Message-ID: <1214946642.3676.9.camel@localhost> Am Dienstag, den 01.07.2008, 22:30 +0200 schrieb Daniel Leidert: > Am Montag, den 23.06.2008, 10:16 +0200 schrieb Werner Koch: > > On Mon, 16 Jun 2008 20:15, ludwig at hammernoch.net said: > > > > > I corrected de.po. from 1.4.9 and created the patch against > > > STABLE-BRANCH-1-4, so it was mostly the inverted patch from issue916. > > > > Commited to 4791. > > Attached is another minor typo fix for the German translation. I found more. Attached patches fix them. Regards, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg.diff Type: text/x-patch Size: 5575 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg_1_4.diff Type: text/x-patch Size: 6312 bytes Desc: not available URL: From adam at adammil.net Wed Jul 2 01:12:15 2008 From: adam at adammil.net (Adam M.) Date: Tue, 01 Jul 2008 16:12:15 -0700 Subject: BUG: gpg 1.4.9 opens --attribute-file in text mode Message-ID: <486AB9CF.10207@adammil.net> On the official Windows build of GPG 1.4.9 available from www.gnupg.org, GPG opens the --attribute-file in text mode, causing all LF characters to be converted to CR LF. Since the attribute data is binary, this corrupts it. This also seems to happen with --attribute-fd, at least if the file descriptor is 2. I looked in the source, and the --attribute-file is opened with gpg.c:open_info_file(), which doesn't specify O_BINARY if for_write is true (which it is in this case). The --attribute-fd is opened with iobuf.c:iobuf_translate_file_handle(), which also doesn't specify O_BINARY. I would add a 'binary' (or 'text') parameter to these two functions and then add the O_BINARY or O_TEXT flags appropriately. -- Adam M. From verbal at gmail.com Wed Jul 2 08:12:33 2008 From: verbal at gmail.com (verbal) Date: Tue, 1 Jul 2008 23:12:33 -0700 Subject: question about setting options with gpgme Message-ID: <800AA7B7-CA82-42D4-9B7C-9247BAE889D9@gmail.com> i am trying to set options with gpgme, especially --cipher-algo and -- compress-algo. can someone tell me what the API to do this is? i am trying to use gpgme to do something like this: gpg --symmetric --cipher-algo AES256 --compress-algo BZIP2 thanks for the help, verbal From wk at gnupg.org Wed Jul 2 12:34:35 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Jul 2008 12:34:35 +0200 Subject: question about setting options with gpgme In-Reply-To: <800AA7B7-CA82-42D4-9B7C-9247BAE889D9@gmail.com> (verbal@gmail.com's message of "Tue, 1 Jul 2008 23:12:33 -0700") References: <800AA7B7-CA82-42D4-9B7C-9247BAE889D9@gmail.com> Message-ID: <873ams1sn8.fsf@wheatstone.g10code.de> On Wed, 2 Jul 2008 08:12, verbal at gmail.com said: > i am trying to use gpgme to do something like this: > > gpg --symmetric --cipher-algo AES256 --compress-algo BZIP2 There is no way to select the algorithm individually per message; you need to change the configuration file. Gpgme allow to manage several configuration files by changing the home directory of GnuPG per context. To change the global options (gpg.conf), you may use the new gpgme interface for managing the configuration files. They are not yet documented, so you need to look at tests/gpg/t-gogconf.c or at the GPA configuration dialog: http://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/src/confdialog.c?root=gpa&view=markup Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From adam at adammil.net Wed Jul 2 23:36:45 2008 From: adam at adammil.net (Adam M.) Date: Wed, 02 Jul 2008 14:36:45 -0700 Subject: more information desired in --edit-key list output Message-ID: <486BF4ED.6080509@adammil.net> The --with-colons --edit-key list output: (something like this) pub:u:1024:1:265CC806C45BF178:1214983729:0::u: fpr:::::::::C4B7E17BBFFDD6792E8CAEEA265CC806C45BF178: uid:u::::::::John! :::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1,mdc,no-ks-modify:1,ps: uid:u::::::::John! :::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1,mdc,no-ks-modify:2,: uat:u::::::::1 7332:::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1,mdc,no-ks-modify:3,: uat:u::::::::1 7332:::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1,mdc,no-ks-modify:4,: doesn't provide enough information to positively correlate the uid and uat records from --list-keys with the ones displayed in --edit-key. In the --list-keys output, the user IDs and attributes can be easily distinguished. They all have different creation times, and the user attributes have different hash values too. But in the --edit-key menu, the user IDs and user attributes look identical, so there's no way to really tell which record I'm editing. This would be greatly helped if two additional pieces of information were displayed in the --edit-key output: the creation date (field 6) and the hash of the UID/UAT contents (field 8). I'm guessing it wouldn't be too hard to output them since the code is already written for --list-keys. What do you think? -- Adam From dshaw at jabberwocky.com Wed Jul 2 23:53:58 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 2 Jul 2008 17:53:58 -0400 Subject: more information desired in --edit-key list output In-Reply-To: <486BF4ED.6080509@adammil.net> References: <486BF4ED.6080509@adammil.net> Message-ID: <20080702215357.GA15573@jabberwocky.com> On Wed, Jul 02, 2008 at 02:36:45PM -0700, Adam M. wrote: > The --with-colons --edit-key list output: > > (something like this) > > pub:u:1024:1:265CC806C45BF178:1214983729:0::u: > fpr:::::::::C4B7E17BBFFDD6792E8CAEEA265CC806C45BF178: > uid:u::::::::John! :::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 > Z1,mdc,no-ks-modify:1,ps: > uid:u::::::::John! :::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 > Z1,mdc,no-ks-modify:2,: > uat:u::::::::1 7332:::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1,mdc,no-ks-modify:3,: > uat:u::::::::1 7332:::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1,mdc,no-ks-modify:4,: > > doesn't provide enough information to positively correlate the uid and > uat records from --list-keys with the ones displayed in --edit-key. > > In the --list-keys output, the user IDs and attributes can be easily > distinguished. They all have different creation times, and the user > attributes have different hash values too. But in the --edit-key menu, > the user IDs and user attributes look identical, so there's no way to > really tell which record I'm editing. You don't need to do the correlation yourself: when selecting the uid you want to operate on in the --edit-key menu, send "uid HASH" (using the hash from --list-keys) instead of "uid NUMBER" to select the exact uid or uat you are interested in. David From bernhard at intevation.de Thu Jul 3 20:12:32 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 3 Jul 2008 20:12:32 +0200 Subject: gpgme: how to interpret signature.status / documentation problem Message-ID: <200807032012.38302.bernhard@intevation.de> info gpgme-1.1.6 tells me `gpgme_error_t status' This is the status of the signature. In particular, the following status codes are of interest: `GPG_ERR_NO_ERROR' This status indicates that the signature is valid. For the combined result this status means that all signatures are valid. `GPG_ERR_SIG_EXPIRED' [..] What I cannot find the constants defined in gpgme. The documentation seems outdate. How to I interpret the status values? (I would want a string representation as well, if possible.) :) E.g. what do the following values indicate signature 1 : summary: 0x800 (this is GPGME_SIGSUM_SYS_ERROR) status: 0x7000001 Thanks, 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: 197 bytes Desc: not available URL: From bernhard at intevation.de Thu Jul 3 20:13:21 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 3 Jul 2008 20:13:21 +0200 Subject: question about setting options with gpgme In-Reply-To: <873ams1sn8.fsf@wheatstone.g10code.de> References: <800AA7B7-CA82-42D4-9B7C-9247BAE889D9@gmail.com> <873ams1sn8.fsf@wheatstone.g10code.de> Message-ID: <200807032013.24191.bernhard@intevation.de> On Wednesday 02 July 2008 12:34, Werner Koch wrote: > On Wed, ?2 Jul 2008 08:12, verbal at gmail.com said: > > i am trying to use gpgme to do something like this: > > > > gpg --symmetric --cipher-algo AES256 --compress-algo BZIP2 > > There is no way to select the algorithm individually per message; you > need to change the configuration file. ?Gpgme allow to manage several > configuration files by changing the home directory of GnuPG per context. I've probably missed it: Is there a possibility to do symmetric crypto operations over gpgme? 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: smime.p7s Type: application/pkcs7-signature Size: 1603 bytes Desc: not available URL: From adam at adammil.net Fri Jul 4 00:49:06 2008 From: adam at adammil.net (Adam M.) Date: Thu, 03 Jul 2008 15:49:06 -0700 Subject: BUG?: gpg 1.4.9 uses incorrect OpenPGP key type when creating subkeys via --edit-key Message-ID: <486D5762.3080102@adammil.net> When creating RSA Encrypt-Only (type 2) or RSA Sign-Only (type 3) subkeys using the --edit-key "addkey" command, gpg 1.4.9 seems to create the subkey as type 1 (RSA [Encrypt or Sign]). Either that, or --list-keys --with-colons reports the type as 1 even when it's actually 2 or 3. Since GPG forces the user to choose RSA Encrypt-Only or RSA Sign-Only, you'd expect it to actually use that in the created subkey. Is there some reason for this? Backwards compatibility maybe? Or is it just a bug? -- Adam From dshaw at jabberwocky.com Fri Jul 4 01:23:13 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 3 Jul 2008 19:23:13 -0400 Subject: BUG?: gpg 1.4.9 uses incorrect OpenPGP key type when creating subkeys via --edit-key In-Reply-To: <486D5762.3080102@adammil.net> References: <486D5762.3080102@adammil.net> Message-ID: <46666A4A-E47A-4DB2-98C5-F68427AC00C9@jabberwocky.com> On Jul 3, 2008, at 6:49 PM, Adam M. wrote: > When creating RSA Encrypt-Only (type 2) or RSA Sign-Only (type 3) > subkeys using the --edit-key "addkey" command, gpg 1.4.9 seems to > create the subkey as type 1 (RSA [Encrypt or Sign]). > > Either that, or --list-keys --with-colons reports the type as 1 even > when it's actually 2 or 3. > > Since GPG forces the user to choose RSA Encrypt-Only or RSA Sign- > Only, you'd expect it to actually use that in the created subkey. Not a bug. RFC-4880: 13.5. RSA There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only keys. These types are deprecated. The "key flags" subpacket in a signature is a much better way to express the same idea, and generalizes it to all algorithms. An implementation SHOULD NOT create such a key, but MAY interpret it. We use key flags to indicate the intended use of the key. David From wk at gnupg.org Fri Jul 4 10:28:28 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Jul 2008 10:28:28 +0200 Subject: question about setting options with gpgme In-Reply-To: <200807032013.24191.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 3 Jul 2008 20:13:21 +0200") References: <800AA7B7-CA82-42D4-9B7C-9247BAE889D9@gmail.com> <873ams1sn8.fsf@wheatstone.g10code.de> <200807032013.24191.bernhard@intevation.de> Message-ID: <87vdzm2gur.fsf@wheatstone.g10code.de> On Thu, 3 Jul 2008 20:13, bernhard at intevation.de said: > I've probably missed it: Is there a possibility to do symmetric crypto > operations over gpgme? Pass NULL instead of an array of recipients to the encrypt function: If @var{recp} is @code{NULL}, symmetric rather than public key encryption is performed. Symmetrically encrypted cipher text can be deciphered with @code{gpgme_op_decrypt}. Note that in this case the crypto backend needs to retrieve a passphrase from the user. Symmetric encryption is currently only supported for the OpenPGP crypto backend. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Fri Jul 4 10:33:47 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Jul 2008 10:33:47 +0200 Subject: gpgme: how to interpret signature.status / documentation problem In-Reply-To: <200807032012.38302.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 3 Jul 2008 20:12:32 +0200") References: <200807032012.38302.bernhard@intevation.de> Message-ID: <87r6aa2glw.fsf@wheatstone.g10code.de> On Thu, 3 Jul 2008 20:12, bernhard at intevation.de said: > What I cannot find the constants defined in gpgme. > The documentation seems outdate. How to I interpret the status values? > (I would want a string representation as well, if possible.) :) They are provided by libgpg-error. Use gpg_err_code (err) == GPG_ERR_FOO to compare an error code and printf ("%s (in module %s)\n", gpg_strerror (err), gpg_strsource (err)); to print it. The constants are in gpg-error.h and you may use the utility gpg-error to decode and print an error code on the command line: $ gpg-error 0x2a 42 = (0, 42) = (GPG_ERR_SOURCE_UNKNOWN, GPG_ERR_TRIBUTE_TO_D_A) = (Unspecified source, Tribute to D. A.) Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Fri Jul 4 10:35:16 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Jul 2008 10:35:16 +0200 Subject: BUG: gpg 1.4.9 opens --attribute-file in text mode In-Reply-To: <486AB9CF.10207@adammil.net> (Adam M.'s message of "Tue, 01 Jul 2008 16:12:15 -0700") References: <486AB9CF.10207@adammil.net> Message-ID: <87k5g22gjf.fsf@wheatstone.g10code.de> On Wed, 2 Jul 2008 01:12, adam at adammil.net said: > On the official Windows build of GPG 1.4.9 available from > www.gnupg.org, GPG opens the --attribute-file in text mode, causing > all LF characters to be converted to CR LF. Since the attribute data > is binary, this corrupts it. I'll fix that. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bernhard at intevation.de Fri Jul 4 10:45:52 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 4 Jul 2008 10:45:52 +0200 Subject: question about setting options with gpgme In-Reply-To: <87vdzm2gur.fsf@wheatstone.g10code.de> References: <800AA7B7-CA82-42D4-9B7C-9247BAE889D9@gmail.com> <200807032013.24191.bernhard@intevation.de> <87vdzm2gur.fsf@wheatstone.g10code.de> Message-ID: <200807041045.55338.bernhard@intevation.de> On Friday 04 July 2008 10:28, Werner Koch wrote: > On Thu, ?3 Jul 2008 20:13, bernhard at intevation.de said: > > I've probably missed it: Is there a possibility to do symmetric crypto > > operations over gpgme? > > Pass NULL instead of an array of recipients to the encrypt function: > > ? If @var{recp} is @code{NULL}, symmetric rather than public key > ? encryption is performed. ?Symmetrically encrypted cipher text can be > ? deciphered with @code{gpgme_op_decrypt}. ?Note that in this case the > ? crypto backend needs to retrieve a passphrase from the user. > ? Symmetric encryption is currently only supported for the OpenPGP > ? crypto backend. Arg, I've tried to look for it in the documentation and must have fumbled (it was very hot in the office yesterday). :( I had looked into the section 3 Protocols and Engines as well as 4 Algorithms, therefore I would suggest to add a small hint towards symmetric to section 4. Thanks! -- 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: 197 bytes Desc: not available URL: From bernhard at intevation.de Fri Jul 4 10:48:09 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 4 Jul 2008 10:48:09 +0200 Subject: gpgme: how to interpret signature.status / documentation problem In-Reply-To: <87r6aa2glw.fsf@wheatstone.g10code.de> References: <200807032012.38302.bernhard@intevation.de> <87r6aa2glw.fsf@wheatstone.g10code.de> Message-ID: <200807041048.12505.bernhard@intevation.de> On Friday 04 July 2008 10:33, Werner Koch wrote: > On Thu, ?3 Jul 2008 20:12, bernhard at intevation.de said: > > What I cannot find the constants defined in gpgme. > > The documentation seems outdate. How to I interpret the status values? > > (I would want a string representation as well, if possible.) :) > > They are provided by libgpg-error. ?Use > > ? ? ?gpg_err_code (err) == GPG_ERR_FOO > > to compare an error code and > > ? ? ?printf ("%s (in module %s)\n", gpg_strerror (err), gpg_strsource > (err)); > > to print it. ?The constants are in gpg-error.h and you may use the > utility gpg-error to decode and print an error code on the command line: > > $ gpg-error ?0x2a > 42 = (0, 42) = (GPG_ERR_SOURCE_UNKNOWN, GPG_ERR_TRIBUTE_TO_D_A) = > (Unspecified source, Tribute to D. A.) Ah, cool. So do you agree that the documentation is outdated at this? I saw the libgpg-error as one possibility, but I've missed the hint that I should interpret the status value of the signature in this sense, especially because there are other constants listed in the .texi file. Best, 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: smime.p7s Type: application/pkcs7-signature Size: 1603 bytes Desc: not available URL: From wk at gnupg.org Fri Jul 4 12:28:40 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Jul 2008 12:28:40 +0200 Subject: question about setting options with gpgme In-Reply-To: <200807041045.55338.bernhard@intevation.de> (Bernhard Reiter's message of "Fri, 4 Jul 2008 10:45:52 +0200") References: <800AA7B7-CA82-42D4-9B7C-9247BAE889D9@gmail.com> <200807032013.24191.bernhard@intevation.de> <87vdzm2gur.fsf@wheatstone.g10code.de> <200807041045.55338.bernhard@intevation.de> Message-ID: <873amq2baf.fsf@wheatstone.g10code.de> On Fri, 4 Jul 2008 10:45, bernhard at intevation.de said: > I had looked into the section 3 Protocols and Engines as well as 4 Algorithms, > therefore I would suggest to add a small hint towards symmetric to section 4. Done in my working copy. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Fri Jul 4 12:31:50 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Jul 2008 12:31:50 +0200 Subject: gpgme: how to interpret signature.status / documentation problem In-Reply-To: <200807041048.12505.bernhard@intevation.de> (Bernhard Reiter's message of "Fri, 4 Jul 2008 10:48:09 +0200") References: <200807032012.38302.bernhard@intevation.de> <87r6aa2glw.fsf@wheatstone.g10code.de> <200807041048.12505.bernhard@intevation.de> Message-ID: <87y74i0wkp.fsf@wheatstone.g10code.de> On Fri, 4 Jul 2008 10:48, bernhard at intevation.de said: > On Friday 04 July 2008 10:33, Werner Koch wrote: >> On Thu, ?3 Jul 2008 20:12, bernhard at intevation.de said: >> > What I cannot find the constants defined in gpgme. >> > The documentation seems outdate. How to I interpret the status values? >> > (I would want a string representation as well, if possible.) :) >> >> They are provided by libgpg-error. ?Use >> >> ? ? ?gpg_err_code (err) == GPG_ERR_FOO >> >> to compare an error code and >> >> ? ? ?printf ("%s (in module %s)\n", gpg_strerror (err), gpg_strsource >> (err)); >> >> to print it. ?The constants are in gpg-error.h and you may use the >> utility gpg-error to decode and print an error code on the command line: >> >> $ gpg-error ?0x2a >> 42 = (0, 42) = (GPG_ERR_SOURCE_UNKNOWN, GPG_ERR_TRIBUTE_TO_D_A) = >> (Unspecified source, Tribute to D. A.) > > Ah, cool. So do you agree that the documentation is outdated at > this? I saw the libgpg-error as one possibility, but I've missed the hint No, I think the manual is pretty clear about this: @section Error Codes @cindex error codes, list of The library @code{libgpg-error} defines many error values. Most of them are not used by @code{GPGME} directly, but might be returned by @acronym{GPGME} because it received them from the crypto engine. The below list only includes such error codes that have a specific meaning in @code{GPGME}, or which are so common that you should know about them. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bernhard at intevation.de Fri Jul 4 13:14:12 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 4 Jul 2008 13:14:12 +0200 Subject: gpgme: how to interpret signature.status / documentation problem In-Reply-To: <87y74i0wkp.fsf@wheatstone.g10code.de> References: <200807032012.38302.bernhard@intevation.de> <200807041048.12505.bernhard@intevation.de> <87y74i0wkp.fsf@wheatstone.g10code.de> Message-ID: <200807041314.15210.bernhard@intevation.de> On Friday 04 July 2008 12:31, Werner Koch wrote: > So do you agree that the documentation is outdated at > > > this? I saw the libgpg-error as one possibility, but I've missed the hint > > No, I think the manual is pretty clear about this: > > ? @section Error Codes > ? @cindex error codes, list of > ? > ? The library @code{libgpg-error} defines many error values. ?Most of > ? them are not used by @code{GPGME} directly, but might be returned by > ? @acronym{GPGME} because it received them from the crypto engine. ?The > ? below list only includes such error codes that have a specific meaning > ? in @code{GPGME}, or which are so common that you should know about > ? them. I disagree, this section above is only instructive if I already know that I am dealing with an error code. That is exactely what I did not clearly understood from section Verify: -- Data type: gpgme_signature_t This is a pointer to a structure used to store a part of the result of a `gpgme_op_verify' operation. The structure contains the following members: [..] `gpgme_error_t status' This is the status of the signature. In particular, the following status codes are of interest: `GPG_ERR_NO_ERROR' This status indicates that the signature is valid. For the combined result this status means that all signatures are valid. `GPG_ERR_SIG_EXPIRED' This status indicate Apart from the type "gpgme_error_t" it only talks about "status", not about an error, which is not wrong, but having a short hint there would allow readers to make the connection more easily. Maybe something similiar like `gpgme_error_t status' This is the status of the signature, provided by gpgme's @xref{Error Handling}. In particular, the following status codes are of interest: Thanks for considering, 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: smime.p7s Type: application/pkcs7-signature Size: 1603 bytes Desc: not available URL: From adam at adammil.net Sat Jul 5 00:21:42 2008 From: adam at adammil.net (Adam M.) Date: Fri, 04 Jul 2008 15:21:42 -0700 Subject: BUG?: gpg 1.4.9 --edit-key writes preferences to TTY rather than STDOUT Message-ID: <486EA276.5010205@adammil.net> Most information in the edit menu is written to STDOUT, allowing it to be received by programs that are scripting GPG, but the keyedit.c:show_names() and show_prefs() functions use tty_printf(), which prevents the output from being captured, since the TTY can't be redirected (at least on Windows). Consequently, it seems rather difficult to do something like retrieve a user ID's preferred keyserver. I think only information that merely provides guidance to an interactive user should be shown on the TTY, while all information that might be usefully captured should be on STDOUT. -- Adam From adam at adammil.net Sun Jul 6 02:36:43 2008 From: adam at adammil.net (Adam Milazzo) Date: Sat, 05 Jul 2008 17:36:43 -0700 Subject: BUG: gpg 1.4.9 --search-keys --with-colons writes strange line endings (at least on Windows) Message-ID: <4870139B.9020906@adammil.net> GPG 1.4.9 --search-keys --with-colons on Windows writes CR CR LF at the end of each line on STDOUT. This causes weird things to happen with most text readers: like a CR character at the end of each line, an LF character at the beginning of each line, and/or blank lines after each line. These extra characters and/or blank lines mess up code to parse the --search-keys output. From nico-gnupg-dev-0 at schottelius.org Sun Jul 6 15:08:05 2008 From: nico-gnupg-dev-0 at schottelius.org (nico-gnupg-dev-0 at schottelius.org) Date: Sun, 6 Jul 2008 15:08:05 +0200 Subject: The nightly gpgme newbie question: en- and decrypt problems In-Reply-To: <87ej6jx49d.fsf@wheatstone.g10code.de> References: <20080626210027.GA10453@denkbrett.schottelius.org> <87ej6jx49d.fsf@wheatstone.g10code.de> Message-ID: <20080706130805.GH27298@denkbrett.schottelius.org> Yeah, found the problem! When I use gpgme_data_new_from_file() and import the result from my previous encryption, it works: http://unix.schottelius.org/cgi-bin/gitweb.cgi?p=EOF/ceofhack;a=commitdiff;h=37e753ff82232c2381e72e8c591eb1f4ce9bd962;hp=389a52942c1bb15183f747dc2902b641fe92b865 So after I removed the gpgme_data_write() call, it works: http://unix.schottelius.org/cgi-bin/gitweb.cgi?p=EOF/ceofhack;a=commitdiff;h=25ae82d55031ca9fc8c8fa3c98af5c135ef5c7b3;hp=37e753ff82232c2381e72e8c591eb1f4ce9bd962 Now I've only to find out, what I made wrong in that call... Nico ps: GPGME_DEBUG is nice, but not so helpful. Werner Koch [Thu, Jun 26, 2008 at 11:42:06PM +0200]: > On Thu, 26 Jun 2008 23:00, nico-gnupg-dev-0 at schottelius.org said: > > > But shouldn't it contain data, if gpgme_op_encrypt() before was successful? > > Run your test program like > > GPGME_DEBUG=9:/tmp/foo.log ./test > > and check the pretty verbose log to see the data excahnged between gpgme > and gpg. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. > -- Think about Free and Open Source Software (FOSS). http://nico.schottelius.org/documentations/foss/the-term-foss/ PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From adam at adammil.net Sun Jul 6 23:51:32 2008 From: adam at adammil.net (Adam Milazzo) Date: Sun, 06 Jul 2008 14:51:32 -0700 Subject: BUG?: gpg doesn't flush attribute stream after writing an attribute Message-ID: <48713E64.9000000@adammil.net> It would be very nice if GPG flushed the attribute stream after writing an attribute, so that the number of bytes reported in the ATTRIBUTE status message can be read reliably in response to that message. As it is, the read often blocks because the data is sitting in GPG's output buffer. I think all this would require is an fflush() call at the end of keylist.c:dump_attribs(). From nico-gnupg-dev-0 at schottelius.org Mon Jul 7 00:10:10 2008 From: nico-gnupg-dev-0 at schottelius.org (Nico Schottelius) Date: Mon, 7 Jul 2008 00:10:10 +0200 Subject: gpgme_data_new_from_mem works, gpgme_data_write doesn't Message-ID: <20080706221010.GC699@denkbrett.schottelius.org> Hello! I am testing around with gpgme and it seems I am doing something wrong with gpgme_data_write(): If I do gerr = gpgme_data_new(&g_test); if(gerr != GPG_ERR_NO_ERROR) return 20; i = strlen(b_encrypt); /* THIS WORKS */ gerr = gpgme_data_new_from_mem(&g_encrypt_send, b_encrypt, i, 1); if(gerr != GPG_ERR_NO_ERROR) return 24; /* decrypt: from gpgme_data_new_from_mem() */ gerr = gpgme_op_decrypt(g_context, g_encrypt_send, g_plain_recv); if(gerr != GPG_ERR_NO_ERROR) { printf("gerr=%d\n",gerr); return 19; } it works. If I do gerr = gpgme_data_new(&g_test); if(gerr != GPG_ERR_NO_ERROR) return 20; i = strlen(b_encrypt); printf("strlen(%s) = %d\n",b_encrypt,i); /* THIS DOES NOT WORK */ tmp = gpgme_data_write(g_test, b_encrypt, i); printf("gpgmedatawrite: %d\n", tmp); /* decrypt: from gpgme_data_write() */ gerr = gpgme_op_decrypt(g_context, g_test, g_plain_recv2); if(gerr != GPG_ERR_NO_ERROR) { printf("gerr=%d\n",gerr); return 41; } it does *NOT* work. I created a testfile, containing both cases to show it in commit 86f3d41a53834231eea54da750bd4564c9c13ae0 of ceofhack. Anyone a hint, what I am doing wrong in the latter case? Sincerly Nico PS: http://unix.schottelius.org/cgi-bin/gitweb.cgi?p=EOF/ceofhack;a=summary -- Think about Free and Open Source Software (FOSS). http://nico.schottelius.org/documentations/foss/the-term-foss/ PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From marcus.brinkmann at ruhr-uni-bochum.de Mon Jul 7 22:39:50 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 07 Jul 2008 22:39:50 +0200 Subject: The nightly gpgme newbie question: en- and decrypt problems In-Reply-To: <20080706130805.GH27298@denkbrett.schottelius.org> References: <20080626210027.GA10453@denkbrett.schottelius.org> <87ej6jx49d.fsf@wheatstone.g10code.de> <20080706130805.GH27298@denkbrett.schottelius.org> Message-ID: <48727F16.6000704@ruhr-uni-bochum.de> nico-gnupg-dev-0 at schottelius.org wrote: > Yeah, found the problem! > > When I use gpgme_data_new_from_file() and import the result from > my previous encryption, it works: > I have limited net access right now, but here are two hints that might help you: gpgme data objects have a file pointer that must be rewound to read written data (gpgme_data_seek). To use the seek function make sure you compile with large file support. See the documentation. Thanks, Marcus From bernhard at intevation.de Tue Jul 8 10:11:52 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 8 Jul 2008 10:11:52 +0200 Subject: combination of text-mode signature (by mutt?) and gpg >= 1.4.8 introduces interoperability problem Message-ID: <200807081011.55193.bernhard@intevation.de> Just followed up on an email written with mutt 1.5.18 and signed with gnupg 1.4.9 which I could verify the signature with gpg2, but not with gpg1 from Debian Sarge and Etch which is 1.4.1 and 1.4.6 with patches respectively. My current hypothesis is that the default change introduced in gnupg 1.4.8 regarding --no-rfc2440-text causes the interoperability problems. From what I have gathered, the new setting is --no-rfc2440-text which will not strip trailing spaces and tabs. So verification with at least 1.4.1 - 1.4.7 fails with default settings, if lines with trailing spaces and tabs are left in unquoted by the MTA. As the email came from mutt 1.5.18, I could observe that trailing spaces were left in, in an message/rfc822 part. (Note that quoted-printable or base64 is forbidden in those parts.) Mutt could have stripped the spaces in this case before calculating the hash, but did not and this is hard to decide, because any message/rfc822 part might contain another signature. Conclusions: Emails send with text-mode signatures to Debian Etch users will not be verifiable by default settings in some situations. This is bad of course as Etch is a production system. Possibilities: a) refrain from using text-mode signatures? b) Educate Debian Etch users to set --no-rfc2440-text as default? c) Convince Debian that this is a security problem and have them update their gpg Etch Package d) Educate users to get rid of the gnupg 1 package, and use gnupg2? Hmmm..... -- 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: smime.p7s Type: application/pkcs7-signature Size: 1603 bytes Desc: not available URL: From dshaw at jabberwocky.com Tue Jul 8 15:02:56 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 8 Jul 2008 09:02:56 -0400 Subject: combination of text-mode signature (by mutt?) and gpg >= 1.4.8 introduces interoperability problem In-Reply-To: <200807081011.55193.bernhard@intevation.de> References: <200807081011.55193.bernhard@intevation.de> Message-ID: <78E4916A-6E54-424D-9B90-4E9188C4D27A@jabberwocky.com> On Jul 8, 2008, at 4:11 AM, Bernhard Reiter wrote: > Just followed up on an email written with mutt 1.5.18 > and signed with gnupg 1.4.9 which I could verify the signature > with gpg2, but not with gpg1 from Debian Sarge and Etch > which is 1.4.1 and 1.4.6 with patches respectively. > > My current hypothesis is that the default change > introduced in gnupg 1.4.8 regarding --no-rfc2440-text > causes the interoperability problems. From what I have gathered, > the new setting is --no-rfc2440-text which will not strip > trailing spaces and tabs. > > So verification with at least 1.4.1 - 1.4.7 fails with default > settings, if lines with trailing spaces and tabs are left in > unquoted by the MTA. > As the email came from mutt 1.5.18, I could observe that trailing > spaces were left in, in an message/rfc822 part. > (Note that quoted-printable or base64 is forbidden in those parts.) > Mutt could have stripped the spaces in this case before calculating > the hash, but did not and this is hard to decide, because any > message/rfc822 > part might contain another signature. Can you clarify a bit more what you are seeing? I think if there was a general problem here we would have heard screaming from many sources. Since you're the first person reporting it here, I wonder if there is something more subtle going on. Specifically: * Are you sure the sending MUA is mutt 1.5.18? (The subject line says "by mutt?" which suggests you're not sure). * What is the receiving MUA? (the one which calls GPG to verify the signature). * Was this message sent OpenPGP/MIME or something else? Clearsigned? An old-style armored blob containing the content plus appended signature? There are (alas) many ways to send a signed mail. If you can send me the message in question, that would be ideal. In mutt, do a ":set mbox_type=mbox", save the message to a file, tar the file to ensure that nothing will mess about with line endings in transit, and send me the tarball. If the message is sensitive and should not be seen by others, can you ask the sender to create another message in the same way to send me? David From bernhard at intevation.de Tue Jul 8 16:52:19 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 8 Jul 2008 16:52:19 +0200 Subject: combination of text-mode signature (by mutt?) and gpg >= 1.4.8 introduces interoperability problem In-Reply-To: <78E4916A-6E54-424D-9B90-4E9188C4D27A@jabberwocky.com> References: <200807081011.55193.bernhard@intevation.de> <78E4916A-6E54-424D-9B90-4E9188C4D27A@jabberwocky.com> Message-ID: <200807081652.19863.bernhard@intevation.de> Am Dienstag, 8. Juli 2008 15:02:56 schrieb David Shaw: > On Jul 8, 2008, at 4:11 AM, Bernhard Reiter wrote: > > Just followed up on an email written with mutt 1.5.18 > > and signed with gnupg 1.4.9 which I could verify the signature > > with gpg2, but not with gpg1 from Debian Sarge and Etch > > which is 1.4.1 and 1.4.6 with patches respectively. > > > > My current hypothesis is that the default change > > introduced in gnupg 1.4.8 regarding --no-rfc2440-text > > causes the interoperability problems. From what I have gathered, > > the new setting is --no-rfc2440-text which will not strip > > trailing spaces and tabs. > > > > So verification with at least 1.4.1 - 1.4.7 fails with default > > settings, if lines with trailing spaces and tabs are left in > > unquoted by the MTA. > > As the email came from mutt 1.5.18, I could observe that trailing > > spaces were left in, in an message/rfc822 part. > > (Note that quoted-printable or base64 is forbidden in those parts.) > > Mutt could have stripped the spaces in this case before calculating > > the hash, but did not and this is hard to decide, because any ? > > message/rfc822 > > part might contain another signature. > > Can you clarify a bit more what you are seeing? ?I think if there was ? > a general problem here we would have heard screaming from many ? > sources. ?Since you're the first person reporting it here, I wonder if ? > there is something more subtle going on. > > Specifically: > * Are you sure the sending MUA is mutt 1.5.18? ?(The subject line says ? > "by mutt?" which suggests you're not sure). Yes, I am quite sure as the header has it and I do not think this is manipulated. I've used the question mark to indicate that I do not know how much mutt contributes to the problem. Note that you would need to have an attachment in, that already has trailing spaces to some lines. Maybe it must be a message/rfc822 attachment, I did not verify yet. > * What is the receiving MUA? (the one which calls GPG to verify the ? > signature). I've tried several e.g. mutt and used gpgparsemail as well. Then I've disassembled this is msg and msg.sig and thus are using gpg and gpg2 directly on these files. gpg --verifiy msg.sig fails. gpg --no-rfc2440-text --verify msg.sig works, as does gpg2. (gpg is gpg 1.4.1 or 1.4.6 from Debian Sarge and Etch). > * Was this message sent OpenPGP/MIME or something else? ?Clearsigned? ? > An old-style armored blob containing the content plus appended ? > signature? ?There are (alas) many ways to send a signed mail. OpenPGP/MIME (which is clearsigned for message/rfc822). > If you can send me the message in question, that would be ideal. ?In ? > mutt, do a ":set mbox_type=mbox", save the message to a file, tar the ? > file to ensure that nothing will mess about with line endings in ? > transit, and send me the tarball. ?If the message is sensitive and ? > should not be seen by others, can you ask the sender to create another ? > message in the same way to send me? I'll ask the sender, as the contents is sensitive and contains a forwarded message and another attachment. Best, 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 From bernhard at intevation.de Tue Jul 8 18:53:42 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 8 Jul 2008 18:53:42 +0200 Subject: pyme for debugging gpgme applications, new verifydetails.py Message-ID: <200807081853.47886.bernhard@intevation.de> I have attached a new verifydetails.py to https://sourceforge.net/tracker/index.php?func=detail&aid=2013640&group_id=104883&atid=639601 It helps to debug how applications deal with gpgme result values E.g. here is an example output python examples/verifydetails.py ~/tmp/y.sig ~/tmp/dbgmd-00001.verify gpgme version: 1.1.6 engines: /usr/bin/gpg2 2.0.9 /usr/bin/gpgsm 2.0.9 OpenPGP True CMS True trying to verify signature /home/bernhard/tmp/y.sig for file /home/bernhard/tmp/dbgmd-00001.verify signature 1 : summary: 0x800 status: 0x7000001 timestamp: 1215123456 fingerprint: XXXXXXXXXXXXX uid: XXXXXXXXXXXXXXXXXXXXX You can use "gpg-error" to decipher the "status" value: $ LANG=C gpg-error 0x7000001 117440513 = (7, 1) = (GPG_ERR_SOURCE_GPGME, GPG_ERR_GENERAL) = (GPGME, General error) To me this has been helpful in analysing if gpgme or Kontact/KMail or both contribute to a problematic behaviour that can be observed. It overcomes the obstacle that "gpg2" or "gpgsm" on the command line might behave a bit differently as compared when being called via gpgme, e.g. here are much more return values to consider. Best, 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: smime.p7s Type: application/pkcs7-signature Size: 1603 bytes Desc: not available URL: From dshaw at jabberwocky.com Tue Jul 8 19:26:32 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 8 Jul 2008 13:26:32 -0400 Subject: combination of text-mode signature (by mutt?) and gpg >= 1.4.8 introduces interoperability problem In-Reply-To: <200807081652.19863.bernhard@intevation.de> References: <200807081011.55193.bernhard@intevation.de> <78E4916A-6E54-424D-9B90-4E9188C4D27A@jabberwocky.com> <200807081652.19863.bernhard@intevation.de> Message-ID: <20080708172632.GA86183@jabberwocky.com> On Tue, Jul 08, 2008 at 04:52:19PM +0200, Bernhard Reiter wrote: > Note that you would need to have an attachment in, that already > has trailing spaces to some lines. Maybe it must be a message/rfc822 > attachment, I did not verify yet. This is interesting, as OpenPGP/MIME requires trailing spaces to be quoted. ("any trailing whitespace MUST then be removed from the signed material.") That would imply that mutt isn't generating the OpenPGP/MIME message properly. I suppose that is possible, but it seems odd as Mutt has always been rigorous about following the OpenPGP/MIME spec to the letter. Have you seen this: http://lists.gnupg.org/pipermail/gnupg-users/2005-January/024408.html Can you ask the sender to perform the test suggested on that page? Specifically: An easy way to tell if your particular mail program correctly implements PGP/MIME signing is to set --no-rfc2440-text, and send yourself a signed message that has a number of blank spaces at the end of a line. Then, set --rfc2440-text and attempt to verify the signature. If the signature does not verify correctly, you may wish to contact the developer of your mail program for an update. In this case, of course, have the sender construct the same sort of message as before (message/rfc822 attachment, etc). David From bernhard at intevation.de Wed Jul 9 09:51:04 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 9 Jul 2008 09:51:04 +0200 Subject: combination of text-mode signature (by mutt?) and gpg >= 1.4.8 introduces interoperability problem In-Reply-To: <20080708172632.GA86183@jabberwocky.com> References: <200807081011.55193.bernhard@intevation.de> <200807081652.19863.bernhard@intevation.de> <20080708172632.GA86183@jabberwocky.com> Message-ID: <200807090951.07828.bernhard@intevation.de> Am Dienstag, 8. Juli 2008 19:26:32 schrieb David Shaw: > On Tue, Jul 08, 2008 at 04:52:19PM +0200, Bernhard Reiter wrote: > > Note that you would need to have an attachment in, that already > > has trailing spaces to some lines. Maybe it must be a message/rfc822 > > attachment, I did not verify yet. > > This is interesting, as OpenPGP/MIME requires trailing spaces to be > quoted. ("any trailing whitespace MUST then be removed from the > signed material.") That would imply that mutt isn't generating the > OpenPGP/MIME message properly. I suppose that is possible, but it > seems odd as Mutt has always been rigorous about following the > OpenPGP/MIME spec to the letter. Hmm, thinking more about this, mutt forwarded a message by which already was signed by Gnus, looking at it again I can see that only the header lines of the forwarded message in two cases have one trailing space. Those are X-Spam: and X-Attachments:, so maybe something in the email transport introduces those spaces unnecessarily. After all it might be a mutt problem that it does not strip those trailing spaces. Stripping those spaces would require some more involved algorithm, so maybe issuing a strong warning would be more appropriate. Note that mutt cannot just encode this body part because it is message/rfc822. > Have you seen this: > http://lists.gnupg.org/pipermail/gnupg-users/2005-January/024408.html > > Can you ask the sender to perform the test suggested on that page? > Specifically: > > An easy way to tell if your particular mail program correctly > implements PGP/MIME signing is to set --no-rfc2440-text, and send > yourself a signed message that has a number of blank spaces at the > end of a line. Then, set --rfc2440-text and attempt to verify the > signature. If the signature does not verify correctly, you may > wish to contact the developer of your mail program for an update. > > In this case, of course, have the sender construct the same sort of > message as before (message/rfc822 attachment, etc). This sounds easier then trying to create test message, thanks for the hint. 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: smime.p7s Type: application/pkcs7-signature Size: 1603 bytes Desc: not available URL: From nico-gnupg-dev-0 at schottelius.org Wed Jul 9 14:29:29 2008 From: nico-gnupg-dev-0 at schottelius.org (Nico Schottelius) Date: Wed, 9 Jul 2008 14:29:29 +0200 Subject: The nightly gpgme newbie question: en- and decrypt problems In-Reply-To: <48727F16.6000704@ruhr-uni-bochum.de> References: <20080626210027.GA10453@denkbrett.schottelius.org> <87ej6jx49d.fsf@wheatstone.g10code.de> <20080706130805.GH27298@denkbrett.schottelius.org> <48727F16.6000704@ruhr-uni-bochum.de> Message-ID: <20080709122929.GC23231@denkbrett.schottelius.org> Hello Marcus? Marcus Brinkmann [Mon, Jul 07, 2008 at 10:39:50PM +0200]: > nico-gnupg-dev-0 at schottelius.org wrote: >> Yeah, found the problem! >> >> When I use gpgme_data_new_from_file() and import the result from >> my previous encryption, it works: >> > I have limited net access right now, but here are two hints that might > help you: gpgme data objects have a file pointer that must be rewound to > read written data (gpgme_data_seek). To use the seek function make sure > you compile with large file support. See the documentation. Tried that here: http://unix.schottelius.org/cgi-bin/gitweb.cgi?p=EOF/ceofhack;a=commitdiff;h=bac6504f564f7da0dd8a48e28cd4a55bff88739d;hp=86f3d41a53834231eea54da750bd4564c9c13ae0 but without success. See my other posting, where it narrows down to a function. Nico -- Think about Free and Open Source Software (FOSS). http://nico.schottelius.org/documentations/foss/the-term-foss/ PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From B.Candler at pobox.com Thu Jul 10 13:06:08 2008 From: B.Candler at pobox.com (Brian Candler) Date: Thu, 10 Jul 2008 12:06:08 +0100 Subject: gpg --decrypt strips space (but not CR) from clearsigned text Message-ID: <20080710110608.GA15301@uk.tiscali.com> (gpg version 1.4.6, Ubuntu 8.06) When I generate a clearsigned document, the signature is insensitive to adding extra spaces, tabs or CR (0x0D) to the end of each line. This is all fine and in accordance with RFC 2440. The clearsigned document retains the extra spaces, tabs and CRs exactly as they were in the source document. However, if I pass this clearsigned document to "gpg --decrypt" and redirect stdout to a file, I find that the extra spaces and tabs are stripped, although a trailing CR is retained. To demonstrate: perl -e 'print "Line one\nLine two \nLine three\t\nLine four \t\r\n"' >testfile gpg --clearsign testfile gpg --decrypt testfile.asc >testfile2 $ hexdump -C testfile 00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw| 00000010 6f 20 0a 4c 69 6e 65 20 74 68 72 65 65 09 0a 4c |o .Line three..L| 00000020 69 6e 65 20 66 6f 75 72 20 09 0d 0a |ine four ...| 0000002c $ cat testfile.asc | grep ^Line | hexdump -C 00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw| 00000010 6f 20 0a 4c 69 6e 65 20 74 68 72 65 65 09 0a 4c |o .Line three..L| 00000020 69 6e 65 20 66 6f 75 72 20 09 0d 0a |ine four ...| 0000002c $ hexdump -C testfile2 00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw| 00000010 6f 0a 4c 69 6e 65 20 74 68 72 65 65 0a 4c 69 6e |o.Line three.Lin| 00000020 65 20 66 6f 75 72 0d 0a |e four..| I was hoping to use "gpg --decrypt" as a way to simultaneously verify the signature and to strip off the wrapping and dash-escaping. However I want to retain trailing spaces as they were in the source, and unfortunately that's not happening. Now, as far as I can see this is intentional, in g10/armor.c: /* Now handle the end-of-line canonicalization */ although I don't see a test for this behaviour in checks/clearsig.test or checks/armor.test What strikes me as odd is that gpg retains a CR at the end of the line, but not tabs or spaces. Futhermore, it happens for --decrypt but not for --clearsign. Both these strike me as inconsistent. Apart from disabling dash-escaping entirely(*), or moving to detached signatures, can anyone suggest another way to verify and unwrap the source document whilst keeping it intact? Thanks, Brian Candler. (*) Because this breaks if the source document contains "-----BEGIN PGP SIGNATURE-----". gpg will happily sign it without raising an error, but the signed document is broken. From B.Candler at pobox.com Thu Jul 10 14:56:19 2008 From: B.Candler at pobox.com (Brian Candler) Date: Thu, 10 Jul 2008 13:56:19 +0100 Subject: gpg --decrypt strips space (but not CR) from clearsigned text In-Reply-To: <886529.92896.qm@web56710.mail.re3.yahoo.com> References: <886529.92896.qm@web56710.mail.re3.yahoo.com> Message-ID: <20080710125619.GA19442@uk.tiscali.com> On Thu, Jul 10, 2008 at 04:59:29AM -0700, Tracy D. Bossong wrote: > During encryption use the switches --textmode --no-rfc2440-text > I think that will resolve your issue. I'm clearsigning, not encrypting. But I've tried your suggestion anyway, and it makes no difference: perl -e 'print "Line one\nLine two \nLine three\t\nLine four \t\r\n"' >testfile gpg --clearsign --textmode --no-rfc2440-text testfile gpg --decrypt testfile.asc >testfile2 The results: $ grep ^Line testfile.asc | hexdump -C 00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw| 00000010 6f 20 0a 4c 69 6e 65 20 74 68 72 65 65 09 0a 4c |o .Line three..L| 00000020 69 6e 65 20 66 6f 75 72 20 09 0d 0a |ine four ...| 0000002c $ hexdump -C testfile2 00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw| 00000010 6f 0a 4c 69 6e 65 20 74 68 72 65 65 0a 4c 69 6e |o.Line three.Lin| 00000020 65 20 66 6f 75 72 0d 0a |e four..| 00000028 Regards, Brian. From dshaw at jabberwocky.com Fri Jul 11 02:22:09 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 10 Jul 2008 20:22:09 -0400 Subject: gpg --decrypt strips space (but not CR) from clearsigned text In-Reply-To: <20080710110608.GA15301@uk.tiscali.com> References: <20080710110608.GA15301@uk.tiscali.com> Message-ID: <8B34FE06-173B-48D9-9040-08DEC6C66DA3@jabberwocky.com> On Jul 10, 2008, at 7:06 AM, Brian Candler wrote: > (gpg version 1.4.6, Ubuntu 8.06) > > When I generate a clearsigned document, the signature is insensitive > to > adding extra spaces, tabs or CR (0x0D) to the end of each line. This > is all > fine and in accordance with RFC 2440. > > The clearsigned document retains the extra spaces, tabs and CRs > exactly as > they were in the source document. > > However, if I pass this clearsigned document to "gpg --decrypt" and > redirect > stdout to a file, I find that the extra spaces and tabs are stripped, > although a trailing CR is retained. This is correct, and is as per the standard. Section 7 of RFC-4880: "Note that this framework is not intended to be reversible." Note that the trailing CR is not actually retained. Rather, the end- of-line marker is made to be correct for your platform. Depending on that platform it might be a CR, a LF, or a CRLF. The only way to get out byte-for-byte exactly what you put in is a regular, non-clearsigned, non-textmode, signature. David From B.Candler at pobox.com Fri Jul 11 08:39:58 2008 From: B.Candler at pobox.com (Brian Candler) Date: Fri, 11 Jul 2008 07:39:58 +0100 Subject: gpg --decrypt strips space (but not CR) from clearsigned text In-Reply-To: <8B34FE06-173B-48D9-9040-08DEC6C66DA3@jabberwocky.com> References: <20080710110608.GA15301@uk.tiscali.com> <8B34FE06-173B-48D9-9040-08DEC6C66DA3@jabberwocky.com> Message-ID: <20080711063958.GA6394@uk.tiscali.com> On Thu, Jul 10, 2008 at 08:22:09PM -0400, David Shaw wrote: > This is correct, and is as per the standard. Section 7 of RFC-4880: > "Note that this framework is not intended to be reversible." True - but I'd argue it's still inconsistent that --clearsign doesn't change the cleartext, but --decrypt does. RFC-4880 also says "any trailing whitespace ... is removed when the cleartext signature is generated". gpg --clearsign doesn't modify the text body in this way, although it does do it to the version of text body which goes into the hash calculation of course. > Note that the trailing CR is not actually retained. Rather, the end- > of-line marker is made to be correct for your platform. Depending on > that platform it might be a CR, a LF, or a CRLF. That's not the behaviour I observe. For each incoming line, if it ends with CRLF it is passed through as CRLF; but if it ends with LF only then it is passed through as LF only. Demonstration: perl -e 'print "One\nTwo\r\n"' >testfile gpg --clearsign testfile gpg --decrypt testfile.asc >testfile2 $ hexdump -C testfile 00000000 4f 6e 65 0a 54 77 6f 0d 0a |One.Two..| ^^ ^^^^^^ 00000009 $ hexdump -C testfile2 00000000 4f 6e 65 0a 54 77 6f 0d 0a |One.Two..| ^^ ^^^^^^ 00000009 I've not tried this with any platform other than Unix however, so perhaps you observe different behaviour under Windows etc. Regards, Brian. From dshaw at jabberwocky.com Fri Jul 11 14:21:52 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 11 Jul 2008 08:21:52 -0400 Subject: gpg --decrypt strips space (but not CR) from clearsigned text In-Reply-To: <20080711063958.GA6394@uk.tiscali.com> References: <20080710110608.GA15301@uk.tiscali.com> <8B34FE06-173B-48D9-9040-08DEC6C66DA3@jabberwocky.com> <20080711063958.GA6394@uk.tiscali.com> Message-ID: On Jul 11, 2008, at 2:39 AM, Brian Candler wrote: > On Thu, Jul 10, 2008 at 08:22:09PM -0400, David Shaw wrote: >> This is correct, and is as per the standard. Section 7 of RFC-4880: >> "Note that this framework is not intended to be reversible." > > True - but I'd argue it's still inconsistent that --clearsign > doesn't change > the cleartext, but --decrypt does. Why? --cleartext is an 'encode' operation. --decrypt is a 'decode'. Not reversible is not reversible. It doesn't matter much where that happens. > RFC-4880 also says "any trailing whitespace ... is removed when the > cleartext signature is generated". gpg --clearsign doesn't modify > the text > body in this way, although it does do it to the version of text body > which > goes into the hash calculation of course. Yes. Any trailing whitespace is, in fact, removed when the cleartext signature is generated. The *signature*. The standard says nothing about removing it from the body of the message. Mind you, it would be legal to remove it, just as it would be legal to add more of it (say, for a system with fixed-width transmission). It's even legal (though silly) if GPG arbitrarily added a secret mesage in morse code to each line using space as 'dot' and tab as 'dash'. All that is required is that the signature contains the correct information. >> Note that the trailing CR is not actually retained. Rather, the end- >> of-line marker is made to be correct for your platform. Depending on >> that platform it might be a CR, a LF, or a CRLF. > > That's not the behaviour I observe. For each incoming line, if it > ends with > CRLF it is passed through as CRLF; but if it ends with LF only then > it is > passed through as LF only. Sorry, my mistake. I was thinking of textmode signatures. There is no need to fix clearsigned end-of-line markers since (by definition) they started as a text file on your local platform. David From tracy.bossong at yahoo.com Thu Jul 10 13:59:29 2008 From: tracy.bossong at yahoo.com (Tracy D. Bossong) Date: Thu, 10 Jul 2008 04:59:29 -0700 (PDT) Subject: gpg --decrypt strips space (but not CR) from clearsigned text Message-ID: <886529.92896.qm@web56710.mail.re3.yahoo.com> During encryption use the switches --textmode --no-rfc2440-text I think that will resolve your issue. ----- Original Message ---- From: Brian Candler To: gnupg-devel at gnupg.org Sent: Thursday, July 10, 2008 6:06:08 AM Subject: gpg --decrypt strips space (but not CR) from clearsigned text (gpg version 1.4.6, Ubuntu 8.06) When I generate a clearsigned document, the signature is insensitive to adding extra spaces, tabs or CR (0x0D) to the end of each line. This is all fine and in accordance with RFC 2440. The clearsigned document retains the extra spaces, tabs and CRs exactly as they were in the source document. However, if I pass this clearsigned document to "gpg --decrypt" and redirect stdout to a file, I find that the extra spaces and tabs are stripped, although a trailing CR is retained. To demonstrate: perl -e 'print "Line one\nLine two \nLine three\t\nLine four \t\r\n"' >testfile gpg --clearsign testfile gpg --decrypt testfile.asc >testfile2 $ hexdump -C testfile 00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw| 00000010 6f 20 0a 4c 69 6e 65 20 74 68 72 65 65 09 0a 4c |o .Line three..L| 00000020 69 6e 65 20 66 6f 75 72 20 09 0d 0a |ine four ...| 0000002c $ cat testfile.asc | grep ^Line | hexdump -C 00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw| 00000010 6f 20 0a 4c 69 6e 65 20 74 68 72 65 65 09 0a 4c |o .Line three..L| 00000020 69 6e 65 20 66 6f 75 72 20 09 0d 0a |ine four ...| 0000002c $ hexdump -C testfile2 00000000 4c 69 6e 65 20 6f 6e 65 0a 4c 69 6e 65 20 74 77 |Line one.Line tw| 00000010 6f 0a 4c 69 6e 65 20 74 68 72 65 65 0a 4c 69 6e |o.Line three.Lin| 00000020 65 20 66 6f 75 72 0d 0a |e four..| I was hoping to use "gpg --decrypt" as a way to simultaneously verify the signature and to strip off the wrapping and dash-escaping. However I want to retain trailing spaces as they were in the source, and unfortunately that's not happening. Now, as far as I can see this is intentional, in g10/armor.c: /* Now handle the end-of-line canonicalization */ although I don't see a test for this behaviour in checks/clearsig.test or checks/armor.test What strikes me as odd is that gpg retains a CR at the end of the line, but not tabs or spaces. Futhermore, it happens for --decrypt but not for --clearsign. Both these strike me as inconsistent. Apart from disabling dash-escaping entirely(*), or moving to detached signatures, can anyone suggest another way to verify and unwrap the source document whilst keeping it intact? Thanks, Brian Candler. (*) Because this breaks if the source document contains "-----BEGIN PGP SIGNATURE-----". gpg will happily sign it without raising an error, but the signed document is broken. _______________________________________________ Gnupg-devel mailing list Gnupg-devel at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at adammil.net Sat Jul 12 07:15:01 2008 From: adam at adammil.net (Adam Milazzo) Date: Fri, 11 Jul 2008 22:15:01 -0700 Subject: BUG: gpg 1.4.9 crashes when creating ELG keys with sign and encrypt capability in batch mode Message-ID: <48783DD5.5020109@adammil.net> I think you're not supposed to use ElGamal keys that can sign and encrypt, but GPG shouldn't crash in any case. This crash happens consistently. C:\> gpg --batch --gen-key Key-Type: RSA Key-Usage: sign Subkey-Type: ELG-E Subkey-Usage: encrypt sign Name-Real: Joe Blow ^Z gpg: keysize invalid; using 1024 bits gpg: NOTE: you should run 'diskperf -y' to enable the disk statistics .+++++ ....+++++ gpg: keysize invalid; using 1024 bits .+++++.+++++.++++++++++++++++++++++++++++++.++++++++++..+++++++++++++ +++++++.+++++.+++++..++++++++++++++++++++++++++++++.++++++++++>+++++. +++++++++^^^ gpg: Ohhhh jeeee: no sign() for 16 secmem usage: 2624/3584 bytes in 8/14 blocks of pool 3872/32768 From adam at adammil.net Sat Jul 12 07:49:38 2008 From: adam at adammil.net (Adam Milazzo) Date: Fri, 11 Jul 2008 22:49:38 -0700 Subject: BUG?: gpg 1.4.9 --edit-key writes preferences to TTY rather than STDOUT In-Reply-To: <486EA276.5010205@adammil.net> References: <486EA276.5010205@adammil.net> Message-ID: <487845F2.2090706@adammil.net> This also prevents adding a key with custom capabilities. The list of current key flags is written to the TTY, so you can't know what flags to turn on or off at the keygen.flags prompt. Adam M. wrote: > Most information in the edit menu is written to STDOUT, allowing it to > be received by programs that are scripting GPG, but the > keyedit.c:show_names() and show_prefs() functions use tty_printf(), > which prevents the output from being captured, since the TTY can't be > redirected (at least on Windows). > > Consequently, it seems rather difficult to do something like retrieve a > user ID's preferred keyserver. > > I think only information that merely provides guidance to an interactive > user should be shown on the TTY, while all information that might be > usefully captured should be on STDOUT. > > -- Adam From wk at gnupg.org Mon Jul 14 16:05:28 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 Jul 2008 16:05:28 +0200 Subject: combination of text-mode signature (by mutt?) and gpg >= 1.4.8 introduces interoperability problem In-Reply-To: <200807081011.55193.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 8 Jul 2008 10:11:52 +0200") References: <200807081011.55193.bernhard@intevation.de> Message-ID: <873amco91z.fsf@wheatstone.g10code.de> On Tue, 8 Jul 2008 10:11, bernhard at intevation.de said: > Just followed up on an email written with mutt 1.5.18 Are you using set crypt_use_gpgme in .muttrc? This enables the other crypto backend; it is important to known which one is used (the old one or the non-default gpgme based one). Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bernhard at intevation.de Wed Jul 16 22:56:54 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 16 Jul 2008 22:56:54 +0200 Subject: combination of text-mode signature (by mutt?) and gpg >= 1.4.8 introduces interoperability problem In-Reply-To: <873amco91z.fsf@wheatstone.g10code.de> References: <200807081011.55193.bernhard@intevation.de> <873amco91z.fsf@wheatstone.g10code.de> Message-ID: <200807162256.55028.bernhard@intevation.de> On Monday 14 July 2008 16:05, Werner Koch wrote: > On Tue, ?8 Jul 2008 10:11, bernhard at intevation.de said: > > Just followed up on an email written with mutt 1.5.18 > > Are you using > > ? set crypt_use_gpgme > > in .muttrc? ?This enables the other crypto backend; it is important to > known which one is used (the old one or the non-default gpgme based > one). The email was send by someone else... This person became less available for completely other reasons, so it might take a while until I can follow up on this. Thanks for the hint, it is true I should have asked this directly. Best, 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: 189 bytes Desc: not available URL: From bernhard at intevation.de Wed Jul 16 23:08:41 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 16 Jul 2008 23:08:41 +0200 Subject: Vs Combined Method? E+S from RFC 3156 6.2 In-Reply-To: <87fxsetkba.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200804291414.53915.bernhard@intevation.de> <200805151416.14925.bernhard@intevation.de> <87fxsetkba.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200807162308.45596.bernhard@intevation.de> I am coming back to the discussion, because I do not see the resolution. According to RFC 3156 6.2 it makes sense to always use the combined method for encryption and signature as there is a requirement for all compliant application to support this method. Still I am looking for arguments why this is not a good idea. On Monday 19 May 2008 16:55, Marcus Brinkmann wrote: > At Thu, 15 May 2008 14:16:09 +0200, Bernhard Reiter wrote: > > On Thursday 15 May 2008 13:20, Marcus Brinkmann wrote: > > > At Tue, 29 Apr 2008 14:14:45 +0200, > > > > > > Bernhard Reiter wrote: > > > > Given the enhanced compatibility, why not do combined method whenever > > > > you can, just getting the compatibility advantage? > > > > > > Compatibility with what? > > > > The RFC from August 2001 says "to increase compatibility > > with non-MIME implementations of OpenPGP". > > I was hoping for some specific applications that are in use today. Even if there is a tiny small number even on older machines, this would be no reason to not use the combined method as all the other applications also need to support it. Also this would be an open question what the RFC writers had in mind when they made this statement. Is there a good way to find out about this?= > > Sure, so you are basically saying: The argument from 2001 is obsolete. > > I am not saying that, I am just suggesting that, after evaluation, it > might be such a case, depending on how important compatibility is in > the real world. > > > On the other hand, to ease the implementation, shouldn't we then push > > for the removal of the combined method requirement? > > At least make it mandadory in new implementation to not create > > new combined method emails? > > I think that, if this is such a case, then that would be a sensible > next step. This makes your argument depend on the outcome of the analysis. Given that Werner does not recommend the combined method, he must have a view on the result already. > > > So, the question is, are there significant MUAs that support only > > > combined mode? > > > > As for non-MIME MUAs, I think Outlook is significant. > > (Being one of the developers of Gpg4win, you know that until recently > > it could not do MIME OpenPGP. And that Outlook itself it not fully > > MIME compliant, e.g. it does not display the text part of a > > multipart/signed email, though it MUST according to MIME standards.) > > Oh well, that may be a millstone around our neck for the time being. > > > There will be others out there as well, e.g. on older unix machines > > which did not update software very often. > > Not really what you are looking for, but: Somehow I question the > wisdom of relying on security software on such systems... Security is orthogonal to software modernisation: you might run a very old unix-like system which is fully supported and thus fine security wise, but still only has old software. 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: 189 bytes Desc: not available URL: From p.tucci at gmail.com Thu Jul 17 22:23:44 2008 From: p.tucci at gmail.com (Primiano Tucci) Date: Thu, 17 Jul 2008 22:23:44 +0200 Subject: about the OpenPGP Card Message-ID: <487FAA50.30602@gmail.com> Hi, I'm an Italian o.s. developer. I've some news to share about the OpenPGP card. I wrote a Java driver for the OpenPGP card (details at http://www.primianotucci.com/go/jopenpgpcard) I think this driver has several advantages: -Does not need any PKCS11 driver to be installed (it's build on top of Sun's javax.smartcardio low level apis) -Requires nothing but a Java JRE. -Can allow access to the OpenPGP card virtually everywhere (where a smart card reader is available) The driver comes with a sample OpenPGPCard Editor application (it's like a graphical gpg --card-edit) Going on with coding, I made a concept OpenID OpenPGP Card endpoint... http://dev.primianotucci.com/openid/ It's a (working) php OpenID service that allows to get an unique login identity on the web using the OpenPGP Card An applet (that I wrote using the driver discussed above) manages the login via a Challenge/Response Digital Signature scheme (using the Authentication key on the smartcard)... than the OpenID protocol makes the rest (e.g. I am able to log in my sourceforge account using my OpenPGP card) The service, of course, is less than a beta release, it's just a conceptual demonstration of how the driver could be implemented to do so. I hope someone could be interested in testing the OpenID service Feel free to write me if you have further questions/comments Best Regards Primiano Tucci -- +-----------------------------------------------+ | Primiano Tucci | | http://www.primianotucci.com | | | | RSA pub key (preferred) | | http://www.primianotucci.com/pubkey.rsa.cer | | PGP pub key [0xE8481C1B] | | http://www.primianotucci.com/pubkey.asc | +-----------------------------------------------+ From rdieter at math.unl.edu Fri Jul 18 02:39:59 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 17 Jul 2008 19:39:59 -0500 Subject: gnupg1 still needed? Message-ID: I thought I (or someone) had asked this question in the not-too-distant past, but I couldn't find it anywhere. (sorry if it has). Is gnupg(1) still needed, where gnupg2 is available? It's been proposed to consider dropping gnupg(1) from Fedora 10, to consolidate on gnupg2, so I am looking for any pros/cons to that. -- Rex From dshaw at jabberwocky.com Fri Jul 18 03:50:03 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 17 Jul 2008 21:50:03 -0400 Subject: gnupg1 still needed? In-Reply-To: References: Message-ID: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> On Jul 17, 2008, at 8:39 PM, Rex Dieter wrote: > I thought I (or someone) had asked this question in the not-too- > distant past, but I couldn't find it anywhere. (sorry if it has). > > Is gnupg(1) still needed, where gnupg2 is available? > > It's been proposed to consider dropping gnupg(1) from Fedora 10, to > consolidate on gnupg2, so I am looking for any pros/cons to that. They are two different programs for two different purposes. There is significant overlap (they both do OpenPGP), but they're not direct replacements for each other. gpg (1) has been built into lots of scripts and server-side gadgets. A forced change to gpg (2) is pretty likely to break all of that. David From eric at debian.org Fri Jul 18 05:52:40 2008 From: eric at debian.org (Eric Dorland) Date: Thu, 17 Jul 2008 23:52:40 -0400 Subject: gnupg1 still needed? In-Reply-To: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> Message-ID: <20080718035240.GA30115@gambit> * David Shaw (dshaw at jabberwocky.com) wrote: > On Jul 17, 2008, at 8:39 PM, Rex Dieter wrote: > >> I thought I (or someone) had asked this question in the not-too- >> distant past, but I couldn't find it anywhere. (sorry if it has). >> >> Is gnupg(1) still needed, where gnupg2 is available? >> >> It's been proposed to consider dropping gnupg(1) from Fedora 10, to >> consolidate on gnupg2, so I am looking for any pros/cons to that. > > They are two different programs for two different purposes. There is > significant overlap (they both do OpenPGP), but they're not direct > replacements for each other. > > gpg (1) has been built into lots of scripts and server-side gadgets. A > forced change to gpg (2) is pretty likely to break all of that. Are there substantial differences in the command line options from 1.4 to 2.0? My cursory glance at the manpages it looked pretty similar. -- Eric Dorland ICQ: #61138586, Jabber: hooty at jabber.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From adam at adammil.net Fri Jul 18 09:33:27 2008 From: adam at adammil.net (Adam Milazzo) Date: Fri, 18 Jul 2008 00:33:27 -0700 Subject: gnupg1 still needed? In-Reply-To: References: Message-ID: <48804747.4010009@adammil.net> Well for one thing, gpg2 forces the use of the gpg-agent, which seems to prevent programs that script GPG from providing passwords themselves. Other than that, they seem equivalent to me. Also, gpg2 has crashed many times for me, whereas gpg rarely does. Rex Dieter wrote: > I thought I (or someone) had asked this question in the not-too-distant past, but I couldn't find it anywhere. (sorry if it has). > > Is gnupg(1) still needed, where gnupg2 is available? > > It's been proposed to consider dropping gnupg(1) from Fedora 10, to consolidate on gnupg2, so I am looking for any pros/cons to that. > > -- Rex From wk at gnupg.org Fri Jul 18 09:31:02 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Jul 2008 09:31:02 +0200 Subject: gnupg1 still needed? In-Reply-To: <20080718035240.GA30115@gambit> (Eric Dorland's message of "Thu, 17 Jul 2008 23:52:40 -0400") References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> Message-ID: <87iqv3myx5.fsf@wheatstone.g10code.de> On Fri, 18 Jul 2008 05:52, eric at debian.org said: > Are there substantial differences in the command line options from 1.4 > to 2.0? My cursory glance at the manpages it looked pretty similar. No. The changes are only related to the fact that the gpg-agent is in general required for gpg2. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Fri Jul 18 09:36:35 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Jul 2008 09:36:35 +0200 Subject: gnupg1 still needed? In-Reply-To: (Rex Dieter's message of "Thu, 17 Jul 2008 19:39:59 -0500") References: Message-ID: <87ej5rmynw.fsf@wheatstone.g10code.de> On Fri, 18 Jul 2008 02:39, rdieter at math.unl.edu said: > Is gnupg(1) still needed, where gnupg2 is available? I guess yes. For a desktop only machine gpg2 should be sufficient. In fact the the default installer for Windows (gpg4win) now installs gpg2 unter the name gpg in the PATH. However for an installer you probably want at least gpgv from gnupg-1. It is far less depencencies that gpgv2. You should don't remove gnupg-1 from a distribution; it should be pssible to install it for the use of existsing scripts which assume a standalone gpg (e.g. in chroot environment or with non-standard use of the passphrase.). Compare the case to Bind-8/9 - both are useful. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Fri Jul 18 09:45:21 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Jul 2008 09:45:21 +0200 Subject: about the OpenPGP Card In-Reply-To: <487FAA50.30602@gmail.com> (Primiano Tucci's message of "Thu, 17 Jul 2008 22:23:44 +0200") References: <487FAA50.30602@gmail.com> Message-ID: <87abgfmy9a.fsf@wheatstone.g10code.de> On Thu, 17 Jul 2008 22:23, p.tucci at gmail.com said: > It's a (working) php OpenID service that allows to get an unique login > identity on the web using the OpenPGP Card As a shameless plug let me mention that there is also Scute (www.scute.org). Scute is a pkcs#11 driver on top of gpg-agent. It can also be used to login to a server using the OpenPGP card. Scute requires a running gpg-agent though and has only be tested with Mozilla. Primiano: Are you aware of the draft 2.0 specification for the card? There are a couple of new things in it; for example a new DO to store a certificiate and a way to reset the card to factory defaults: http://g10code.com/docs/openpgp-card-2.0-rc1.pdf . Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Fri Jul 18 10:28:57 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Jul 2008 10:28:57 +0200 Subject: gnupg1 still needed? In-Reply-To: <48804747.4010009@adammil.net> (Adam Milazzo's message of "Fri, 18 Jul 2008 00:33:27 -0700") References: <48804747.4010009@adammil.net> Message-ID: <87od4vlho6.fsf@wheatstone.g10code.de> On Fri, 18 Jul 2008 09:33, adam at adammil.net said: > Also, gpg2 has crashed many times for me, whereas gpg rarely does. Please report these crashes if they still happen with the current version. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From kssingvo at suse.de Fri Jul 18 11:46:58 2008 From: kssingvo at suse.de (Klaus Singvogel) Date: Fri, 18 Jul 2008 11:46:58 +0200 Subject: gnupg1 still needed? In-Reply-To: <87iqv3myx5.fsf@wheatstone.g10code.de> References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de> Message-ID: <20080718094658.GB23370@suse.de> Werner Koch wrote: > On Fri, 18 Jul 2008 05:52, eric at debian.org said: > > > Are there substantial differences in the command line options from 1.4 > > to 2.0? My cursory glance at the manpages it looked pretty similar. > > No. The changes are only related to the fact that the gpg-agent is in > general required for gpg2. Sorry for asking back... But I noticed that gpg1 could support old PGP keys, if module idea is added. On the other side gpg2 it seems that gpg2 is capable to support modules, and therefore lacks of IDEA support. Is there a way to support old rsa/idea keys in gpg2? Regards, Klaus. -- Klaus Singvogel - Maxfeldstr. 5 - 90409 Nuernberg - Germany Phone: +49-911-74053-0 GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) From p.tucci at gmail.com Fri Jul 18 12:18:48 2008 From: p.tucci at gmail.com (Primiano Tucci) Date: Fri, 18 Jul 2008 12:18:48 +0200 Subject: about the OpenPGP Card In-Reply-To: <87abgfmy9a.fsf@wheatstone.g10code.de> References: <487FAA50.30602@gmail.com> <87abgfmy9a.fsf@wheatstone.g10code.de> Message-ID: On Fri, Jul 18, 2008 at 9:45 AM, Werner Koch wrote: > On Thu, 17 Jul 2008 22:23, p.tucci at gmail.com said: > >> It's a (working) php OpenID service that allows to get an unique login >> identity on the web using the OpenPGP Card > > As a shameless plug let me mention that there is also Scute > (www.scute.org). Scute is a pkcs#11 driver on top of gpg-agent. It can > also be used to login to a server using the OpenPGP card. Scute > requires a running gpg-agent though and has only be tested with Mozilla. Scute is a pkcs11 driver, it means that prior to make your card work you need to have downloaded the libary, configured mozilla (and it seems no way for IE) and have a working gpg-agent. My driver, on the other side, does not need anything, just a java insatllation... so if you are on another pc that has a smartcard reader (where probably there isn't any gpg-agent nor pkcs11 library) you can still have many chances to use your OpenPGP card (see my openpgp openid project http://dev.primianotucci.com/openid/) > Primiano: Are you aware of the draft 2.0 specification for the card? > There are a couple of new things in it; for example a new DO to store a > certificiate and a way to reset the card to factory defaults: > http://g10code.com/docs/openpgp-card-2.0-rc1.pdf . I haven't looked at 2.0 specifications (i'm waiting for the final one)... I don't think there are actually OpenPGP cards that implements such specifications (correct me if wrong) The driver is based on the 1.1 specs.... i'll update it as soon as the final 2.0 specs will be ready. Honestly I think the fact that enetering 3 wrong CHV3 destroyes the card is a simple ashame... the "reset to blank" command should be a must! (hopes for the 2.0 card :)) > > Salam-Shalom, > > Werner Thanks for your interest, Primiano Tucci From wk at gnupg.org Fri Jul 18 14:21:09 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Jul 2008 14:21:09 +0200 Subject: about the OpenPGP Card In-Reply-To: (Primiano Tucci's message of "Fri, 18 Jul 2008 12:18:48 +0200") References: <487FAA50.30602@gmail.com> <87abgfmy9a.fsf@wheatstone.g10code.de> Message-ID: <87sku7jscq.fsf@wheatstone.g10code.de> On Fri, 18 Jul 2008 12:18, p.tucci at gmail.com said: > Scute is a pkcs11 driver, it means that prior to make your card work > you need to have downloaded the libary, configured mozilla (and it > seems no way for IE) and have a working gpg-agent. Mozilla uses pkcs#11 as its crypto API thus you need such a driver. Should also work with other browsers but not tested. Windows port is under way. > My driver, on the other side, does not need anything, just a java > insatllation... so if you are on another pc that has a smartcard And you need to allow Java in your browser. Some folks hesitate to enable this. > you can still have many chances to use your OpenPGP card (see my > openpgp openid project http://dev.primianotucci.com/openid/) Interesting. > I haven't looked at 2.0 specifications (i'm waiting for the final > one)... I don't think there are actually OpenPGP cards that implements > such specifications (correct me if wrong) In a couple of months. Actually the new spec has some feature to better support Java cards. > The driver is based on the 1.1 specs.... i'll update it as soon as the > final 2.0 specs will be ready. This is a release candidate - there are just a few typos left and possible we need to extend the size of some fields. I already started to implemented that in GnuPG. > Honestly I think the fact that enetering 3 wrong CHV3 destroyes the > card is a simple ashame... the "reset to blank" command should be a > must! (hopes for the 2.0 card :)) Included in the new spec due to great public demand. How I just need top add a command to gpg to allow resetting the card. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Fri Jul 18 14:23:52 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Jul 2008 14:23:52 +0200 Subject: gnupg1 still needed? In-Reply-To: <20080718094658.GB23370@suse.de> (Klaus Singvogel's message of "Fri, 18 Jul 2008 11:46:58 +0200") References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de> <20080718094658.GB23370@suse.de> Message-ID: <87od4vjs87.fsf@wheatstone.g10code.de> On Fri, 18 Jul 2008 11:46, kssingvo at suse.de said: > But I noticed that gpg1 could support old PGP keys, if module idea is > added. On the other side gpg2 it seems that gpg2 is capable to support I wonder why you ask. It is not possible for SuSE to include any such support for an outdated, useless and patented cipher algorithm. > Is there a way to support old rsa/idea keys in gpg2? There are no IDEA keys. It might be that a key has been protected with IDEA but there exists an easy workaround to change the protection algorithm. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Fri Jul 18 14:28:17 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Jul 2008 14:28:17 +0200 Subject: about the OpenPGP Card In-Reply-To: (Primiano Tucci's message of "Fri, 18 Jul 2008 12:18:48 +0200") References: <487FAA50.30602@gmail.com> <87abgfmy9a.fsf@wheatstone.g10code.de> Message-ID: <87iqv3js0u.fsf@wheatstone.g10code.de> On Fri, 18 Jul 2008 12:18, p.tucci at gmail.com said: > openpgp openid project http://dev.primianotucci.com/openid/) Unfortunately there is no mailing list just a web forum. Thus not useful for me. Feel free to use this list for technical discussions related to the OpenPGP card. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Fri Jul 18 14:41:56 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 18 Jul 2008 08:41:56 -0400 Subject: gnupg1 still needed? In-Reply-To: <87od4vjs87.fsf@wheatstone.g10code.de> References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de> <20080718094658.GB23370@suse.de> <87od4vjs87.fsf@wheatstone.g10code.de> Message-ID: <2FE58E51-2FEB-4515-9CD6-95022EAF3496@jabberwocky.com> On Jul 18, 2008, at 8:23 AM, Werner Koch wrote: > On Fri, 18 Jul 2008 11:46, kssingvo at suse.de said: > >> But I noticed that gpg1 could support old PGP keys, if module idea is >> added. On the other side gpg2 it seems that gpg2 is capable to >> support > > I wonder why you ask. It is not possible for SuSE to include any such > support for an outdated, useless and patented cipher algorithm. > >> Is there a way to support old rsa/idea keys in gpg2? > > There are no IDEA keys. It might be that a key has been protected > with > IDEA but there exists an easy workaround to change the protection > algorithm. I think he's referring to IDEA keys in the sense of PGP 2.x: v3 RSA keys that always use IDEA as their cipher. We need to let PGP 2.x stay dead. I had fond hopes that the MD5 break would kill PGP 2.x for good, but I was - alas - mistaken. David From p.tucci at gmail.com Fri Jul 18 15:01:49 2008 From: p.tucci at gmail.com (Primiano Tucci) Date: Fri, 18 Jul 2008 15:01:49 +0200 Subject: about the OpenPGP Card In-Reply-To: <87sku7jscq.fsf@wheatstone.g10code.de> References: <487FAA50.30602@gmail.com> <87abgfmy9a.fsf@wheatstone.g10code.de> <87sku7jscq.fsf@wheatstone.g10code.de> Message-ID: On Fri, Jul 18, 2008 at 2:21 PM, Werner Koch wrote: > On Fri, 18 Jul 2008 12:18, p.tucci at gmail.com said: > >> Scute is a pkcs11 driver, it means that prior to make your card work >> you need to have downloaded the libary, configured mozilla (and it >> seems no way for IE) and have a working gpg-agent. > > Mozilla uses pkcs#11 as its crypto API thus you need such a driver. This is absolutely uncorrect. I do NOT need mozilla crypto api, i do not need the entire pkcs#11 layer since my driver rawly communicates via the T=1 protocol with the card (thanks to Sun's Java low level APIs). I just need Java and the card reader drivers (but NOT the pkcs11), that's the big point of the driver. > Should also work with other browsers but not tested. Windows port is > under way. Internet explorer does not use the standard PKCS11 layer... it uses a more sofisticated layer (CSP). There is an open source project (actually I miss the name) that claims to act as a wrapper between Microsoft CSP and the PKCS11 layer, but i never tested it. >> My driver, on the other side, does not need anything, just a java >> insatllation... so if you are on another pc that has a smartcard > > And you need to allow Java in your browser. Some folks hesitate to > enable this. Anyone chooses his paranoid level. There are people that do not allow Internet on their computers :) But we're in the 2008 and the i suppose the probability to find a Java installation in a PC is realistically high (and absolutely higher than the probability to find a pkcs11 layer + gpg agent + pkcs11 correctly installed ) >> you can still have many chances to use your OpenPGP card (see my >> openpgp openid project http://dev.primianotucci.com/openid/) > > Interesting. > >> I haven't looked at 2.0 specifications (i'm waiting for the final >> one)... I don't think there are actually OpenPGP cards that implements >> such specifications (correct me if wrong) > > In a couple of months. Actually the new spec has some feature to better > support Java cards. > >> The driver is based on the 1.1 specs.... i'll update it as soon as the >> final 2.0 specs will be ready. > > This is a release candidate - there are just a few typos left and > possible we need to extend the size of some fields. I already started > to implemented that in GnuPG. > >> Honestly I think the fact that enetering 3 wrong CHV3 destroyes the >> card is a simple ashame... the "reset to blank" command should be a >> must! (hopes for the 2.0 card :)) > > Included in the new spec due to great public demand. How I just need > top add a command to gpg to allow resetting the card. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. > > Primiano Tucci From kssingvo at suse.de Fri Jul 18 15:18:11 2008 From: kssingvo at suse.de (Klaus Singvogel) Date: Fri, 18 Jul 2008 15:18:11 +0200 Subject: gnupg1 still needed? In-Reply-To: <87od4vjs87.fsf@wheatstone.g10code.de> References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de> <20080718094658.GB23370@suse.de> <87od4vjs87.fsf@wheatstone.g10code.de> Message-ID: <20080718131811.GB7442@suse.de> Werner Koch wrote: > On Fri, 18 Jul 2008 11:46, kssingvo at suse.de said: > > > But I noticed that gpg1 could support old PGP keys, if module idea is > > added. On the other side gpg2 it seems that gpg2 is capable to support > > I wonder why you ask. It is not possible for SuSE to include any such > support for an outdated, useless and patented cipher algorithm. Thats our problem: we cannot support/distribute algorithms with a patent-fee. :-) But I think, I should have deleted my .signature, as I was speaking out of personal interests and not for my company. Please note either that SUSE Linux dropped the support for gpg1 since 10.3 (Oct 2007), and is shipping gpg2 only now. Sorry for my mistake. The reason is that people came every then and a while to me and ask me how to use the exact algorithms, why Phil Zimmerman got accused for their release in the Usenet. As it is still not known how to break RSA and IDEA, people still want only to use (insist on?) algorithms the NSA showed the only time nervousness in the past. Hope it helps for better understanding. Regards, Klaus. -- Klaus Singvogel - Maxfeldstr. 5 - 90409 Nuernberg - Germany Phone: +49-911-74053-0 GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) From wk at gnupg.org Fri Jul 18 15:58:02 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Jul 2008 15:58:02 +0200 Subject: about the OpenPGP Card In-Reply-To: (Primiano Tucci's message of "Fri, 18 Jul 2008 15:01:49 +0200") References: <487FAA50.30602@gmail.com> <87abgfmy9a.fsf@wheatstone.g10code.de> <87sku7jscq.fsf@wheatstone.g10code.de> Message-ID: <87prpbi9at.fsf@wheatstone.g10code.de> On Fri, 18 Jul 2008 15:01, p.tucci at gmail.com said: >> Mozilla uses pkcs#11 as its crypto API thus you need such a driver. > > This is absolutely uncorrect. PKCS#11 is the native crypto API of Mozilla. But that is irrelevant because you do not use it ... > I do NOT need mozilla crypto api, i do not need the entire pkcs#11 > layer since my driver rawly communicates via the T=1 protocol with the > card (thanks to Sun's Java low level APIs). .. sure. >> Should also work with other browsers but not tested. Windows port is >> under way. > > Internet explorer does not use the standard PKCS11 layer... it uses a > more sofisticated layer (CSP). "Windows port" does not necessary mean "for Internet Exploder". > But we're in the 2008 and the i suppose the probability to find a Java > installation in a PC is realistically high (and absolutely higher than > the probability to find a pkcs11 layer + gpg agent + pkcs11 correctly > installed ) Depends on whom you ask. Those people using the OpenPGP card are probably a bit more security aware than the average Windows user. In fact, many security policies of companies and public administrations do not allow the use of Java on client machines. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From jmoore3rd at bellsouth.net Fri Jul 18 16:57:15 2008 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Fri, 18 Jul 2008 10:57:15 -0400 Subject: gnupg1 still needed? In-Reply-To: <20080718131811.GB7442@suse.de> References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de> <20080718094658.GB23370@suse.de> <87od4vjs87.fsf@wheatstone.g10code.de> <20080718131811.GB7442@suse.de> Message-ID: <4880AF4B.1000301@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Klaus Singvogel wrote: > and IDEA, people still want only to use (insist on?) algorithms the > NSA showed the only time nervousness in the past. FWIW; "NSA nervousness" could very well be a 'Social Engineering' tactic explicitly designed into lulling folks into a false sense of security. Additionally, note should be taken of the phrase "in the past" and respect given to the fact that NSA & their ilk recruit, employ and devote literally 1,000's of mathematicians & analysts to 'solving problems' and if any 'solutions' are discovered they _won't_ be advertised or published. :-\ People are responsible for determining their Own threat model and acting accordingly. From experience I can assure You that anything that really makes NSA nervous won't be discussed with more than a handful of folks outside Ft. Meade. JOHN ;) Timestamp: Friday 18 Jul 2008, 10:56 --400 (Eastern Daylight Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10-svn4799: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: https://www.gswot.org Comment: TokBox: http://www.tokbox.com/John234 Comment: Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJIgK9IAAoJEBCGy9eAtCsP73oH/jZZrmtkkXyI8trbF6xUnnrw FP3F0OynYBjdxUf3e5++5e6p2XJ9aLJ2sz9zlz9lA+yxpih5oU33/wuts2leaAQU 2lV7kJWCLMf2dGG1JVRGEecAnyOwjQ2X5Lrtgytghoj8cDhLit81qJKR+JTvA9ZY 0XUbM73frEDugSfKmVFWQ0JagNG5y2rttUQSPLH53VeQ1at1ronVa1lVxd3U/nzd JqGNHy6pXYY29U4Fg4TnzRQmEcx5IWmn5yTiG5TAX8/qnbvk+gPmo3kbHm4m5nKH 8zEHsiAn6oczipYGfiUdH0Jt6yCT94sLIj+nLjmehJ0ZKU7ZU/U+TbglfSeMVqc= =yHP/ -----END PGP SIGNATURE----- From cwal989 at comcast.net Fri Jul 18 16:28:26 2008 From: cwal989 at comcast.net (Chris Walters) Date: Fri, 18 Jul 2008 10:28:26 -0400 Subject: gnupg1 still needed? In-Reply-To: <87od4vjs87.fsf@wheatstone.g10code.de> References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de> <20080718094658.GB23370@suse.de> <87od4vjs87.fsf@wheatstone.g10code.de> Message-ID: <4880A88A.8090602@comcast.net> Werner Koch wrote: > On Fri, 18 Jul 2008 11:46, kssingvo at suse.de said: > >> But I noticed that gpg1 could support old PGP keys, if module idea is >> added. On the other side gpg2 it seems that gpg2 is capable to support > > I wonder why you ask. It is not possible for SuSE to include any such > support for an outdated, useless and patented cipher algorithm. > >> Is there a way to support old rsa/idea keys in gpg2? > > There are no IDEA keys. It might be that a key has been protected with > IDEA but there exists an easy workaround to change the protection > algorithm. It is rather difficult to know where IDEA is still patented and where it is not (i.e. where the patent has expired). Even so, it is more than 10 years old (the length of a patent in the US), and there are much better symmetric algorithms out there, so I really don't see the need to use it. There is a way to compile in support for IDEA in both gpg and gpg2, depending on the distribution, but with AES, I think IDEA is outdated, myself. JMHO. Regards, Chris From dshaw at jabberwocky.com Fri Jul 18 17:23:45 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 18 Jul 2008 11:23:45 -0400 Subject: IDEA isn't magic (was Re: gnupg1 still needed?) In-Reply-To: <20080718131811.GB7442@suse.de> References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de> <20080718094658.GB23370@suse.de> <87od4vjs87.fsf@wheatstone.g10code.de> <20080718131811.GB7442@suse.de> Message-ID: <20080718152345.GA49835@jabberwocky.com> On Fri, Jul 18, 2008 at 03:18:11PM +0200, Klaus Singvogel wrote: > Werner Koch wrote: > > On Fri, 18 Jul 2008 11:46, kssingvo at suse.de said: > > > > > But I noticed that gpg1 could support old PGP keys, if module idea is > > > added. On the other side gpg2 it seems that gpg2 is capable to support > > > > I wonder why you ask. It is not possible for SuSE to include any such > > support for an outdated, useless and patented cipher algorithm. > > Thats our problem: we cannot support/distribute algorithms with a > patent-fee. :-) > > But I think, I should have deleted my .signature, as I was speaking > out of personal interests and not for my company. Please note either > that SUSE Linux dropped the support for gpg1 since 10.3 (Oct 2007), > and is shipping gpg2 only now. Sorry for my mistake. > > The reason is that people came every then and a while to me and ask me > how to use the exact algorithms, why Phil Zimmerman got accused for > their release in the Usenet. In that case, shouldn't you be pointing them to BassOmatic? ;) http://en.wikipedia.org/wiki/BassOmatic > As it is still not known how to break RSA and IDEA, people still > want only to use (insist on?) algorithms the NSA showed the only > time nervousness in the past. This is silly. IDEA has not been broken, but then neither has 3DES. 3DES (1978) has been studied a lot longer, and withstood far more attacks than IDEA (1991). David From adam at adammil.net Fri Jul 18 20:11:19 2008 From: adam at adammil.net (Adam Milazzo) Date: Fri, 18 Jul 2008 11:11:19 -0700 Subject: sendings passwords with gpg-agent? (was Re: gnupg1 still needed?) In-Reply-To: <20080718131811.GB7442@suse.de> References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de> <20080718094658.GB23370@suse.de> <87od4vjs87.fsf@wheatstone.g10code.de> <20080718131811.GB7442@suse.de> Message-ID: <4880DCC7.5080801@adammil.net> Klaus Singvogel wrote: > Please note either > that SUSE Linux dropped the support for gpg1 since 10.3 (Oct 2007), > and is shipping gpg2 only now. Well, this makes me wonder, then. gpg1 allows programs to send passwords using --command-fd. gpg2 always uses gpg-agent, and never asks for passwords on the --command-fd. Is there a way to get something equivalent on gpg2, though? i.e., can a program hook into the gpg-agent in such a way as to provide its own UI for password entry? From sutter at informatik.hs-furtwangen.de Sat Jul 19 17:52:48 2008 From: sutter at informatik.hs-furtwangen.de (Phil Sutter) Date: Sat, 19 Jul 2008 17:52:48 +0200 Subject: Secret Sharing In-Reply-To: <20080525123053.GD29955@base.freewrt> References: <20080319212325.GB12049@nuty.freewrt> <20080525123053.GD29955@base.freewrt> Message-ID: <20080719155248.GA17555@nuty> Hi! So far I have a working daemon setting up new Secret-Sharing sessions and/or combining given shares. It already talks assuan. In order to improve usability (a lot in my eyes), the daemon uses a backing store (two files for now) holding all (sharing and combining) sessions, so it can be called multiple times inserting/generating a share each time. On Sun, May 25, 2008 at 02:30:53PM +0200, Phil Sutter wrote: > using an implementation of Shamir's (t,w)-threshold scheme I want to > share the passphrase to a secret key. At least for now the algorithm > will operate in GF(p). Currently I'm using an implementation of arithmetics in GF(2^8) written by James S. Plank, so the secret can consist of an arbitrary number of bytes and therefore hold the hole secret key. For the user interface I think of implementing the following set of commands: * setup: generate a new key pair, feed the secret key into a new Secret-Sharing session and return the pubkey * get_share: generate and return a new share for the session identified by given keygrip * finalise: remove all data (including the secret key) of the session corresponding to the given keygrip * combine: prepare combining shares for the given keygrip * add_share: add the given share to the interpolation for it's keygrip; if the key is available then, return it and remove the interpolation metadata gpg-agent uses GNUPG_PRIVATE_KEYS_DIR to lookup secret keys (at least) (agent_key_available()). I haven't found the code yet where any key is being written there, is it desirable at all to write recombined secret keys there, or should I pass them over to gpg directly? Greetings, Phil From info at danielnylander.se Sun Jul 20 16:15:45 2008 From: info at danielnylander.se (Daniel Nylander) Date: Sun, 20 Jul 2008 16:15:45 +0200 Subject: Updated Swedish translations Message-ID: <1216563345.8165.2246.camel@fatbastard.internal.lidkoping.net> I have updated the Swedish translations for gnupg 2.x and 1.4.x. Please commit. http://home.danielnylander.se/translations/gnupg/gnupg-1.4.sv.po http://home.danielnylander.se/translations/gnupg/gnupg-2.sv.po Regards, Daniel Nylander Stockholm, Sweden From lists at lina.inka.de Sun Jul 20 22:50:19 2008 From: lists at lina.inka.de (Bernd Eckenfels) Date: Sun, 20 Jul 2008 22:50:19 +0200 Subject: Secret Sharing In-Reply-To: <20080719155248.GA17555@nuty> References: <20080319212325.GB12049@nuty.freewrt> <20080525123053.GD29955@base.freewrt> <20080719155248.GA17555@nuty> Message-ID: <20080720205019.GA21274@lina.inka.de> On Sat, Jul 19, 2008 at 05:52:48PM +0200, Phil Sutter wrote: > * get_share: generate and return a new share for the session identified > by given keygrip A nice feature would be to pass a public key to it, so you get the key-share encrypted back. That way the secret is less exposed. Gruss Bernd -- (OO) -- Bernd_Eckenfels at M?rscher_Strasse_8.76185Karlsruhe.de -- ( .. ) ecki@{inka.de,linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E eckes at IRCNet v:+497211603874 f:+49721151516129 (O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! From sutter at informatik.hs-furtwangen.de Mon Jul 21 01:55:29 2008 From: sutter at informatik.hs-furtwangen.de (Phil Sutter) Date: Mon, 21 Jul 2008 01:55:29 +0200 Subject: Secret Sharing In-Reply-To: <20080720205019.GA21274@lina.inka.de> References: <20080319212325.GB12049@nuty.freewrt> <20080525123053.GD29955@base.freewrt> <20080719155248.GA17555@nuty> <20080720205019.GA21274@lina.inka.de> Message-ID: <20080720235529.GD8043@base.freewrt> On Sun, Jul 20, 2008 at 10:50:19PM +0200, Bernd Eckenfels wrote: > On Sat, Jul 19, 2008 at 05:52:48PM +0200, Phil Sutter wrote: > > * get_share: generate and return a new share for the session identified > > by given keygrip > > A nice feature would be to pass a public key to it, so you get the key-share > encrypted back. That way the secret is less exposed. Yes, that's part of the plan. ;) Also for recombining I think of the shares being encrypted with the combiner's public key. In case of an interactive combining process (i.e. a user sitting there entering a password), encrypting the secret-sharing's backing store with the combiner's public key would increase security without increasing overhead on the user interface side. MfG, Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From buanzo at buanzo.com.ar Mon Jul 21 01:37:22 2008 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Sun, 20 Jul 2008 20:37:22 -0300 Subject: gpg under wine? Message-ID: <4883CC32.603@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I'm attempting to run gpg4win under Wine, but I get this: buanzo at murray:~/.wine/drive_c/Program Files/GNU/GnuPG$ wine gpg.exe --gen-key gpg (GnuPG) 1.4.7; Copyright (C) 2006 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. gpg: fatal: WriteConsole failed: Access denied secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 Any ideas? I'm on Kubuntu Linux, up-to-date, nothing from source. It's gpg4win 1.1.3. - -- Arturo "Buanzo" Busleiman Independent Linux and Security Consultant - SANS - OISSG - OWASP http://www.buanzo.com.ar/pro/eng.html Mailing List Archives at http://archiver.mailfighter.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIg8wxAlpOsGhXcE0RCmMhAJ4u2r0g/PKLV9K5TDOojUKVmIfjyACfYLeP nZfP8epTuO9QPh43+PxR8Ck= =8Lgr -----END PGP SIGNATURE----- From wk at gnupg.org Mon Jul 21 09:05:54 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Jul 2008 09:05:54 +0200 Subject: Updated Swedish translations In-Reply-To: <1216563345.8165.2246.camel@fatbastard.internal.lidkoping.net> (Daniel Nylander's message of "Sun, 20 Jul 2008 16:15:45 +0200") References: <1216563345.8165.2246.camel@fatbastard.internal.lidkoping.net> Message-ID: <87ej5nogx9.fsf@wheatstone.g10code.de> On Sun, 20 Jul 2008 16:15, info at danielnylander.se said: > I have updated the Swedish translations for gnupg 2.x and 1.4.x. > Please commit. Done. Many thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Mon Jul 21 10:57:31 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 21 Jul 2008 10:57:31 +0200 Subject: gpg under wine? In-Reply-To: <4883CC32.603@buanzo.com.ar> References: <4883CC32.603@buanzo.com.ar> Message-ID: <877ibf7gxw.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sun, 20 Jul 2008 20:37:22 -0300, Arturo 'Buanzo' Busleiman wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi, I'm attempting to run gpg4win under Wine, but I get this: > > buanzo at murray:~/.wine/drive_c/Program Files/GNU/GnuPG$ wine gpg.exe --gen-key > gpg (GnuPG) 1.4.7; Copyright (C) 2006 Free Software Foundation, Inc. > This program comes with ABSOLUTELY NO WARRANTY. > This is free software, and you are welcome to redistribute it > under certain conditions. See the file COPYING for details. > > gpg: fatal: WriteConsole failed: Access denied > secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 > > Any ideas? I'm on Kubuntu Linux, up-to-date, nothing from source. It's gpg4win 1.1.3. Please use wineconsole. Some gpg operations like gen-key really want to talk to the console directly for increased security (for example to prevent the passphrase from appearing on the screen). So, you should use wineconsole instead of wine, which will launch a windows console that implements those additional features. There are also operation modes in gpg that don't require a console, but those are harder to use and do not provide the interactivity you get with --gen-key. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Mon Jul 21 11:05:09 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 21 Jul 2008 11:05:09 +0200 Subject: sendings passwords with gpg-agent? (was Re: gnupg1 still needed?) In-Reply-To: <4880DCC7.5080801@adammil.net> References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de> <20080718094658.GB23370@suse.de> <87od4vjs87.fsf@wheatstone.g10code.de> <20080718131811.GB7442@suse.de> <4880DCC7.5080801@adammil.net> Message-ID: <8763qz7gl6.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Fri, 18 Jul 2008 11:11:19 -0700, Adam Milazzo wrote: > > Klaus Singvogel wrote: > > Please note either > > that SUSE Linux dropped the support for gpg1 since 10.3 (Oct 2007), > > and is shipping gpg2 only now. > Well, this makes me wonder, then. > > gpg1 allows programs to send passwords using --command-fd. gpg2 always > uses gpg-agent, and never asks for passwords on the --command-fd. Is > there a way to get something equivalent on gpg2, though? i.e., can a > program hook into the gpg-agent in such a way as to provide its own UI > for password entry? I am not aware of such an option with gpg2, but note that you will never get it in all circumstances. Consider smart cards used on a terminal with a number pad. In this case, you really do not want the pin number to go through the application. It is best to consider gpg2 with this use case in mind. Just forget about secret key handling and passphrases and such. They are not the business of applications any more with gpg2. Now, in case you really want this, you can replace the pinentry program. There is currently no easy way to do this (you need to set up your own gnupghome for it). But conceptually, the pinentry program is the component you want to replace if you want to change its GUI. Yes, this is harder to integrate into the application. This is on purpose, see above. Thanks, Marcus From adam at adammil.net Mon Jul 21 12:03:20 2008 From: adam at adammil.net (Adam Milazzo) Date: Mon, 21 Jul 2008 03:03:20 -0700 Subject: sendings passwords with gpg-agent? (was Re: gnupg1 still needed?) In-Reply-To: <8763qz7gl6.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de> <20080718094658.GB23370@suse.de> <87od4vjs87.fsf@wheatstone.g10code.de> <20080718131811.GB7442@suse.de> <4880DCC7.5080801@adammil.net> <8763qz7gl6.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <48845EE8.50305@adammil.net> [Whoops. Adding list.] > Consider smart cards used on a > terminal with a number pad. In this case, you really do not want the > pin number to go through the application. Yes, I agree. > It is best to consider gpg2 with this use case in mind. Just forget > about secret key handling and passphrases and such. They are not the > business of applications any more with gpg2. The main problem I have is that the gpg-agent UI sucks. For instance, with symmetric decryption, it just says "Enter password", which leaves the user wondering "which password??". They'll probably enter their secret key password, which won't work. And they won't know why it didn't work... Second, there's no obvious way to cache the passwords, so the user would think he has to to type them in for every file in a multi-file operation, for instance. And finally, unit tests for libraries that script GPG behind the scenes can't be run automatically. The gpg-agent dialog pops up a hundred times during the tests. This would be a moot point if there was a GPG library, but the official answer seems to be to script the GPG text-mode executable, which is made harder by gpg-agent. From buanzo at buanzo.com.ar Mon Jul 21 14:30:40 2008 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Mon, 21 Jul 2008 09:30:40 -0300 Subject: gpg under wine? In-Reply-To: <877ibf7gxw.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <4883CC32.603@buanzo.com.ar> <877ibf7gxw.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <48848170.7070506@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Marcus Brinkmann wrote: | Please use wineconsole. Some gpg operations like gen-key really want Silly me. Not a real wine user here. Sorry, should've analyzed wine more thorughly. Anyway, Googling showed nothing useful for "WriteConsole failed" gpg wine, so I guess this is good anyway for future searches ;) - -- Arturo "Buanzo" Busleiman Independent Linux and Security Consultant - SANS - OISSG - OWASP http://www.buanzo.com.ar/pro/eng.html Mailing List Archives at http://archiver.mailfighter.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIhIEeAlpOsGhXcE0RCo32AJ46qXopKtGYw3BX7XprNYr64vMJWgCfQU9A Fp8uR/SRYRbcXcFuExDcJDs= =ZlS3 -----END PGP SIGNATURE----- From wk at gnupg.org Mon Jul 21 17:24:03 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Jul 2008 17:24:03 +0200 Subject: sendings passwords with gpg-agent? In-Reply-To: <48845EE8.50305@adammil.net> (Adam Milazzo's message of "Mon, 21 Jul 2008 03:03:20 -0700") References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de> <20080718094658.GB23370@suse.de> <87od4vjs87.fsf@wheatstone.g10code.de> <20080718131811.GB7442@suse.de> <4880DCC7.5080801@adammil.net> <8763qz7gl6.wl%marcus.brinkmann@ruhr-uni-bochum.de> <48845EE8.50305@adammil.net> Message-ID: <87k5ff45ws.fsf@wheatstone.g10code.de> On Mon, 21 Jul 2008 12:03, adam at adammil.net said: > The main problem I have is that the gpg-agent UI sucks. For instance, > with symmetric decryption, it just says "Enter password", which leaves > the user wondering "which password??". They'll probably enter their This is for sure not good. However there is no other information available. Symmetric only encryption is usually only used in unattended settings and thus there is no need for a pinentry (Use --passphrase-fd). Please suggest a wording for the prompt uside with symmteric encryption. > Second, there's no obvious way to cache the passwords, so the user would > think he has to to type them in for every file in a multi-file Well these are one-off passphrases and it does not make sense to cache them - use public-key encryption instead. To allow for passphrase caching we would need to implement a key management for symmetric encryption; i.e. to use a random key protected by a passphrase. This is quite some work becuase you need to have all the code to distribute such protected symmetric passphrases. > And finally, unit tests for libraries that script GPG behind the scenes > can't be run automatically. The gpg-agent dialog pops up a hundred times > during the tests. Hmmm, gpg2 uses quite some regression tests without any problems. On my todo list is a loopback-pinentry which would allow to test the entire gpg-agent/gpg[sm] passphrase system. But well, regression tests are a lot of work and a work most people don't won't to pay for and finding volunteers is evene harder. Yes, there should be far more regresseion tests. > This would be a moot point if there was a GPG library, but the official There is one: gpgme. gpgme even has a lot rof regression tests. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From adam at adammil.net Tue Jul 22 00:03:47 2008 From: adam at adammil.net (Adam Milazzo) Date: Mon, 21 Jul 2008 15:03:47 -0700 Subject: BUG: gpgconf --apply-defaults seems to fail if it's in a directory with a space Message-ID: <488507C3.9010604@adammil.net> Looks like it's invoking the shell without quoting the program to run, or something like that: C:\Program Files\GNU\GnuPG>gpgconf --apply-defaults 'C:\Program' is not recognized as an internal or external command, operable program or batch file. gpgconf: Option gpgconf-gpg.conf, needed by backend GnuPG, was not initialized gpgconf: fatal error (exit status 1) From marcus.brinkmann at ruhr-uni-bochum.de Tue Jul 22 01:21:20 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue, 22 Jul 2008 01:21:20 +0200 Subject: sendings passwords with gpg-agent? (was Re: gnupg1 still needed?) In-Reply-To: References: <9204C269-59A5-4E60-88A9-5447C195D3ED@jabberwocky.com> <20080718035240.GA30115@gambit> <87iqv3myx5.fsf@wheatstone.g10code.de> <20080718094658.GB23370@suse.de> <87od4vjs87.fsf@wheatstone.g10code.de> <20080718131811.GB7442@suse.de> <4880DCC7.5080801@adammil.net> <8763qz7gl6.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <87vdyy6cy7.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 21 Jul 2008 12:43:25 -0400 (EDT), mskala at ansuz.sooke.bc.ca wrote: > > On Mon, 21 Jul 2008, Marcus Brinkmann wrote: > > I am not aware of such an option with gpg2, but note that you will > > never get it in all circumstances. Consider smart cards used on a > > terminal with a number pad. In this case, you really do not want the > > pin number to go through the application. > > Being able to decrypt and sign in scripts is pretty important. If gpg2 > can't do that, people will use gpg1 whether you approve or not. gpg2 can do that. Off the cuff, I can think of about 3-5 ways to do it. The best method depends on your environment and security needs. Just to give you a hint, check out the various passphrase related command line options, the GPGME test suite in SVN, and the gpg-preset-passphrase tool. There is nothing wrong with using gpg1. We approve fully. Thanks, Marcus From petr.uzel at suse.cz Wed Jul 23 11:17:40 2008 From: petr.uzel at suse.cz (Petr Uzel) Date: Wed, 23 Jul 2008 11:17:40 +0200 Subject: [PATCH] - pinentry uses wrong apostrophe Message-ID: <200807231117.41190.petr.uzel@suse.cz> Hi list, here comes small patch that fixes wrong apostrophes in pinentry/secmem/secmem.c. -- Best regards / s pozdravem Petr Uzel, Packages maintainer --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: petr.uzel at suse.cz Lihovarsk? 1060/12 tel: +420 284 028 964 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz -------------- next part -------------- A non-text attachment was scrubbed... Name: pinentry-0.7.5-wrong-apostrophe.patch Type: text/x-diff Size: 535 bytes Desc: not available URL: From wk at gnupg.org Wed Jul 23 13:18:39 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Jul 2008 13:18:39 +0200 Subject: [PATCH] - pinentry uses wrong apostrophe In-Reply-To: <200807231117.41190.petr.uzel@suse.cz> (Petr Uzel's message of "Wed, 23 Jul 2008 11:17:40 +0200") References: <200807231117.41190.petr.uzel@suse.cz> Message-ID: <87ljzsg86o.fsf@wheatstone.g10code.de> On Wed, 23 Jul 2008 11:17, petr.uzel at suse.cz said: > here comes small patch that fixes wrong apostrophes in > pinentry/secmem/secmem.c. Thanks. Committed to revision 184. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From sutter at informatik.hs-furtwangen.de Thu Jul 24 15:06:37 2008 From: sutter at informatik.hs-furtwangen.de (Phil Sutter) Date: Thu, 24 Jul 2008 15:06:37 +0200 Subject: sending large bulk data with assuan Message-ID: <20080724130637.GB30370@base.freewrt> Hi! I want to send about 3.5kBytes of bulk data using assuan_send_data() on the server side. On client side this is triggered using assuan_transact() and a data callback function. The problem here is the callback function only receives the first line of data (996 Bytes). Though when I talk assuan directly to the server (i.e. executing it and typing the commands manually) I get four lines of data (prefixed with "D") and then a final "OK". The data being transfered is just a long string of (uppercase) hex chars, so no escaping should be necessary. Do you have any idea why this happens or what I'm doing wrong? Sadly, the Assuan Infopage isn't too verbose about this particular topic, and searching the GnuPG code didn't reveal any special magic when doing bulk data transfers. Greetings, Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From sutter at informatik.hs-furtwangen.de Fri Jul 25 16:37:08 2008 From: sutter at informatik.hs-furtwangen.de (Phil Sutter) Date: Fri, 25 Jul 2008 16:37:08 +0200 Subject: sending large bulk data with assuan In-Reply-To: <20080724130637.GB30370@base.freewrt> References: <20080724130637.GB30370@base.freewrt> Message-ID: <20080725143708.GB19168@base.freewrt> Hi, On Thu, Jul 24, 2008 at 03:06:37PM +0200, Phil Sutter wrote: > The problem here is the callback function only receives the first line > of data (996 Bytes). Though when I talk assuan directly to the server > (i.e. executing it and typing the commands manually) I get four lines of > data (prefixed with "D") and then a final "OK". Ok, forget it. I already knew that the callback functions have to return zero to indicate everything is fine. Though having a statement like this: | return (write(fd, buf, len) == len); is a very bad idea. Sorry for the traffic these mails generated. ;) Greetings, Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From sutter at informatik.hs-furtwangen.de Mon Jul 28 16:55:13 2008 From: sutter at informatik.hs-furtwangen.de (Phil Sutter) Date: Mon, 28 Jul 2008 16:55:13 +0200 Subject: equivalent to encrypt_filter for decryption Message-ID: <20080728145513.GB13241@base.freewrt> Hi! For encrypting generated shares I had a look at sign_file() in g10/sign.c, which uses the encrypt_filter and now have basic code encrypting internally available data when writing it out. The function encode_crypt() in g10/encode.c doesn't use this filter although it's actually encrypting data, is this because of historical reasons? Now when searching for an appropriate method for decrypting given shares for recombination I looked at decrypt_message() in g10/decrypt.c and it seems to be getting really ugly now: do_proc_encryption_packets() is quite a bunch of code, decrypting data to either opt.outfile or stdout; But I need the decrypted data internally to send it to the combiner. Is there any way doing this without reinventing the wheel? I mean, before I start copying much code only to change certain bits or hacking up the existing functions (which seems non-trivial here) I find it more useful to leave it to the user doing the en-/decryption on commandline (e.g. via pipe: "gpg -d share.pgp | gpg --add-share"). Greetings, Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From wk at gnupg.org Mon Jul 28 18:10:33 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Jul 2008 18:10:33 +0200 Subject: sending large bulk data with assuan In-Reply-To: <20080725143708.GB19168@base.freewrt> (Phil Sutter's message of "Fri, 25 Jul 2008 16:37:08 +0200") References: <20080724130637.GB30370@base.freewrt> <20080725143708.GB19168@base.freewrt> Message-ID: <87zlo22dmu.fsf@wheatstone.g10code.de> On Fri, 25 Jul 2008 16:37, sutter at informatik.hs-furtwangen.de said: > Sorry for the traffic these mails generated. ;) Such mails are often a good resource for people to find answers on their questions without asking. Thus no need to be sorry about sending questions and figuring out the answer yourself (but let the list know the solution). Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From thijs at debian.org Tue Jul 29 13:12:49 2008 From: thijs at debian.org (Thijs Kinkhorst) Date: Tue, 29 Jul 2008 13:12:49 +0200 Subject: revision 4603 has reverted 4547? Message-ID: <200807291312.53537.thijs@debian.org> Hi, SVN revision 4547 was applied to fix bug #810: http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/configure.ac?root=GnuPG&rev=4547&r1=4538&r2=4547 however, it seems that revision 4603 undoes the change: http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/configure.ac?root=GnuPG&rev=4603&r1=4594&r2=4603 I'm not sure if that was intentional, but at least in 1.4.9 I'm experiencing the bug described in #810 again: build fails when using --enable-minimal in the exact same way. cheers, Thijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: not available URL: From marcus.brinkmann at ruhr-uni-bochum.de Thu Jul 31 02:49:41 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu, 31 Jul 2008 02:49:41 +0200 Subject: gpgme_data_new_from_mem works, gpgme_data_write doesn't In-Reply-To: <20080706221010.GC699@denkbrett.schottelius.org> References: <20080706221010.GC699@denkbrett.schottelius.org> Message-ID: <87abfy27yy.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 7 Jul 2008 00:10:10 +0200, Nico Schottelius wrote: > > [1 ] > [1.1 ] > Hello! > > I am testing around with gpgme and it seems I am doing something > wrong with gpgme_data_write(): > > If I do > > gerr = gpgme_data_new(&g_test); > if(gerr != GPG_ERR_NO_ERROR) return 20; > i = strlen(b_encrypt); > > /* THIS WORKS */ > gerr = gpgme_data_new_from_mem(&g_encrypt_send, b_encrypt, i, 1); > if(gerr != GPG_ERR_NO_ERROR) return 24; > > /* decrypt: from gpgme_data_new_from_mem() */ > gerr = gpgme_op_decrypt(g_context, g_encrypt_send, g_plain_recv); > if(gerr != GPG_ERR_NO_ERROR) { > printf("gerr=%d\n",gerr); > return 19; > } > > > it works. If I do > > gerr = gpgme_data_new(&g_test); > if(gerr != GPG_ERR_NO_ERROR) return 20; > i = strlen(b_encrypt); > printf("strlen(%s) = %d\n",b_encrypt,i); > > /* THIS DOES NOT WORK */ > tmp = gpgme_data_write(g_test, b_encrypt, i); > printf("gpgmedatawrite: %d\n", tmp); > > /* decrypt: from gpgme_data_write() */ > gerr = gpgme_op_decrypt(g_context, g_test, g_plain_recv2); > if(gerr != GPG_ERR_NO_ERROR) { > printf("gerr=%d\n",gerr); > return 41; > } > > it does *NOT* work. As I wrote before: "gpgme data objects have a file pointer that must be rewound to read written data (gpgme_data_seek). To use the seek function make sure you compile with large file support. See the documentation." The gpgme_data_write() above works just fine, but after it the file pointer is at the end of the data, and the gpgme_op_decrypt sees an empty data buffer: g_test: some-data ^ | "file" pointer You need to rewind the file pointer to the beginning after gpgme_data_write. Please see the documentation, and take notice of the large file support necessary when using gpgme_data_seek. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Thu Jul 31 03:10:13 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu, 31 Jul 2008 03:10:13 +0200 Subject: BUG: gpgconf --apply-defaults seems to fail if it's in a directory with a space In-Reply-To: <488507C3.9010604@adammil.net> References: <488507C3.9010604@adammil.net> Message-ID: <878wvi270q.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 21 Jul 2008 15:03:47 -0700, Adam Milazzo wrote: > > Looks like it's invoking the shell without quoting the program to run, > or something like that: > > C:\Program Files\GNU\GnuPG>gpgconf --apply-defaults > 'C:\Program' is not recognized as an internal or external command, > operable program or batch file. > gpgconf: Option gpgconf-gpg.conf, needed by backend GnuPG, was not > initialized > gpgconf: fatal error (exit status 1) I can not reproduce this with 2.0.10-svn4797 included in recent gpg4win beta versions. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Thu Jul 31 03:15:38 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu, 31 Jul 2008 03:15:38 +0200 Subject: BUG: gpg 1.4.9 crashes when creating ELG keys with sign and encrypt capability in batch mode In-Reply-To: <48783DD5.5020109@adammil.net> References: <48783DD5.5020109@adammil.net> Message-ID: <877ib226rp.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Fri, 11 Jul 2008 22:15:01 -0700, Adam Milazzo wrote: > > I think you're not supposed to use ElGamal keys that can sign and > encrypt, but GPG shouldn't crash in any case. This crash happens > consistently. Well, at least it is a controlled termination. I suppose the idea is that the caller has already checked the input. Thanks, Marcus From wk at gnupg.org Thu Jul 31 14:51:45 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 31 Jul 2008 14:51:45 +0200 Subject: [Announce] Dirmngr 1.0.2 released Message-ID: <87r69ajjxa.fsf@wheatstone.g10code.de> Hi! We are pleased to announce the availability of Dirmngr version 1.0.2. Dirmngr is a server for managing and downloading certificate revocation lists (CRLs) for X.509 certificates and for downloading the certificates themselves. Dirmngr also handles OCSP requests as an alternative to CRLs. Although Dirmngr can be invoked on demand, it should in general be installed as a system daemon. Get it from: ftp://ftp.gnupg.org/gcrypt/dirmngr/dirmngr-1.0.2.tar.bz2 (541k) ftp://ftp.gnupg.org/gcrypt/dirmngr/dirmngr-1.0.2.tar.bz2.sig or as a patch against the last beta version: ftp://ftp.gnupg.org/gcrypt/dirmngr/dirmngr-1.0.1-1.0.2.diff.bz2 (144k) SHA-1 checksums are: 55c82f918731f142cbe26d598a97c0c08bd7d1f8 dirmngr-1.0.2.tar.bz2 8d1482be8e8189aec726e0b20d66a3bcfd43e459 dirmngr-1.0.1-1.0.2.diff.bz2 Whats new in this release ========================= * New option --url for the LOOKUP command and dirmngr-client. * The LOOKUP command does now also consults the local cache. New option --cache-only for it and --local for dirmngr-client. * Port to Windows completed. * Improved certificate chain construction. * Support loading of PEM encoded CRLs via HTTP. There is now also a collection of some useful certificates in the doc/examples directory. Documentation ============= Dirmngr comes with man pages and as well as with a texinfo based manual. Run "info dirmngr" to read the manual or run make -C doc dirmngr.pdf to build a printable version. If you have questions on the use of Dirmngr, feel free to ask at gnupg-users at gnupg.org. Support ======= Improving Dirmngr is costly, but you can help! We are looking for organizations that find Dirmngr useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or by donating money. Commercial support contracts for Dirmngr 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 Dirmngr development. We are always looking for interesting development projects. A service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release. The folks at Intevation helped a lot to track down bugs and to define new features. Marcus Brinkmann is mainly responsible for completing the Windows port. Happy Hacking, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From rdieter at math.unl.edu Thu Jul 31 17:52:14 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 31 Jul 2008 10:52:14 -0500 Subject: [Announce] Dirmngr 1.0.2 released References: <87r69ajjxa.fsf__33608.8929245763$1217510912$gmane$org@wheatstone.g10code.de> Message-ID: Werner Koch wrote: > We are pleased to announce the availability of Dirmngr version 1.0.2. build fails here (fedora 8): ... gcc -I../jnlib -O2 -Wall -o dirmngr-client dirmngr-client.o b64enc.o get-path.o no-libgcrypt.o ../jnlib/libjnlib.a -lassuan -lgpg-error crlcache.o: In function `start_sig_check': /var/tmp/BUILD/dirmngr-1.0.2/src/crlcache.c:1448: undefined reference to `gcry_md_debug' I suspect there's a minimal build dep not satisfied, I'm currently using: libassuan-1.0.4 libgcrypt-1.2.4 libgpg-error-1.5 libksba-1.0.2 -- Rex From wk at gnupg.org Thu Jul 31 18:26:47 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 31 Jul 2008 18:26:47 +0200 Subject: [Announce] Dirmngr 1.0.2 released In-Reply-To: (Rex Dieter's message of "Thu, 31 Jul 2008 10:52:14 -0500") References: <87r69ajjxa.fsf__33608.8929245763$1217510912$gmane$org@wheatstone.g10code.de> Message-ID: <87bq0eggu0.fsf@wheatstone.g10code.de> On Thu, 31 Jul 2008 17:52, rdieter at math.unl.edu said: > In function `start_sig_check': > /var/tmp/BUILD/dirmngr-1.0.2/src/crlcache.c:1448: undefined reference to > `gcry_md_debug' Ooops. However, this is easy to fix: Index: src/crlcache.c =================================================================== --- src/crlcache.c (revision 304) +++ src/crlcache.c (working copy) @@ -1445,7 +1445,13 @@ return err; } if (DBG_HASHING) - gcry_md_debug (*md, "crl"); + { +#ifdef HAVE_GCRY_MD_DEBUG + gcry_md_debug (*md, "hash.cert"); +#else + gcry_md_start_debug (*md, "crl"); +#endif + } ksba_crl_set_hash_function (crl, HASH_FNC, *md); return 0; Most developers today use libgcrypt 1.4 but I hesitated to make this a requirement as too many installations are running 1.2. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From sutter at informatik.hs-furtwangen.de Thu Jul 31 21:38:24 2008 From: sutter at informatik.hs-furtwangen.de (Phil Sutter) Date: Thu, 31 Jul 2008 21:38:24 +0200 Subject: Secret-Sharing: changes to existing code Message-ID: <20080731193824.GC11056@base.freewrt> Hi! After solving my "decrypt shares to internal buffer" issue my proof of concept code now provides all the functionalities I wanted to be available before considering it the right way to go. So with my patched version of gpg I can: * setup an existing secret key for being shared (N is the threshold) | gpg --ss-setup * generate encrypted shares for an existing session | gpg -r -o sharefile --gen-share * list information about a share file | gpg --list-packets sharefile * list information about "open" sharing/recombining sessions | gpg --ss-info * add a share for recombination | gpg --ss-add-share sharefile * clear sharing/recombining metadata | gpg --ss-clear for now, there is no command for explicitly solving a recombining session, as this is done each time after adding a share. The combiner is able to detect whether the secret is already found or not. If so, the secret data is being sent to gpg and imported to the secret keyring. There are more features I could think of: * a way for participants to store shares, and a command to prepare a share for sending it to the combiner (i.e. de- and encrypting it) * finer grained control about what data to clear with --ss-clear (including removal of the secret key itself from the keyring) * maybe some way to automate recombining shares via network (perhaps a task for gpg-server?) * maybe usage of these key-stubs and minimising the data being shared to only the secret key params but as I have to finish my diploma thesis first, from now on I will concentrate on writing. Meanwhile I start sending in code for being reviewed. The attachment contains only the changes to the existing files to keep it simple for now. The rest will follow in chunks after I have fixed all your concerns with this one. Greetings, Phil PS: something in advance: it may well be possible that I messed up indentation in some cases, as it actually is not very consistent throughout the existing code. -------------- next part -------------- Index: configure.ac =================================================================== --- configure.ac (revision 4803) +++ configure.ac (working copy) @@ -132,6 +132,13 @@ AM_CONDITIONAL(GNUPG_SCDAEMON_PGM, test -n "$GNUPG show_gnupg_scdaemon_pgm="(default)" test -n "$GNUPG_SCDAEMON_PGM" && show_gnupg_scdaemon_pgm="$GNUPG_SCDAEMON_PGM" +AC_ARG_WITH(ssd-pgm, + [ --with-ssd-pgm=PATH Use PATH as the default for ssd)], + GNUPG_SSD_PGM="$withval", GNUPG_SSD_PGM="" ) +AC_SUBST(GNUPG_SSD_PGM) +AM_CONDITIONAL(GNUPG_SSD_PGM, test -n "$GNUPG_SSD_PGM") +show_gnupg_ssd_pgm="(default)" +test -n "$GNUPG_SSD_PGM" && show_gnupg_ssd_pgm="$GNUPG_SSD_PGM" AC_ARG_WITH(dirmngr-pgm, [ --with-dirmngr-pgm=PATH Use PATH as the default for the dirmngr)], @@ -158,6 +165,14 @@ AC_ARG_ENABLE(agent-only, AC_HELP_STRING([--enable-agent-only],[build only the gpg-agent]), build_agent_only=$enableval) +# Enable secret-sharing +AC_MSG_CHECKING([whether to enable secret-sharing]) +AC_ARG_ENABLE(secret-sharing, + AC_HELP_STRING([--enable-secret-sharing], + [Enable secret-sharing and build ssd]), + secret_sharing=$enableval, secret_sharing=no) +AC_MSG_RESULT($secret_sharing) + # SELinux support includes tracking of sensitive files to avoid # leaking their contents through processing these files by gpg itself AC_MSG_CHECKING([whether SELinux support is requested]) @@ -971,6 +986,12 @@ if test "$selinux_support" = yes ; then AC_DEFINE(ENABLE_SELINUX_HACKS,1,[Define to enable SELinux support]) fi +# +# support for Secret-Sharing +# +if test "$secret_sharing" = yes ; then + AC_DEFINE(ENABLE_SECRET_SHARING,1,[Define to enable Secret-Sharing]) +fi # # Checks for header files. @@ -1332,11 +1353,16 @@ if test "$build_scdaemon" = "yes"; then fi fi +if test "$enable_secret_sharing" = "yes" ; then + build_ssd=yes +fi + if test "$build_agent_only" = "yes" ; then build_gpg=no build_gpgsm=no build_scdaemon=no + build_ssd=no build_tools=no build_doc=no fi @@ -1346,6 +1372,7 @@ AM_CONDITIONAL(BUILD_GPG, test "$build_gpg" = "y AM_CONDITIONAL(BUILD_GPGSM, test "$build_gpgsm" = "yes") AM_CONDITIONAL(BUILD_AGENT, test "$build_agent" = "yes") AM_CONDITIONAL(BUILD_SCDAEMON, test "$build_scdaemon" = "yes") +AM_CONDITIONAL(BUILD_SSD, test "$build_ssd" = "yes") AM_CONDITIONAL(BUILD_TOOLS, test "$build_tools" = "yes") AM_CONDITIONAL(BUILD_DOC, test "$build_doc" = "yes") AM_CONDITIONAL(BUILD_SYMCRYPTRUN, test "$build_symcryptrun" = "yes") @@ -1436,6 +1463,7 @@ g10/Makefile sm/Makefile agent/Makefile scd/Makefile +ssd/Makefile keyserver/Makefile keyserver/gpg2keys_mailto keyserver/gpg2keys_test @@ -1458,11 +1486,13 @@ echo " S/MIME: $build_gpgsm Agent: $build_agent $build_agent_threaded Smartcard: $build_scdaemon $build_scdaemon_extra + Secret-Sharing: $enable_secret_sharing Protect tool: $show_gnupg_protect_tool_pgm Default agent: $show_gnupg_agent_pgm Default pinentry: $show_gnupg_pinentry_pgm Default scdaemon: $show_gnupg_scdaemon_pgm + Default ssd: $show_gnupg_ssd_pgm Default dirmngr: $show_gnupg_dirmngr_pgm " if test x"$use_regex" != xyes ; then Index: g10/encr-data.c =================================================================== --- g10/encr-data.c (revision 4803) +++ g10/encr-data.c (working copy) @@ -72,7 +72,8 @@ release_dfx_context (decode_filter_ctx_t dfx) * Decrypt the data, specified by ED with the key DEK. */ int -decrypt_data( void *procctx, PKT_encrypted *ed, DEK *dek ) +decrypt_data( void *procctx, PKT_encrypted *ed, + DEK *dek, int (*callback)(iobuf_t, void *) ) { decode_filter_ctx_t dfx; byte *p; @@ -187,7 +188,10 @@ int else iobuf_push_filter ( ed->buf, decode_filter, dfx ); - proc_packets ( procctx, ed->buf ); + if ( callback ) + callback ( ed->buf, procctx ); + else + proc_packets ( procctx, ed->buf ); ed->buf = NULL; if ( ed->mdc_method && dfx->eof_seen == 2 ) rc = gpg_error (GPG_ERR_INV_PACKET); Index: g10/gpgv.c =================================================================== --- g10/gpgv.c (revision 4803) +++ g10/gpgv.c (working copy) @@ -303,7 +303,8 @@ get_override_session_key( DEK *dek, const char *st } /* Stub: */ int -decrypt_data( void *procctx, PKT_encrypted *ed, DEK *dek ) +decrypt_data( void *procctx, PKT_encrypted *ed, DEK *dek, + int (*callback)(iobuf_t, void *) ) { return G10ERR_GENERAL; } @@ -383,3 +384,7 @@ void destroy_dotlock (DOTLOCK h) {} int make_dotlock( DOTLOCK h, long timeout ) { return 0;} int release_dotlock( DOTLOCK h ) {return 0;} void remove_lockfiles(void) {} + +/* Stubs to avoid linking to call-ssd.c */ +int ssd_put_share(u32 *keyid, void *data, u32 len) { return 0; } + Index: g10/mainproc.c =================================================================== --- g10/mainproc.c (revision 4803) +++ g10/mainproc.c (working copy) @@ -63,6 +63,7 @@ struct mainproc_context md_filter_context_t mfx; int sigs_only; /* Process only signatures and reject all other stuff. */ int encrypt_only; /* Process only encryption messages. */ + int shares_only; /* Process only gpg shares (ignored else) */ /* Name of the file with the complete signature or the file with the detached signature. This is currently only used to deduce the @@ -480,7 +481,13 @@ print_pkenc_list( struct kidlist_item *list, int f } } +static int +proc_gpg_share_cb( IOBUF a, void *info ) +{ + return proc_gpg_share_packets( info, a ); +} + static void proc_encrypted( CTX c, PACKET *pkt ) { @@ -555,8 +562,11 @@ proc_encrypted( CTX c, PACKET *pkt ) } else if( !c->dek ) result = G10ERR_NO_SECKEY; - if( !result ) - result = decrypt_data( c, pkt->pkt.encrypted, c->dek ); + if( !result && c->shares_only ) + result = decrypt_data( c, pkt->pkt.encrypted, + c->dek, proc_gpg_share_cb); + else if ( !result ) + result = decrypt_data( c, pkt->pkt.encrypted, c->dek, NULL ); if( result == -1 ) ; @@ -767,6 +777,8 @@ proc_compressed( CTX c, PACKET *pkt ) rc = handle_compressed( c, zd, proc_compressed_cb, c ); else if( c->encrypt_only ) rc = handle_compressed( c, zd, proc_encrypt_cb, c ); + else if( c->shares_only ) + rc = handle_compressed( c, zd, proc_gpg_share_cb, c ); else rc = handle_compressed( c, zd, NULL, NULL ); if( rc ) @@ -775,6 +787,16 @@ proc_compressed( CTX c, PACKET *pkt ) c->last_was_session_key = 0; } +static void +proc_gpg_share( CTX c, PACKET *pkt) +{ + PKT_gpg_share *sh = pkt->pkt.gpg_share; + printf("proc_gpg_share(): handling packet of type %d\n", pkt->pkttype); + + handle_share(c, sh); + free_packet(pkt); +} + /**************** * check the signature * Returns: 0 = valid signature or an error code @@ -1256,6 +1278,18 @@ proc_encryption_packets( void *anchor, IOBUF a ) return rc; } +int +proc_gpg_share_packets( void *anchor, IOBUF a ) +{ + CTX c = xmalloc_clear( sizeof *c ); + int rc; + + c->anchor = anchor; + c->shares_only = 1; + rc = do_proc_packets( c, a ); + xfree( c ); + return rc; +} int do_proc_packets( CTX c, IOBUF a ) @@ -1329,6 +1363,27 @@ do_proc_packets( CTX c, IOBUF a ) default: newpkt = 0; break; } } + else if( c->shares_only ) { + switch( pkt->pkttype ) { + case PKT_PUBLIC_KEY: + case PKT_SECRET_KEY: + case PKT_USER_ID: + case PKT_PLAINTEXT: + case PKT_SIGNATURE: + case PKT_SYMKEY_ENC: + case PKT_ONEPASS_SIG: + case PKT_GPG_CONTROL: + write_status_text( STATUS_UNEXPECTED, "0" ); + rc = G10ERR_UNEXPECTED; + goto leave; + case PKT_PUBKEY_ENC: proc_pubkey_enc( c, pkt ); break; + case PKT_ENCRYPTED: + case PKT_ENCRYPTED_MDC: proc_encrypted( c, pkt ); break; + case PKT_COMPRESSED: proc_compressed( c, pkt ); break; + case PKT_GPG_SHARE: proc_gpg_share(c, pkt); break; + default: newpkt = 0; break; + } + } else { switch( pkt->pkttype ) { case PKT_PUBLIC_KEY: Index: g10/build-packet.c =================================================================== --- g10/build-packet.c (revision 4803) +++ g10/build-packet.c (working copy) @@ -41,6 +41,7 @@ static int do_symkey_enc( IOBUF out, int ctb, PKT_ static int do_pubkey_enc( IOBUF out, int ctb, PKT_pubkey_enc *enc ); static u32 calc_plaintext( PKT_plaintext *pt ); static int do_plaintext( IOBUF out, int ctb, PKT_plaintext *pt ); +static int do_gpg_share( IOBUF out, int ctb, PKT_gpg_share *sh ); static int do_encrypted( IOBUF out, int ctb, PKT_encrypted *ed ); static int do_encrypted_mdc( IOBUF out, int ctb, PKT_encrypted *ed ); static int do_compressed( IOBUF out, int ctb, PKT_compressed *cd ); @@ -122,6 +123,9 @@ build_packet( IOBUF out, PACKET *pkt ) case PKT_PLAINTEXT: rc = do_plaintext( out, ctb, pkt->pkt.plaintext ); break; + case PKT_GPG_SHARE: + rc = do_gpg_share( out, ctb, pkt->pkt.gpg_share ); + break; case PKT_ENCRYPTED: rc = do_encrypted( out, ctb, pkt->pkt.encrypted ); break; @@ -549,6 +553,17 @@ do_plaintext( IOBUF out, int ctb, PKT_plaintext *p return rc; } +static int +do_gpg_share( IOBUF out, int ctb, PKT_gpg_share *sh ) +{ + int rc; + + write_header(out, ctb, calc_gpg_share_len(sh)); + if ((rc = write_gpg_share_pkt(out, sh))) + log_error("do_gpg_share(): could not write share packet: %s\n", + gpg_strerror(rc)); + return rc; +} static int Index: g10/parse-packet.c =================================================================== --- g10/parse-packet.c (revision 4803) +++ g10/parse-packet.c (working copy) @@ -77,6 +77,8 @@ static int parse_mdc( IOBUF inp, int pkttype, uns PACKET *packet, int new_ctb); static int parse_gpg_control( IOBUF inp, int pkttype, unsigned long pktlen, PACKET *packet, int partial ); +static int parse_gpg_share( IOBUF inp, int pkttype, unsigned long pktlen, + PACKET *packet, int partial ); static unsigned short read_16(IOBUF inp) @@ -578,6 +580,9 @@ parse( IOBUF inp, PACKET *pkt, int onlykeypkts, of case PKT_GPG_CONTROL: rc = parse_gpg_control(inp, pkttype, pktlen, pkt, partial ); break; + case PKT_GPG_SHARE: + rc = parse_gpg_share( inp, pkttype, pktlen, pkt, partial ); + break; case PKT_MARKER: rc = parse_marker(inp,pkttype,pktlen); break; @@ -2425,6 +2430,25 @@ parse_mdc( IOBUF inp, int pkttype, unsigned long p return rc; } +static int +parse_gpg_share(iobuf_t inp, int pkttype, + unsigned long pktlen, PACKET *packet, int partial) +{ + PKT_gpg_share *sh; + + packet->pkt.gpg_share = read_gpg_share_pkt(inp, pktlen); + if ((sh = packet->pkt.gpg_share) == NULL) { + log_error("reading share packet failed\n"); + return gpg_error(GPG_ERR_INV_PACKET); + } + + if (list_mode) { + fprintf(listfp, ":gpg share:\n\tkeyid: %08x%08x\n\tshare " + "number: %u\n\tlength: %u\n", sh->keyid[0], + sh->keyid[1], sh->id, sh->len); + } + return 0; +} /* * This packet is internally generated by PGG (by armor.c) to Index: g10/packet.h =================================================================== --- g10/packet.h (revision 4803) +++ g10/packet.h (working copy) @@ -318,6 +318,13 @@ typedef struct { } PKT_plaintext; typedef struct { + u32 len; /* length of share data */ + u32 keyid[2]; /* ID of shared key */ + unsigned char id; /* session internal ID of share */ + char data[1]; /* share data */ +} PKT_gpg_share; + +typedef struct { int control; size_t datalen; char data[1]; @@ -341,6 +348,7 @@ struct packet_struct { PKT_mdc *mdc; /* PKT_MDC */ PKT_ring_trust *ring_trust; /* PKT_RING_TRUST */ PKT_plaintext *plaintext; /* PKT_PLAINTEXT */ + PKT_gpg_share *gpg_share; /* PKT_GPG_SHARE */ PKT_gpg_control *gpg_control; /* PKT_GPG_CONTROL */ } pkt; }; @@ -372,6 +380,7 @@ int proc_signature_packets( void *ctx, iobuf_t a, strlist_t signedfiles, const char *sigfile ); int proc_signature_packets_by_fd ( void *anchor, IOBUF a, int signed_data_fd ); int proc_encryption_packets( void *ctx, iobuf_t a ); +int proc_gpg_share_packets( void *ctx, iobuf_t a ); int list_packets( iobuf_t a ); /*-- parse-packet.c --*/ @@ -484,7 +493,8 @@ int handle_compressed( void *ctx, PKT_compressed * int (*callback)(iobuf_t, void *), void *passthru ); /*-- encr-data.c --*/ -int decrypt_data( void *ctx, PKT_encrypted *ed, DEK *dek ); +int decrypt_data( void *ctx, PKT_encrypted *ed, DEK *dek, + int (*callback)(iobuf_t, void *)); /*-- plaintext.c --*/ int handle_plaintext( PKT_plaintext *pt, md_filter_context_t *mfx, @@ -511,4 +521,10 @@ int update_keysig_packet( PKT_signature **ret_sig, /*-- keygen.c --*/ PKT_user_id *generate_user_id(void); +/*-- share.c --*/ +u32 calc_gpg_share_len(PKT_gpg_share *); +void handle_share(void *, PKT_gpg_share *); +int write_gpg_share_pkt(iobuf_t, PKT_gpg_share *); +PKT_gpg_share *read_gpg_share_pkt(iobuf_t, unsigned long); + #endif /*G10_PACKET_H*/ Index: g10/gpg.c =================================================================== --- g10/gpg.c (revision 4803) +++ g10/gpg.c (working copy) @@ -53,6 +53,7 @@ #include "keyserver-internal.h" #include "exec.h" #include "gc-opt-flags.h" +#include "secret-sharing.h" #if defined(HAVE_DOSISH_SYSTEM) || defined(__CYGWIN__) #define MY_O_BINARY O_BINARY @@ -147,6 +148,11 @@ enum cmd_and_opt_values aCardEdit, aChangePIN, aServer, + aSSSetup, + aSSInfo, + aSSAddShare, + aSSGenShare, + aSSClear, oTextmode, oNoTextmode, @@ -431,6 +437,11 @@ static ARGPARSE_OPTS opts[] = { { aPrimegen, "gen-prime" , 256, "@" }, { aGenRandom, "gen-random", 256, "@" }, { aServer, "server", 256, N_("run in server mode")}, + { aSSSetup, "ss-setup", 0, N_("setup a new secret-sharing")}, + { aSSInfo, "ss-info", 0, N_("retrieve info about secret-sharing")}, + { aSSAddShare, "ss-add-share", 0, N_("add a share to the combiner")}, + { aSSGenShare, "ss-gen-share", 0, N_("generate a new share")}, + { aSSClear, "ss-clear", 0, N_("clear secret-sharing metadata for a key")}, { 301, NULL, 0, N_("@\nOptions:\n ") }, @@ -2158,6 +2169,21 @@ main (int argc, char **argv) set_cmd (&cmd, pargs.r_opt); opt.batch = 1; break; + case aSSSetup: + set_cmd (&cmd, pargs.r_opt); + break; + case aSSInfo: + set_cmd (&cmd, pargs.r_opt); + break; + case aSSAddShare: + set_cmd (&cmd, pargs.r_opt); + break; + case aSSGenShare: + set_cmd (&cmd, pargs.r_opt); + break; + case aSSClear: + set_cmd (&cmd, pargs.r_opt); + break; case oArmor: opt.armor = 1; opt.no_armor=0; break; case oOutput: opt.outfile = pargs.r.ret_str; break; @@ -3937,6 +3963,47 @@ main (int argc, char **argv) xfree(str); } break; + case aSSSetup: + if (argc != 2) + wrong_args("--ss-setup Threshold KeyID"); + { + int thold; + char *endptr; + thold = strtol(*argv, &endptr, 10); + if (strlen(endptr) || thold < 2) + log_error("Threshold needs to be >= 2\n"); + else + ss_setup(thold, *(argv + 1)); + } + //printf("would now setup Secret Sharing for %s\n", *argv); + break; + case aSSInfo: + if (argc > 1) + wrong_args("--ss-info [KeyID]"); + if (argc) + ss_info(*argv); + else + ss_info(NULL); + break; + case aSSAddShare: + if (!argc) + wrong_args("--ss-add-share filename [filename ...]"); + { + int i; + for (i = 0; i < argc; i++) + ss_put_share(argv[i]); + } + break; + case aSSGenShare: + if (argc != 1) + wrong_args("--ss-gen-share KeyID"); + ss_gen_share(*argv, remusr, opt.outfile); + break; + case aSSClear: + if (argc != 1) + wrong_args("--ss-clear KeyID"); + ss_clear(*argv); + break; case aListPackets: opt.list_packets=2; Index: g10/Makefile.am =================================================================== --- g10/Makefile.am (revision 4803) +++ g10/Makefile.am (working copy) @@ -64,6 +64,7 @@ common_source = \ parse-packet.c \ cpr.c \ plaintext.c \ + share.c \ sig-check.c \ keylist.c \ pkglue.c pkglue.h @@ -100,7 +101,9 @@ gpg2_SOURCES = gpg.c \ photoid.c photoid.h \ call-agent.c call-agent.h \ card-util.c \ - exec.c exec.h + exec.c exec.h \ + secret-sharing.c secret-sharing.h \ + call-ssd.c call-ssd.h gpgv2_SOURCES = gpgv.c \ $(common_source) \ Index: common/openpgpdefs.h =================================================================== --- common/openpgpdefs.h (revision 4803) +++ common/openpgpdefs.h (working copy) @@ -43,6 +43,7 @@ typedef enum PKT_ENCRYPTED_MDC = 18, /* Integrity protected encrypted data. */ PKT_MDC = 19, /* Manipulation detection code packet. */ PKT_COMMENT = 61, /* new comment packet (GnuPG specific). */ + PKT_GPG_SHARE = 62, /* internal packet for transfering a share */ PKT_GPG_CONTROL = 63 /* internal control packet (GnuPG specific). */ } pkttype_t; Index: am/cmacros.am =================================================================== --- am/cmacros.am (revision 4803) +++ am/cmacros.am (working copy) @@ -41,6 +41,9 @@ endif if GNUPG_SCDAEMON_PGM AM_CPPFLAGS += -DGNUPG_DEFAULT_SCDAEMON="\"@GNUPG_SCDAEMON_PGM@\"" endif +if GNUPG_SSD_PGM +AM_CPPFLAGS += -DGNUPG_DEFAULT_SSD="\"@GNUPG_SSD_PGM@\"" +endif if GNUPG_DIRMNGR_PGM AM_CPPFLAGS += -DGNUPG_DEFAULT_DIRMNGR="\"@GNUPG_DIRMNGR_PGM@\"" endif Index: Makefile.am =================================================================== --- Makefile.am (revision 4803) +++ Makefile.am (working copy) @@ -54,6 +54,11 @@ scd = scd else scd = endif +if BUILD_SSD +ssd = ssd +else +ssd = +endif if BUILD_TOOLS tools = tools else @@ -72,7 +77,7 @@ tests = tests endif SUBDIRS = m4 gl include jnlib common ${kbx} \ - ${gpg} ${keyserver} ${sm} ${agent} ${scd} ${tools} po ${doc} ${tests} + ${gpg} ${keyserver} ${sm} ${agent} ${scd} ${ssd} ${tools} po ${doc} ${tests} dist_doc_DATA = README -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From thijs at debian.org Mon Jul 28 17:31:06 2008 From: thijs at debian.org (Thijs Kinkhorst) Date: Mon, 28 Jul 2008 15:31:06 -0000 Subject: revision 4603 has reverted 4547? Message-ID: <30af9d3f364b174243b52041408ceb65.squirrel@wm.kinkhorst.nl> Hi, SVN revision 4547 was applied to fix bug #810: http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/configure.ac?root=GnuPG&rev=4547&r1=4538&r2=4547 however, it seems that revision 4603 undoes the change: http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/configure.ac?root=GnuPG&rev=4603&r1=4594&r2=4603 I'm not sure if that was intentional, but at least in 1.4.9 I'm experiencing the bug described in #810 again: build fails when using --enable-minimal in the exact same way. cheers, Thijs From thijs at debian.org Mon Jul 28 17:33:57 2008 From: thijs at debian.org (Thijs Kinkhorst) Date: Mon, 28 Jul 2008 15:33:57 -0000 Subject: revision 4603 has reverted 4547? Message-ID: <200807281406.33074.thijs@debian.org> Hi, SVN revision 4547 was applied to fix bug #810: http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/configure.ac?root=GnuPG&rev=4547&r1=4538&r2=4547 however, it seems that revision 4603 undoes the change: http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/configure.ac?root=GnuPG&rev=4603&r1=4594&r2=4603 I'm not sure if that was intentional, but at least in 1.4.9 I'm experiencing the bug described in #810 again: build fails when using --enable-minimal in the exact same way. cheers, Thijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: not available URL: