From marcus.brinkmann at ruhr-uni-bochum.de Mon Jul 4 19:05:40 2011 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 4 Jul 2011 19:05:40 +0200 Subject: [Announce] libassuan 2.0.2 released Message-ID: <4E11F2E4.7030902@ruhr-uni-bochum.de> Hi, libassuan 2.0.2 is a minor release of libassuan. It provides a shared library which is a dependency of of the upcoming versions of GPGME, GnupG 2.1.x and others. ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.0.2.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.0.2.tar.bz2.sig The sha1sums of these files are: e843fd96b4cb05eb737e465891034229f50469d4 libassuan-2.0.1-2.0.2.diff.bz2 dbcd96e2525d4c3a2da9e8054a06fa517f20a185 libassuan-2.0.2.tar.bz2 74b09f626c67ffe51ba21a38b7bed0ea35112c6b libassuan-2.0.2.tar.bz2.asc Noteworthy changes in version 2.0.2 (2010-06-16) ------------------------------------------------ * A new flag may now be used to convey comments via assuan_transact. * A new flag value may now be used to disable logging. * The gpgcedev.c driver now provides a log device. * It is now possible to overwrite socket and connect functions in struct assuan_system_hooks. * Interface changes relative to the 2.0.1 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ASSUAN_CONVEY_COMMENTS NEW. ASSUAN_NO_LOGGING NEW. assuan_system_hooks_t CHANGED: Added socket and connect members. ASSUAN_SYSTEM_HOOKS_VERSION CHANGED: Bumped to 2. assuan_register_pre_cmd_notify NEW. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From marcus.brinkmann at ruhr-uni-bochum.de Mon Jul 4 19:06:01 2011 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 4 Jul 2011 19:06:01 +0200 Subject: [Announce] GPGME 1.3.1 released Message-ID: <4E11F2F9.9050306@ruhr-uni-bochum.de> Hi, We are pleased to announce version 1.3.1 of GnuPG Made Easy, a library designed to make access to GnuPG easier for applications. It may be found in the file ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.3.1.tar.bz2 ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.3.1.tar.bz2.sig It should soon appear on the mirrors listed at: http://www.gnupg.org/mirrors.html Bug reports and requests for assistance should be sent to: gnupg-devel at gnupg.org The sha1sum checksums for this distibution are 7d19a95a2239da13764dad7f97541be884ec5a37 gpgme-1.3.1.tar.bz2 93316a81a8f903c5b604716b6937884ea7b0917a gpgme-1.3.1.tar.bz2.sig Noteworthy changes in version 1.3.1 (2011-06-16) ------------------------------------------------ * Ported to Windows CE. * Detect GPG versions not supporting ---passwd. * Interface changes relative to the 1.3.0 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GPGME_EXPORT_MODE_MINIMAL NEW GPGME_STATUS_SUCCESS NEW gpgme_err_code_from_syserror NEW gpgme_err_set_errno NEW gpgme_error_from_errno CHANGED: Return gpgme_error_t (compatible type). gpgme_error_from_syserror NEW ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From mb at g10code.com Mon Jul 4 20:35:23 2011 From: mb at g10code.com (Marcus Brinkmann) Date: Mon, 04 Jul 2011 18:35:23 -0000 Subject: [Announce] GPGME 1.3.1 released Message-ID: <4DFA27BB.8090106@g10code.com> Hi, We are pleased to announce version 1.3.1 of GnuPG Made Easy, a library designed to make access to GnuPG easier for applications. It may be found in the file ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.3.1.tar.bz2 ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.3.1.tar.bz2.sig It should soon appear on the mirrors listed at: http://www.gnupg.org/mirrors.html Bug reports and requests for assistance should be sent to: gnupg-devel at gnupg.org The sha1sum checksums for this distibution are 7d19a95a2239da13764dad7f97541be884ec5a37 gpgme-1.3.1.tar.bz2 93316a81a8f903c5b604716b6937884ea7b0917a gpgme-1.3.1.tar.bz2.sig Noteworthy changes in version 1.3.1 (2011-06-16) ------------------------------------------------ * Ported to Windows CE. * Detect GPG versions not supporting ---passwd. * Interface changes relative to the 1.3.0 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GPGME_EXPORT_MODE_MINIMAL NEW GPGME_STATUS_SUCCESS NEW gpgme_err_code_from_syserror NEW gpgme_err_set_errno NEW gpgme_error_from_errno CHANGED: Return gpgme_error_t (compatible type). gpgme_error_from_syserror NEW ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From mb at g10code.com Mon Jul 4 21:15:59 2011 From: mb at g10code.com (Marcus Brinkmann) Date: Mon, 04 Jul 2011 19:15:59 -0000 Subject: [Announce] libassuan 2.0.2 released Message-ID: <4DFA273E.3040807@g10code.com> Hi, libassuan 2.0.2 is a minor release of libassuan. It provides a shared library which is a dependency of of the upcoming versions of GPGME, GnupG 2.1.x and others. ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.0.2.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.0.2.tar.bz2.sig The sha1sums of these files are: e843fd96b4cb05eb737e465891034229f50469d4 libassuan-2.0.1-2.0.2.diff.bz2 dbcd96e2525d4c3a2da9e8054a06fa517f20a185 libassuan-2.0.2.tar.bz2 74b09f626c67ffe51ba21a38b7bed0ea35112c6b libassuan-2.0.2.tar.bz2.asc Noteworthy changes in version 2.0.2 (2010-06-16) ------------------------------------------------ * A new flag may now be used to convey comments via assuan_transact. * A new flag value may now be used to disable logging. * The gpgcedev.c driver now provides a log device. * It is now possible to overwrite socket and connect functions in struct assuan_system_hooks. * Interface changes relative to the 2.0.1 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ASSUAN_CONVEY_COMMENTS NEW. ASSUAN_NO_LOGGING NEW. assuan_system_hooks_t CHANGED: Added socket and connect members. ASSUAN_SYSTEM_HOOKS_VERSION CHANGED: Bumped to 2. assuan_register_pre_cmd_notify NEW. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From ml at schoenitzer.de Fri Jul 8 03:08:32 2011 From: ml at schoenitzer.de (Michael Florian =?iso-8859-1?q?Sch=F6nitzer?=) Date: Fri, 8 Jul 2011 01:08:32 +0000 (UTC) Subject: GPGME Keyserver get_key/sync Message-ID: Hi, I' started writing programs with GPGME some days before, and had no big problems until now. I want to ad some keyserver-synchronization feature to my program. Because GPGME doesn't support this out of the box, I wanted to write it using gpgme_get_key (with GPGME_KEYLIST_MODE_EXT). But I only get and "End of file"-error. Does anyone know what I did wrong or could anyone show me some example code? Best regards, Michi -- Michael F. Sch?nitzer Mail: michael ?t schoenitzer.de From wk at gnupg.org Fri Jul 8 15:03:08 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Jul 2011 15:03:08 +0200 Subject: GPGME Keyserver get_key/sync In-Reply-To: ("Michael Florian =?utf-8?Q?Sc?= =?utf-8?Q?h=C3=B6nitzer=22's?= message of "Fri, 8 Jul 2011 01:08:32 +0000 (UTC)") References: Message-ID: <87hb6w6i2b.fsf@vigenere.g10code.de> On Fri, 8 Jul 2011 03:08, ml at schoenitzer.de said: > wanted to write it using gpgme_get_key (with GPGME_KEYLIST_MODE_EXT). But (It is GPGME_KEYLIST_MODE_EXTERN) > I only get and "End of file"-error. Please try it on the command line. What gpgme does is gpg --search-keys PATTERN it might also use gpg2. If that works, you need to enable gpgme tracing; see the manual. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ml at schoenitzer.de Fri Jul 8 18:07:01 2011 From: ml at schoenitzer.de (Michael Florian =?iso-8859-1?q?Sch=F6nitzer?=) Date: Fri, 8 Jul 2011 16:07:01 +0000 (UTC) Subject: GPGME Keyserver get_key/sync References: <87hb6w6i2b.fsf@vigenere.g10code.de> Message-ID: Am Fri, 08 Jul 2011 15:03:08 +0200 schrieb Werner Koch: > Please try it on the command line. What gpgme does is > > gpg --search-keys PATTERN > > it might also use gpg2. Original my PATTERN was the key-ID in short form. I tried it with gpg --search-keys PATTERN that works but gpg2 didn't work. So I also tried using the long id, that works with gpg and gpg2 but doesn't work with gpgme, too. I also wonder about how fast he gives out the EOF-error, he seams not to connect to the server. > If that works, you need to enable gpgme tracing; see the manual. I'm not familiar with tracing and I also haven't found anything in the manual for now. Thanks for help. Best regards, Michi -- Michael F. Sch?nitzer Mail: michael ?t schoenitzer.de Homepage: http://www.schoenitzer.de Jabber: Schoenitzer at jabber.piratenpartei.de From jeanjacquesbrucker at gmail.com Sun Jul 10 21:07:50 2011 From: jeanjacquesbrucker at gmail.com (Jbar) Date: Sun, 10 Jul 2011 21:07:50 +0200 Subject: new uids don't not appear in my --list-secret-keys Message-ID: <201107102107.53995.jeanjacquesbrucker@gmail.com> Hi, I have a problem : Hi have create new 2 new uids from my PC at the office (my main private key is on both computers), switch main uid to one them, revoked the old uid, then export the updated certificate on the key server, then import it at home. They appear correctly on my certificate with the --list-keys option, but don't appear with the --list-secret-keys option. Is that a bug ? How to make new uids appears in the --list-secret at home ? (to complicated things, I did generated a new signing key at home before, which I don't want to export the secret in my office. as i am playing with money key for the OpenUDC project). Then I noticed a notice a bug on other software : i deleted my old uid at home, the --list-secret-keys option did then show no more uid, which makes crash at least psi jabber client (maybe some other tools using gpg, cleopatra should manage uid without checking the --list-secret as it didn't crash for now). I am using gpg (GnuPG) 2.0.15 and gpg (GnuPG) 1.4.10 (they behave the same with the --list-secret-keys option). Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From jeanjacquesbrucker at gmail.com Mon Jul 11 16:58:47 2011 From: jeanjacquesbrucker at gmail.com (Jean-Jacques Brucker) Date: Mon, 11 Jul 2011 16:58:47 +0200 Subject: new uids don't not appear in my --list-secret-keys In-Reply-To: <201107102107.53995.jeanjacquesbrucker@gmail.com> References: <201107102107.53995.jeanjacquesbrucker@gmail.com> Message-ID: I have found a solution using gpgsplit from the home and the office exports, and then merge (re-concatenate) chunks I want. I note that --list-secret-key option is only usefull to get the private KeyIDs, but not reliable to get uid, and don't provide revocation informations. I will handle that and I understand why revocation information are not displayed with --list-secret-key. But, may one day the --import option auto-merge chunks ? Regards, 2011/7/10 Jbar > Hi, I have a problem : > > Hi have create new 2 new uids from my PC at the office (my main private key > is on both computers), switch main uid to one them, revoked the old > uid, then export the updated certificate on the key server, then import it > at home. > They appear correctly on my certificate with the --list-keys option, but > don't appear with the --list-secret-keys option. > > Is that a bug ? > How to make new uids appears in the --list-secret at home ? > > (to complicated things, I did generated a new signing key at home before, > which I don't want to export the secret in my office. as i am playing with > money key for the OpenUDC project). > > Then I noticed a notice a bug on other software : i deleted my old uid at > home, the --list-secret-keys option did then show no more uid, which > makes crash at least psi jabber client (maybe some other tools using gpg, > cleopatra should manage uid without checking the --list-secret as it > didn't crash for now). > > I am using gpg (GnuPG) 2.0.15 and gpg (GnuPG) 1.4.10 (they behave the same > with the --list-secret-keys option). > > Thanks. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Jul 12 09:41:54 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Jul 2011 09:41:54 +0200 Subject: new uids don't not appear in my --list-secret-keys In-Reply-To: (Jean-Jacques Brucker's message of "Mon, 11 Jul 2011 16:58:47 +0200") References: <201107102107.53995.jeanjacquesbrucker@gmail.com> Message-ID: <87hb6s3pz1.fsf@vigenere.g10code.de> On Mon, 11 Jul 2011 16:58, jeanjacquesbrucker at gmail.com said: > displayed with --list-secret-key. But, may one day the --import option > auto-merge chunks ? 2.1 beta does this. The problem is that we would need to fully sync the secring and the pubring which turned out to be too complicate. 2.1 makes it easier - there is no secring anymore: just the plain key parameters in addition to the public key. I was able to remove a lot of code from gpg. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dirkx at webweaving.org Wed Jul 13 13:36:25 2011 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Wed, 13 Jul 2011 12:36:25 +0100 Subject: Supressing the "gpg: NOTE: trustdb not writable" on read only systems In-Reply-To: References: Message-ID: <439B54CA-AE95-4F05-A1B5-8D11557CC3EF@webweaving.org> Scratching a minor itch (Using gpg a lot on readonly file systems where it is in the path for backups against public keys). In that situation the warning "gpg: NOTE: trustdb not writable" on read only systems comes up regularly (even though we killed off all other warnings with things like below). #!/bin/sh ...something making the backup |\ /usr/local/bin/gpg --yes -q \ -e \ -r XXX -r XX -r XXXX \ --lock-never --no-random-seed-file \ --no-greeting --no-secmem-warning \ --no-auto-check-trustdb |\ /usr/local/bin/gpg --yes -q -s \ --default-key XXXXX \ --lock-never --no-random-seed-file \ --no-greeting --no-secmem-warning \ --no-auto-check-trustdb |\ ssh r651 at 10.11.0.2 some-command-locked-down-in-the-auth-key-file .. error handling Is below patch a good idea. Or are there not so intrusive ways to do this ? Or should this be done clearer - i.e. the trust db is opened read-only always - and only upgraded to RW when we actually want to write to it (which is a lot rarer). Thanks, Dw diff --git a/g10/gpg.c b/g10/gpg.c index 8326ee7..9788f46 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -332,6 +332,8 @@ enum cmd_and_opt_values oNoSigCreateCheck, oAutoCheckTrustDB, oNoAutoCheckTrustDB, + oAutoUpdateTrustDB, + oNoAutoUpdateTrustDB, oPreservePermissions, oDefaultPreferenceList, oDefaultKeyserverURL, @@ -700,6 +702,8 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_s_n (oNoSigCreateCheck, "no-sig-create-check", "@"), ARGPARSE_s_n (oAutoCheckTrustDB, "auto-check-trustdb", "@"), ARGPARSE_s_n (oNoAutoCheckTrustDB, "no-auto-check-trustdb", "@"), + ARGPARSE_s_n (oAutoUpdateTrustDB, "auto-update-trustdb", "@"), + ARGPARSE_s_n (oNoUpdateTrustDB, "no-auto-update-trustdb", "@"), ARGPARSE_s_n (oMergeOnly, "merge-only", "@" ), ARGPARSE_s_n (oAllowSecretKeyImport, "allow-secret-key-import", "@"), ARGPARSE_s_n (oTryAllSecrets, "try-all-secrets", "@"), @@ -2851,6 +2855,8 @@ main (int argc, char **argv) case oNoExpensiveTrustChecks: opt.no_expensive_trust_checks=1; break; case oAutoCheckTrustDB: opt.no_auto_check_trustdb=0; break; case oNoAutoCheckTrustDB: opt.no_auto_check_trustdb=1; break; + case oAutoUpdateTrustDB: opt.no_auto_update_trustdb=0; break; + case oNoAutoUpdateTrustDB: opt.no_auto_update_trustdb=1; break; case oPreservePermissions: opt.preserve_permissions=1; break; case oDefaultPreferenceList: opt.def_preference_list = pargs.r.ret_str; diff --git a/g10/options.h b/g10/options.h index e67d0ce..8ffb3e5 100644 --- a/g10/options.h +++ b/g10/options.h @@ -187,6 +187,7 @@ struct int no_sig_cache; int no_sig_create_check; int no_auto_check_trustdb; + int no_auto_update_trustdb; int preserve_permissions; int no_homedir_creation; struct groupitem *grouplist; diff --git a/g10/tdbio.c b/g10/tdbio.c index 45ec73b..68f643e 100644 --- a/g10/tdbio.c +++ b/g10/tdbio.c @@ -93,6 +93,7 @@ struct cmp_xdir_struct { static char *db_name; +static int db_readonly = 0; static dotlock_t lockhandle; static int is_locked; static int db_fd = -1; @@ -478,10 +479,11 @@ create_version_record (void) int -tdbio_set_dbname( const char *new_dbname, int create ) +tdbio_set_dbname( const char *new_dbname, int create, int _rw ) { char *fname; static int initialized = 0; + db_readonly = _rw ? 0 : 1; if( !initialized ) { atexit( cleanup ); @@ -561,7 +563,7 @@ tdbio_set_dbname( const char *new_dbname, int create ) if( !fp ) log_fatal( _("can't create `%s': %s\n"), fname, strerror(errno) ); fclose(fp); - db_fd = open( db_name, O_RDWR | MY_O_BINARY ); + db_fd = open( db_name, (db_readonly ? O_RDONLY | O_RDWR) | MY_O_BINARY ); if( db_fd == -1 ) log_fatal( _("can't open `%s': %s\n"), db_name, strerror(errno) ); @@ -621,8 +623,12 @@ open_db() wchar_t *wname = utf8_to_wchar (db_name); if (wname) { - db_fd = (int)CreateFile (wname, GENERIC_READ|GENERIC_WRITE, - FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, + db_fd = (int)CreateFile (wname, + GENERIC_READ| + (db_readonly ? 0 : GENERIC_WRITE) | + FILE_SHARE_READ| + (db_readonly ? 0 : FILE_SHARE_WRITE), + NULL, OPEN_EXISTING, 0, NULL); xfree (wname); } @@ -631,7 +637,7 @@ open_db() (int)prevrc, (int)GetLastError ()); } #else /*!HAVE_W32CE_SYSTEM*/ - db_fd = open (db_name, O_RDWR | MY_O_BINARY ); + db_fd = open (db_name, (db_readonly ? O_RDONLY | O_RDWR) | MY_O_BINARY ); if (db_fd == -1 && (errno == EACCES #ifdef EROFS || errno == EROFS From kevhilton at gmail.com Wed Jul 13 23:07:14 2011 From: kevhilton at gmail.com (Kevin Hilton) Date: Wed, 13 Jul 2011 17:07:14 -0400 Subject: PO Compiling errors Message-ID: When trying to compile the STABLE-BRANCH-1-4, I getting an error during the make process within the po directory (gosh how I hate gettext-related errors!!). I'm just wondering if this is because various po files are missing from gnupg or this represents a true gettext error: test -z "en at quot.gmo en at boldquot.gmo be.gmo ca.gmo cs.gmo da.gmo de.gm o eo.gmo el.gmo es.gmo et.gmo fi.gmo fr.gmo gl.gmo hu.gmo id.gmo it.gmo ja.gmo n b.gmo nl.gmo pl.gmo pt_BR.gmo pt.gmo ro.gmo ru.gmo sk.gmo sv.gmo tr.gmo zh_TW.gm o zh_CN.gmo" || make en at quot.gmo en at boldquot.gmo be.gmo ca.gmo cs.gmo da.gmo de. gmo eo.gmo el.gmo es.gmo et.gmo fi.gmo fr.gmo gl.gmo hu.gmo id.gmo it.gmo ja.gmo nb.gmo nl.gmo pl.gmo pt_BR.gmo pt.gmo ro.gmo ru.gmo sk.gmo sv.gmo tr.gmo zh_TW. gmo zh_CN.gmo make[1]: Entering directory `/home/klal/src/gnupg/po' make[2]: Entering directory `/home/klal/src/gnupg/po' make en at quot.po-update make[3]: Entering directory `/home/klal/src/gnupg/po' sed -e '/^#/d' -e 's/HEADER/en at quot.header/g' ./insert-header.sin > en at quot.inse rt-header en at quot: creation of en at quot.po failed! en at quot: msgmerge en at quot.po gnupg.pot -o en at quot.new.po msgmerge: error while opening "en at quot.po" for reading: No such file or director y msgmerge for en at quot.po failed! make[3]: Leaving directory `/home/klal/src/gnupg/po' make[2]: Leaving directory `/home/klal/src/gnupg/po' rm -f en at quot.gmo && /usr/local/bin/msgfmt -c --statistics -o en at quot.gmoen@quo t.po /usr/local/bin/msgfmt: error while opening "en at quot.po" for reading: No such fil e or directory make[1]: *** [en at quot.gmo] Error 1 make[1]: Leaving directory `/home/klal/src/gnupg/po' make: *** [stamp-po] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Jul 14 07:03:48 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 14 Jul 2011 14:03:48 +0900 Subject: NeoG - a random number generator implementation for STM32F103 Message-ID: <4E1E78B4.9000205@fsij.org> Hello, This month, I don't release newer version of Gnuk. Instead, I started a small project, while I seek RNG for Gnuk. Its name is "NeuG". I think that users and developers of GnuPG would have interests on this project, I announce here. NeuG is a set of routines of random number generator (RNG) which is based on physical noise. It supports STM32F103. It can be stand alone USB RNG device (with main routine), too. The NeuG device is seen as starndard USB-CDC device. On GNU/Linux, it is something like /dev/ttyACM0. Configured by stty, $ stty -F /dev/ttyACM0 -echo raw /dev/ttyACM0 becomes random binary stream. The name comes from Japanized English word "noidgy" (from English word "noisy"), where many Japanese (including me) don't distinguish pronunciations of "gee" and "zee". NeuG includes my important letters of "g", "n", and "u", and the word "neu" (German spelling of "new"). My primary intention was to incorporate NeuG routines into Gnuk for random number generation, but the stand alone version could be useful too. Please look at the Git repository of NeuG. http://www.gniibe.org/gitweb?p=neug.git;a=summary While tarball is available as http://www.gniibe.org/download/neug/neug-0.00.tar.gz it doesn't include ChibiOS/RT snapshot (you need to download it yourself). So, Git repo would be better. Your comments are much appreciated. Note that STM32F2xx has built-in TRNG. As I like STM32F103 so much, I need to implement RNG by myself. -- From wk at gnupg.org Thu Jul 14 09:34:54 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Jul 2011 09:34:54 +0200 Subject: PO Compiling errors In-Reply-To: (Kevin Hilton's message of "Wed, 13 Jul 2011 17:07:14 -0400") References: Message-ID: <877h7l1fj5.fsf@vigenere.g10code.de> On Wed, 13 Jul 2011 23:07, kevhilton at gmail.com said: > errors!!). I'm just wondering if this is because various po files are > missing from gnupg or this represents a true gettext error: The required files should all be in the tarball. > sed -e '/^#/d' -e 's/HEADER/en at quot.header/g' ./insert-header.sin > > en at quot.inse > rt-header > en at quot: > creation of en at quot.po failed! The en at quot.po file is generated from the gnupg.pot template by replacing the quote characters. See the ".insert-header.po-update-en" rule in the Makefile. However this is only done if required, i.e. if a source file is newer than a target file. Check that your clock is is setup correctly and that you didn't touch some of the files. If it needs to be build you need to have a decent version of gettext installed. However, as said this should not happen. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From veryconcerneduser at gmail.com Fri Jul 15 21:35:28 2011 From: veryconcerneduser at gmail.com (Concerned User) Date: Fri, 15 Jul 2011 12:35:28 -0700 Subject: PKCS#11 in GnuPG (yes, again!) Message-ID: GnuPG-devel and *especially* WK, As many of you are well-aware, PKCS#11 is the de-facto standard for working with cryptographic keys. Some zealots would try to have you believe that this is only the case outside of the "free software world." (What the bloody heck does that mean, anyway? Since when is free software mutually exclusive to the rest of the planet? What a load.) Most people hold sane ideas about PKCS#11. These people include the developers of illustrious libre-software such as OpenSSL, Mozilla and virtually every piece of GPL'd code that accesses cryptographic keys. Many of you might be thinking "Well, what's the problem, then?" I'll tell you the problem: antiquated ideas. The reason why PKCS#11 is not supported is because of the ideology of one person, Mr. Werner Koch. Long time readers of this list know full well that this is the case as *many* users have written in befuddled by the lack of support only to be confronted by baseless opinion. If the OpenPGP card (a glorious, wonderful piece of kit) is ever going to make it out of almost-complete obscurity, PKCS#11 must be implemented in GnuPG-stable. If we want to push free software in the modern computing world, we must not be stuck in the mud, forsaking globally implemented standards. Currently, there are two projects which seek to remedy this. There is a GPL'd gnupg-pkcs11-scd project which is hardly supported and barely documented. There is also a library from Dr. Peter Koch of smartcard-auth.de which is fully proprietary although (beer) free for OpenPGP card users. Neither solution is befitting of the OpenPGP card or its users. We deserve better. The community and the free software world deserves interoperable software and solutions that can be integrated into favorite projects. To see the hindrance this is causing, one need look no further than: < https://www.privacyfoundation.de/wiki/CryptoStickSoftware#Anwendungen>. Gentlemen and gentlewomen, I hope that you heed my call for reform inside the GnuPG project. It is atrocious that open software and open standards are being fractured into multiple projects, resulting in a hodgepodge of semi-working, poorly documented and hackish solutions. Let us make real progress in the adoption of GnuPG and OpenPGP smart card cryptography by adopting the worldwide standard of PKCS#11. (I am posting this anonymously because the *who* should not matter in this case. Consider this my anonymous treatise now nailed to the door of this project.) Best regards and FSM-speed in fixing this debacle, One VERY Concerned User -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Fri Jul 15 23:15:54 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 15 Jul 2011 14:15:54 -0700 Subject: PKCS#11 in GnuPG (yes, again!) In-Reply-To: References: Message-ID: <80af6d0d020ddd38af7397b3e54855e3@localhost> > As many of you are well-aware, PKCS#11 is the de-facto standard for working > with cryptographic keys. Having worked with PKCS11 a fair bit in a past life and a prior employer, I would say it is one standard of many. PC/SC is also in a good bit of demand. Further, most of the cryptographic tokens I've worked with have actually had their own proprietary APIs, with PKCS11 and/or PC/SC interfaces wrapped on top of them. Some interfaces have been very good: others have been a never-ending river of tears. (Cheap rhetoric implying that anyone who disagrees is a zealot and/or insane omitted. Moving on...) > I'll tell you the problem: antiquated ideas. The reason why PKCS#11 is not > supported is because of the ideology of one person, Mr. Werner Koch. His name is Werner Koch, not Steve Jobs. :) (In other words, "Werner doesn't have anywhere *near* the influence on the technology scene that you seem to think.") > If the OpenPGP card (a glorious, wonderful piece of kit) is ever going to > make it out of almost-complete obscurity, PKCS#11 must be implemented in > GnuPG-stable. ... Let us make real progress in the adoption of GnuPG and > OpenPGP smart card cryptography by adopting the worldwide standard of > PKCS#11. I would recommend reading Shirley Gaw's paper, "Secrecy, Flagging and Paranoia: Adoption Criteria in Encrypted Email" (http://portal.acm.org/citation.cfm?id=1124862). That paper seems to be the definitive treatise on why OpenPGP adoption (including smartcards) has lagged so much. Everybody has their own pet theory on why adoption is lagging. Few of these theories have ever been put to any kind of empirical test. Why should your theory be believed, when there are so many competing ones? Why should your theory be believed, when you haven't even addressed the issues raised in Gaw's paper? From sebastien.lorquet at gmail.com Sat Jul 16 15:18:13 2011 From: sebastien.lorquet at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Sat, 16 Jul 2011 15:18:13 +0200 Subject: PKCS#11 in GnuPG (yes, again!) In-Reply-To: <80af6d0d020ddd38af7397b3e54855e3@localhost> References: <80af6d0d020ddd38af7397b3e54855e3@localhost> Message-ID: Even if I could agree with some of your technical views, I fully disagree with : 1) coward anonymity. What are you afraid of? being rejected yes again? 2) personal attacks towards the maintainer of this project. both of these problems don't build up your credibility and the project's willingness to listen to you. hey, if you want pkcs 11 in gpg, fork, code, publish, maintain, and have something to be proud of. at the moment I can't understand the reason why are you posting to this list. complaining? ranting? whining? seriously? Sebastien -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanxe at gmx.net Sun Jul 17 06:23:59 2011 From: stefanxe at gmx.net (Stefan Xenon) Date: Sun, 17 Jul 2011 12:23:59 +0800 Subject: PKCS#11 in GnuPG (yes, again!) In-Reply-To: <80af6d0d020ddd38af7397b3e54855e3@localhost> References: <80af6d0d020ddd38af7397b3e54855e3@localhost> Message-ID: <4E2263DF.1080709@gmx.net> Am 16.07.2011 05:15, schrieb Robert J. Hansen: >> As many of you are well-aware, PKCS#11 is the de-facto standard for > working >> with cryptographic keys. > > Having worked with PKCS11 a fair bit in a past life and a prior employer, > I would say it is one standard of many. PC/SC is also in a good bit of I don't know PKCS#11 in detail but an interesting project in respect to this discussion is P11 Glue. "This is an effort to use and promote PKCS#11 as glue between crypto libraries and security applications on the open source desktop." http://p11-glue.freedesktop.org/ Not sure how GnuPG fits into this picture... From wk at gnupg.org Mon Jul 18 10:21:24 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Jul 2011 10:21:24 +0200 Subject: PKCS#11 in GnuPG (yes, again!) In-Reply-To: (Concerned User's message of "Fri, 15 Jul 2011 12:35:28 -0700") References: Message-ID: <878vrwxam3.fsf@vigenere.g10code.de> On Fri, 15 Jul 2011 21:35, veryconcerneduser at gmail.com said: > As many of you are well-aware, PKCS#11 is the de-facto standard for working > with cryptographic keys. Some zealots would try to have you believe that PKCS#11 is simply one of many standards. FWIW, even a major desktop OS does not use it anymore. > If the OpenPGP card (a glorious, wonderful piece of kit) is ever going to > make it out of almost-complete obscurity, PKCS#11 must be implemented in > GnuPG-stable. If we want to push free software in the modern computing Please get the facts: There is PKCS#11 support for GnuPG. See http://www.scute.org . The reason why GnuPG does not support smartcards which are only accessible due to proprietary pkcs#11 middleware should be well known: The GPL does not allow for this and even more relevant: We don't want to support proprietary applications. Ask the vendors of those smartcards to release the specs and write a new module for scdaemon; if required. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sebastien.lorquet at gmail.com Mon Jul 18 10:55:09 2011 From: sebastien.lorquet at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Mon, 18 Jul 2011 10:55:09 +0200 Subject: PKCS#11 in GnuPG (yes, again!) In-Reply-To: <878vrwxam3.fsf@vigenere.g10code.de> References: <878vrwxam3.fsf@vigenere.g10code.de> Message-ID: Please get the facts: There is PKCS#11 support for GnuPG. See > http://www.scute.org . > > The reason why GnuPG does not support smartcards which are only > accessible due to proprietary pkcs#11 middleware should be well known: > The GPL does not allow for this and even more relevant: We don't want to > support proprietary applications. Ask the vendors of those smartcards > to release the specs and write a new module for scdaemon; if required. > > nice piece of software, but what about the reverse, eg using other cards with gnupg? What about OpenSC? Was this already discussed in the past? They provide a pkcs11 lib that may be usable. Or is the problem in the PKCS11 API itself? Sebastien -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Jul 18 18:37:32 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Jul 2011 18:37:32 +0200 Subject: PKCS#11 in GnuPG (yes, again!) In-Reply-To: (=?utf-8?Q?=22S=C3=A9bastien?= Lorquet"'s message of "Mon, 18 Jul 2011 10:55:09 +0200") References: <878vrwxam3.fsf@vigenere.g10code.de> Message-ID: <87bowrwnn7.fsf@vigenere.g10code.de> On Mon, 18 Jul 2011 10:55, sebastien.lorquet at gmail.com said: >> The reason why GnuPG does not support smartcards which are only >> accessible due to proprietary pkcs#11 middleware should be well known: >> The GPL does not allow for this and even more relevant: We don't want to >> support proprietary applications. Ask the vendors of those smartcards >> to release the specs and write a new module for scdaemon; if required. >> >> > nice piece of software, but what about the reverse, eg using other cards > with gnupg? That is what my above response is all about about. "proprietary pkcs#11 middleware" is what most vendors call a "pkcs#11 driver". The term driver is usually only used to implement a certain hardware access software. "pkcs#11 driver" often implement much more and sometimes even parts of stuff should be done in the smartcard. > What about OpenSC? Was this already discussed in the past? They provide a Actually GnuPG once used OpenSC to access PKCS#15 structured cards and I wrote the TCOS support for OpenSC. We dropped that because OpenSC is more about creating PKCS#15 structures than to access those structures. PKCS#15 was developed to make access to cards easier. Indeed with about 3000 SLoC we do this now directly in GnuPG (scd/app-p15.c). The problem is only that there are not many PKCS#15 compliant cards and if they are you need to add a few hacks nevertheless. > pkcs11 lib that may be usable. Or is the problem in the PKCS11 API itself? A pretty old fashioned and only partyly specified API. For Scute we even had to write a free replacement for the PKCS#11 header files because at that time no free header files were available. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jul 22 09:43:59 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jul 2011 09:43:59 +0200 Subject: gpg-agent from gnupg-2.0.17 crashes when trying to add ECDSA key In-Reply-To: <4DFC7298.4040509@gmx.net> (Nico's message of "Sat, 18 Jun 2011 11:40:40 +0200") References: <4DFC7298.4040509@gmx.net> Message-ID: <8762muu5ds.fsf@vigenere.g10code.de> On Sat, 18 Jun 2011 11:40, n-roeser at gmx.net said: > The bug is triggered in gnupg-2.0.17/agent/command-ssh.c, line 1410, > which says ?xfree (comment);?. Fix commited, see attached patch. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-crash-while-reading-unsupported-ssh-keys.patch Type: text/x-diff Size: 15933 bytes Desc: not available URL: From nicholas.cole at gmail.com Mon Jul 25 12:31:55 2011 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 25 Jul 2011 11:31:55 +0100 Subject: Building on OS X Lion Message-ID: Dear List, Building 1.4.11 on OS X Lion (Intel Core 2 Duo) fails with the following error: Is this a known problem? Best wishes, Nicholas gcc -g -O2 -Wall -Wno-pointer-sign -o gpg gpg.o build-packet.o compress.o compress-bz2.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-packet.o status.o plaintext.o sig-check.o keylist.o signal.o cardglue.o tlv.o card-util.o app-openpgp.o iso7816.o apdu.o ccid-driver.o pkclist.o skclist.o pubkey-enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdbio.o delkey.o keygen.o pipemode.o helptext.o keyserver.o photoid.o exec.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -liconv ../intl/libintl.a -liconv -Wl,-framework -Wl,CoreFoundation -lz -lbz2 -L/opt/local/lib -lusb Undefined symbols for architecture x86_64: "_iconv_open", referenced from: _utf8_to_native in libutil.a(strgutil.o) _native_to_utf8 in libutil.a(strgutil.o) _set_native_charset in libutil.a(strgutil.o) __nl_find_msg in libintl.a(dcigettext.o) "_iconv", referenced from: _utf8_to_native in libutil.a(strgutil.o) _native_to_utf8 in libutil.a(strgutil.o) __nl_find_msg in libintl.a(dcigettext.o) "_iconv_close", referenced from: _utf8_to_native in libutil.a(strgutil.o) _native_to_utf8 in libutil.a(strgutil.o) _set_native_charset in libutil.a(strgutil.o) ld: symbol(s) not found for architecture x86_64 From nicholas.cole at gmail.com Mon Jul 25 17:38:59 2011 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 25 Jul 2011 16:38:59 +0100 Subject: Building on OS X Lion In-Reply-To: References: Message-ID: On Mon, Jul 25, 2011 at 11:31 AM, Nicholas Cole wrote: > Dear List, > > Building 1.4.11 on OS X Lion (Intel Core 2 Duo) fails with the following error: > > Is this a known problem? My mistake - I think I might have had some 3rd party libraries confusing the build process! N From nicholas.cole at gmail.com Mon Jul 25 17:40:52 2011 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 25 Jul 2011 16:40:52 +0100 Subject: Building on OS X Lion In-Reply-To: References: Message-ID: On Mon, Jul 25, 2011 at 4:38 PM, Nicholas Cole wrote: > On Mon, Jul 25, 2011 at 11:31 AM, Nicholas Cole wrote: >> Dear List, >> >> Building 1.4.11 on OS X Lion (Intel Core 2 Duo) fails with the following error: >> >> Is this a known problem? > > My mistake - I think I might have had some 3rd party libraries > confusing the build process! But a rebuilt gpg is still failing with this error: nicholas$ gpg --card-status gpg(97903) malloc: *** mmap(size=2608166010582208512) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug gpg: out of memory while allocating 26 bytes From alex at gpgtools.org Mon Jul 25 17:44:07 2011 From: alex at gpgtools.org (Alex (via GPGTools)) Date: Mon, 25 Jul 2011 17:44:07 +0200 Subject: Building on OS X Lion In-Reply-To: References: Message-ID: Hi Nicholas, actually, I've the same issue when compiling MacGPG1 on Lion using this script: https://github.com/GPGTools/MacGPG1/blob/master/build-script.sh (also removed the ppc part) Best regards, Alex On Mon, Jul 25, 2011 at 17:38, Nicholas Cole wrote: > On Mon, Jul 25, 2011 at 11:31 AM, Nicholas Cole wrote: >> Dear List, >> >> Building 1.4.11 on OS X Lion (Intel Core 2 Duo) fails with the following error: >> >> Is this a known problem? > > My mistake - I think I might have had some 3rd party libraries > confusing the build process! > > N > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -- gpgtools.org From wk at gnupg.org Mon Jul 25 17:49:48 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Jul 2011 17:49:48 +0200 Subject: Building on OS X Lion In-Reply-To: (Nicholas Cole's message of "Mon, 25 Jul 2011 11:31:55 +0100") References: Message-ID: <87sjpuqs0z.fsf@vigenere.g10code.de> On Mon, 25 Jul 2011 12:31, nicholas.cole at gmail.com said: > ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -liconv ^^^^^^^ > ../intl/libintl.a -liconv -Wl,-framework -Wl,CoreFoundation -lz ^^^^^^^ It seems ld doesn't re-scan libiconv again and messes up entirely. Is the GNU ld or the system's ld? Try manual linking without the first -liconv . Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Mon Jul 25 18:20:30 2011 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 25 Jul 2011 17:20:30 +0100 Subject: Building on OS X Lion In-Reply-To: <87sjpuqs0z.fsf@vigenere.g10code.de> References: <87sjpuqs0z.fsf@vigenere.g10code.de> Message-ID: On Mon, Jul 25, 2011 at 4:49 PM, Werner Koch wrote: > On Mon, 25 Jul 2011 12:31, nicholas.cole at gmail.com said: > >> ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -liconv > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^^^^^^^ >> ../intl/libintl.a -liconv ?-Wl,-framework -Wl,CoreFoundation ?-lz > ? ? ? ? ? ? ? ? ? ?^^^^^^^ > It seems ld doesn't re-scan libiconv again and messes up entirely. ?Is > the GNU ld or the system's ld? Dear Warner, The system ld. Macintosh-2:gnupg-1.4.11 nicholas$ ld -v @(#)PROGRAM:ld PROJECT:ld64-123.2.1 llvm version 3.0svn, from Apple Clang 2.1 (build 163.7.1) Best wishes, Nicholas From wk at gnupg.org Mon Jul 25 18:26:06 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Jul 2011 18:26:06 +0200 Subject: Building on OS X Lion In-Reply-To: (Nicholas Cole's message of "Mon, 25 Jul 2011 16:40:52 +0100") References: Message-ID: <87k4b6qqch.fsf@vigenere.g10code.de> On Mon, 25 Jul 2011 17:40, nicholas.cole at gmail.com said: > nicholas$ gpg --card-status > gpg(97903) malloc: *** mmap(size=2608166010582208512) failed (error code=12) That is probably a bug in the pcsc code: We dlopen the pcsc library and have our own prototypes for the functions. However we use "unsigned long" instead of the "DWORD" type Windows originally used. Thus we have a 64/32 bit mismatch if tyhe pcsc library is 32 bit. See also https://bugs.gnupg.org/gnupg/issue1358 . Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at JABBERWOCKY.COM Mon Jul 25 18:10:38 2011 From: dshaw at JABBERWOCKY.COM (David Shaw) Date: Mon, 25 Jul 2011 12:10:38 -0400 Subject: Building on OS X Lion In-Reply-To: References: Message-ID: <2B911886-CE4E-42CD-A32F-099D46BB9936@jabberwocky.com> On Jul 25, 2011, at 11:40 AM, Nicholas Cole wrote: > On Mon, Jul 25, 2011 at 4:38 PM, Nicholas Cole wrote: >> On Mon, Jul 25, 2011 at 11:31 AM, Nicholas Cole wrote: >>> Dear List, >>> >>> Building 1.4.11 on OS X Lion (Intel Core 2 Duo) fails with the following error: >>> >>> Is this a known problem? >> >> My mistake - I think I might have had some 3rd party libraries >> confusing the build process! > > But a rebuilt gpg is still failing with this error: > > nicholas$ gpg --card-status > gpg(97903) malloc: *** mmap(size=2608166010582208512) failed (error code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > gpg: out of memory while allocating 26 bytes Interesting. 2608166010582208512 in binary is 10010000110010000100010010101100000000000000000001000000000000. Looks like the lower 32 bits are correct (being equal to 4096, which makes sense in this context), but the upper 32 bits are uninitialized or otherwise mangled. I haven't upgraded to Lion yet, so I can't easily run this myself, but can you get a backtrace via gdb? Just run gpg under gdb, and "break malloc_error_break", then "run --card-status". It'll stop at the breakpoint, and you can then do "bt full". David From sebastien.lorquet at gmail.com Mon Jul 25 21:26:35 2011 From: sebastien.lorquet at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Mon, 25 Jul 2011 21:26:35 +0200 Subject: Building on OS X Lion In-Reply-To: <87k4b6qqch.fsf@vigenere.g10code.de> References: <87k4b6qqch.fsf@vigenere.g10code.de> Message-ID: Hi, some work was done recently in pcsclite regarding 64-bit compatibility. Contacting Ludovic Rousseau on the pcsclite mailing list might be a good thing. Regards Sebastien Lorquet On Mon, Jul 25, 2011 at 6:26 PM, Werner Koch wrote: > On Mon, 25 Jul 2011 17:40, nicholas.cole at gmail.com said: > > > nicholas$ gpg --card-status > > gpg(97903) malloc: *** mmap(size=2608166010582208512) failed (error > code=12) > > That is probably a bug in the pcsc code: We dlopen the pcsc library and > have our own prototypes for the functions. However we use "unsigned > long" instead of the "DWORD" type Windows originally used. Thus we > have a 64/32 bit mismatch if tyhe pcsc library is 32 bit. > > See also https://bugs.gnupg.org/gnupg/issue1358 . > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > _______________________________________________ > 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 nicholas.cole at gmail.com Mon Jul 25 22:58:46 2011 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 25 Jul 2011 21:58:46 +0100 Subject: Building on OS X Lion In-Reply-To: <2B911886-CE4E-42CD-A32F-099D46BB9936@jabberwocky.com> References: <2B911886-CE4E-42CD-A32F-099D46BB9936@jabberwocky.com> Message-ID: On Mon, Jul 25, 2011 at 5:10 PM, David Shaw wrote: > On Jul 25, 2011, at 11:40 AM, Nicholas Cole wrote: > >> On Mon, Jul 25, 2011 at 4:38 PM, Nicholas Cole wrote: >>> On Mon, Jul 25, 2011 at 11:31 AM, Nicholas Cole wrote: >>>> Dear List, >>>> >>>> Building 1.4.11 on OS X Lion (Intel Core 2 Duo) fails with the following error: >>>> >>>> Is this a known problem? >>> >>> My mistake - I think I might have had some 3rd party libraries >>> confusing the build process! >> >> But a rebuilt gpg is still failing with this error: >> >> nicholas$ gpg --card-status >> gpg(97903) malloc: *** mmap(size=2608166010582208512) failed (error code=12) >> *** error: can't allocate region >> *** set a breakpoint in malloc_error_break to debug >> gpg: out of ?memory while allocating 26 bytes > > Interesting. ?2608166010582208512 in binary is 10010000110010000100010010101100000000000000000001000000000000. ?Looks like the lower 32 bits are correct (being equal to 4096, which makes sense in this context), but the upper 32 bits are uninitialized or otherwise mangled. > > I haven't upgraded to Lion yet, so I can't easily run this myself, but can you get a backtrace via gdb? ?Just run gpg under gdb, and "break malloc_error_break", then "run --card-status". ?It'll stop at the breakpoint, and you can then do "bt full". Dear David, I hope that the following output is useful! Best wishes, Nicholas Macintosh-2:gnupg-1.4.11 nicholas$ gdb ./g10/gpg GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul 1 10:50:06 UTC 2011) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ...... done (gdb) break malloc_error_break Function "malloc_error_break" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (malloc_error_break) pending. (gdb) run --card-status Starting program: /Users/nicholas/Downloads/gnupg-1.4.11/g10/gpg --card-status Reading symbols for shared libraries +++++............................... done Breakpoint 1 at 0x7fff8f0606c0 Pending breakpoint 1 - "malloc_error_break" resolved Reading symbols for shared libraries . done gpg(20035) malloc: *** mmap(size=2608166010582208512) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Breakpoint 1, 0x00007fff8f0606c0 in malloc_error_break () (gdb) bt full #0 0x00007fff8f0606c0 in malloc_error_break () No symbol table info available. #1 0x00007fff8f023477 in szone_error () No symbol table info available. #2 0x00007fff8f025404 in allocate_pages () No symbol table info available. #3 0x00007fff8f025ba4 in large_malloc () No symbol table info available. #4 0x00007fff8f02bdee in szone_malloc_should_clear () No symbol table info available. #5 0x00007fff8f0603c8 in malloc_zone_malloc () No symbol table info available. #6 0x00007fff8f0611a4 in malloc () No symbol table info available. #7 0x000000010009aaad in xmalloc (n=4296171520) at memory.c:443 p = 0x0 #8 0x00000001000417f2 in open_pcsc_reader_direct [inlined] () at apdu.c:1499 nreader = 2608166010582204441 slot = 0 err = 0 list = 0x0 #9 0x00000001000417f2 in open_pcsc_reader [inlined] () at /Users/nicholas/Downloads/gnupg-1.4.11/g10/apdu.c:1785 nreader = 2608166010582204441 slot = 0 err = 0 list = 0x0 #10 0x00000001000417f2 in apdu_open_reader (portstr=0x0) at apdu.c:2463 nreader = 2608166010582204441 slot = 0 err = 0 list = 0x0 #11 0x000000010002d339 in open_card () at cardglue.c:453 No locals. #12 0x000000010002f323 in agent_learn (info=0x7fff5fbff0f0) at cardglue.c:874 stamp = 140735592927652 serial = 0x7fff5fbff0b0 "" app = (app_t) 0x0 ctrl = { status_cb = 0x10012a268, status_cb_arg = 0xa8 } rc = #13 0x0000000100030e50 in card_status (fp=0x7fff7ca664e8, serialno=0x0, serialnobuflen=0) at card-util.c:369 info = { error = 1221232, apptype = 0x100129a00 "", serialno = 0xffffffffffffffe0
, disp_name = 0x5
, disp_lang = 0x100126000 "", disp_sex = 8192, pubkey_url = 0x7fff5fbff1b0 "", login_data = 0x7fff8f0275c3 "A??P\b", private_do = {0x1002fc080 "", 0xad
, 0x0, 0x40000000
}, cafpr1valid = -32 '?', cafpr2valid = -15 '?', cafpr3valid = -65 '?', cafpr1 = "_?\000\000?u\002??\000\000??/\000\001\000", cafpr2 = "\000?\000\000\000\000\000\000\000\000\000 \000\001\000\000\000?\000", cafpr3 = "\000\000\000\000\000\000\000 \000\001\000\000\000@\000\000\000\000\000", fpr1valid = 0 '\0', fpr2valid = 1 '\001', fpr3valid = 0 '\0', fpr1 = "\000\000\000\000\000\000? \000\001\000\000\000\000\000 \000\001", fpr2 = "\000\000?? \000\001\000\000\000\000`\022\000\001\000\000\000??", fpr3 = " \000\001\000\000\000\b? \000\001\000\000\000\000\000\000\000\000", fpr1time = 1204224, fpr2time = 1, fpr3time = 64, sig_counter = 140734799802928, chv1_cached = -1895430263, is_v2 = 32767, chvmaxlen = {0, 0, 0}, chvretry = {0, 64, 0}, key_attr = {{ algo = 0, nbits = 0 }, { algo = 2140680, nbits = 1 }, { algo = 0, nbits = 0 }}, extcap = { ki = 0, aac = 0 } } uval = 0 rc = 2140680 thefpr = (const unsigned char *) 0x0 #14 0x0000000100007b19 in main (argc=0, argv=0x7fff5fbff970) at gpg.c:3926 remusr = (STRLIST) 0x0 nrings = (STRLIST) 0x0 configname = 0x0 sl = (STRLIST) 0x0 cmd = aCardStatus orig_argc = 2 default_configname = 0x0 locusr = (STRLIST) 0x0 sec_nrings = (STRLIST) 0x0 configlineno = 228 orig_argv = (char **) 0x7fff5fbff960 a = (IOBUF) 0x0 pargs = { argc = 0x7fff5fbff61c, argv = 0x7fff5fbff610, flags = 32769, err = 0, r_opt = 0, r_type = 0, r = { ret_int = 0, ret_long = 0, ret_ulong = 0, ret_str = 0x0 }, internal = { idx = 2, inarg = 0, stopped = 0, last = 0x7fff5fbffab7 "--card-status", aliases = 0x0, cur_alias = 0x0 } } may_coredump = 0 afx = { refcount = 0, what = 0, only_keyblocks = 0, hdrlines = 0x0, no_openpgp_data = 0, inp_checked = 0, inp_bypass = 0, in_cleartext = 0, not_dash_escaped = 0, hashes = 0, faked = 0, truncated = 0, qp_detected = 0, pgp2mode = 0, eol = "\000\000", buffer = 0x0, buffer_size = 0, buffer_len = 0, buffer_pos = 0, radbuf = "\000\000\000", idx = 0, idx2 = 0, crc = 0, status = 0, cancel = 0, any_data = 0, pending_lf = 0 } rc = 0 (gdb) From dshaw at jabberwocky.com Tue Jul 26 05:22:10 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 25 Jul 2011 23:22:10 -0400 Subject: Building on OS X Lion In-Reply-To: References: <2B911886-CE4E-42CD-A32F-099D46BB9936@jabberwocky.com> Message-ID: <5F6E9E8C-A6EE-4CC8-9348-F4D873D8A325@jabberwocky.com> On Jul 25, 2011, at 4:58 PM, Nicholas Cole wrote: > On Mon, Jul 25, 2011 at 5:10 PM, David Shaw wrote: >> On Jul 25, 2011, at 11:40 AM, Nicholas Cole wrote: >> >>> On Mon, Jul 25, 2011 at 4:38 PM, Nicholas Cole wrote: >>>> On Mon, Jul 25, 2011 at 11:31 AM, Nicholas Cole wrote: >>>>> Dear List, >>>>> >>>>> Building 1.4.11 on OS X Lion (Intel Core 2 Duo) fails with the following error: >>>>> >>>>> Is this a known problem? >>>> >>>> My mistake - I think I might have had some 3rd party libraries >>>> confusing the build process! >>> >>> But a rebuilt gpg is still failing with this error: >>> >>> nicholas$ gpg --card-status >>> gpg(97903) malloc: *** mmap(size=2608166010582208512) failed (error code=12) >>> *** error: can't allocate region >>> *** set a breakpoint in malloc_error_break to debug >>> gpg: out of memory while allocating 26 bytes >> >> Interesting. 2608166010582208512 in binary is 10010000110010000100010010101100000000000000000001000000000000. Looks like the lower 32 bits are correct (being equal to 4096, which makes sense in this context), but the upper 32 bits are uninitialized or otherwise mangled. >> >> I haven't upgraded to Lion yet, so I can't easily run this myself, but can you get a backtrace via gdb? Just run gpg under gdb, and "break malloc_error_break", then "run --card-status". It'll stop at the breakpoint, and you can then do "bt full". > > Dear David, > > I hope that the following output is useful! Werner spotted it earlier. This looks like a 32-bit/64-bit mismatch between gpg and pcsc. It's an open bug at https://bugs.gnupg.org/gnupg/issue1358 David From martin at martinpaljak.net Tue Jul 26 07:57:18 2011 From: martin at martinpaljak.net (Martin Paljak) Date: Tue, 26 Jul 2011 08:57:18 +0300 Subject: Building on OS X Lion In-Reply-To: <87k4b6qqch.fsf@vigenere.g10code.de> References: <87k4b6qqch.fsf@vigenere.g10code.de> Message-ID: <861990B8-0C32-44D8-82D6-F563067E4364@martinpaljak.net> On Jul 25, 2011, at 7:26 PM, Werner Koch wrote: > On Mon, 25 Jul 2011 17:40, nicholas.cole at gmail.com said: > >> nicholas$ gpg --card-status >> gpg(97903) malloc: *** mmap(size=2608166010582208512) failed (error code=12) > > That is probably a bug in the pcsc code: We dlopen the pcsc library and > have our own prototypes for the functions. However we use "unsigned > long" instead of the "DWORD" type Windows originally used. Thus we > have a 64/32 bit mismatch if tyhe pcsc library is 32 bit. Why don't you use the provided .h files? Martin From wk at gnupg.org Tue Jul 26 10:47:40 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Jul 2011 10:47:40 +0200 Subject: Building on OS X Lion In-Reply-To: <861990B8-0C32-44D8-82D6-F563067E4364@martinpaljak.net> (Martin Paljak's message of "Tue, 26 Jul 2011 08:57:18 +0300") References: <87k4b6qqch.fsf@vigenere.g10code.de> <861990B8-0C32-44D8-82D6-F563067E4364@martinpaljak.net> Message-ID: <87pqkxpgwj.fsf@vigenere.g10code.de> On Tue, 26 Jul 2011 07:57, martin at martinpaljak.net said: >> have a 64/32 bit mismatch if tyhe pcsc library is 32 bit. > Why don't you use the provided .h files? Because that adds yet another dependency to GnuPG and I try to avoid this. Actually many people are better off not to use PC/SC but the internal driver. This is the reason why PCSC and the old ctAPI are dlopened. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Tue Jul 26 11:29:24 2011 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 26 Jul 2011 10:29:24 +0100 Subject: gpg card on OS X Lion Message-ID: Dear Lists, I am not sure how to go about de-bugging this issue. I'm trying to get an openpgp card to work on OS X Lion. The first issue is a bug in gpg related to a 64-bit and 32-bit incompatibility (the gpg developers are aware of this). I've therefore tried building a 32-bit only version of gpg. However, this still fails with the following error gpg --card-status gpg: detected reader `Gemplus GemPC Key 00 00' gpg: pcsc_connect failed: unpowered card (0x80100067) gpg: apdu_send_simple(0) failed: general error Please insert the card and hit return or enter 'c' to cancel: c gpg: selecting openpgp failed: general error gpg: OpenPGP card not available: general error I remember a similar problem when 10.5 came out, which at the time I fixed by removing one of Apple's drivers ( /System/Library/Security/tokend/BELPIC.tokend ) I did file a bug report with Apple, though I never got to the bottom of what the actual problem was. That file no longer exists, however. What should I do to go about helping to track down this issue? Best wishes, Nicholas From gnupg+Steven.Murdoch at cl.cam.ac.uk Wed Jul 27 17:36:41 2011 From: gnupg+Steven.Murdoch at cl.cam.ac.uk (Steven J. Murdoch) Date: Wed, 27 Jul 2011 16:36:41 +0100 Subject: [PATCH] Allow signing of files which are not present on the system Message-ID: <20110727153640.GA1074@ramsey.cl.cam.ac.uk> For a particular use case of GnuPG, I needed to sign a number of files which were not on the same machine as the private key. It would be insecure to upload the private key to the machine with the files, and it would take a very long time to download all the files to the machine with the private key. I've written a patch which does this (attached), but I'd like to find out whether this (after some cleaning up), would be considered for acceptance? Options I looked at included forwarding gpg-agent over SSH, but gpg-agent still requires having the private key on the machine doing the signing. I therefore looked into signing a hash of the file, as suggested here: http://lists.gnupg.org/pipermail/gnupg-devel/2004-May/021010.html It turned out to be a bit more complicated than that mail suggested, because GnuPG appends a footer to the file to be signed, before calculating the hash which is actually signed. This footer includes a timestamp, so is different each time. Therefore, I don't think it is possible to sign a file, given only the hash of that file. My solution was to modify --print-md to output the intermediate state of the hash calculation, after hashing the file but before finalizing the hash. Then I modified --sign so that it will accept this intermediate state as input. To use it, on the system with the files you want to sign, run: $ gpg --with-colons --print-md sha256 FILENAME | cut -f 4 -d ':' where FILENAME is the name of the file you want to sign. This will output the intermediate state of the message digest needed to calculate a SHA256 signature. On the system with your private key run: $ gpg --use-agent --load-md-state STATE --personal-digest-preferences sha256 --detach-sign --output OUTPUT < /dev/null where STATE is the intermediate state output by the command above, and OUTPUT is where you want to save the signature. The attached patch (on GnuPG 1.4.11) works, but needs some cleaning up before it could be merged. My question is whether this feature would be considered for acceptance by the GnuPG team? I would also like feedback on both the feature design and patch code. Steven. -- http://www.cl.cam.ac.uk/users/sjm217/ -------------- next part -------------- >From b927f2e7fd426bd593eb5a2809ec9a44cf400e93 Mon Sep 17 00:00:00 2001 From: Steven Murdoch Date: Mon, 25 Jul 2011 22:18:12 +0100 Subject: [PATCH] Allow signing of files which are not present on the system This change allows GnuPG to sign files which are not present on the same system as where the keys are stored. This is achieved by: - --print-md --with-colons outputs the message digest state as the 4th colon-delimited item. - --load-md-state STATE used in combination with --detach-sign replaces the digest state with the value specified on the command line, before calculating the digital signature Typical usage is: $ gpg --with-colons --print-md SHA256 tmp.txt $ gpg --load-md-state 67[...]00 --output tmp.sig \ --personal-digest-preferences SHA256 --detach-sign < /dev/null --- cipher/md.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ g10/gpg.c | 38 ++++++++++++++++++++++---------- g10/main.h | 3 +- g10/options.h | 1 + g10/sign.c | 13 ++++++---- include/cipher.h | 2 + 6 files changed, 103 insertions(+), 18 deletions(-) diff --git a/cipher/md.c b/cipher/md.c index 9ee0fa7..b2d6c16 100644 --- a/cipher/md.c +++ b/cipher/md.c @@ -237,6 +237,70 @@ md_enable( MD_HANDLE h, int algo ) (*ac->init)( &ac->context.c ); } +static void +md_load_string(byte *state, const char *replacement) +{ + int pos=0; + int shift; + char c; + byte *r = (byte *)state; + + while (replacement[pos]) { + c = replacement[pos]; + if (pos % 2 == 0) { + r[pos/2] = 0; + shift = 4; + } else { + shift = 0; + } + if (c >= '0' && c <= '9') + r[pos/2] |= (c - '0') << shift; + else if (c >= 'A' && c <= 'F') + r[pos/2] |= (c - 'A' + 10) << shift; + else if (c >= 'a' && c <= 'f') + r[pos/2] |= (c - 'a' + 10) << shift; + pos ++; + } +} + +void +md_load(MD_HANDLE a, int algo, const char *b) +{ + struct md_digest_list_s *r; + + if( !algo ) { /* return the first algorithm */ + if( (r=a->list) ) { + if( r->next ) + log_debug("more than algorithm in md_load(0)\n"); + md_load_string(r->context.c, b); + return; + } + } + else { + for(r=a->list; r; r = r->next ) { + if( r->algo == algo ) { + md_load_string(r->context.c, b); + return; + } + } + } + BUG(); +} + +char * +md_dump(MD_HANDLE a, int algo) +{ + struct md_digest_list_s *ar; + + if( a->bufcount ) + md_write( a, NULL, 0 ); + for( ar=a->list; ar; ar = ar->next ) { + if( ar->algo == algo ) + return bin2hex((void *)ar->context.c, ar->contextsize, + NULL); + } + BUG(); +} MD_HANDLE md_copy( MD_HANDLE a ) diff --git a/g10/gpg.c b/g10/gpg.c index 0142168..4ef9f1b 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -372,6 +372,7 @@ enum cmd_and_opt_values oDisableDSA2, oAllowMultipleMessages, oNoAllowMultipleMessages, + oLoadMDState, oNoop }; @@ -719,6 +720,7 @@ static ARGPARSE_OPTS opts[] = { { oDisableDSA2, "disable-dsa2", 0, "@"}, { oAllowMultipleMessages, "allow-multiple-messages", 0, "@"}, { oNoAllowMultipleMessages, "no-allow-multiple-messages", 0, "@"}, + { oLoadMDState, "load-md-state", 2, "@"}, /* These two are aliases to help users of the PGP command line product use gpg with minimal pain. Many commands are common @@ -2887,6 +2889,8 @@ main (int argc, char **argv ) case oNoAllowMultipleMessages: opt.flags.allow_multiple_messages=0; break; + case oLoadMDState: + opt.load_md_state = pargs.r.ret_str; break; case oNoop: break; @@ -3441,7 +3445,7 @@ main (int argc, char **argv ) strcpy(sl->d, fname); } } - if( (rc = sign_file( sl, detached_sig, locusr, 0, NULL, NULL)) ) + if( (rc = sign_file( sl, detached_sig, locusr, 0, NULL, NULL, opt.load_md_state)) ) log_error("signing failed: %s\n", g10_errstr(rc) ); free_strlist(sl); break; @@ -3455,7 +3459,7 @@ main (int argc, char **argv ) } else sl = NULL; - if( (rc = sign_file(sl, detached_sig, locusr, 1, remusr, NULL)) ) + if( (rc = sign_file(sl, detached_sig, locusr, 1, remusr, NULL, opt.load_md_state)) ) log_error("%s: sign+encrypt failed: %s\n", print_fname_stdin(fname), g10_errstr(rc) ); free_strlist(sl); @@ -3479,7 +3483,7 @@ main (int argc, char **argv ) } else sl = NULL; - if( (rc = sign_file(sl, detached_sig, locusr, 2, remusr, NULL)) ) + if( (rc = sign_file(sl, detached_sig, locusr, 2, remusr, NULL, opt.load_md_state)) ) log_error("%s: symmetric+sign+encrypt failed: %s\n", print_fname_stdin(fname), g10_errstr(rc) ); free_strlist(sl); @@ -4107,7 +4111,7 @@ print_hex( MD_HANDLE md, int algo, const char *fname ) } static void -print_hashline( MD_HANDLE md, int algo, const char *fname ) +print_hashline( MD_HANDLE md, int algo, const char *fname, const char *md_state ) { int i, n; const byte *p; @@ -4126,6 +4130,10 @@ print_hashline( MD_HANDLE md, int algo, const char *fname ) n = md_digest_length(algo); for(i=0; i < n ; i++, p++ ) printf("%02X", *p ); + if (md_state) { + putchar(':'); + printf("%s", md_state); + } putchar(':'); putchar('\n'); } @@ -4180,21 +4188,25 @@ print_mds( const char *fname, int algo ) if( ferror(fp) ) log_error("%s: %s\n", fname?fname:"[stdin]", strerror(errno) ); else { + char *md_state = NULL; + md_write(md, NULL, 0); + if (algo) + md_state = md_dump(md, algo); md_final(md); if ( opt.with_colons ) { if ( algo ) - print_hashline( md, algo, fname ); + print_hashline( md, algo, fname, md_state); else { - print_hashline( md, DIGEST_ALGO_MD5, fname ); - print_hashline( md, DIGEST_ALGO_SHA1, fname ); - print_hashline( md, DIGEST_ALGO_RMD160, fname ); + print_hashline( md, DIGEST_ALGO_MD5, fname, md_state ); + print_hashline( md, DIGEST_ALGO_SHA1, fname, md_state ); + print_hashline( md, DIGEST_ALGO_RMD160, fname, md_state ); #ifdef USE_SHA256 - print_hashline( md, DIGEST_ALGO_SHA224, fname ); - print_hashline( md, DIGEST_ALGO_SHA256, fname ); + print_hashline( md, DIGEST_ALGO_SHA224, fname, md_state ); + print_hashline( md, DIGEST_ALGO_SHA256, fname, md_state ); #endif #ifdef USE_SHA512 - print_hashline( md, DIGEST_ALGO_SHA384, fname ); - print_hashline( md, DIGEST_ALGO_SHA512, fname ); + print_hashline( md, DIGEST_ALGO_SHA384, fname, md_state ); + print_hashline( md, DIGEST_ALGO_SHA512, fname, md_state ); #endif } } @@ -4215,6 +4227,8 @@ print_mds( const char *fname, int algo ) #endif } } + if (md_state) + xfree(md_state); } md_close(md); diff --git a/g10/main.h b/g10/main.h index 584c4c7..bce37a6 100644 --- a/g10/main.h +++ b/g10/main.h @@ -152,7 +152,8 @@ int encrypt_filter( void *opaque, int control, /*-- sign.c --*/ int complete_sig( PKT_signature *sig, PKT_secret_key *sk, MD_HANDLE md ); int sign_file( STRLIST filenames, int detached, STRLIST locusr, - int do_encrypt, STRLIST remusr, const char *outfile ); + int do_encrypt, STRLIST remusr, const char *outfile, + const char *replace_md_context); int clearsign_file( const char *fname, STRLIST locusr, const char *outfile ); int sign_symencrypt_file (const char *fname, STRLIST locusr); diff --git a/g10/options.h b/g10/options.h index cac1c4c..97f2e06 100644 --- a/g10/options.h +++ b/g10/options.h @@ -74,6 +74,7 @@ struct int bz2_compress_level; int bz2_decompress_lowmem; const char *def_secret_key; + const char *load_md_state; char *def_recipient; int def_recipient_self; int def_cert_level; diff --git a/g10/sign.c b/g10/sign.c index 5003e9e..1a8f868 100644 --- a/g10/sign.c +++ b/g10/sign.c @@ -622,7 +622,7 @@ write_plaintext_packet (IOBUF out, IOBUF inp, const char *fname, static int write_signature_packets (SK_LIST sk_list, IOBUF out, MD_HANDLE hash, int sigclass, u32 timestamp, u32 duration, - int status_letter) + int status_letter, const char *replace_md_context) { SK_LIST sk_rover; @@ -656,6 +656,8 @@ write_signature_packets (SK_LIST sk_list, IOBUF out, MD_HANDLE hash, sig->sig_class = sigclass; md = md_copy (hash); + if (replace_md_context) + md_load(md, hash_for(sk), replace_md_context); if (sig->version >= 4) { @@ -705,7 +707,8 @@ write_signature_packets (SK_LIST sk_list, IOBUF out, MD_HANDLE hash, */ int sign_file( STRLIST filenames, int detached, STRLIST locusr, - int encryptflag, STRLIST remusr, const char *outfile ) + int encryptflag, STRLIST remusr, const char *outfile, + const char *replace_md_context) { const char *fname; armor_filter_context_t afx; @@ -1009,7 +1012,7 @@ sign_file( STRLIST filenames, int detached, STRLIST locusr, /* write the signatures */ rc = write_signature_packets (sk_list, out, mfx.md, opt.textmode && !outfile? 0x01 : 0x00, - create_time, duration, detached ? 'D':'S'); + create_time, duration, detached ? 'D':'S', replace_md_context); if( rc ) goto leave; @@ -1169,7 +1172,7 @@ clearsign_file( const char *fname, STRLIST locusr, const char *outfile ) /* write the signatures */ rc=write_signature_packets (sk_list, out, textmd, 0x01, - create_time, duration, 'C'); + create_time, duration, 'C', NULL); if( rc ) goto leave; @@ -1331,7 +1334,7 @@ sign_symencrypt_file (const char *fname, STRLIST locusr) /*(current filters: zip - encrypt - armor)*/ rc = write_signature_packets (sk_list, out, mfx.md, opt.textmode? 0x01 : 0x00, - create_time, duration, 'S'); + create_time, duration, 'S', NULL); if( rc ) goto leave; diff --git a/include/cipher.h b/include/cipher.h index 2bc57d6..5655b1d 100644 --- a/include/cipher.h +++ b/include/cipher.h @@ -130,6 +130,8 @@ const char * digest_algo_to_string( int algo ); int check_digest_algo( int algo ); MD_HANDLE md_open( int algo, int secure ); void md_enable( MD_HANDLE hd, int algo ); +void md_load(MD_HANDLE a, int algo, const char *b); +char * md_dump(MD_HANDLE a, int algo); MD_HANDLE md_copy( MD_HANDLE a ); void md_reset( MD_HANDLE a ); void md_close(MD_HANDLE a); -- 1.7.3.1 From jerome at jeromebaum.com Wed Jul 27 18:48:55 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Wed, 27 Jul 2011 18:48:55 +0200 Subject: [PATCH] Allow signing of files which are not present on the system In-Reply-To: <20110727153640.GA1074@ramsey.cl.cam.ac.uk> References: <20110727153640.GA1074@ramsey.cl.cam.ac.uk> Message-ID: Why modify print-md to no longer print the "normal" hash? (Mobile/Handy) Am 27.07.2011 18:20 schrieb "Steven J. Murdoch" < gnupg+Steven.Murdoch at cl.cam.ac.uk>: For a particular use case of GnuPG, I needed to sign a number of files which were not on the same machine as the private key. It would be insecure to upload the private key to the machine with the files, and it would take a very long time to download all the files to the machine with the private key. I've written a patch which does this (attached), but I'd like to find out whether this (after some cleaning up), would be considered for acceptance? Options I looked at included forwarding gpg-agent over SSH, but gpg-agent still requires having the private key on the machine doing the signing. I therefore looked into signing a hash of the file, as suggested here: http://lists.gnupg.org/pipermail/gnupg-devel/2004-May/021010.html It turned out to be a bit more complicated than that mail suggested, because GnuPG appends a footer to the file to be signed, before calculating the hash which is actually signed. This footer includes a timestamp, so is different each time. Therefore, I don't think it is possible to sign a file, given only the hash of that file. My solution was to modify --print-md to output the intermediate state of the hash calculation, after hashing the file but before finalizing the hash. Then I modified --sign so that it will accept this intermediate state as input. To use it, on the system with the files you want to sign, run: $ gpg --with-colons --print-md sha256 FILENAME | cut -f 4 -d ':' where FILENAME is the name of the file you want to sign. This will output the intermediate state of the message digest needed to calculate a SHA256 signature. On the system with your private key run: $ gpg --use-agent --load-md-state STATE --personal-digest-preferences sha256 --detach-sign --output OUTPUT < /dev/null where STATE is the intermediate state output by the command above, and OUTPUT is where you want to save the signature. The attached patch (on GnuPG 1.4.11) works, but needs some cleaning up before it could be merged. My question is whether this feature would be considered for acceptance by the GnuPG team? I would also like feedback on both the feature design and patch code. Steven. -- http://www.cl.cam.ac.uk/users/sjm217/ _______________________________________________ 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 wk at gnupg.org Wed Jul 27 19:35:04 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 27 Jul 2011 19:35:04 +0200 Subject: [PATCH] Allow signing of files which are not present on the system In-Reply-To: <20110727153640.GA1074@ramsey.cl.cam.ac.uk> (Steven J. Murdoch's message of "Wed, 27 Jul 2011 16:36:41 +0100") References: <20110727153640.GA1074@ramsey.cl.cam.ac.uk> Message-ID: <87oc0focdz.fsf@vigenere.g10code.de> On Wed, 27 Jul 2011 17:36, gnupg+Steven.Murdoch at cl.cam.ac.uk said: > My solution was to modify --print-md to output the intermediate state of the > hash calculation, after hashing the file but before finalizing the hash. Then I > modified --sign so that it will accept this intermediate state as input. That is exactly waht I had in mind once when I was in need for such a feature. I never came around to implement it, though. > The attached patch (on GnuPG 1.4.11) works, but needs some cleaning up before it > could be merged. My question is whether this feature would be considered for > acceptance by the GnuPG team? We would first need a copyright assignment to the FSF. Further I would like to have the user interface more similar to --show-session-key/--override-session-key. Maybe --show-md-state and --override-md-state where the first would also stop right before actually doing the signing. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gnupg+Steven.Murdoch at cl.cam.ac.uk Wed Jul 27 20:29:53 2011 From: gnupg+Steven.Murdoch at cl.cam.ac.uk (Steven J. Murdoch) Date: Wed, 27 Jul 2011 19:29:53 +0100 Subject: [PATCH] Allow signing of files which are not present on the system In-Reply-To: References: <20110727153640.GA1074@ramsey.cl.cam.ac.uk> Message-ID: <20110727182953.GB1074@ramsey.cl.cam.ac.uk> On Wed, Jul 27, 2011 at 06:48:55PM +0200, Jerome Baum wrote: > Why modify print-md to no longer print the "normal" hash? This was the most expedient way to implement the prototype, but that is certainly one thing that needs to be changed (as it will break software which depends on the format). The other option I was considering was for it to output the hash state to a file, and for --detach-sign (with some extra option set) to expect such a file as input. Currently, --detach-sign still expects a file, but ignores it (hence why I pipe in /dev/null in the example). Werner's other suggestion sounds good. I don't have any particular preference about the UI (other than it be easily scriptable), so aiming for consistency with existing functionality is a good principle to follow. Steven. -- http://www.cl.cam.ac.uk/~sjm217/ From gnupg+Steven.Murdoch at cl.cam.ac.uk Wed Jul 27 20:47:42 2011 From: gnupg+Steven.Murdoch at cl.cam.ac.uk (Steven J. Murdoch) Date: Wed, 27 Jul 2011 19:47:42 +0100 Subject: [PATCH] Allow signing of files which are not present on the system In-Reply-To: <87oc0focdz.fsf@vigenere.g10code.de> References: <20110727153640.GA1074@ramsey.cl.cam.ac.uk> <87oc0focdz.fsf@vigenere.g10code.de> Message-ID: <20110727184742.GD1074@ramsey.cl.cam.ac.uk> On Wed, Jul 27, 2011 at 07:35:04PM +0200, Werner Koch wrote: > On Wed, 27 Jul 2011 17:36, gnupg+Steven.Murdoch at cl.cam.ac.uk said: > > My solution was to modify --print-md to output the intermediate state of the > > hash calculation, after hashing the file but before finalizing the hash. Then I > > modified --sign so that it will accept this intermediate state as input. > > That is exactly waht I had in mind once when I was in need for such a > feature. I never came around to implement it, though. Good, I'm glad to see I was on the right track. There are some downsides though, one being that I think the intermediate state is platform-specific (endianness and sizeof int). Fixing this would I believe require changing all the hash function implementations, whereas the current patch just copies contextsize bytes and this works for all supported hash functions as far as I can tell. > > The attached patch (on GnuPG 1.4.11) works, but needs some cleaning up before it > > could be merged. My question is whether this feature would be considered for > > acceptance by the GnuPG team? > > We would first need a copyright assignment to the FSF. I'll look into this. > Further I would like to have the user interface more similar to > --show-session-key/--override-session-key. Maybe --show-md-state and > --override-md-state where the first would also stop right before actually > doing the signing. That sounds like a fine idea. I'm not a GnuPG expert so was not sure what would be the most consistent UI. Steven. -- http://www.cl.cam.ac.uk/users/sjm217/ From wk at gnupg.org Fri Jul 29 10:03:59 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Jul 2011 10:03:59 +0200 Subject: Supressing the "gpg: NOTE: trustdb not writable" on read only systems In-Reply-To: <439B54CA-AE95-4F05-A1B5-8D11557CC3EF@webweaving.org> (Dirk-Willem van Gulik's message of "Wed, 13 Jul 2011 12:36:25 +0100") References: <439B54CA-AE95-4F05-A1B5-8D11557CC3EF@webweaving.org> Message-ID: <87oc0dms28.fsf@vigenere.g10code.de> On Wed, 13 Jul 2011 13:36, dirkx at webweaving.org said: > "gpg: NOTE: trustdb not writable" on read only systems > > comes up regularly (even though we killed off all other warnings with The easiest way to fix that is this: /* Take care of read-only trustdb. */ db_fd = open (db_name, O_RDONLY | MY_O_BINARY ); - if (db_fd != -1) + if (db_fd != -1 && !opt.quiet) log_info (_("NOTE: trustdb not writable\n")); I did this for master (2.1) and also for 2.0. BTW, the CreateFile part in your patch is only for WindowsCE and there we really don't need it becuase most users - if any at all - won't see it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jul 29 10:19:06 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Jul 2011 10:19:06 +0200 Subject: [PATCH] Allow signing of files which are not present on the system In-Reply-To: <20110727184742.GD1074@ramsey.cl.cam.ac.uk> (Steven J. Murdoch's message of "Wed, 27 Jul 2011 19:47:42 +0100") References: <20110727153640.GA1074@ramsey.cl.cam.ac.uk> <87oc0focdz.fsf@vigenere.g10code.de> <20110727184742.GD1074@ramsey.cl.cam.ac.uk> Message-ID: <87fwlpmrd1.fsf@vigenere.g10code.de> On Wed, 27 Jul 2011 20:47, gnupg+Steven.Murdoch at cl.cam.ac.uk said: > Good, I'm glad to see I was on the right track. There are some downsides though, > one being that I think the intermediate state is platform-specific (endianness > and sizeof int). Fixing this would I believe require changing all the hash > function implementations, whereas the current patch just copies contextsize > bytes and this works for all supported hash functions as far as I can tell. Right. Thinking more about it I come to the conclusion that I would like to have is a general infrastructure for suspending and resuming hash computations. The to be saved state should of course be machine independent. This is something which needs to be done in Libgcrypt (used by GnuPG 2.x) and requires a bit of coding and a new API. I will do this for Libgcrypt 1.6. I am not sure whether it will be possible to eventually backport such changes to 1.4. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gnupg+Steven.Murdoch at cl.cam.ac.uk Fri Jul 29 17:31:16 2011 From: gnupg+Steven.Murdoch at cl.cam.ac.uk (Steven J. Murdoch) Date: Fri, 29 Jul 2011 16:31:16 +0100 Subject: [PATCH] Allow signing of files which are not present on the system In-Reply-To: <87fwlpmrd1.fsf@vigenere.g10code.de> References: <20110727153640.GA1074@ramsey.cl.cam.ac.uk> <87oc0focdz.fsf@vigenere.g10code.de> <20110727184742.GD1074@ramsey.cl.cam.ac.uk> <87fwlpmrd1.fsf@vigenere.g10code.de> Message-ID: <20110729153116.GG1074@ramsey.cl.cam.ac.uk> On Fri, Jul 29, 2011 at 10:19:06AM +0200, Werner Koch wrote: > Right. Thinking more about it I come to the conclusion that I would > like to have is a general infrastructure for suspending and resuming > hash computations. The to be saved state should of course be machine > independent. This is something which needs to be done in Libgcrypt > (used by GnuPG 2.x) and requires a bit of coding and a new API. I will > do this for Libgcrypt 1.6. > > I am not sure whether it will be possible to eventually backport such > changes to 1.4. I think that plan sounds good, although I still think it is worthwhile for me to finish off my patch and make it available to those who would like it sooner rather than later (I had another private request). Would it still be useful to do they copyright assignment? If so, please let me know what I should do. Steven. -- http://www.cl.cam.ac.uk/users/sjm217/