From nmav at gnutls.org Sat Jan 4 17:26:07 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 04 Jan 2014 17:26:07 +0100 Subject: openpgp -> pkcs #11 Message-ID: <52C8361F.8090606@gnutls.org> Hello, There was [0] an ongoing 30-day public review for the new OASIS PKCS#11 specification. The time for comments expired by the end of the year but I think it would be nice to have suggestions to accommodate the needs of the openpgp card to the PKCS #11 committee. regards, Nikos [0]. https://www.oasis-open.org/news/announcements/30-day-public-review-for-four-pkcs-11-committee-specification-drafts From wk at gnupg.org Sun Jan 5 13:33:10 2014 From: wk at gnupg.org (Werner Koch) Date: Sun, 05 Jan 2014 13:33:10 +0100 Subject: openpgp -> pkcs #11 In-Reply-To: <52C8361F.8090606@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat, 04 Jan 2014 17:26:07 +0100") References: <52C8361F.8090606@gnutls.org> Message-ID: <87iotyk3qx.fsf@vigenere.g10code.de> On Sat, 4 Jan 2014 17:26, nmav at gnutls.org said: > I think it would be nice to have suggestions to accommodate the needs of > the openpgp card to the PKCS #11 committee. We already have a way to provide the card as PKCS#11 token for those who want that. In general I consider PKCS#11 too complicate due to a design targeted to proprietary applications. It is bad enough that we usually don't have free software cards, but in most cases we do not even have complete card specs and instead vendors resort to hide them in their proprietary drivers. That should be a no-no after the summer of snowden. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nmav at gnutls.org Sun Jan 5 16:20:53 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 05 Jan 2014 16:20:53 +0100 Subject: openpgp -> pkcs #11 In-Reply-To: <87iotyk3qx.fsf@vigenere.g10code.de> References: <52C8361F.8090606@gnutls.org> <87iotyk3qx.fsf@vigenere.g10code.de> Message-ID: <52C97855.1070606@gnutls.org> On 01/05/2014 01:33 PM, Werner Koch wrote: > On Sat, 4 Jan 2014 17:26, nmav at gnutls.org said: > >> I think it would be nice to have suggestions to accommodate the needs of >> the openpgp card to the PKCS #11 committee. > We already have a way to provide the card as PKCS#11 token for those who > want that. If you are referring to the openpgp card opensc driver, it is really far from being usable. I have reported the issues I had using the FSFE card at: http://sourceforge.net/mailarchive/forum.php?thread_name=1387821918.1143.18.camel%40aspire.lan&forum_name=opensc-devel > In general I consider PKCS#11 too complicate due to a design > targeted to proprietary applications. Indeed it is, but it is not much more than other security-related standards (see X.509 and PKIX). Nevertheless, a card or a module needs not to support the whole standard, it simply needs to implement the few operations it supports. PKCS #11's design can support proprietary applications as well as free software. > It is bad enough that we usually don't have free software cards, but in > most cases we do not even have complete card specs and instead vendors > resort to hide them in their proprietary drivers. That should be a > no-no after the summer of snowden. Most of the smart cards today are supported by the opensc drivers and the PKCS #11 driver which is LGPLv2.1. In fact PKCS #11 today is used mainly by free software (NSS is fully using PKCS #11, gnutls uses it for asymmetric keys, p11-kit provides a PKCS #11 trust module, and gnome-keyring, openssh, ...). It would be very good to have an open card such as the openpgp card to integrate seamlessly in all that software. regards, Nikos From wk at gnupg.org Mon Jan 6 12:40:21 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 06 Jan 2014 12:40:21 +0100 Subject: openpgp -> pkcs #11 In-Reply-To: <52C97855.1070606@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 05 Jan 2014 16:20:53 +0100") References: <52C8361F.8090606@gnutls.org> <87iotyk3qx.fsf@vigenere.g10code.de> <52C97855.1070606@gnutls.org> Message-ID: <877gadgwyi.fsf@vigenere.g10code.de> On Sun, 5 Jan 2014 16:20, nmav at gnutls.org said: > If you are referring to the openpgp card opensc driver, it is really far I mean www.scute.org - there is a Debian package for it: OpenPGP smartcard plugin for Mozilla Network Security Services Scute is a PKCS #11 implementation for the GnuPG Agent using the GnuPG Smart Card Daemon which enables you to use your OpenPGP smart card for client authentication with SSL in Mozilla. > Indeed it is, but it is not much more than other security-related > standards (see X.509 and PKIX). Nevertheless, a card or a module needs No, it is very different from that. PKIX is a protocol description and not an API description. > mainly by free software (NSS is fully using PKCS #11, gnutls uses it for Because NSS used to be a proprietary way longer than Mozilla. > such as the openpgp card to integrate seamlessly in all that software. Use Scute and add the missing parts (encryption) ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dbaryshkov at gmail.com Mon Jan 6 22:33:03 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Tue, 7 Jan 2014 01:33:03 +0400 Subject: openpgp -> pkcs #11 In-Reply-To: <877gadgwyi.fsf@vigenere.g10code.de> References: <52C8361F.8090606@gnutls.org> <87iotyk3qx.fsf@vigenere.g10code.de> <52C97855.1070606@gnutls.org> <877gadgwyi.fsf@vigenere.g10code.de> Message-ID: Hello, On Mon, Jan 6, 2014 at 3:40 PM, Werner Koch wrote: > On Sun, 5 Jan 2014 16:20, nmav at gnutls.org said: > >> If you are referring to the openpgp card opensc driver, it is really far > > I mean www.scute.org - there is a Debian package for it: Please update onsite instructions to point to git and gitweb instead of svn. It took me a while till I found SCM for scute. -- With best wishes Dmitry From daniele.athome at gmail.com Tue Jan 7 15:26:46 2014 From: daniele.athome at gmail.com (Daniele Ricci) Date: Tue, 7 Jan 2014 15:26:46 +0100 Subject: [gpgme] export test: wrong mode flags? Message-ID: Hello developers, I'm implementing some more --export-options in gpgme and I've noticed that the export test includes the 0x2 flag but using another name: mode |= GPGME_KEYLIST_MODE_EXTERN; I think it should use instead: mode |= GPGME_EXPORT_MODE_EXTERN; Even if the value is the same... or maybe I'm missing something? Regards -- Daniele From daniele.athome at gmail.com Tue Jan 7 17:13:57 2014 From: daniele.athome at gmail.com (Daniele Ricci) Date: Tue, 7 Jan 2014 17:13:57 +0100 Subject: [gpgme] export test: wrong mode flags? In-Reply-To: <87mwj7dbn5.fsf@vigenere.g10code.de> References: <87mwj7dbn5.fsf@vigenere.g10code.de> Message-ID: tests/run-export.c:84 http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=tests/run-export.c;h=43332087aa20e2ad578c7e6c6d998e0656faf08c;hb=HEAD#l84 And it's not the only one. In the same file the same constant is used a few times. I didn't checked on other parts of the code (yet). On Tue, Jan 7, 2014 at 5:01 PM, Werner Koch wrote: > On Tue, 7 Jan 2014 15:26, daniele.athome at gmail.com said: > >> that the export test includes the 0x2 flag but using another name: >> >> mode |= GPGME_KEYLIST_MODE_EXTERN; > > Where? > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -- Daniele From dbaryshkov at gmail.com Tue Jan 7 17:27:16 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Tue, 7 Jan 2014 20:27:16 +0400 Subject: [ksba] Formatting of public keys Message-ID: Hello, I'm currently playing with adding GOST R 34.10/34.11 support in libksba. I'm currently facing an issue with pubkey conversion from S-exp to DER. I need to convert pubkeys differently depending on the hashing algo (old or new one) used with the certificate. Is there a way to cleanly express that in libksba? -- With best wishes Dmitry From wk at gnupg.org Tue Jan 7 18:08:14 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 07 Jan 2014 18:08:14 +0100 Subject: [ksba] Formatting of public keys In-Reply-To: (Dmitry Eremin-Solenikov's message of "Tue, 7 Jan 2014 20:27:16 +0400") References: Message-ID: <87eh4jd8jl.fsf@vigenere.g10code.de> On Tue, 7 Jan 2014 17:27, dbaryshkov at gmail.com said: > I need to convert pubkeys differently depending on the hashing algo (old > or new one) used with the certificate. Is there a way to cleanly express that > in libksba? Can you please explain that in more detail. What are the desired inputs and outputs? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jan 7 18:11:50 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 07 Jan 2014 18:11:50 +0100 Subject: [gpgme] export test: wrong mode flags? In-Reply-To: (Daniele Ricci's message of "Tue, 7 Jan 2014 17:13:57 +0100") References: <87mwj7dbn5.fsf@vigenere.g10code.de> Message-ID: <877gabd8dl.fsf@vigenere.g10code.de> On Tue, 7 Jan 2014 17:13, daniele.athome at gmail.com said: > tests/run-export.c:84 > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=tests/run-export.c;h=43332087aa20e2ad578c7e6c6d998e0656faf08c;hb=HEAD#l84 > > And it's not the only one. In the same file the same constant is used > a few times. I didn't checked on other parts of the code (yet). Right, should be changed. It does not harm because we can't change the values of the macros anyway. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From daniele.athome at gmail.com Tue Jan 7 18:22:23 2014 From: daniele.athome at gmail.com (Daniele Ricci) Date: Tue, 7 Jan 2014 18:22:23 +0100 Subject: [gpgme] export test: wrong mode flags? In-Reply-To: <877gabd8dl.fsf@vigenere.g10code.de> References: <87mwj7dbn5.fsf@vigenere.g10code.de> <877gabd8dl.fsf@vigenere.g10code.de> Message-ID: Alright then, I will include it in my patch I will submit to you through this ML. On Tue, Jan 7, 2014 at 6:11 PM, Werner Koch wrote: > On Tue, 7 Jan 2014 17:13, daniele.athome at gmail.com said: >> tests/run-export.c:84 >> http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=tests/run-export.c;h=43332087aa20e2ad578c7e6c6d998e0656faf08c;hb=HEAD#l84 >> >> And it's not the only one. In the same file the same constant is used >> a few times. I didn't checked on other parts of the code (yet). > > Right, should be changed. It does not harm because we can't change the > values of the macros anyway. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -- Daniele From dbaryshkov at gmail.com Tue Jan 7 18:40:52 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Tue, 7 Jan 2014 21:40:52 +0400 Subject: [ksba] Formatting of public keys In-Reply-To: <87eh4jd8jl.fsf@vigenere.g10code.de> References: <87eh4jd8jl.fsf@vigenere.g10code.de> Message-ID: On Tue, Jan 7, 2014 at 9:08 PM, Werner Koch wrote: > On Tue, 7 Jan 2014 17:27, dbaryshkov at gmail.com said: > >> I need to convert pubkeys differently depending on the hashing algo (old >> or new one) used with the certificate. Is there a way to cleanly express that >> in libksba? > > Can you please explain that in more detail. What are the desired inputs > and outputs? This is quite a problematic story. Old format is defined in rfc4491 with parameters being defined in rfc4357. An example of the certificate can be found at https://tools.ietf.org/html/rfc4491#section-4.2 (note - you should care only about 34.10-2001 example). New format is a draft (currently) and is described only in Russian. See http://tc26.ru/metodiki/draft/Addition_to_PKCS12_v2.pdf. Examples can be found in section 7.1 I settled for the following S-expressions: Sexp for the old public key used with old hash algorithm: (public-key (gost (curve 16:1.2.643.2.2.35.1 )(digest 16:1.2.643.2.2.30.1 )(q #04........# ))) For the new hash algorithm (stribog): (public-key (gost (curve 16:1.2.643.2.2.35.1 )(q #04...........# ))) You see, even the curves used are the same. The only difference in public key information seems to be the information about digest (and optional cipher) parameters - the OID named digest. -- With best wishes Dmitry From daniele.athome at gmail.com Tue Jan 7 20:32:45 2014 From: daniele.athome at gmail.com (Daniele Ricci) Date: Tue, 7 Jan 2014 20:32:45 +0100 Subject: [gpgme] incoming patch: implement more export options (clean, no-export-attributes) Message-ID: Hello, I'm going to send (by git-send-email) a quick patch I've just wrote (and tested a bit) that implements more --export-options. As you will see, I've decided to use a static buffer approach with fixed lengths instead of doing malloc/realloc. I hope it's ok for you. If you want another approach or you want me to implement it in another way, just tell me, I can fix that of course. Patch is based on latest git master. Python bindings will follow soon, although I think it's not very actively maintained any more [1] [1] https://code.launchpad.net/~jamesh/pygpgme -- Daniele From daniele.athome at gmail.com Tue Jan 7 20:35:32 2014 From: daniele.athome at gmail.com (Daniele Ricci) Date: Tue, 7 Jan 2014 20:35:32 +0100 Subject: [PATCH] Implement more export-options (clean, no-export-attributes) Message-ID: <1389123332-29095-1-git-send-email-daniele.athome@gmail.com> Signed-off-by: Daniele Ricci --- src/engine-gpg.c | 20 ++++++++++++++++++-- src/export.c | 8 ++++++-- src/gpgme.h.in | 2 ++ tests/run-export.c | 26 ++++++++++++++++++++++---- 4 files changed, 48 insertions(+), 8 deletions(-) diff --git a/src/engine-gpg.c b/src/engine-gpg.c index 2f59bb9..d902d38 100644 --- a/src/engine-gpg.c +++ b/src/engine-gpg.c @@ -1754,19 +1754,35 @@ gpg_encrypt_sign (void *engine, gpgme_key_t recp[], return err; } +// exact length of: --export-options=export-minimal,export-clean,no-export-attributes +#define EXPORT_OPTIONS_FULL_LEN 65 +// exact length of: --export-options= +#define EXPORT_OPTIONS_PREFIX_LEN 17 static gpgme_error_t export_common (engine_gpg_t gpg, gpgme_export_mode_t mode, gpgme_data_t keydata, int use_armor) { gpgme_error_t err = 0; + char export_options[EXPORT_OPTIONS_FULL_LEN+1] = "--export-options="; if ((mode & ~(GPGME_EXPORT_MODE_EXTERN - |GPGME_EXPORT_MODE_MINIMAL))) + |GPGME_EXPORT_MODE_MINIMAL + |GPGME_EXPORT_MODE_CLEAN + |GPGME_EXPORT_MODE_NO_ATTRIBUTES))) return gpg_error (GPG_ERR_NOT_SUPPORTED); if ((mode & GPGME_EXPORT_MODE_MINIMAL)) - err = add_arg (gpg, "--export-options=export-minimal"); + strcat(export_options, "export-minimal,"); + + if ((mode & GPGME_EXPORT_MODE_CLEAN)) + strcat(export_options, "export-clean,"); + + if ((mode & GPGME_EXPORT_MODE_NO_ATTRIBUTES)) + strcat(export_options, "no-export-attributes,"); + + if (strlen(export_options) > EXPORT_OPTIONS_PREFIX_LEN) + err = add_arg (gpg, export_options); if (err) ; diff --git a/src/export.c b/src/export.c index 81a23b0..9151087 100644 --- a/src/export.c +++ b/src/export.c @@ -45,7 +45,9 @@ export_start (gpgme_ctx_t ctx, int synchronous, const char *pattern, gpgme_error_t err; if ((mode & ~(GPGME_EXPORT_MODE_EXTERN - |GPGME_EXPORT_MODE_MINIMAL))) + |GPGME_EXPORT_MODE_MINIMAL + |GPGME_EXPORT_MODE_CLEAN + |GPGME_EXPORT_MODE_NO_ATTRIBUTES))) return gpg_error (GPG_ERR_INV_VALUE); /* Invalid flags in MODE. */ @@ -116,7 +118,9 @@ export_ext_start (gpgme_ctx_t ctx, int synchronous, const char *pattern[], gpgme_error_t err; if ((mode & ~(GPGME_EXPORT_MODE_EXTERN - |GPGME_EXPORT_MODE_MINIMAL))) + |GPGME_EXPORT_MODE_MINIMAL + |GPGME_EXPORT_MODE_CLEAN + |GPGME_EXPORT_MODE_NO_ATTRIBUTES))) return gpg_error (GPG_ERR_INV_VALUE); /* Invalid flags in MODE. */ if ((mode & GPGME_EXPORT_MODE_EXTERN)) diff --git a/src/gpgme.h.in b/src/gpgme.h.in index 5c4de6b..551ed60 100644 --- a/src/gpgme.h.in +++ b/src/gpgme.h.in @@ -388,6 +388,8 @@ gpgme_pinentry_mode_t; /* The available export mode flags. */ #define GPGME_EXPORT_MODE_EXTERN 2 #define GPGME_EXPORT_MODE_MINIMAL 4 +#define GPGME_EXPORT_MODE_CLEAN 8 +#define GPGME_EXPORT_MODE_NO_ATTRIBUTES 16 typedef unsigned int gpgme_export_mode_t; diff --git a/tests/run-export.c b/tests/run-export.c index 4333208..b0e0771 100644 --- a/tests/run-export.c +++ b/tests/run-export.c @@ -43,6 +43,9 @@ show_usage (int ex) fputs ("usage: " PGM " [options] USERIDS\n\n" "Options:\n" " --verbose run in verbose mode\n" + " --clean remove any unusable user IDs and signatures\n" + " --minimal remove all signatures except self-signatures\n" + " --no-attributes do not include any user attribute\n" " --extern send keys to the keyserver (TAKE CARE!)\n" , stderr); exit (ex); @@ -81,7 +84,22 @@ main (int argc, char **argv) } else if (!strcmp (*argv, "--extern")) { - mode |= GPGME_KEYLIST_MODE_EXTERN; + mode |= GPGME_EXPORT_MODE_EXTERN; + argc--; argv++; + } + else if (!strcmp (*argv, "--clean")) + { + mode |= GPGME_EXPORT_MODE_CLEAN; + argc--; argv++; + } + else if (!strcmp (*argv, "--minimal")) + { + mode |= GPGME_EXPORT_MODE_MINIMAL; + argc--; argv++; + } + else if (!strcmp (*argv, "--no-attributes")) + { + mode |= GPGME_EXPORT_MODE_NO_ATTRIBUTES; argc--; argv++; } else if (!strncmp (*argv, "--", 2)) @@ -131,7 +149,7 @@ main (int argc, char **argv) } /* Now for the actual export. */ - if ((mode & GPGME_KEYLIST_MODE_EXTERN)) + if ((mode & GPGME_EXPORT_MODE_EXTERN)) printf ("sending keys to keyserver\n"); err = gpgme_data_new (&out); @@ -139,11 +157,11 @@ main (int argc, char **argv) gpgme_set_armor (ctx, 1); err = gpgme_op_export_keys (ctx, keyarray, mode, - (mode & GPGME_KEYLIST_MODE_EXTERN)? NULL:out); + (mode & GPGME_EXPORT_MODE_EXTERN)? NULL:out); fail_if_err (err); fflush (NULL); - if (!(mode & GPGME_KEYLIST_MODE_EXTERN)) + if (!(mode & GPGME_EXPORT_MODE_EXTERN)) { fputs ("Begin Result:\n", stdout); print_data (out); -- 1.8.5.2 From daniele.athome at gmail.com Mon Jan 13 13:48:35 2014 From: daniele.athome at gmail.com (Daniele Ricci) Date: Mon, 13 Jan 2014 13:48:35 +0100 Subject: [PATCH] Implement more export-options (clean, no-export-attributes) In-Reply-To: <1389123332-29095-1-git-send-email-daniele.athome@gmail.com> References: <1389123332-29095-1-git-send-email-daniele.athome@gmail.com> Message-ID: Hello, any chance to see this patch reviewed? Are there any rules for patch posting? Thank you Regards On Tue, Jan 7, 2014 at 8:35 PM, Daniele Ricci wrote: > Signed-off-by: Daniele Ricci > --- > src/engine-gpg.c | 20 ++++++++++++++++++-- > src/export.c | 8 ++++++-- > src/gpgme.h.in | 2 ++ > tests/run-export.c | 26 ++++++++++++++++++++++---- > 4 files changed, 48 insertions(+), 8 deletions(-) > > diff --git a/src/engine-gpg.c b/src/engine-gpg.c > index 2f59bb9..d902d38 100644 > --- a/src/engine-gpg.c > +++ b/src/engine-gpg.c > @@ -1754,19 +1754,35 @@ gpg_encrypt_sign (void *engine, gpgme_key_t recp[], > return err; > } > > +// exact length of: --export-options=export-minimal,export-clean,no-export-attributes > +#define EXPORT_OPTIONS_FULL_LEN 65 > +// exact length of: --export-options= > +#define EXPORT_OPTIONS_PREFIX_LEN 17 > > static gpgme_error_t > export_common (engine_gpg_t gpg, gpgme_export_mode_t mode, > gpgme_data_t keydata, int use_armor) > { > gpgme_error_t err = 0; > + char export_options[EXPORT_OPTIONS_FULL_LEN+1] = "--export-options="; > > if ((mode & ~(GPGME_EXPORT_MODE_EXTERN > - |GPGME_EXPORT_MODE_MINIMAL))) > + |GPGME_EXPORT_MODE_MINIMAL > + |GPGME_EXPORT_MODE_CLEAN > + |GPGME_EXPORT_MODE_NO_ATTRIBUTES))) > return gpg_error (GPG_ERR_NOT_SUPPORTED); > > if ((mode & GPGME_EXPORT_MODE_MINIMAL)) > - err = add_arg (gpg, "--export-options=export-minimal"); > + strcat(export_options, "export-minimal,"); > + > + if ((mode & GPGME_EXPORT_MODE_CLEAN)) > + strcat(export_options, "export-clean,"); > + > + if ((mode & GPGME_EXPORT_MODE_NO_ATTRIBUTES)) > + strcat(export_options, "no-export-attributes,"); > + > + if (strlen(export_options) > EXPORT_OPTIONS_PREFIX_LEN) > + err = add_arg (gpg, export_options); > > if (err) > ; > diff --git a/src/export.c b/src/export.c > index 81a23b0..9151087 100644 > --- a/src/export.c > +++ b/src/export.c > @@ -45,7 +45,9 @@ export_start (gpgme_ctx_t ctx, int synchronous, const char *pattern, > gpgme_error_t err; > > if ((mode & ~(GPGME_EXPORT_MODE_EXTERN > - |GPGME_EXPORT_MODE_MINIMAL))) > + |GPGME_EXPORT_MODE_MINIMAL > + |GPGME_EXPORT_MODE_CLEAN > + |GPGME_EXPORT_MODE_NO_ATTRIBUTES))) > return gpg_error (GPG_ERR_INV_VALUE); /* Invalid flags in MODE. */ > > > @@ -116,7 +118,9 @@ export_ext_start (gpgme_ctx_t ctx, int synchronous, const char *pattern[], > gpgme_error_t err; > > if ((mode & ~(GPGME_EXPORT_MODE_EXTERN > - |GPGME_EXPORT_MODE_MINIMAL))) > + |GPGME_EXPORT_MODE_MINIMAL > + |GPGME_EXPORT_MODE_CLEAN > + |GPGME_EXPORT_MODE_NO_ATTRIBUTES))) > return gpg_error (GPG_ERR_INV_VALUE); /* Invalid flags in MODE. */ > > if ((mode & GPGME_EXPORT_MODE_EXTERN)) > diff --git a/src/gpgme.h.in b/src/gpgme.h.in > index 5c4de6b..551ed60 100644 > --- a/src/gpgme.h.in > +++ b/src/gpgme.h.in > @@ -388,6 +388,8 @@ gpgme_pinentry_mode_t; > /* The available export mode flags. */ > #define GPGME_EXPORT_MODE_EXTERN 2 > #define GPGME_EXPORT_MODE_MINIMAL 4 > +#define GPGME_EXPORT_MODE_CLEAN 8 > +#define GPGME_EXPORT_MODE_NO_ATTRIBUTES 16 > > typedef unsigned int gpgme_export_mode_t; > > diff --git a/tests/run-export.c b/tests/run-export.c > index 4333208..b0e0771 100644 > --- a/tests/run-export.c > +++ b/tests/run-export.c > @@ -43,6 +43,9 @@ show_usage (int ex) > fputs ("usage: " PGM " [options] USERIDS\n\n" > "Options:\n" > " --verbose run in verbose mode\n" > + " --clean remove any unusable user IDs and signatures\n" > + " --minimal remove all signatures except self-signatures\n" > + " --no-attributes do not include any user attribute\n" > " --extern send keys to the keyserver (TAKE CARE!)\n" > , stderr); > exit (ex); > @@ -81,7 +84,22 @@ main (int argc, char **argv) > } > else if (!strcmp (*argv, "--extern")) > { > - mode |= GPGME_KEYLIST_MODE_EXTERN; > + mode |= GPGME_EXPORT_MODE_EXTERN; > + argc--; argv++; > + } > + else if (!strcmp (*argv, "--clean")) > + { > + mode |= GPGME_EXPORT_MODE_CLEAN; > + argc--; argv++; > + } > + else if (!strcmp (*argv, "--minimal")) > + { > + mode |= GPGME_EXPORT_MODE_MINIMAL; > + argc--; argv++; > + } > + else if (!strcmp (*argv, "--no-attributes")) > + { > + mode |= GPGME_EXPORT_MODE_NO_ATTRIBUTES; > argc--; argv++; > } > else if (!strncmp (*argv, "--", 2)) > @@ -131,7 +149,7 @@ main (int argc, char **argv) > } > > /* Now for the actual export. */ > - if ((mode & GPGME_KEYLIST_MODE_EXTERN)) > + if ((mode & GPGME_EXPORT_MODE_EXTERN)) > printf ("sending keys to keyserver\n"); > > err = gpgme_data_new (&out); > @@ -139,11 +157,11 @@ main (int argc, char **argv) > > gpgme_set_armor (ctx, 1); > err = gpgme_op_export_keys (ctx, keyarray, mode, > - (mode & GPGME_KEYLIST_MODE_EXTERN)? NULL:out); > + (mode & GPGME_EXPORT_MODE_EXTERN)? NULL:out); > fail_if_err (err); > > fflush (NULL); > - if (!(mode & GPGME_KEYLIST_MODE_EXTERN)) > + if (!(mode & GPGME_EXPORT_MODE_EXTERN)) > { > fputs ("Begin Result:\n", stdout); > print_data (out); > -- > 1.8.5.2 > -- Daniele From gniibe at fsij.org Tue Jan 14 13:54:17 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 14 Jan 2014 21:54:17 +0900 Subject: Adding the secp256k1 curve for ECDSA Message-ID: <52D53379.4080404@fsij.org> Hello, I added support of the secp256k1 curve in libgcrypt. Next, I'd like to add a feature of ECDSA with secp256k1 to GnuPG. My plan is to enable gpg-agent sign transactions of Bitcoin, and to extend Gnuk so that it can store Bitcoin's private key and can compute ECDSA of the curve secp256k1. I'm considering Electrum as Bitcoin client. In the lower layer, I'm considering using INTERNAL AUTHENTICATE command in the OpenPGP card specification (like gpg-agent as ssh-agent uses that command). Any suggestions, comments are welcome. Direct questions of mine were: Is there any good Bitcoin client? Where could I put my private key of Bitcoin? -- From martin at martinpaljak.net Tue Jan 14 14:38:15 2014 From: martin at martinpaljak.net (Martin Paljak) Date: Tue, 14 Jan 2014 13:38:15 +0000 Subject: Adding the secp256k1 curve for ECDSA In-Reply-To: <52D53379.4080404@fsij.org> References: <52D53379.4080404@fsij.org> Message-ID: Hello, On Tue, Jan 14, 2014 at 12:54 PM, NIIBE Yutaka wrote: > My plan is to enable gpg-agent sign transactions of Bitcoin, and to > extend Gnuk so that it can store Bitcoin's private key and can compute > ECDSA of the curve secp256k1. I'm considering Electrum as Bitcoin > client. Once you get to actually extending electrum, keep me posted. I thought about doing it once a year or two ago for a smart card applet, but did not do it. I found that doing refactoring of not well known python code is way more complicated than Java (or C)... Martin From gniibe at fsij.org Wed Jan 15 01:58:57 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 15 Jan 2014 09:58:57 +0900 Subject: Adding the secp256k1 curve for ECDSA In-Reply-To: References: <52D53379.4080404@fsij.org> Message-ID: <1389747537.1927.3.camel@cfw2.gniibe.org> On 2014-01-14 at 13:38 +0000, Martin Paljak wrote: > Once you get to actually extending electrum, keep me posted. I thought > about doing it once a year or two ago for a smart card applet, but did > not do it. Sure. > I found that doing refactoring of not well known python code is way > more complicated than Java (or C)... I think that the protocol of gpg-agent is clear, and the another one of OpenPGP card specification is also clear, there would be no fundamental difficulty. Speaking about taste, I don't want to use Java for signing. Using the code of ECDSA running by Python interpreter is the thing to avoid for me, either. I don't evaluate how much risk it would have, though. I prefer the approach of gpgme and gpg-agent (although I would directly connect to gpg-agent), the model where a process handles secure operations (and some device (such as Gnuk Token) can be connected, specifically for helping these operations). I don't feel easy when a library handles secure data directly (for interactive usage), if there would be some other ambitious activities such as conservative garbage collection. -- From dkg at fifthhorseman.net Wed Jan 15 05:11:02 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 14 Jan 2014 23:11:02 -0500 Subject: gpg --trust-model=always sometimes fails with fatal error as of 1.4.16 Message-ID: <87sisp51gp.fsf@alice.fifthhorseman.net> Control: affects 735363 signing-party re: http://bugs.debian.org/735363 -- "Fatal error/non-zero exit code returned when --trust-model=always used" (filed in debian against gpg 1.4.16) caff (from debian's signing-party package) also fails with the recent change to gnupg's behavior when --trust-model=always is set (the symptom in caff is an endless stream of errors like: Could not import 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 into temporary gnupg. Caff seems to be invoking gpg like this: /usr/bin/gpg --batch --no-tty --homedir /tmp/caff-0EE5BE979282D80B9F7540F1CCD2ED94D21739E9-dNk5a --status-fd 5 --no-auto-check-trustdb --trust-model=always --import It seems i can replicate the problem with: PGPID=0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 mkdir -m 0700 -p /tmp/fake-gpg gpg --export $PGPID | gpg --trust-model=always --homedir /tmp/fake-gpg --import but subsequent invocations of: gpg --export $PGPID | gpg --trust-model=always --homedir /tmp/fake-gpg --import do not fail (presumably because they do not modify pubring.gpg, as the first import was already actually imported successfully). The change seems to be related to upstream's relatively recent change 2528178e7e2fac6454dd988121167305db7c71d9 (replicated below), which from the comment log appears to try to address the issue, but maybe missed a corner case. Werner, perhaps you can comment on this? commit 2528178e7e2fac6454dd988121167305db7c71d9 Author: Werner Koch Date: Fri Oct 11 09:25:58 2013 +0200 gpg: Do not require a trustdb with --always-trust. * g10/tdbio.c (tdbio_set_dbname): Add arg R_NOFILE. * g10/trustdb.c (trustdb_args): Add field no_trustdb. (init_trustdb): Set that field. (revalidation_mark): Take care of a nonexistent trustdb file. (read_trust_options): Ditto. (get_ownertrust): Ditto. (get_min_ownertrust): Ditto. (update_ownertrust): Ditto. (update_min_ownertrust): Ditto. (clear_ownertrusts): Ditto. (cache_disabled_value): Ditto. (check_trustdb_stale): Ditto. (get_validity): Ditto. * g10/gpg.c (main): Do not create a trustdb with most commands for trust-model always. -- This slightly changes the semantics of most commands in that they won't create a trustdb if --trust-model=always is used. It just does not make sense to create a trustdb if there is no need for it. Signed-off-by: Werner Koch (cherry picked from commit 1a0eeaacd1bf09fe5125dbc3f56016bc20f3512e) Resolved conflicts: g10/gpg.c g10/tdbio.h g10/trustdb.c (indentation fixes) diff --git a/NEWS b/NEWS index ca4bfca..ad3471e 100644 --- a/NEWS +++ b/NEWS @@ -1,6 +1,8 @@ Noteworthy changes in version 1.4.16 (unreleased) ------------------------------------------------- + * Do not create a trustdb file if --trust-model=always is used. + Noteworthy changes in version 1.4.15 (2013-10-04) ------------------------------------------------- diff --git a/g10/gpg.c b/g10/gpg.c index b310308..ca120ab 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -3318,14 +3318,12 @@ main (int argc, char **argv ) case aFixTrustDB: case aExportOwnerTrust: rc = setup_trustdb( 0, trustdb_name ); break; case aListTrustDB: rc = setup_trustdb( argc? 1:0, trustdb_name ); break; - case aEncr: - case aEncrFiles: - /* No need to create the trust model if we are using the + default: + /* No need to create the trust model if we are using the * always trust model. */ rc = setup_trustdb (opt.trust_model != TM_ALWAYS, trustdb_name); break; - default: rc = setup_trustdb(1, trustdb_name ); break; - } + } if( rc ) log_error(_("failed to initialize the TrustDB: %s\n"), g10_errstr(rc)); diff --git a/g10/tdbio.c b/g10/tdbio.c index 4f02ff9..f109dde 100644 --- a/g10/tdbio.c +++ b/g10/tdbio.c @@ -471,7 +471,7 @@ create_version_record (void) int -tdbio_set_dbname( const char *new_dbname, int create ) +tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile) { char *fname; static int initialized = 0; @@ -481,6 +481,8 @@ tdbio_set_dbname( const char *new_dbname, int create ) initialized = 1; } + *r_nofile = 0; + if(new_dbname==NULL) fname=make_filename(opt.homedir,"trustdb" EXTSEP_S "gpg", NULL); else if (*new_dbname != DIRSEP_C ) @@ -499,7 +501,9 @@ tdbio_set_dbname( const char *new_dbname, int create ) xfree(fname); return G10ERR_TRUSTDB; } - if( create ) { + if (!create) + *r_nofile = 1; + else { FILE *fp; TRUSTREC rec; int rc; diff --git a/g10/tdbio.h b/g10/tdbio.h index 39e8cba..dd6e9d3 100644 --- a/g10/tdbio.h +++ b/g10/tdbio.h @@ -90,7 +90,7 @@ typedef struct trust_record TRUSTREC; /*-- tdbio.c --*/ int tdbio_update_version_record(void); -int tdbio_set_dbname( const char *new_dbname, int create ); +int tdbio_set_dbname( const char *new_dbname, int create, int *r_nofile); const char *tdbio_get_dbname(void); void tdbio_dump_record( TRUSTREC *rec, FILE *fp ); int tdbio_read_record( ulong recnum, TRUSTREC *rec, int expected ); diff --git a/g10/trustdb.c b/g10/trustdb.c index 24d675b..0bf92e4 100644 --- a/g10/trustdb.c +++ b/g10/trustdb.c @@ -48,7 +48,7 @@ /* * A structure to store key identification as well as some stuff needed - * for validation + * for validation */ struct key_item { struct key_item *next; @@ -64,7 +64,7 @@ typedef struct key_item **KeyHashTable; /* see new_key_hash_table() */ /* * Structure to keep track of keys, this is used as an array wherre - * the item right after the last one has a keyblock set to NULL. + * the item right after the last one has a keyblock set to NULL. * Maybe we can drop this thing and replace it by key_item */ struct key_array { @@ -77,6 +77,7 @@ static struct { int init; int level; char *dbname; + int no_trustdb; /* Set if a trustdb file is not available. */ } trustdb_args; /* some globals */ @@ -96,7 +97,7 @@ static struct key_item * new_key_item (void) { struct key_item *k; - + k = xmalloc_clear (sizeof *k); return k; } @@ -118,11 +119,11 @@ release_key_items (struct key_item *k) * For fast keylook up we need a hash table. Each byte of a KeyIDs * should be distributed equally over the 256 possible values (except * for v3 keyIDs but we consider them as not important here). So we - * can just use 10 bits to index a table of 1024 key items. + * can just use 10 bits to index a table of 1024 key items. * Possible optimization: Don not use key_items but other hash_table when the - * duplicates lists gets too large. + * duplicates lists gets too large. */ -static KeyHashTable +static KeyHashTable new_key_hash_table (void) { struct key_item **tbl; @@ -143,7 +144,7 @@ release_key_hash_table (KeyHashTable tbl) xfree (tbl); } -/* +/* * Returns: True if the keyID is in the given hash table */ static int @@ -168,7 +169,7 @@ add_key_hash_table (KeyHashTable tbl, u32 *kid) for (k = tbl[(kid[1] & 0x03ff)]; k; k = k->next) if (k->kid[0] == kid[0] && k->kid[1] == kid[1]) return; /* already in table */ - + kk = new_key_item (); kk->kid[0] = kid[0]; kk->kid[1] = kid[1]; @@ -238,7 +239,7 @@ add_utk (u32 *kid) { struct key_item *k; - for (k = utk_list; k; k = k->next) + for (k = utk_list; k; k = k->next) { if (k->kid[0] == kid[0] && k->kid[1] == kid[1]) { @@ -273,15 +274,15 @@ verify_own_keys(void) return; /* scan the trustdb to find all ultimately trusted keys */ - for (recnum=1; !tdbio_read_record (recnum, &rec, 0); recnum++ ) + for (recnum=1; !tdbio_read_record (recnum, &rec, 0); recnum++ ) { - if ( rec.rectype == RECTYPE_TRUST + if ( rec.rectype == RECTYPE_TRUST && (rec.r.trust.ownertrust & TRUST_MASK) == TRUST_ULTIMATE) { byte *fpr = rec.r.trust.fingerprint; int fprlen; u32 kid[2]; - + /* Problem: We do only use fingerprints in the trustdb but * we need the keyID here to indetify the key; we can only * use that ugly hack to distinguish between 16 and 20 @@ -297,9 +298,9 @@ verify_own_keys(void) } /* Put any --trusted-key keys into the trustdb */ - for (k = user_utk_list; k; k = k->next) + for (k = user_utk_list; k; k = k->next) { - if ( add_utk (k->kid) ) + if ( add_utk (k->kid) ) { /* not yet in trustDB as ultimately trusted */ PKT_public_key pk; @@ -445,7 +446,7 @@ init_trustdb() if(level==0 || level==1) { - int rc = tdbio_set_dbname( dbname, !!level ); + int rc = tdbio_set_dbname (dbname, !!level, &trustdb_args.no_trustdb); if( rc ) log_fatal("can't init trustdb: %s\n", g10_errstr(rc) ); } @@ -496,7 +497,7 @@ init_trustdb() static int trust_letter (unsigned int value) { - switch( (value & TRUST_MASK) ) + switch( (value & TRUST_MASK) ) { case TRUST_UNKNOWN: return '-'; case TRUST_EXPIRED: return 'e'; @@ -545,7 +546,7 @@ uid_trust_string_fixed(PKT_public_key *key,PKT_user_id *uid) const char * trust_value_to_string (unsigned int value) { - switch( (value & TRUST_MASK) ) + switch( (value & TRUST_MASK) ) { case TRUST_UNKNOWN: return _("unknown"); case TRUST_EXPIRED: return _("expired"); @@ -614,7 +615,7 @@ check_trustdb () /* - * Recreate the WoT. + * Recreate the WoT. */ void update_trustdb() @@ -631,6 +632,9 @@ void revalidation_mark (void) { init_trustdb(); + if (trustdb_args.no_trustdb && opt.trust_model == TM_ALWAYS) + return; + /* we simply set the time for the next check to 1 (far back in 1970) * so that a --update-trustdb will be scheduled */ if (tdbio_write_nextcheck (1)) @@ -666,8 +670,10 @@ read_trust_options(byte *trust_model,ulong *created,ulong *nextcheck, TRUSTREC opts; init_trustdb(); - - read_record(0,&opts,RECTYPE_VER); + if (trustdb_args.no_trustdb && opt.trust_model == TM_ALWAYS) + memset (&opts, 0, sizeof opts); + else + read_record(0,&opts,RECTYPE_VER); if(trust_model) *trust_model=opts.r.ver.trust_model; @@ -689,29 +695,29 @@ read_trust_options(byte *trust_model,ulong *created,ulong *nextcheck, *********** Ownertrust et al. **************** ***********************************************/ -static int +static int read_trust_record (PKT_public_key *pk, TRUSTREC *rec) { int rc; - + init_trustdb(); rc = tdbio_search_trust_bypk (pk, rec); if (rc == -1) return -1; /* no record yet */ - if (rc) + if (rc) { log_error ("trustdb: searching trust record failed: %s\n", g10_errstr (rc)); - return rc; + return rc; } - + if (rec->rectype != RECTYPE_TRUST) { log_error ("trustdb: record %lu is not a trust record\n", rec->recnum); - return G10ERR_TRUSTDB; - } - + return G10ERR_TRUSTDB; + } + return 0; } @@ -719,16 +725,19 @@ read_trust_record (PKT_public_key *pk, TRUSTREC *rec) * Return the assigned ownertrust value for the given public key. * The key should be the primary key. */ -unsigned int +unsigned int get_ownertrust ( PKT_public_key *pk) { TRUSTREC rec; int rc; - + + if (trustdb_args.no_trustdb && opt.trust_model == TM_ALWAYS) + return TRUST_UNKNOWN; + rc = read_trust_record (pk, &rec); if (rc == -1) return TRUST_UNKNOWN; /* no record yet */ - if (rc) + if (rc) { tdbio_invalid (); return rc; /* actually never reached */ @@ -737,16 +746,19 @@ get_ownertrust ( PKT_public_key *pk) return rec.r.trust.ownertrust; } -unsigned int +unsigned int get_min_ownertrust (PKT_public_key *pk) { TRUSTREC rec; int rc; - + + if (trustdb_args.no_trustdb && opt.trust_model == TM_ALWAYS) + return TRUST_UNKNOWN; + rc = read_trust_record (pk, &rec); if (rc == -1) return TRUST_UNKNOWN; /* no record yet */ - if (rc) + if (rc) { tdbio_invalid (); return rc; /* actually never reached */ @@ -809,7 +821,10 @@ update_ownertrust (PKT_public_key *pk, unsigned int new_trust ) { TRUSTREC rec; int rc; - + + if (trustdb_args.no_trustdb && opt.trust_model == TM_ALWAYS) + return; + rc = read_trust_record (pk, &rec); if (!rc) { @@ -841,7 +856,7 @@ update_ownertrust (PKT_public_key *pk, unsigned int new_trust ) do_sync (); rc = 0; } - else + else { tdbio_invalid (); } @@ -854,6 +869,9 @@ update_min_ownertrust (u32 *kid, unsigned int new_trust ) TRUSTREC rec; int rc; + if (trustdb_args.no_trustdb && opt.trust_model == TM_ALWAYS) + return; + pk = xmalloc_clear (sizeof *pk); rc = get_pubkey (pk, kid); if (rc) @@ -895,7 +913,7 @@ update_min_ownertrust (u32 *kid, unsigned int new_trust ) do_sync (); rc = 0; } - else + else { tdbio_invalid (); } @@ -908,7 +926,10 @@ clear_ownertrusts (PKT_public_key *pk) { TRUSTREC rec; int rc; - + + if (trustdb_args.no_trustdb && opt.trust_model == TM_ALWAYS) + return 0; + rc = read_trust_record (pk, &rec); if (!rc) { @@ -936,8 +957,8 @@ clear_ownertrusts (PKT_public_key *pk) return 0; } -/* - * Note: Caller has to do a sync +/* + * Note: Caller has to do a sync */ static void update_validity (PKT_public_key *pk, PKT_user_id *uid, @@ -956,7 +977,7 @@ update_validity (PKT_public_key *pk, PKT_user_id *uid, return; } if (rc == -1) /* no record yet - create a new one */ - { + { size_t dummy; rc = 0; @@ -1011,6 +1032,8 @@ cache_disabled_value(PKT_public_key *pk) return (pk->is_disabled==2); init_trustdb(); + if (trustdb_args.no_trustdb) + return 0; /* No trustdb => not disabled. */ rc = read_trust_record (pk, &trec); if (rc && rc != -1) @@ -1020,10 +1043,10 @@ cache_disabled_value(PKT_public_key *pk) } if (rc == -1) /* no record found, so assume not disabled */ goto leave; - + if(trec.r.trust.ownertrust & TRUST_FLAG_DISABLED) disabled=1; - + /* Cache it for later so we don't need to look at the trustdb every time */ if(disabled) @@ -1041,6 +1064,9 @@ check_trustdb_stale(void) static int did_nextcheck=0; init_trustdb (); + if (trustdb_args.no_trustdb) + return; /* No trustdb => can't be stale. */ + if (!did_nextcheck && (opt.trust_model==TM_PGP || opt.trust_model==TM_CLASSIC)) { @@ -1051,7 +1077,7 @@ check_trustdb_stale(void) if ((scheduled && scheduled <= make_timestamp ()) || pending_check_trustdb) { - if (opt.no_auto_check_trustdb) + if (opt.no_auto_check_trustdb) { pending_check_trustdb = 1; log_info (_("please do a --check-trustdb\n")); @@ -1068,7 +1094,7 @@ check_trustdb_stale(void) /* * Return the validity information for PK. If the namehash is not * NULL, the validity of the corresponsing user ID is returned, - * otherwise, a reasonable value for the entire key is returned. + * otherwise, a reasonable value for the entire key is returned. */ unsigned int get_validity (PKT_public_key *pk, PKT_user_id *uid) @@ -1084,6 +1110,14 @@ get_validity (PKT_public_key *pk, PKT_user_id *uid) namehash_from_uid(uid); init_trustdb (); + + /* If we have no trustdb (which also means it has not been created) + and the trust-model is always, we don't know the validity - + return immediately. If we won't do that the tdbio code would try + to open the trustdb and run into a fatal error. */ + if (trustdb_args.no_trustdb && opt.trust_model == TM_ALWAYS) + return TRUST_UNKNOWN; + check_trustdb_stale(); keyid_from_pk (pk, kid); @@ -1097,7 +1131,7 @@ get_validity (PKT_public_key *pk, PKT_user_id *uid) log_error ("error getting main key %s of subkey %s: %s\n", tempkeystr, keystr(kid), g10_errstr(rc)); xfree(tempkeystr); - validity = TRUST_UNKNOWN; + validity = TRUST_UNKNOWN; goto leave; } } @@ -1120,7 +1154,7 @@ get_validity (PKT_public_key *pk, PKT_user_id *uid) } if (rc == -1) /* no record found */ { - validity = TRUST_UNKNOWN; + validity = TRUST_UNKNOWN; goto leave; } @@ -1153,7 +1187,7 @@ get_validity (PKT_public_key *pk, PKT_user_id *uid) recno = vrec.r.valid.next; } - + if ( (trec.r.trust.ownertrust & TRUST_FLAG_DISABLED) ) { validity |= TRUST_FLAG_DISABLED; @@ -1172,7 +1206,7 @@ get_validity (PKT_public_key *pk, PKT_user_id *uid) * I initially designed it that way */ if (main_pk->has_expired || pk->has_expired) validity = (validity & ~TRUST_MASK) | TRUST_EXPIRED; - + if (pending_check_trustdb) validity |= TRUST_FLAG_PENDING_CHECK; @@ -1307,7 +1341,7 @@ ask_ownertrust (u32 *kid,int minimum) keystr(kid), g10_errstr(rc) ); return TRUST_UNKNOWN; } - + if(opt.force_ownertrust) { log_info("force trust for key %s to %s\n", @@ -1380,7 +1414,7 @@ dump_key_array (int depth, struct key_array *keys) } } } -} +} static void @@ -1403,7 +1437,7 @@ store_validation_status (int depth, KBNODE keyblock, KeyHashTable stored) status = TRUST_UNDEFINED; else status = 0; - + if (status) { update_validity (keyblock->pkt->pkt.public_key, @@ -1418,7 +1452,7 @@ store_validation_status (int depth, KBNODE keyblock, KeyHashTable stored) if (any) do_sync (); -} +} /* * check whether the signature sig is in the klist k @@ -1450,7 +1484,7 @@ mark_usable_uid_certs (KBNODE keyblock, KBNODE uidnode, { KBNODE node; PKT_signature *sig; - + /* first check all signatures */ for (node=uidnode->next; node; node = node->next) { @@ -1483,7 +1517,7 @@ mark_usable_uid_certs (KBNODE keyblock, KBNODE uidnode, continue; } node->flag |= 1<<9; - } + } /* reset the remaining flags */ for (; node; node = node->next) node->flag &= ~(1<<8 | 1<<9 | 1<<10 | 1<<11 | 1<<12); @@ -1531,7 +1565,7 @@ mark_usable_uid_certs (KBNODE keyblock, KBNODE uidnode, older: if signode was older then we don't want to take n as signode is nonrevocable. If n was older then we're automatically fine. */ - + if(((IS_UID_SIG(signode->pkt->pkt.signature) && !signode->pkt->pkt.signature->flags.revocable && (signode->pkt->pkt.signature->expiredate==0 || @@ -1547,7 +1581,7 @@ mark_usable_uid_certs (KBNODE keyblock, KBNODE uidnode, n was older then we don't want to take signode as n is nonrevocable. If signode was older then we're automatically fine. */ - + if((!(IS_UID_SIG(signode->pkt->pkt.signature) && !signode->pkt->pkt.signature->flags.revocable && (signode->pkt->pkt.signature->expiredate==0 || @@ -1578,7 +1612,7 @@ mark_usable_uid_certs (KBNODE keyblock, KBNODE uidnode, sig = signode->pkt->pkt.signature; if (IS_UID_SIG (sig)) - { /* this seems to be a usable one which is not revoked. + { /* this seems to be a usable one which is not revoked. * Just need to check whether there is an expiration time, * We do the expired certification after finding a suitable * certification, the assumption is that a signator does not @@ -1587,7 +1621,7 @@ mark_usable_uid_certs (KBNODE keyblock, KBNODE uidnode, * different expiration time */ const byte *p; u32 expire; - + p = parse_sig_subpkt (sig->hashed, SIGSUBPKT_SIG_EXPIRE, NULL ); expire = p? sig->timestamp + buffer_to_u32(p) : 0; @@ -1674,7 +1708,7 @@ clean_sigs_from_uid(KBNODE keyblock,KBNODE uidnode,int noisy,int self_only) delete_kbnode(node); deleted++; } - + return deleted; } @@ -1931,7 +1965,7 @@ validate_one_keyblock (KBNODE kb, struct key_item *klist, { if (uid->help_full_count >= opt.completes_needed || uid->help_marginal_count >= opt.marginals_needed ) - uidnode->flag |= 4; + uidnode->flag |= 4; else if (uid->help_full_count || uid->help_marginal_count) uidnode->flag |= 2; uidnode->flag |= 1; @@ -1946,7 +1980,7 @@ validate_one_keyblock (KBNODE kb, struct key_item *klist, issigned = 0; get_validity_counts(pk,uid); - mark_usable_uid_certs (kb, uidnode, main_kid, klist, + mark_usable_uid_certs (kb, uidnode, main_kid, klist, curtime, next_expire); } else if (node->pkt->pkttype == PKT_SIGNATURE @@ -1954,7 +1988,7 @@ validate_one_keyblock (KBNODE kb, struct key_item *klist, { /* Note that we are only seeing unrevoked sigs here */ PKT_signature *sig = node->pkt->pkt.signature; - + kr = is_in_klist (klist, sig); /* If the trust_regexp does not match, it's as if the sig did not exist. This is safe for non-trust sigs as well @@ -2047,7 +2081,7 @@ validate_one_keyblock (KBNODE kb, struct key_item *klist, { if (uid->help_full_count >= opt.completes_needed || uid->help_marginal_count >= opt.marginals_needed ) - uidnode->flag |= 4; + uidnode->flag |= 4; else if (uid->help_full_count || uid->help_marginal_count) uidnode->flag |= 2; uidnode->flag |= 1; @@ -2070,7 +2104,7 @@ search_skipfnc (void *opaque, u32 *kid, PKT_user_id *dummy) * kllist. The caller has to pass keydb handle so that we don't use * to create our own. Returns either a key_array or NULL in case of * an error. No results found are indicated by an empty array. - * Caller hast to release the returned array. + * Caller hast to release the returned array. */ static struct key_array * validate_key_list (KEYDB_HANDLE hd, KeyHashTable full_trust, @@ -2081,11 +2115,11 @@ validate_key_list (KEYDB_HANDLE hd, KeyHashTable full_trust, size_t nkeys, maxkeys; int rc; KEYDB_SEARCH_DESC desc; - + maxkeys = 1000; keys = xmalloc ((maxkeys+1) * sizeof *keys); nkeys = 0; - + rc = keydb_search_reset (hd); if (rc) { @@ -2110,21 +2144,21 @@ validate_key_list (KEYDB_HANDLE hd, KeyHashTable full_trust, xfree (keys); return NULL; } - + desc.mode = KEYDB_SEARCH_MODE_NEXT; /* change mode */ do { PKT_public_key *pk; - + rc = keydb_get_keyblock (hd, &keyblock); - if (rc) + if (rc) { log_error ("keydb_get_keyblock failed: %s\n", g10_errstr(rc)); xfree (keys); return NULL; } - - if ( keyblock->pkt->pkttype != PKT_PUBLIC_KEY) + + if ( keyblock->pkt->pkttype != PKT_PUBLIC_KEY) { log_debug ("ooops: invalid pkttype %d encountered\n", keyblock->pkt->pkttype); @@ -2134,7 +2168,7 @@ validate_key_list (KEYDB_HANDLE hd, KeyHashTable full_trust, } /* prepare the keyblock for further processing */ - merge_keys_and_selfsig (keyblock); + merge_keys_and_selfsig (keyblock); clear_kbnode_flags (keyblock); pk = keyblock->pkt->pkt.public_key; if (pk->has_expired || pk->is_revoked) @@ -2171,9 +2205,9 @@ validate_key_list (KEYDB_HANDLE hd, KeyHashTable full_trust, release_kbnode (keyblock); keyblock = NULL; - } + } while ( !(rc = keydb_search (hd, &desc, 1)) ); - if (rc && rc != -1) + if (rc && rc != -1) { log_error ("keydb_search_next failed: %s\n", g10_errstr(rc)); xfree (keys); @@ -2182,7 +2216,7 @@ validate_key_list (KEYDB_HANDLE hd, KeyHashTable full_trust, keys[nkeys].keyblock = NULL; return keys; -} +} /* Caller must sync */ static void @@ -2192,7 +2226,7 @@ reset_trust_records(void) ulong recnum; int count = 0, nreset = 0; - for (recnum=1; !tdbio_read_record (recnum, &rec, 0); recnum++ ) + for (recnum=1; !tdbio_read_record (recnum, &rec, 0); recnum++ ) { if(rec.rectype==RECTYPE_TRUST) { @@ -2231,7 +2265,7 @@ reset_trust_records(void) * Step 2: loop max_cert_times * Step 3: if OWNERTRUST of any key in klist is undefined * ask user to assign ownertrust - * Step 4: Loop over all keys in the keyDB which are not marked seen + * Step 4: Loop over all keys in the keyDB which are not marked seen * Step 5: if key is revoked or expired * mark key as seen * continue loop at Step 4 @@ -2243,7 +2277,7 @@ reset_trust_records(void) * End Loop * Step 8: Build a new klist from all fully trusted keys from step 6 * End Loop - * Ready + * Ready * */ static int @@ -2313,7 +2347,7 @@ validate_keys (int interactive) if ( pk->expiredate && pk->expiredate >= start_time && pk->expiredate < next_expire) next_expire = pk->expiredate; - + release_kbnode (keyblock); do_sync (); } @@ -2389,7 +2423,7 @@ validate_keys (int interactive) /* Find all keys which are signed by a key in kdlist */ keys = validate_key_list (kdb, full_trust, klist, start_time, &next_expire); - if (!keys) + if (!keys) { log_error ("validate_key_list failed\n"); rc = G10ERR_GENERAL; @@ -2407,9 +2441,9 @@ validate_keys (int interactive) store_validation_status (depth, kar->keyblock, stored); log_info (_("depth: %d valid: %3d signed: %3d" - " trust: %d-, %dq, %dn, %dm, %df, %du\n"), + " trust: %d-, %dq, %dn, %dm, %df, %du\n"), depth, valids, key_count, ot_unknown, ot_undefined, - ot_never, ot_marginal, ot_full, ot_ultimate ); + ot_never, ot_marginal, ot_full, ot_ultimate ); /* Build a new kdlist from all fully valid keys in KEYS */ if (klist != utk_list) @@ -2471,10 +2505,10 @@ validate_keys (int interactive) if (!rc && !quit) /* mark trustDB as checked */ { if (next_expire == 0xffffffff || next_expire < start_time ) - tdbio_write_nextcheck (0); + tdbio_write_nextcheck (0); else { - tdbio_write_nextcheck (next_expire); + tdbio_write_nextcheck (next_expire); log_info (_("next trustdb check due at %s\n"), strtimestamp (next_expire)); } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From gniibe at fsij.org Wed Jan 15 07:05:27 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 15 Jan 2014 15:05:27 +0900 Subject: Adding the secp256k1 curve for ECDSA In-Reply-To: <52D53379.4080404@fsij.org> References: <52D53379.4080404@fsij.org> Message-ID: <1389765927.1927.8.camel@cfw2.gniibe.org> On 2014-01-14 at 21:54 +0900, NIIBE Yutaka wrote: > I added support of the secp256k1 curve in libgcrypt. Next, I'd like > to add a feature of ECDSA with secp256k1 to GnuPG. As a start, I add OID of secp256k1 and add an entry for --gen-key. Here it is. OK to push to master? diff --git a/common/openpgp-oid.c b/common/openpgp-oid.c index 05b1a40..28567b7 100644 --- a/common/openpgp-oid.c +++ b/common/openpgp-oid.c @@ -310,6 +310,11 @@ openpgp_curve_to_oid (const char *name, unsigned int *r_nbits) oidstr = "1.3.36.3.3.2.8.1.1.13"; nbits = 512; } + else if (!strcmp (name, "secp256k1")) + { + oidstr = "1.3.132.0.10"; + nbits = 256; + } else oidstr = NULL; @@ -333,6 +338,8 @@ openpgp_oid_to_curve (const char *oid) name = "Ed25519"; else if (!strcmp (oid, "1.2.840.10045.3.1.7")) name = "nistp256"; + else if (!strcmp (oid, "1.3.132.0.10")) + name = "secp256k1"; else if (!strcmp (oid, "1.3.132.0.34")) name = "nistp384"; else if (!strcmp (oid, "1.3.132.0.35")) diff --git a/g10/keygen.c b/g10/keygen.c index 4bb8bba..7582b0b 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -2062,6 +2062,7 @@ ask_curve (void) { "brainpoolP256r1", 0, 1, "Brainpool P-256" }, { "brainpoolP384r1", 0, 1, "Brainpool P-384" }, { "brainpoolP512r1", 0, 1, "Brainpool P-512" }, + { "secp256k1", 0, 1 }, }; int idx; char *answer; -- From gniibe at fsij.org Wed Jan 15 07:12:29 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 15 Jan 2014 15:12:29 +0900 Subject: agent_is_eddsa_key is broken currently Message-ID: <1389766349.1927.10.camel@cfw2.gniibe.org> With the development version of GnuPG (master branch), I generated secp256k1 key. However, in the function agent_pksign_do, it is recognized a key for EdDSA, because the function agent_is_eddsa_key returns TRUE. I think that it's forgotten to be edited, copying agent_is_dsa_key. Possible edit would be: diff --git a/agent/findkey.c b/agent/findkey.c index aa2c6a2..6464b02 100644 --- a/agent/findkey.c +++ b/agent/findkey.c @@ -812,14 +812,10 @@ agent_is_eddsa_key (gcry_sexp_t s_key) return 0; if (key_parms_from_sexp (s_key, NULL, algoname, sizeof algoname, NULL, 0)) - return 0; /* Error - assume it is not an DSA key. */ + return 0; /* Error - assume it is not an EdDSA key. */ - if (!strcmp (algoname, "dsa")) - return GCRY_PK_DSA; - else if (!strcmp (algoname, "ecc")) - return GCRY_PK_ECDSA; /* FIXME: Check for the EdDSA flag. */ - else if (!strcmp (algoname, "ecdsa")) - return GCRY_PK_ECDSA; + if (!strcmp (algoname, "eddsa")) + return 1; else return 0; } -- From wk at gnupg.org Wed Jan 15 13:13:06 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 15 Jan 2014 13:13:06 +0100 Subject: Adding the secp256k1 curve for ECDSA In-Reply-To: <1389765927.1927.8.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Wed, 15 Jan 2014 15:05:27 +0900") References: <52D53379.4080404@fsij.org> <1389765927.1927.8.camel@cfw2.gniibe.org> Message-ID: <874n555tpp.fsf@vigenere.g10code.de> On Wed, 15 Jan 2014 07:05, gniibe at fsij.org said: > Here it is. OK to push to master? ACK. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jan 15 13:18:43 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 15 Jan 2014 13:18:43 +0100 Subject: gpg --trust-model=always sometimes fails with fatal error as of 1.4.16 In-Reply-To: <87sisp51gp.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 14 Jan 2014 23:11:02 -0500") References: <87sisp51gp.fsf@alice.fifthhorseman.net> Message-ID: <87zjmx4evw.fsf@vigenere.g10code.de> On Wed, 15 Jan 2014 05:11, dkg at fifthhorseman.net said: > The change seems to be related to upstream's relatively recent change > 2528178e7e2fac6454dd988121167305db7c71d9 (replicated below), which from > the comment log appears to try to address the issue, but maybe missed a > corner case. > > Werner, perhaps you can comment on this? IIRC, I did this change to help popularity-contest. It is quite possible that missed a case. I don't think that I can go after it this week. Thus I'd appreciate if someone could dig into it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jan 15 13:23:51 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 15 Jan 2014 13:23:51 +0100 Subject: agent_is_eddsa_key is broken currently In-Reply-To: <1389766349.1927.10.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Wed, 15 Jan 2014 15:12:29 +0900") References: <1389766349.1927.10.camel@cfw2.gniibe.org> Message-ID: <87vbxl4enc.fsf@vigenere.g10code.de> On Wed, 15 Jan 2014 07:12, gniibe at fsij.org said: > I think that it's forgotten to be edited, copying agent_is_dsa_key. Definitely. I stopped working on the Eddsa code after realizing that it will be better to have a different OpenPGP algorithm ID for this signature algorithms (EdDSA is basically a Schnorr signature and not a ECDSA signature) Please push a fix. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Thu Jan 16 02:10:15 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 16 Jan 2014 10:10:15 +0900 Subject: agent: Not remove SSH socket when already running. Message-ID: <1389834615.5861.2.camel@cfw2.gniibe.org> Hello, I tried to push my changes to master, and I found another problem. When SSH support is enabled and gpg-agent is already running, the socket for SSH will be removed. (And I can't use SSH.) This is obvious bug and simple fix, so, I'm going to push this. * agent/gpg-agent.c (main): Defer setting of socket_name_ssh to avoid removal of the socket when it will die in create_server_socket for socket_name. diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index ed664ea..1e60717 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -1045,13 +1045,14 @@ main (int argc, char **argv ) /* Create the sockets. */ socket_name = create_socket_name (GPG_AGENT_SOCK_NAME, "gpg-XXXXXX/"GPG_AGENT_SOCK_NAME); - if (opt.ssh_support) - socket_name_ssh = create_socket_name - (GPG_AGENT_SSH_SOCK_NAME, "gpg-XXXXXX/"GPG_AGENT_SSH_SOCK_NAME); fd = create_server_socket (socket_name, 0, &socket_nonce); if (opt.ssh_support) - fd_ssh = create_server_socket (socket_name_ssh, 1, &socket_nonce_ssh); + { + socket_name_ssh = create_socket_name + (GPG_AGENT_SSH_SOCK_NAME, "gpg-XXXXXX/"GPG_AGENT_SSH_SOCK_NAME); + fd_ssh = create_server_socket (socket_name_ssh, 1, &socket_nonce_ssh); + } else fd_ssh = GNUPG_INVALID_FD; -- From gniibe at fsij.org Thu Jan 16 08:48:36 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 16 Jan 2014 16:48:36 +0900 Subject: gpgkey2bc: Generating address of Bitcoin from public key Message-ID: <1389858516.16357.2.camel@cfw2.gniibe.org> Hello, Attached 'gpgkey2bc.py'. Few people use OpenPGP key for OpenSSH, but I think that this is very useful feature of GnuPG. There is a command 'gpgkey2ssh' to convert OpenPGP key to SSH key. Likewise, I write 'gpgkey2bc.py' to convert OpenPGP key to Bitcoin address. This requires Python 3.2 or later, and the key should be a subkey of secp256k1. After getting my public key on keyserver, you can get my Bitcoin's address by: $ python3.3 gpgkey2bc.py 975B9053 No, I haven't had wallet yet. You could give me some pressure by sending some Satoshi to my address. :-p Here is a session creating a subkey of secp256k1. ==================================== $ gpg2 --version gpg (GnuPG) 2.1.0-beta285 libgcrypt 1.7.0-beta31 NOTE: THIS IS A DEVELOPMENT VERSION! It is only intended for test purposes and should NOT be used in a production environment or with production keys! Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECC, ECC Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES128, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 $ gpg2 --expert --edit-key 4ca7babe @GPG@ (@GNUPG@) 2.1.0-beta285; Copyright (C) 2012 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! Secret key is available. pub 2048R/4CA7BABE created: 2010-10-15 expires: never usage: SC trust: ultimate validity: ultimate sub 2048R/084239CF created: 2010-10-15 expires: never usage: E sub 2048R/5BB065DC created: 2010-10-22 expires: never usage: A [ultimate] (1). NIIBE Yutaka [ultimate] (2) NIIBE Yutaka gpg> addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (10) ECDSA (sign only) (11) ECDSA (set your own capabilities) (12) ECDH (encrypt only) (13) Existing key Your selection? 11 Possible actions for a ECC key: Sign Authenticate Current allowed actions: Sign (S) Toggle the sign capability (A) Toggle the authenticate capability (Q) Finished Your selection? a Possible actions for a ECC key: Sign Authenticate Current allowed actions: Sign Authenticate (S) Toggle the sign capability (A) Toggle the authenticate capability (Q) Finished Your selection? q Please select which elliptic curve you want: (1) Curve 25519 (2) NIST P-256 (3) NIST P-384 (4) NIST P-521 (5) Brainpool P-256 (6) Brainpool P-384 (7) Brainpool P-512 (8) secp256k1 Your selection? 8 Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. pub 2048R/4CA7BABE created: 2010-10-15 expires: never usage: SC trust: ultimate validity: ultimate sub 2048R/084239CF created: 2010-10-15 expires: never usage: E sub 2048R/5BB065DC created: 2010-10-22 expires: never usage: A sub 256E/975B9053 created: 2014-01-16 expires: never usage: SA [ultimate] (1). NIIBE Yutaka [ultimate] (2) NIIBE Yutaka gpg> quit Save changes? (y/N) y $ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgkey2bc.py Type: text/x-python Size: 1895 bytes Desc: not available URL: From wk at gnupg.org Thu Jan 16 11:47:08 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Jan 2014 11:47:08 +0100 Subject: human readable key algorithm (was: gpgkey2bc: Generating address of Bitcoin from public key) In-Reply-To: <1389858516.16357.2.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Thu, 16 Jan 2014 16:48:36 +0900") References: <1389858516.16357.2.camel@cfw2.gniibe.org> Message-ID: <87bnzc430z.fsf@vigenere.g10code.de> On Thu, 16 Jan 2014 08:48, gniibe at fsij.org said: > Attached 'gpgkey2bc.py'. Cool. Feel free to put it under tools/. > sub 256E/975B9053 created: 2014-01-16 expires: never usage: SA Which shows one of the little things I have not found a solution so far: The "256E" is not very descriptive. With RSA and DSA things were easy because there was no need for domain parameters or we use random ones. With EC things changes because we use fixed domain parameters (aka the curve name). In the example 256 may stand for all kind of curves and some people will probably like to see whether that is a NIST curve or some other curve with a more trustworthy origin. Well, for Curve25519 we the 255 bit would give a clue but having the curve name would probably be better. The --with-colons output already has this information. One idea how to change it would be to use descriptions like: nistp256/12345678 secp256k1/975B9053 ed25519/87654321 Given that a curve name never starts with a digit, this can easily be distinguished from RSA/Elgamal/DSA key sizes. There are two drawbacks: The fixed column format of the key listing can't be kept. For sure there are scripts which will break if they see such key specifications. Another idea would be to use a GnuPG specific mapping of curve names to to simple identifiers: 1E/12345678 2E/975B9053 11E/87654321 Opinions? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Thu Jan 16 14:30:21 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 16 Jan 2014 22:30:21 +0900 Subject: human readable key algorithm (was: gpgkey2bc: Generating address of Bitcoin from public key) In-Reply-To: <87bnzc430z.fsf@vigenere.g10code.de> References: <1389858516.16357.2.camel@cfw2.gniibe.org> <87bnzc430z.fsf@vigenere.g10code.de> Message-ID: <1389879021.4429.0.camel@latx1.gniibe.org> On 2014-01-16 at 11:47 +0100, Werner Koch wrote: > On Thu, 16 Jan 2014 08:48, gniibe at fsij.org said: > > > Attached 'gpgkey2bc.py'. > > Cool. Feel free to put it under tools/. Thanks. I think that it's a proof of concept (less checking, no robustness, etc.), and I'm afraid of Python version dependency. For real use, it would be better to extend gpgkey2ssh to support Bitcoin address, say, with --btc option. I'll look into gpgkey2ssh. N.B. I don't recommend using Bitcoin, per se. It's a bit contradictory if GnuPG (GNU Privacy Guard) pushed something with no or less privacy. ^^^^^^^^^^^^^ My hack only means that I'm going to accept BTC for people who already use Bitcoin and it's GnuPG where I want to put my secret key. Nevertheless, it's interesting that you can send BTC to your friend when you have his OpenPGP key with a subkey of secp256k1 (even if he hasn't been Bitcoin user yet, just owning private key of secp256k1 curve). Anyhow, this is very good opportunity for me to rethink about network and privacy. > Which shows one of the little things I have not found a solution so far: > > The "256E" is not very descriptive. [...] > One idea how to change it would be to use descriptions like: > > nistp256/12345678 > secp256k1/975B9053 > ed25519/87654321 I like this, but other options are OK too. Besides, there is another place: --card-status. We discussed last year and currently it's like "256E" (for ECDSA NIST P-256) or "256e" (ECDH NIST P-256): http://lists.gnupg.org/pipermail/gnupg-devel/2013-February/027410.html This is needed to fix, too. We need to consider updating of ECC support for OpenPGP card specification as well, anyway. -- From wk at gnupg.org Thu Jan 16 18:33:10 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Jan 2014 18:33:10 +0100 Subject: human readable key algorithm In-Reply-To: <1389879021.4429.0.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Thu, 16 Jan 2014 22:30:21 +0900") References: <1389858516.16357.2.camel@cfw2.gniibe.org> <87bnzc430z.fsf@vigenere.g10code.de> <1389879021.4429.0.camel@latx1.gniibe.org> Message-ID: <87zjmv3k89.fsf@vigenere.g10code.de> On Thu, 16 Jan 2014 14:30, gniibe at fsij.org said: > robustness, etc.), and I'm afraid of Python version dependency. For > real use, it would be better to extend gpgkey2ssh to support Bitcoin > address, say, with --btc option. I'll look into gpgkey2ssh. Well, gpgkey2ssh is also just a debugging aid and not really robust. For example it runs "gpg" and not the gpg version from the same package. Frankly, I never used it and I would need to read the code to see for what it is used. > N.B. I don't recommend using Bitcoin, per se. It's a bit > contradictory if GnuPG (GNU Privacy Guard) pushed something with no or > less privacy. ^^^^^^^^^^^^^ Creating signature neither provides privacy but is nevertheless useful to enable encryption. > when you have his OpenPGP key with a subkey of secp256k1 (even if he > hasn't been Bitcoin user yet, just owning private key of secp256k1 Adding notation data to the key or a newly defined keyflag would be useful to identify such a subkey. The question is whether we can deploy this before the BC bubble bursts. > Besides, there is another place: --card-status. We discussed last > year and currently it's like "256E" (for ECDSA NIST P-256) or "256e" Sure. > This is needed to fix, too. We need to consider updating of ECC > support for OpenPGP card specification as well, anyway. I have not followed Achims draft development closely. We should address non-ECDSA schemes. Maybe simply by providing a DO with a list of OIDs for supported curves. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Thu Jan 16 23:00:36 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 16 Jan 2014 17:00:36 -0500 Subject: usage flags for bitcoin addresses on OpenPGP keys [was: Re: human readable key algorithm] In-Reply-To: <87zjmv3k89.fsf@vigenere.g10code.de> References: <1389858516.16357.2.camel@cfw2.gniibe.org> <87bnzc430z.fsf@vigenere.g10code.de> <1389879021.4429.0.camel@latx1.gniibe.org> <87zjmv3k89.fsf@vigenere.g10code.de> Message-ID: <52D85684.7070808@fifthhorseman.net> On 01/16/2014 12:33 PM, Werner Koch wrote: > Adding notation data to the key or a newly defined keyflag would be > useful to identify such a subkey. The question is whether we can deploy > this before the BC bubble bursts. I agree with the suggestion to use a notation. In fact, i'd rather not see such a key marked as authentication-capable, because that would imply that it should be used in other authentication contexts (like SSH). I also don't think the key is really used in bitcoin in authentication contexts -- aiui, in bitcoin, the wallet's key is only used for signing an outbound transaction. this isn't an authentication step, it's clearly a digital signature. That said, it's not an OpenPGP digital signature, so maybe the traditional signing flag doesn't make sense either. I certainly wouldn't want attaching such a key to my OpenPGP certificate to make it so that when i sent mail it signed my mail with my bitcoin wallet's key! I note that gpg's notion of "capabilities" doesn't map directly to the usage-flags subpacket anyway (since E maps to multiple usage flags, and some defined usage flags aren't settable). I wonder if gpg should expose a "bitcoin address" capability (within --expert mode) and set such a subkey up as having no usage flags set, and a notation like: extended-usage at gnupg.org=bitcoin in human-readable form, gpg could indicate this as "Usage: B" what do y'all think? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From daniele.athome at gmail.com Fri Jan 17 00:10:51 2014 From: daniele.athome at gmail.com (Daniele Ricci) Date: Fri, 17 Jan 2014 00:10:51 +0100 Subject: [PATCH] Implement more export-options (clean, no-export-attributes) Message-ID: <1389913851-26005-1-git-send-email-daniele.athome@gmail.com> Signed-off-by: Daniele Ricci --- doc/gpgme.texi | 6 ++++++ src/engine-gpg.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++--- src/export.c | 8 ++++++-- src/gpgme.h.in | 2 ++ tests/run-export.c | 26 +++++++++++++++++++++---- 5 files changed, 90 insertions(+), 9 deletions(-) diff --git a/doc/gpgme.texi b/doc/gpgme.texi index 3f31492..1aabbea 100644 --- a/doc/gpgme.texi +++ b/doc/gpgme.texi @@ -3547,6 +3547,12 @@ If this bit is set, the smallest possible key is exported. For OpenPGP keys it removes all signatures except for the latest self-signatures. For X.509 keys it has no effect. + at item GPGME_EXPORT_MODE_CLEAN +If this bit is set, key is exported with only usable signatures. More +specifically, it will exclude all signatures from unusable user IDs and +all unusable signatures, including signatures from keys not present on +the keyring. This is currently only allowed for OpenPGP keys. + @end table diff --git a/src/engine-gpg.c b/src/engine-gpg.c index 2f59bb9..921db93 100644 --- a/src/engine-gpg.c +++ b/src/engine-gpg.c @@ -261,6 +261,40 @@ add_arg (engine_gpg_t gpg, const char *arg) static gpgme_error_t +add_to_last_arg (engine_gpg_t gpg, const char *arg) +{ + struct arg_and_data_s *a; + + assert (gpg); + assert (arg); + + /* Iterate to the last argument. */ + a = gpg->arglist; + while (a) + { + if (!a->next) + break; + + a = a->next; + } + + if (!a) + return gpg_error (GPG_ERR_INV_VALUE); + + a = realloc (a, sizeof *a + strlen (a->arg) + strlen (arg)); + if (!a) + return gpg_error_from_syserror (); + + strcat (a->arg, arg); + + *gpg->argtail = a; + gpg->argtail = &a->next; + + return 0; +} + + +static gpgme_error_t add_data (engine_gpg_t gpg, gpgme_data_t data, int dup_to, int inbound) { struct arg_and_data_s *a; @@ -973,6 +1007,7 @@ build_argv (engine_gpg_t gpg) gpg->argv = argv; gpg->fd_data_map = fd_data_map; + return 0; } @@ -1762,11 +1797,27 @@ export_common (engine_gpg_t gpg, gpgme_export_mode_t mode, gpgme_error_t err = 0; if ((mode & ~(GPGME_EXPORT_MODE_EXTERN - |GPGME_EXPORT_MODE_MINIMAL))) + |GPGME_EXPORT_MODE_MINIMAL + |GPGME_EXPORT_MODE_CLEAN + |GPGME_EXPORT_MODE_NO_ATTRIBUTES))) return gpg_error (GPG_ERR_NOT_SUPPORTED); - if ((mode & GPGME_EXPORT_MODE_MINIMAL)) - err = add_arg (gpg, "--export-options=export-minimal"); + if ((mode & GPGME_EXPORT_MODE_MINIMAL) | + (mode & GPGME_EXPORT_MODE_CLEAN) | + (mode & GPGME_EXPORT_MODE_NO_ATTRIBUTES)) + { + err = add_arg(gpg, "--export-options="); + + if (!err && (mode & GPGME_EXPORT_MODE_MINIMAL)) + err = add_to_last_arg(gpg, "export-minimal,"); + + if (!err && (mode & GPGME_EXPORT_MODE_CLEAN)) + err = add_to_last_arg(gpg, "export-clean,"); + + if (!err && (mode & GPGME_EXPORT_MODE_NO_ATTRIBUTES)) + err = add_to_last_arg(gpg, "no-export-attributes,"); + + } if (err) ; diff --git a/src/export.c b/src/export.c index 81a23b0..9151087 100644 --- a/src/export.c +++ b/src/export.c @@ -45,7 +45,9 @@ export_start (gpgme_ctx_t ctx, int synchronous, const char *pattern, gpgme_error_t err; if ((mode & ~(GPGME_EXPORT_MODE_EXTERN - |GPGME_EXPORT_MODE_MINIMAL))) + |GPGME_EXPORT_MODE_MINIMAL + |GPGME_EXPORT_MODE_CLEAN + |GPGME_EXPORT_MODE_NO_ATTRIBUTES))) return gpg_error (GPG_ERR_INV_VALUE); /* Invalid flags in MODE. */ @@ -116,7 +118,9 @@ export_ext_start (gpgme_ctx_t ctx, int synchronous, const char *pattern[], gpgme_error_t err; if ((mode & ~(GPGME_EXPORT_MODE_EXTERN - |GPGME_EXPORT_MODE_MINIMAL))) + |GPGME_EXPORT_MODE_MINIMAL + |GPGME_EXPORT_MODE_CLEAN + |GPGME_EXPORT_MODE_NO_ATTRIBUTES))) return gpg_error (GPG_ERR_INV_VALUE); /* Invalid flags in MODE. */ if ((mode & GPGME_EXPORT_MODE_EXTERN)) diff --git a/src/gpgme.h.in b/src/gpgme.h.in index 5c4de6b..551ed60 100644 --- a/src/gpgme.h.in +++ b/src/gpgme.h.in @@ -388,6 +388,8 @@ gpgme_pinentry_mode_t; /* The available export mode flags. */ #define GPGME_EXPORT_MODE_EXTERN 2 #define GPGME_EXPORT_MODE_MINIMAL 4 +#define GPGME_EXPORT_MODE_CLEAN 8 +#define GPGME_EXPORT_MODE_NO_ATTRIBUTES 16 typedef unsigned int gpgme_export_mode_t; diff --git a/tests/run-export.c b/tests/run-export.c index 4333208..b0e0771 100644 --- a/tests/run-export.c +++ b/tests/run-export.c @@ -43,6 +43,9 @@ show_usage (int ex) fputs ("usage: " PGM " [options] USERIDS\n\n" "Options:\n" " --verbose run in verbose mode\n" + " --clean remove any unusable user IDs and signatures\n" + " --minimal remove all signatures except self-signatures\n" + " --no-attributes do not include any user attribute\n" " --extern send keys to the keyserver (TAKE CARE!)\n" , stderr); exit (ex); @@ -81,7 +84,22 @@ main (int argc, char **argv) } else if (!strcmp (*argv, "--extern")) { - mode |= GPGME_KEYLIST_MODE_EXTERN; + mode |= GPGME_EXPORT_MODE_EXTERN; + argc--; argv++; + } + else if (!strcmp (*argv, "--clean")) + { + mode |= GPGME_EXPORT_MODE_CLEAN; + argc--; argv++; + } + else if (!strcmp (*argv, "--minimal")) + { + mode |= GPGME_EXPORT_MODE_MINIMAL; + argc--; argv++; + } + else if (!strcmp (*argv, "--no-attributes")) + { + mode |= GPGME_EXPORT_MODE_NO_ATTRIBUTES; argc--; argv++; } else if (!strncmp (*argv, "--", 2)) @@ -131,7 +149,7 @@ main (int argc, char **argv) } /* Now for the actual export. */ - if ((mode & GPGME_KEYLIST_MODE_EXTERN)) + if ((mode & GPGME_EXPORT_MODE_EXTERN)) printf ("sending keys to keyserver\n"); err = gpgme_data_new (&out); @@ -139,11 +157,11 @@ main (int argc, char **argv) gpgme_set_armor (ctx, 1); err = gpgme_op_export_keys (ctx, keyarray, mode, - (mode & GPGME_KEYLIST_MODE_EXTERN)? NULL:out); + (mode & GPGME_EXPORT_MODE_EXTERN)? NULL:out); fail_if_err (err); fflush (NULL); - if (!(mode & GPGME_KEYLIST_MODE_EXTERN)) + if (!(mode & GPGME_EXPORT_MODE_EXTERN)) { fputs ("Begin Result:\n", stdout); print_data (out); -- 1.8.5.2 From nicholas.cole at gmail.com Fri Jan 17 00:09:22 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Thu, 16 Jan 2014 23:09:22 +0000 Subject: usage flags for bitcoin addresses on OpenPGP keys [was: Re: human readable key algorithm] In-Reply-To: <52D85684.7070808@fifthhorseman.net> References: <1389858516.16357.2.camel@cfw2.gniibe.org> <87bnzc430z.fsf@vigenere.g10code.de> <1389879021.4429.0.camel@latx1.gniibe.org> <87zjmv3k89.fsf@vigenere.g10code.de> <52D85684.7070808@fifthhorseman.net> Message-ID: On Thu, Jan 16, 2014 at 10:00 PM, Daniel Kahn Gillmor wrote: > I wonder if gpg should > expose a "bitcoin address" capability (within --expert mode) and set > such a subkey up as having no usage flags set, and a notation like: > > extended-usage at gnupg.org=bitcoin > > in human-readable form, gpg could indicate this as "Usage: B" > > what do y'all think? > > --dkg Yes. Certainly think this should be a notation and not a 'flag'. I'm not even sure that gnupg needs to do much more than show the notation in the standard way it would for any notation. Whatever is added now will need supporting for years, and I'm not convinced myself that Bitcoin is more than a bubble. Even if it isn't, gnupg is hardly a primary tool for handling these keys, and it isn't reasonable to think that gnupg should add special support for every new digital currency. Just my (pun intended) $0.02 From wk at gnupg.org Fri Jan 17 08:45:24 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jan 2014 08:45:24 +0100 Subject: usage flags for bitcoin addresses on OpenPGP keys In-Reply-To: <52D85684.7070808@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 16 Jan 2014 17:00:36 -0500") References: <1389858516.16357.2.camel@cfw2.gniibe.org> <87bnzc430z.fsf@vigenere.g10code.de> <1389879021.4429.0.camel@latx1.gniibe.org> <87zjmv3k89.fsf@vigenere.g10code.de> <52D85684.7070808@fifthhorseman.net> Message-ID: <87zjmv127f.fsf@vigenere.g10code.de> On Thu, 16 Jan 2014 23:00, dkg at fifthhorseman.net said: > some defined usage flags aren't settable). I wonder if gpg should > expose a "bitcoin address" capability (within --expert mode) and set > such a subkey up as having no usage flags set, and a notation like: > > extended-usage at gnupg.org=bitcoin I would be fine with that. We need to see how implementations act upon all zero keyflags. > in human-readable form, gpg could indicate this as "Usage: B" I think this is to specific. An "X" or a "T" may indicate that some extended usage is expected. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jan 17 08:58:58 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jan 2014 08:58:58 +0100 Subject: [PATCH] Implement more export-options (clean, no-export-attributes) In-Reply-To: <1389913851-26005-1-git-send-email-daniele.athome@gmail.com> (Daniele Ricci's message of "Fri, 17 Jan 2014 00:10:51 +0100") References: <1389913851-26005-1-git-send-email-daniele.athome@gmail.com> Message-ID: <87vbxj11kt.fsf@vigenere.g10code.de> On Fri, 17 Jan 2014 00:10, daniele.athome at gmail.com said: > + a = realloc (a, sizeof *a + strlen (a->arg) + strlen (arg)); > + if (!a) > + return gpg_error_from_syserror (); > + > + strcat (a->arg, arg); > + > + *gpg->argtail = a; > + gpg->argtail = &a->next; This assumes that realloc does not change the value of A. realloc may return a pointer to a different memory block. In turn the predecessor of the original A will have a dangling pointer. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Fri Jan 17 09:07:45 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 17 Jan 2014 08:07:45 +0000 Subject: usage flags for bitcoin addresses on OpenPGP keys In-Reply-To: <87zjmv127f.fsf@vigenere.g10code.de> References: <1389858516.16357.2.camel@cfw2.gniibe.org> <87bnzc430z.fsf@vigenere.g10code.de> <1389879021.4429.0.camel@latx1.gniibe.org> <87zjmv3k89.fsf@vigenere.g10code.de> <52D85684.7070808@fifthhorseman.net> <87zjmv127f.fsf@vigenere.g10code.de> Message-ID: On Fri, Jan 17, 2014 at 7:45 AM, Werner Koch wrote: > On Thu, 16 Jan 2014 23:00, dkg at fifthhorseman.net said: > >> some defined usage flags aren't settable). I wonder if gpg should >> expose a "bitcoin address" capability (within --expert mode) and set >> such a subkey up as having no usage flags set, and a notation like: >> >> extended-usage at gnupg.org=bitcoin > > I would be fine with that. We need to see how implementations act upon > all zero keyflags. > >> in human-readable form, gpg could indicate this as "Usage: B" > > I think this is to specific. An "X" or a "T" may indicate that some > extended usage is expected. I'd be willing to bet that gnupg will be around longer than bitcoin.... From daniele.athome at gmail.com Fri Jan 17 10:34:34 2014 From: daniele.athome at gmail.com (Daniele Ricci) Date: Fri, 17 Jan 2014 10:34:34 +0100 Subject: [PATCH] Implement more export-options (clean, no-export-attributes) In-Reply-To: <87vbxj11kt.fsf@vigenere.g10code.de> References: <1389913851-26005-1-git-send-email-daniele.athome@gmail.com> <87vbxj11kt.fsf@vigenere.g10code.de> Message-ID: You're right, sorry. Fixing now. On Fri, Jan 17, 2014 at 8:58 AM, Werner Koch wrote: > On Fri, 17 Jan 2014 00:10, daniele.athome at gmail.com said: >> + a = realloc (a, sizeof *a + strlen (a->arg) + strlen (arg)); >> + if (!a) >> + return gpg_error_from_syserror (); >> + >> + strcat (a->arg, arg); >> + >> + *gpg->argtail = a; >> + gpg->argtail = &a->next; > > This assumes that realloc does not change the value of A. realloc may > return a pointer to a different memory block. In turn the predecessor > of the original A will have a dangling pointer. > > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -- Daniele From daniele.athome at gmail.com Fri Jan 17 10:41:47 2014 From: daniele.athome at gmail.com (Daniele Ricci) Date: Fri, 17 Jan 2014 10:41:47 +0100 Subject: [PATCH] Implement more export-options (clean, no-export-attributes) In-Reply-To: References: <1389913851-26005-1-git-send-email-daniele.athome@gmail.com> <87vbxj11kt.fsf@vigenere.g10code.de> Message-ID: I fixed the dangling pointer issue. This time I have to attach the patch because I'm behind corporate proxy (I only have web access and Gmail is known to break long lines). Sorry for that. On Fri, Jan 17, 2014 at 10:34 AM, Daniele Ricci wrote: > You're right, sorry. Fixing now. > > On Fri, Jan 17, 2014 at 8:58 AM, Werner Koch wrote: >> On Fri, 17 Jan 2014 00:10, daniele.athome at gmail.com said: >>> + a = realloc (a, sizeof *a + strlen (a->arg) + strlen (arg)); >>> + if (!a) >>> + return gpg_error_from_syserror (); >>> + >>> + strcat (a->arg, arg); >>> + >>> + *gpg->argtail = a; >>> + gpg->argtail = &a->next; >> >> This assumes that realloc does not change the value of A. realloc may >> return a pointer to a different memory block. In turn the predecessor >> of the original A will have a dangling pointer. >> >> >> >> Shalom-Salam, >> >> Werner >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> > > > > -- > Daniele -- Daniele -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Implement-more-export-options-clean-no-export-attrib.patch Type: text/x-patch Size: 6906 bytes Desc: not available URL: From smari at immi.is Fri Jan 17 11:44:26 2014 From: smari at immi.is (=?ISO-8859-1?Q?Sm=E1ri_McCarthy?=) Date: Fri, 17 Jan 2014 10:44:26 +0000 Subject: human readable key algorithm In-Reply-To: <87bnzc430z.fsf@vigenere.g10code.de> References: <1389858516.16357.2.camel@cfw2.gniibe.org> <87bnzc430z.fsf@vigenere.g10code.de> Message-ID: <52D9098A.7090302@immi.is> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/16/2014 10:47 AM, Werner Koch wrote: > Which shows one of the little things I have not found a solution so > far: > > The "256E" is not very descriptive. With RSA and DSA things were > easy because there was no need for domain parameters or we use > random ones. With EC things changes because we use fixed domain > parameters (aka the curve name). In the example 256 may stand for > all kind of curves and some people will probably like to see > whether that is a NIST curve or some other curve with a more > trustworthy origin. Well, for Curve25519 we the 255 bit would give > a clue but having the curve name would probably be better. The > --with-colons output already has this information. > > One idea how to change it would be to use descriptions like: > > nistp256/12345678 secp256k1/975B9053 ed25519/87654321 > > Given that a curve name never starts with a digit, this can easily > be distinguished from RSA/Elgamal/DSA key sizes. There are two > drawbacks: The fixed column format of the key listing can't be > kept. For sure there are scripts which will break if they see such > key specifications. > > Another idea would be to use a GnuPG specific mapping of curve > names to to simple identifiers: > > 1E/12345678 2E/975B9053 11E/87654321 > > > Opinions? I like how the subject of this mail is "human readable" but none of the suggestions are. "1E" is meaningless to everybody and "ed25519" is only meaningful to those who have a fair bit of knowledge about things such as Curve 25519. While it would lengthen the descriptor, it might be useful to add a standard prefix that suggests a) that it's an algorithm, b) what family it belongs to, and c) its distinguishing characteristics. So: alg-ec-nistp256/12345678 alg-ec-secp256k1/975B9053 alg-ec-ed25519/87654321 Others might be: alg-f-rsa4096/deadbeef alg-f-dsa2086/beefcafe And of course you could expand this scheme to include other families: alg-dl-aes256 alg-dl-cast alg-sp-keccak .. whatever. (The "families" I used in this mockup were "elliptic curve", "factorization", "discrete logarithm" and "sponge" -- somebody might think it'd be better to use a different family definition scheme, and I would not necessarily disagree.) I'm aware that this is a substantial modification from the current approach, and in theory people should already know that an algorithm is an algorithm and such, but really, people don't, and the current naming scheme is not useful beyond a narrow set of cases. Key naming convention design criteria: the terms must be easily found using a web search engine. I'm sure it's obvious why "11E" is not. - Sm?ri > Shalom-Salam, > > Werner > - -- Sm?ri McCarthy - smari at immi.is - http://immi.is/ Iceland: +354 662 2701 UK: +44 7462 795953 PGP: B221 6FD2 779A E5B5 9D79 743C D5DC 2A79 C2E4 AE92 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIbBAEBAgAGBQJS2QmKAAoJENXcKnnC5K6Sgq4P+P4KWiEgOZeHUIPDjcbM6+5V /+MtpQWUAlCV/c7rxzyLc84xDx1GzV14f+ptD9AxrO6ipTnKOFbtmpnDC5xAvBgP Ptc2LRrWPNuy+vNgHnbqo/gKspDqp3CCxDk6FWk4Ef0hHTFDf7O23lXKUlLmDsYX Ur5Oklr/gPQGhKxpjmMSvlgQA66JFJDe6sjfYKHBTPbvJqRHqrf+0qGyIP6icERB ELb8Vg0/rudAXfp6IVXJM8sYcihqAIFqbbNekj3C5N7Y4i6V4I2M3KyyxHpCk/kh SmBDWmlAF4sPmJ84d8Wz5eje1wTZr1rFu81RbGVSwqGWD0CzGQaS4SezszyQ9s0r wjdysg6FpHNzjmdCukOfJzJ2+4L+q3d5wBrlpjFUoPMMpsuWKOypwmLRAn3GUhi/ JTHX4RkOaCKmGY7OAQ96P8oqPkBgjyNkbnoo7QiX+tmlOkwVC3UlPw5KQx+NHZiK teE0Qo54g+Id2PddEPRQ0p6yMLSRPTFzhWiCvONtdYouXnmW9tazf7Z7wtvbPrzx FFBzc0ZC+/8TtGC3m//CSex6fTXa/7sDJKSwqC9fmyWD+ekbuataHdOgQu4CvZLK UDpJNl/bpIOrbASFB0Jug53lyvUwyjjzct768sEJCS45vOm9nMIOW6d9TNTOAELx 5ZDO6GikIwtL7BNCORY= =3Q4a -----END PGP SIGNATURE----- From wk at gnupg.org Fri Jan 17 14:04:48 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jan 2014 14:04:48 +0100 Subject: human readable key algorithm In-Reply-To: <52D9098A.7090302@immi.is> (=?utf-8?Q?=22Sm=C3=A1ri?= McCarthy"'s message of "Fri, 17 Jan 2014 10:44:26 +0000") References: <1389858516.16357.2.camel@cfw2.gniibe.org> <87bnzc430z.fsf@vigenere.g10code.de> <52D9098A.7090302@immi.is> Message-ID: <87a9eu21zj.fsf@vigenere.g10code.de> On Fri, 17 Jan 2014 11:44, smari at immi.is said: > I like how the subject of this mail is "human readable" but none of > the suggestions are. "1E" is meaningless to everybody and "ed25519" is gpg has two interfaces: The human readable and the machine readable (--with-colons). Agreed, the humans are expected to be PGP/GPG addicts. > While it would lengthen the descriptor, it might be useful to add a > standard prefix that suggests a) that it's an algorithm, b) what > family it belongs to, and c) its distinguishing characteristics. Does not fit nicely into one line or a printout for a signing party > alg-ec-nistp256/12345678 > alg-ec-secp256k1/975B9053 > alg-ec-ed25519/87654321 We know that this is about the public key algorithms. Historically (PGP-2) is has been used to indicate the strength of the key. However at least with EC there is no easy way to compare the key lengths. We could keep this key strength idiom by using scaled strengths (like Intel CPU naming) but I am not keen to start discussing such a mapping table. > alg-f-rsa4096/deadbeef > alg-f-dsa2086/beefcafe Well, I would risk switching from "2048R/xxxxxxxx" to something "rsa2048/xxxxxx" with GnuPG 2.1. It might break things but after all machine interfaces are not supposed to use this information. The algorithm family does not make much sense to me. There are other parameters required for the use of the public key algorithm, which we don't want to put into the key overview. > Key naming convention design criteria: the terms must be easily found > using a web search engine. I'm sure it's obvious why "11E" is not. Makes sense. Changing to rsa4096/deadbeef nistp521/12345678 secp256k1/9abcdef01 would be consistent and even allow scripts (and gpgme) to test whether this is a new style listing or an old style. Shall I change the code for this, so we can do some tests? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Fri Jan 17 17:20:07 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 17 Jan 2014 11:20:07 -0500 Subject: libgcrypt.so has text relocations. This is wasting memory and is a security risk. Please fix. Message-ID: <52D95837.60500@guardianproject.info> Since updating from libgcrypt 1.5.x to the head of master in GPG for Android, I now get this warning from the Android linker: libgcrypt.so has text relocations. This is wasting memory and is a security risk. Please fix. It seems to happen whenever any program that links to libgcrypt starts. This is a bit beyond my knowledge of linking. Anyone have any ideas or pointers? The only thing I could find is this bug in the Android NDK: https://code.google.com/p/android/issues/detail?id=23203 But I'm using NDK r9b, and that issue was apparently fixes in r8c. Attached is the full text of `readelf -a libgcrypt.so`. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: readelf-a-libgcrypt-so.txt.bz2 Type: application/x-bzip Size: 13961 bytes Desc: not available URL: From wich at yuugen.jp Fri Jan 17 17:59:44 2014 From: wich at yuugen.jp (Remko van der Vossen) Date: Sat, 18 Jan 2014 01:59:44 +0900 Subject: libgcrypt.so has text relocations. This is wasting memory and is a security risk. Please fix. In-Reply-To: <52D95837.60500@guardianproject.info> References: <52D95837.60500@guardianproject.info> Message-ID: <20140117165944.GL2697@yuugen.jp> Hi Hans-Christoph, On Fri, Jan 17, 2014 at 11:20:07AM -0500, Hans-Christoph Steiner wrote: > libgcrypt.so has text relocations. This is wasting memory and is a security > risk. Please fix. Is the library perhaps not compiled with -fPIC -fpic? Regards, Remko van der Vossen From hans at guardianproject.info Fri Jan 17 18:48:21 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 17 Jan 2014 12:48:21 -0500 Subject: libgcrypt.so has text relocations. This is wasting memory and is a security risk. Please fix. In-Reply-To: <20140117165944.GL2697@yuugen.jp> References: <52D95837.60500@guardianproject.info> <20140117165944.GL2697@yuugen.jp> Message-ID: <52D96CE5.9060100@guardianproject.info> On 01/17/2014 11:59 AM, Remko van der Vossen wrote: > Hi Hans-Christoph, > > On Fri, Jan 17, 2014 at 11:20:07AM -0500, Hans-Christoph Steiner wrote: >> libgcrypt.so has text relocations. This is wasting memory and is a security >> risk. Please fix. > > Is the library perhaps not compiled with -fPIC -fpic? > > Regards, > > Remko van der Vossen I'm using the build flags that Android sets, looks like it sets -fpic but not -fPIC: make[3]: Entering directory `/var/lib/jenkins/workspace/gnupg-for-android-eighthave/external/libgcrypt/mpi' /bin/bash ../libtool --tag=CC --mode=compile /opt/android-ndk/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc --sysroot=/opt/android-ndk/platforms/android-9/arch-arm -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/var/lib/jenkins/workspace/gnupg-for-android-eighthave/external/data/data/info.guardianproject.gpg/app_opt/include -DANDROID -I/var/lib/jenkins/workspace/gnupg-for-android-eighthave/external/data/data/info.guardianproject.gpg/app_opt/include -fpic -ffunction-sections -funwind-tables -fstack-protector -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -O2 -g -DNDEBUG -fomit-frame-pointer -fstrict-aliasing -funswitch-loops -finline-limit=300 -fvisibility=hidden -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wextra -Wbad-function-cast -Wwrite-strings -Wdeclaration-after-statement -Wno-missing-field-initializers -Wno-sign-compare -Wpointer-arith -MT mpi-add.lo -MD -MP -MF .deps/mpi-add.Tpo -c -o mpi-add.lo mpi-add.c This is compiling for ARM, where according to `man gcc`, -fPIC does not have an effect: -fPIC If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table. This option makes a difference on the m68k, PowerPC and SPARC. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From hans at guardianproject.info Fri Jan 17 19:34:38 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 17 Jan 2014 13:34:38 -0500 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys Message-ID: <52D977BE.5070802@guardianproject.info> On GPG for Android, I've updated to the latest libgcrypt in master (or close to it, its commit 4b7db51ad5d1bf98fd08ca3048f258059eca61a4). Now it seems that any operation that needs a passphrase is crashing somewhere in libgcrypt. I've tried building with auto-detection of CPU which enables Padlock, Intelt DRNG, and NEON. I also tried with --disable-padlock-support --disable-drng-support --disable-neon-support, and seemed to get the same thing. I've also tried running gpg-agent with and without --enable-ssh-support, and same result each time. Here's the basic backtrace: #00 pc 00045fb4 /data/app-lib/info.guardianproject.gpg-1/libgcrypt.so #01 pc 00043d98 /data/app-lib/info.guardianproject.gpg-1/libgcrypt.so #02 pc 00043dc8 /data/app-lib/info.guardianproject.gpg-1/libgcrypt.so #03 pc 00043f8c /data/app-lib/info.guardianproject.gpg-1/libgcrypt.so #04 pc 00019ac0 /data/app-lib/info.guardianproject.gpg-1/libgcrypt.so #05 pc 00018294 /data/app-lib/info.guardianproject.gpg-1/libgcrypt.so #06 pc 000184d0 /data/app-lib/info.guardianproject.gpg-1/libgcrypt.so #07 pc 0000692c /data/app-lib/info.guardianproject.gpg-1/libgcrypt.so (gcry_cipher_decrypt+84) #08 pc 0001fac8 /data/data/info.guardianproject.gpg/app_opt/bin/gpg-agent (agent_askpin+1184) #09 pc 0001ae24 /data/data/info.guardianproject.gpg/app_opt/bin/gpg-agent (ssh_handler_add_identity+1088) #10 pc 00017c4c /data/data/info.guardianproject.gpg/app_opt/bin/gpg-agent (do_one_keyinfo+872) #11 pc 0001b850 /data/data/info.guardianproject.gpg/app_opt/bin/gpg-agent (ssh_handler_sign_request+876) #12 pc 0001d4b8 /data/data/info.guardianproject.gpg/app_opt/bin/gpg-agent (ssh_handler_request_identities+3012) #13 pc 00009d10 /data/data/info.guardianproject.gpg/app_opt/bin/gpg-agent #14 pc 0000632c /data/app-lib/info.guardianproject.gpg-1/libassuan.so #15 pc 000066e4 /data/app-lib/info.guardianproject.gpg-1/libassuan.so (assuan_process+204) #16 pc 00010b88 /data/data/info.guardianproject.gpg/app_opt/bin/gpg-agent (option_handler+624) #17 pc 00007a64 /data/data/info.guardianproject.gpg/app_opt/bin/gpg-agent #18 pc 00001274 /data/app-lib/info.guardianproject.gpg-1/libnpth.so #19 pc 0000d170 /system/lib/libc.so (__thread_entry+72) #20 pc 0000d308 /system/lib/libc.so (pthread_create+240) From the bug report in our tracker, you can download the complete build log, a debug log from the Android app, a log from gpg-agent, and a log from gpgme: https://dev.guardianproject.info/issues/2888 .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Jan 17 21:35:41 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jan 2014 21:35:41 +0100 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52D977BE.5070802@guardianproject.info> (Hans-Christoph Steiner's message of "Fri, 17 Jan 2014 13:34:38 -0500") References: <52D977BE.5070802@guardianproject.info> Message-ID: <87ob3az6qq.fsf@vigenere.g10code.de> On Fri, 17 Jan 2014 19:34, hans at guardianproject.info said: > On GPG for Android, I've updated to the latest libgcrypt in master (or close > to it, its commit 4b7db51ad5d1bf98fd08ca3048f258059eca61a4). Now it seems Did the full Libgcrypt test suite pass? In general it is advisable to use LIBGCRYPT-1-6-BRANCH and not master. Of course we are glad about any bug reports but we may not be able to follow up on such reports. If the test suite passed, please try with 1.6 to see whether it makes a difference. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Sat Jan 18 03:59:34 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 17 Jan 2014 21:59:34 -0500 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <87ob3az6qq.fsf@vigenere.g10code.de> References: <52D977BE.5070802@guardianproject.info> <87ob3az6qq.fsf@vigenere.g10code.de> Message-ID: <52D9EE16.5040500@guardianproject.info> On 01/17/2014 03:35 PM, Werner Koch wrote: > On Fri, 17 Jan 2014 19:34, hans at guardianproject.info said: >> On GPG for Android, I've updated to the latest libgcrypt in master (or close >> to it, its commit 4b7db51ad5d1bf98fd08ca3048f258059eca61a4). Now it seems > > Did the full Libgcrypt test suite pass? Ok, I'm working on getting that running now. Its failing on AES. Building for Android means cross-compiling, so running the tests means manually scripting, unless someone knows some amazing autotools tricks to make `make check` run in an Android emulator. > In general it is advisable to use LIBGCRYPT-1-6-BRANCH and not > master. Of course we are glad about any bug reports but we may not be > able to follow up on such reports. > > If the test suite passed, please try with 1.6 to see whether it makes a > difference. So AES is failing. I went with master rather than the 1.6 branch because this commit is needed to make the ARM asm code work on Android: Parse /proc/cpuinfo for ARM HW features a05be441d8cd89b90d8d58e3a343a436dae377d0 But it turns out that the libgcrypt tests are failing with both the head of master and LIBGCRYPT-1-6-BRANCH. I'll see what I can come with tonight. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From jussi.kivilinna at iki.fi Sat Jan 18 12:31:04 2014 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Sat, 18 Jan 2014 13:31:04 +0200 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52D977BE.5070802@guardianproject.info> References: <52D977BE.5070802@guardianproject.info> Message-ID: <52DA65F8.7060104@iki.fi> On 17.01.2014 20:34, Hans-Christoph Steiner wrote: > > On GPG for Android, I've updated to the latest libgcrypt in master (or close > to it, its commit 4b7db51ad5d1bf98fd08ca3048f258059eca61a4). Now it seems > that any operation that needs a passphrase is crashing somewhere in libgcrypt. > I've tried building with auto-detection of CPU which enables Padlock, Intelt > DRNG, and NEON. I also tried with --disable-padlock-support > --disable-drng-support --disable-neon-support, and seemed to get the same thing. > > I've also tried running gpg-agent with and without --enable-ssh-support, and > same result each time. > > Here's the basic backtrace: <..snip..> > From the bug report in our tracker, you can download the complete build log, a > debug log from the Android app, a log from gpg-agent, and a log from gpgme: > > https://dev.guardianproject.info/issues/2888 Have you configured gcc flags correctly for target platform? It seems that compiler (and libgcrypt assembly) are configured to allow unaligned memory accesses, but target does not support them. Disassembly of crash site: 0: e1866469 orr r6, r6, r9, ror #8 4: e8900f00 ldm r0, {r8, r9, sl, fp} 8: e0244008 eor r4, r4, r8 c: e0255009 eor r5, r5, r9 10: e026600a eor r6, r6, sl 14: e027700b eor r7, r7, fp 18: eafffded b 0xfffff7d4 1c: e92d5ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr} !!20: e89200f0 ldm r2, {r4, r5, r6, r7} 24: e24dd010 sub sp, sp, #16 28: e59fe864 ldr lr, [pc, #2148] ; 0x894 2c: e3a0c0ff mov ip, #255 ; 0xff 30: e58d1004 str r1, [sp, #4] 34: e1a0c18c lsl ip, ip, #3 38: e353000c cmp r3, #12 3c: aa000215 bge 0x898 Crash happens in rinjdael_arm.S:_gcry_aes_arm_decrypt_block, line 496: /* aligned load */ ldm %r2, {RA, RB, RC, RD}; This just loads four 32-bit words from input buffer (pointer in r2). The pointer in r2 is 0x013ebf9f, not aligned to 32-bit word boundary. Above disassembly shows that code is compiled with __ARM_FEATURE_UNALIGNED (-munaligned-access) and unaligned memory accesses are assumed to be ok. But clearly unaligned memory accesses are not allowed as programs crashes with "signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 013ebf9f" - Invalid address alignment. GCC documentation says [1]: -munaligned-access -mno-unaligned-access Enables (or disables) reading and writing of 16- and 32- bit values from addresses that are not 16- or 32- bit aligned. By default unaligned access is disabled for all pre-ARMv6 and all ARMv6-M architectures, and enabled for all other architectures. If unaligned access is not enabled then words in packed data structures will be accessed a byte at a time. The ARM attribute Tag_CPU_unaligned_access will be set in the generated object file to either true or false, depending upon the setting of this option. If unaligned access is enabled then the preprocessor symbol __ARM_FEATURE_UNALIGNED will also be defined. -Jussi [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html > > .hc > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From dbaryshkov at gmail.com Sun Jan 19 01:47:41 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sun, 19 Jan 2014 04:47:41 +0400 Subject: PKCS 12 support questions Message-ID: Hello, I'm currently looking onto extending gpgsm import to support more private key algorithms. (Primary target being gost ecc public keys, but see below). After looking onto minip12.c I have several questions. 1) Is there a reason, why minip12 is so limited on supported features? Even small changes in the options used to generate p12 make minip12 barf on errors. Even aes-256-cbs is not supported. 2) Why is it implemented in gnupg itself - i.e. not in libksba? Would it benefitable to push at least parts of ASN.1 parsing to libksba? -- With best wishes Dmitry From hans at guardianproject.info Sun Jan 19 03:03:17 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Sat, 18 Jan 2014 21:03:17 -0500 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52DA65F8.7060104@iki.fi> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> Message-ID: <52DB3265.3040209@guardianproject.info> On 01/18/2014 06:31 AM, Jussi Kivilinna wrote: > On 17.01.2014 20:34, Hans-Christoph Steiner wrote: >> >> On GPG for Android, I've updated to the latest libgcrypt in master (or close >> to it, its commit 4b7db51ad5d1bf98fd08ca3048f258059eca61a4). Now it seems >> that any operation that needs a passphrase is crashing somewhere in libgcrypt. >> I've tried building with auto-detection of CPU which enables Padlock, Intelt >> DRNG, and NEON. I also tried with --disable-padlock-support >> --disable-drng-support --disable-neon-support, and seemed to get the same thing. >> >> I've also tried running gpg-agent with and without --enable-ssh-support, and >> same result each time. >> >> Here's the basic backtrace: > <..snip..> >> From the bug report in our tracker, you can download the complete build log, a >> debug log from the Android app, a log from gpg-agent, and a log from gpgme: >> >> https://dev.guardianproject.info/issues/2888 > > Have you configured gcc flags correctly for target platform? It seems that > compiler (and libgcrypt assembly) are configured to allow unaligned memory > accesses, but target does not support them. > > Disassembly of crash site: > > 0: e1866469 orr r6, r6, r9, ror #8 > 4: e8900f00 ldm r0, {r8, r9, sl, fp} > 8: e0244008 eor r4, r4, r8 > c: e0255009 eor r5, r5, r9 > 10: e026600a eor r6, r6, sl > 14: e027700b eor r7, r7, fp > 18: eafffded b 0xfffff7d4 > 1c: e92d5ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr} > !!20: e89200f0 ldm r2, {r4, r5, r6, r7} > 24: e24dd010 sub sp, sp, #16 > 28: e59fe864 ldr lr, [pc, #2148] ; 0x894 > 2c: e3a0c0ff mov ip, #255 ; 0xff > 30: e58d1004 str r1, [sp, #4] > 34: e1a0c18c lsl ip, ip, #3 > 38: e353000c cmp r3, #12 > 3c: aa000215 bge 0x898 > > Crash happens in rinjdael_arm.S:_gcry_aes_arm_decrypt_block, line 496: > /* aligned load */ > ldm %r2, {RA, RB, RC, RD}; > > This just loads four 32-bit words from input buffer (pointer in r2). The pointer > in r2 is 0x013ebf9f, not aligned to 32-bit word boundary. Above disassembly > shows that code is compiled with __ARM_FEATURE_UNALIGNED (-munaligned-access) > and unaligned memory accesses are assumed to be ok. But clearly unaligned > memory accesses are not allowed as programs crashes with "signal 7 (SIGBUS), > code 1 (BUS_ADRALN), fault addr 013ebf9f" - Invalid address alignment. > > GCC documentation says [1]: > -munaligned-access > -mno-unaligned-access/tmp/tmp.CJXiMkm9O0 > Enables (or disables) reading and writing of 16- and 32- bit values from > addresses that are not 16- or 32- bit aligned. By default unaligned access > is disabled for all pre-ARMv6 and all ARMv6-M architectures, and enabled for > all other architectures. If unaligned access is not enabled then words in > packed data structures will be accessed a byte at a time. > > The ARM attribute Tag_CPU_unaligned_access will be set in the generated > object file to either true or false, depending upon the setting of this > option. If unaligned access is enabled then the preprocessor symbol > __ARM_FEATURE_UNALIGNED will also be defined. > > -Jussi > > [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html Attached is a log of all of the various tests (libgpg-error, libassuan, npth, libksba, libgcrypt, and gpgme). The script echos "FAILED" then continues when a test fails. Most of the tests passed, I think only tests in libgcrypt failed. I did not include the gnupg tests because they are shell scripts that can't be run on Android. This device in question is ARMv7, so gcc would default to -munaligned-access according to that gcc man page snippet. I'll try setting -mno-unaligned-access and re-running. It looks like the default Android flags don't do anything about unaligned access: /bin/bash ../libtool --mode=compile /opt/android-ndk/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc --sysroot=/opt/android-ndk/platforms/android-9/arch-arm -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -Wa,--noexecstack -DANDROID -I/var/lib/jenkins/workspace/gnupg-for-android-eighthave/external/data/data/info.guardianproject.gpg/app_opt/include -fpic -ffunction-sections -funwind-tables -fstack-protector -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -O2 -g -DNDEBUG -fomit-frame-pointer -fstrict-aliasing -funswitch-loops -finline-limit=300 -MT rijndael-arm.lo -MD -MP -MF .deps/rijndael-arm.Tpo -c -o rijndael-arm.lo rijndael-arm.S libtool: compile: /opt/android-ndk/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc --sysroot=/opt/android-ndk/platforms/android-9/arch-arm -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -Wa,--noexecstack -DANDROID -I/var/lib/jenkins/workspace/gnupg-for-android-eighthave/external/data/data/info.guardianproject.gpg/app_opt/include -fpic -ffunction-sections -funwind-tables -fstack-protector -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -O2 -g -DNDEBUG -fomit-frame-pointer -fstrict-aliasing -funswitch-loops -finline-limit=300 -MT rijndael-arm.lo -MD -MP -MF .deps/rijndael-arm.Tpo -c rijndael-arm.S -fPIC -DPIC -o .libs/rijndael-arm.o libtool: compile: /opt/android-ndk/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc --sysroot=/opt/android-ndk/platforms/android-9/arch-arm -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -Wa,--noexecstack -DANDROID -I/var/lib/jenkins/workspace/gnupg-for-android-eighthave/external/data/data/info.guardianproject.gpg/app_opt/include -fpic -ffunction-sections -funwind-tables -fstack-protector -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -O2 -g -DNDEBUG -fomit-frame-pointer -fstrict-aliasing -funswitch-loops -finline-limit=300 -MT rijndael-arm.lo -MD -MP -MF .deps/rijndael-arm.Tpo -c rijndael-arm.S -o rijndael-arm.o >/dev/null 2>&1 mv -f .deps/rijndael-arm.Tpo .deps/rijndael-arm.Plo Here's the specific CPU this test is running: # cat /proc/cpuinfo Processor : ARMv7 Processor rev 0 (v7l) processor : 0 BogoMIPS : 13.53 processor : 1 BogoMIPS : 13.53 processor : 2 BogoMIPS : 13.53 processor : 3 BogoMIPS : 13.53 Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 CPU implementer : 0x51 CPU architecture: 7 CPU variant : 0x1 CPU part : 0x06f CPU revision : 0 Hardware : QCT APQ8064 FLO Revision : 0000 Serial : 0000000000000000 -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-tests-nexus-7.txt.bz2 Type: application/x-bzip Size: 11898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From hans at guardianproject.info Sun Jan 19 05:08:13 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Sat, 18 Jan 2014 23:08:13 -0500 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52DA65F8.7060104@iki.fi> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> Message-ID: <52DB4FAD.3010303@guardianproject.info> On 01/18/2014 06:31 AM, Jussi Kivilinna wrote: > On 17.01.2014 20:34, Hans-Christoph Steiner wrote: >> >> On GPG for Android, I've updated to the latest libgcrypt in master (or close >> to it, its commit 4b7db51ad5d1bf98fd08ca3048f258059eca61a4). Now it seems >> that any operation that needs a passphrase is crashing somewhere in libgcrypt. >> I've tried building with auto-detection of CPU which enables Padlock, Intelt >> DRNG, and NEON. I also tried with --disable-padlock-support >> --disable-drng-support --disable-neon-support, and seemed to get the same thing. >> >> I've also tried running gpg-agent with and without --enable-ssh-support, and >> same result each time. >> >> Here's the basic backtrace: > <..snip..> >> From the bug report in our tracker, you can download the complete build log, a >> debug log from the Android app, a log from gpg-agent, and a log from gpgme: >> >> https://dev.guardianproject.info/issues/2888 > > Have you configured gcc flags correctly for target platform? It seems that > compiler (and libgcrypt assembly) are configured to allow unaligned memory > accesses, but target does not support them. > > Disassembly of crash site: > > 0: e1866469 orr r6, r6, r9, ror #8 > 4: e8900f00 ldm r0, {r8, r9, sl, fp} > 8: e0244008 eor r4, r4, r8 > c: e0255009 eor r5, r5, r9 > 10: e026600a eor r6, r6, sl > 14: e027700b eor r7, r7, fp > 18: eafffded b 0xfffff7d4 > 1c: e92d5ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr} > !!20: e89200f0 ldm r2, {r4, r5, r6, r7} > 24: e24dd010 sub sp, sp, #16 > 28: e59fe864 ldr lr, [pc, #2148] ; 0x894 > 2c: e3a0c0ff mov ip, #255 ; 0xff > 30: e58d1004 str r1, [sp, #4] > 34: e1a0c18c lsl ip, ip, #3 > 38: e353000c cmp r3, #12 > 3c: aa000215 bge 0x898 > > Crash happens in rinjdael_arm.S:_gcry_aes_arm_decrypt_block, line 496: > /* aligned load */ > ldm %r2, {RA, RB, RC, RD}; > > This just loads four 32-bit words from input buffer (pointer in r2). The pointer > in r2 is 0x013ebf9f, not aligned to 32-bit word boundary. Above disassembly > shows that code is compiled with __ARM_FEATURE_UNALIGNED (-munaligned-access) > and unaligned memory accesses are assumed to be ok. But clearly unaligned > memory accesses are not allowed as programs crashes with "signal 7 (SIGBUS), > code 1 (BUS_ADRALN), fault addr 013ebf9f" - Invalid address alignment. > > GCC documentation says [1]: > -munaligned-access > -mno-unaligned-access > Enables (or disables) reading and writing of 16- and 32- bit values from > addresses that are not 16- or 32- bit aligned. By default unaligned access > is disabled for all pre-ARMv6 and all ARMv6-M architectures, and enabled for > all other architectures. If unaligned access is not enabled then words in > packed data structures will be accessed a byte at a time. > > The ARM attribute Tag_CPU_unaligned_access will be set in the generated > object file to either true or false, depending upon the setting of this > option. If unaligned access is enabled then the preprocessor symbol > __ARM_FEATURE_UNALIGNED will also be defined. > > -Jussi > > [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html I forget if I mentioned this before: the build flags are set by the default Android build system. So I built the whole thing again, manually adding -mno-unaligned-access to the libgcrypt build, and the tests seem to be failing in the same place. I tested head of master on the armv7a emulator, which failed a lot more, and the head of LIBGCRYPT-1-6-BRANCH on the Nexus 7 ARMv7 tablet, which failed in the same places. Any pointers for next steps? FYI, I'm gathering all these log files on our bug tracker: https://dev.guardianproject.info/issues/2888 Attached are the latest test logs, including the full build log for head of master running tests on the armv7a emulator. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-tests-emulator-armv7a-mno-unaligned-access.txt.bz2 Type: application/x-bzip Size: 5371 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-tests-nexus-7-mno-unaligned-access.txt.bz2 Type: application/x-bzip Size: 11934 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From jussi.kivilinna at iki.fi Sun Jan 19 10:25:33 2014 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Sun, 19 Jan 2014 11:25:33 +0200 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52DB4FAD.3010303@guardianproject.info> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> Message-ID: <52DB9A0D.4040900@iki.fi> On 19.01.2014 06:08, Hans-Christoph Steiner wrote: > > > On 01/18/2014 06:31 AM, Jussi Kivilinna wrote: >> On 17.01.2014 20:34, Hans-Christoph Steiner wrote: >>> >>> On GPG for Android, I've updated to the latest libgcrypt in master (or close >>> to it, its commit 4b7db51ad5d1bf98fd08ca3048f258059eca61a4). Now it seems >>> that any operation that needs a passphrase is crashing somewhere in libgcrypt. >>> I've tried building with auto-detection of CPU which enables Padlock, Intelt >>> DRNG, and NEON. I also tried with --disable-padlock-support >>> --disable-drng-support --disable-neon-support, and seemed to get the same thing. >>> >>> I've also tried running gpg-agent with and without --enable-ssh-support, and >>> same result each time. >>> >>> Here's the basic backtrace: >> <..snip..> >>> From the bug report in our tracker, you can download the complete build log, a >>> debug log from the Android app, a log from gpg-agent, and a log from gpgme: >>> >>> https://dev.guardianproject.info/issues/2888 >> >> Have you configured gcc flags correctly for target platform? It seems that >> compiler (and libgcrypt assembly) are configured to allow unaligned memory >> accesses, but target does not support them. >> <...snip...> >> -Jussi >> >> [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html > > I forget if I mentioned this before: the build flags are set by the default > Android build system. > > So I built the whole thing again, manually adding -mno-unaligned-access to the > libgcrypt build, and the tests seem to be failing in the same place. I tested > head of master on the armv7a emulator, which failed a lot more, and the head > of LIBGCRYPT-1-6-BRANCH on the Nexus 7 ARMv7 tablet, which failed in the same > places. Any pointers for next steps? > That's a bit strange. Do you have crash logs of these? -Jussi > FYI, I'm gathering all these log files on our bug tracker: > https://dev.guardianproject.info/issues/2888 > > Attached are the latest test logs, including the full build log for head of > master running tests on the armv7a emulator. > > .hc > > From wk at gnupg.org Sun Jan 19 15:19:56 2014 From: wk at gnupg.org (Werner Koch) Date: Sun, 19 Jan 2014 15:19:56 +0100 Subject: PKCS 12 support questions In-Reply-To: (Dmitry Eremin-Solenikov's message of "Sun, 19 Jan 2014 04:47:41 +0400") References: Message-ID: <87a9esyrxv.fsf@vigenere.g10code.de> On Sun, 19 Jan 2014 01:47, dbaryshkov at gmail.com said: > 1) Is there a reason, why minip12 is so limited on supported features? Because pkcs#12 is an entirely broken design and I did this only on customer request for migrating existisng keys. > 2) Why is it implemented in gnupg itself - i.e. not in libksba? Would > it benefitable to push > at least parts of ASN.1 parsing to libksba? Please keep that extra insane data format out of Libksba. pkcs#12 is plain horror. Do you really need it? Isn't X.509 dead anyway? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tomanek at internet-sicherheit.de Sun Jan 19 19:46:03 2014 From: tomanek at internet-sicherheit.de (Stefan Tomanek) Date: Sun, 19 Jan 2014 19:46:03 +0100 Subject: [PATCH v5 (stable 1.4)] filter and verify keyserver responses Message-ID: <20140119184603.GB30808@zirkel.wertarbyte.de> This changes introduces import functions that apply a constraining filter to imported keys. These filters can verify the fingerprints of the keys returned before importing them into the keyring, ensuring that the keys fetched from the keyserver are in fact those selected by the user beforehand. This prevents malicious keyservers and men in the middle from creating confusion by planting unrequested keys in the keyrings. It also prevents the accidental import of secret keys through key server responses. Signed-off-by: Stefan Tomanek --- g10/import.c | 47 ++++++++++++++++++++++++++++++++--------------- g10/keyserver.c | 48 ++++++++++++++++++++++++++++++++++++++++++++---- g10/main.h | 4 +++- 3 files changed, 79 insertions(+), 20 deletions(-) diff --git a/g10/import.c b/g10/import.c index 441dcca..cd93f12 100644 --- a/g10/import.c +++ b/g10/import.c @@ -59,14 +59,17 @@ struct stats_s { static int import( IOBUF inp, const char* fname,struct stats_s *stats, - unsigned char **fpr,size_t *fpr_len,unsigned int options ); + unsigned char **fpr,size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg ); static int read_block( IOBUF a, PACKET **pending_pkt, KBNODE *ret_root ); static void revocation_present(KBNODE keyblock); static int import_one(const char *fname, KBNODE keyblock,struct stats_s *stats, unsigned char **fpr,size_t *fpr_len, - unsigned int options,int from_sk); + unsigned int options,int from_sk, + import_filter filter, void *filter_arg); static int import_secret_one( const char *fname, KBNODE keyblock, - struct stats_s *stats, unsigned int options); + struct stats_s *stats, unsigned int options, + import_filter filter, void *filter_arg ); static int import_revoke_cert( const char *fname, KBNODE node, struct stats_s *stats); static int chk_self_sigs( const char *fname, KBNODE keyblock, @@ -163,7 +166,8 @@ import_release_stats_handle (void *p) static int import_keys_internal( IOBUF inp, char **fnames, int nnames, void *stats_handle, unsigned char **fpr, size_t *fpr_len, - unsigned int options ) + unsigned int options, + import_filter filter, void *filter_arg ) { int i, rc = 0; struct stats_s *stats = stats_handle; @@ -172,7 +176,7 @@ import_keys_internal( IOBUF inp, char **fnames, int nnames, stats = import_new_stats_handle (); if (inp) { - rc = import( inp, "[stream]", stats, fpr, fpr_len, options); + rc = import( inp, "[stream]", stats, fpr, fpr_len, options, filter, filter_arg); } else { int once = (!fnames && !nnames); @@ -192,7 +196,7 @@ import_keys_internal( IOBUF inp, char **fnames, int nnames, log_error(_("can't open `%s': %s\n"), fname, strerror(errno) ); else { - rc = import( inp2, fname, stats, fpr, fpr_len, options ); + rc = import( inp2, fname, stats, fpr, fpr_len, options, NULL, NULL ); iobuf_close(inp2); /* Must invalidate that ugly cache to actually close it. */ iobuf_ioctl (NULL, 2, 0, (char*)fname); @@ -223,19 +227,21 @@ void import_keys( char **fnames, int nnames, void *stats_handle, unsigned int options ) { - import_keys_internal(NULL,fnames,nnames,stats_handle,NULL,NULL,options); + import_keys_internal(NULL,fnames,nnames,stats_handle,NULL,NULL,options,NULL,NULL); } int import_keys_stream( IOBUF inp, void *stats_handle, - unsigned char **fpr, size_t *fpr_len,unsigned int options ) + unsigned char **fpr, size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg ) { - return import_keys_internal(inp,NULL,0,stats_handle,fpr,fpr_len,options); + return import_keys_internal(inp,NULL,0,stats_handle,fpr,fpr_len,options,filter,filter_arg); } static int import( IOBUF inp, const char* fname,struct stats_s *stats, - unsigned char **fpr,size_t *fpr_len,unsigned int options ) + unsigned char **fpr,size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg ) { PACKET *pending_pkt = NULL; KBNODE keyblock = NULL; @@ -252,9 +258,10 @@ import( IOBUF inp, const char* fname,struct stats_s *stats, while( !(rc = read_block( inp, &pending_pkt, &keyblock) )) { if( keyblock->pkt->pkttype == PKT_PUBLIC_KEY ) - rc = import_one( fname, keyblock, stats, fpr, fpr_len, options, 0); + rc = import_one( fname, keyblock, stats, fpr, fpr_len, options, 0, + filter, filter_arg); else if( keyblock->pkt->pkttype == PKT_SECRET_KEY ) - rc = import_secret_one( fname, keyblock, stats, options ); + rc = import_secret_one( fname, keyblock, stats, options, filter, filter_arg ); else if( keyblock->pkt->pkttype == PKT_SIGNATURE && keyblock->pkt->pkt.signature->sig_class == 0x20 ) rc = import_revoke_cert( fname, keyblock, stats ); @@ -738,7 +745,7 @@ check_prefs(KBNODE keyblock) static int import_one( const char *fname, KBNODE keyblock, struct stats_s *stats, unsigned char **fpr,size_t *fpr_len,unsigned int options, - int from_sk ) + int from_sk, import_filter filter, void *filter_arg) { PKT_public_key *pk; PKT_public_key *pk_orig; @@ -778,6 +785,10 @@ import_one( const char *fname, KBNODE keyblock, struct stats_s *stats, return 0; } + if (filter && filter(pk, NULL, filter_arg)) { + log_error( _("key %s: rejected by import filter\n"), keystr_from_pk(pk)); + return 0; + } if (opt.interactive) { if(is_status_enabled()) print_import_check (pk, uidnode->pkt->pkt.user_id); @@ -1146,7 +1157,8 @@ sec_to_pub_keyblock(KBNODE sec_keyblock) */ static int import_secret_one( const char *fname, KBNODE keyblock, - struct stats_s *stats, unsigned int options) + struct stats_s *stats, unsigned int options, + import_filter filter, void *filter_arg ) { PKT_secret_key *sk; KBNODE node, uidnode; @@ -1162,6 +1174,11 @@ import_secret_one( const char *fname, KBNODE keyblock, keyid_from_sk( sk, keyid ); uidnode = find_next_kbnode( keyblock, PKT_USER_ID ); + if (filter && filter(NULL, sk, filter_arg)) { + log_error( _("secret key %s: rejected by import filter\n"), keystr_from_sk(sk)); + return 0; + } + if( opt.verbose ) { log_info( "sec %4u%c/%s %s ", @@ -1241,7 +1258,7 @@ import_secret_one( const char *fname, KBNODE keyblock, if(pub_keyblock) { import_one(fname,pub_keyblock,stats, - NULL,NULL,opt.import_options,1); + NULL,NULL,opt.import_options,1,NULL,NULL); release_kbnode(pub_keyblock); } } diff --git a/g10/keyserver.c b/g10/keyserver.c index 7bf9830..6bd7776 100644 --- a/g10/keyserver.c +++ b/g10/keyserver.c @@ -959,6 +959,46 @@ direct_uri_map(const char *scheme,unsigned int is_direct) #define KEYSERVER_ARGS_KEEP " -o \"%O\" \"%I\"" #define KEYSERVER_ARGS_NOKEEP " -o \"%o\" \"%i\"" +static int +keyserver_retrieval_filter(PKT_public_key *pk, PKT_secret_key *sk, void *arg) +{ + KEYDB_SEARCH_DESC *desc = arg; + u32 keyid[2]; + byte fpr[MAX_FINGERPRINT_LEN]; + size_t fpr_len = 0; + + /* we definitely do not want to import secret keys! */ + if (sk) { + return 1; + } + + fingerprint_from_pk(pk, fpr, &fpr_len); + keyid_from_pk(pk, keyid); + + /* compare requested and returned fingerprints if available */ + if (desc->mode == KEYDB_SEARCH_MODE_FPR20) { + if (fpr_len != 20 || memcmp(fpr, desc->u.fpr, 20)) { + return 1; + } + } + else if (desc->mode == KEYDB_SEARCH_MODE_FPR16) { + if (fpr_len != 16 || memcmp(fpr, desc->u.fpr, 16)) { + return 1; + } + } + else if (desc->mode == KEYDB_SEARCH_MODE_LONG_KID) { + if (memcmp(keyid, desc->u.kid, sizeof(keyid))) { + return 1; + } + } + else if (desc->mode == KEYDB_SEARCH_MODE_SHORT_KID) { + if (memcmp(&keyid[1], &desc->u.kid[1], 1)) { + return 1; + } + } + return 0; +} + static int keyserver_spawn(enum ks_action action,STRLIST list,KEYDB_SEARCH_DESC *desc, int count,int *prog,unsigned char **fpr,size_t *fpr_len, @@ -1508,9 +1548,9 @@ keyserver_spawn(enum ks_action action,STRLIST list,KEYDB_SEARCH_DESC *desc, keyserver. Keyservers should never accept or send them but we better protect against rogue keyservers. */ - import_keys_stream (spawn->fromchild, stats_handle, fpr, fpr_len, - (opt.keyserver_options.import_options - | IMPORT_NO_SECKEY)); + import_keys_stream(spawn->fromchild,stats_handle,fpr,fpr_len, + (opt.keyserver_options.import_options | IMPORT_NO_SECKEY), + &keyserver_retrieval_filter, desc); import_print_stats(stats_handle); import_release_stats_handle(stats_handle); @@ -2043,7 +2083,7 @@ keyserver_import_cert(const char *name,unsigned char **fpr,size_t *fpr_len) rc=import_keys_stream (key, NULL, fpr, fpr_len, (opt.keyserver_options.import_options - | IMPORT_NO_SECKEY)); + | IMPORT_NO_SECKEY), NULL, NULL); opt.no_armor=armor_status; diff --git a/g10/main.h b/g10/main.h index 784ade0..8f794be 100644 --- a/g10/main.h +++ b/g10/main.h @@ -207,11 +207,13 @@ MPI encode_md_value( PKT_public_key *pk, PKT_secret_key *sk, MD_HANDLE md, int hash_algo ); /*-- import.c --*/ +typedef int (*import_filter)(PKT_public_key *pk, PKT_secret_key *sk, void *arg); int parse_import_options(char *str,unsigned int *options,int noisy); void import_keys( char **fnames, int nnames, void *stats_hd, unsigned int options ); int import_keys_stream( IOBUF inp,void *stats_hd,unsigned char **fpr, - size_t *fpr_len,unsigned int options ); + size_t *fpr_len,unsigned int options, + import_filter constr, void *filter_arg); void *import_new_stats_handle (void); void import_release_stats_handle (void *p); void import_print_stats (void *hd); -- 1.7.10.4 From tomanek at internet-sicherheit.de Sun Jan 19 19:45:20 2014 From: tomanek at internet-sicherheit.de (Stefan Tomanek) Date: Sun, 19 Jan 2014 19:45:20 +0100 Subject: [PATCH v5 (master)] filter and verify keyserver responses Message-ID: <20140119184520.GA30808@zirkel.wertarbyte.de> This changes introduces import functions that apply a constraining filter to imported keys. These filters can verify the fingerprints of the keys returned before importing them into the keyring, ensuring that the keys fetched from the keyserver are in fact those selected by the user beforehand. This prevents malicious keyservers and men in the middle from creating confusion by planting unrequested keys in the keyrings. Signed-off-by: Stefan Tomanek --- g10/import.c | 51 ++++++++++++++++++++++++++++++++++----------------- g10/keyserver.c | 43 ++++++++++++++++++++++++++++++++++++++++--- g10/main.h | 7 +++++-- 3 files changed, 79 insertions(+), 22 deletions(-) diff --git a/g10/import.c b/g10/import.c index 3846c21..df99174 100644 --- a/g10/import.c +++ b/g10/import.c @@ -62,15 +62,18 @@ struct stats_s { static int import (ctrl_t ctrl, IOBUF inp, const char* fname, struct stats_s *stats, - unsigned char **fpr, size_t *fpr_len, unsigned int options); + unsigned char **fpr, size_t *fpr_len, unsigned int options, + import_filter filter, void *filter_arg); static int read_block( IOBUF a, PACKET **pending_pkt, KBNODE *ret_root ); static void revocation_present (ctrl_t ctrl, kbnode_t keyblock); static int import_one (ctrl_t ctrl, const char *fname, KBNODE keyblock,struct stats_s *stats, unsigned char **fpr,size_t *fpr_len, - unsigned int options,int from_sk); + unsigned int options,int from_sk, + import_filter filter, void *filter_arg); static int import_secret_one (ctrl_t ctrl, const char *fname, KBNODE keyblock, - struct stats_s *stats, unsigned int options); + struct stats_s *stats, unsigned int options, + import_filter filter, void *filter_arg ); static int import_revoke_cert( const char *fname, KBNODE node, struct stats_s *stats); static int chk_self_sigs( const char *fname, KBNODE keyblock, @@ -167,7 +170,8 @@ import_release_stats_handle (void *p) static int import_keys_internal (ctrl_t ctrl, iobuf_t inp, char **fnames, int nnames, void *stats_handle, unsigned char **fpr, size_t *fpr_len, - unsigned int options ) + unsigned int options, + import_filter filter, void *filter_arg ) { int i, rc = 0; struct stats_s *stats = stats_handle; @@ -176,7 +180,7 @@ import_keys_internal (ctrl_t ctrl, iobuf_t inp, char **fnames, int nnames, stats = import_new_stats_handle (); if (inp) { - rc = import (ctrl, inp, "[stream]", stats, fpr, fpr_len, options); + rc = import (ctrl, inp, "[stream]", stats, fpr, fpr_len, options, filter, filter_arg); } else { if( !fnames && !nnames ) @@ -197,7 +201,7 @@ import_keys_internal (ctrl_t ctrl, iobuf_t inp, char **fnames, int nnames, log_error(_("can't open '%s': %s\n"), fname, strerror(errno) ); else { - rc = import (ctrl, inp2, fname, stats, fpr, fpr_len, options); + rc = import (ctrl, inp2, fname, stats, fpr, fpr_len, options, NULL, NULL); iobuf_close(inp2); /* Must invalidate that ugly cache to actually close it. */ iobuf_ioctl (NULL, IOBUF_IOCTL_INVALIDATE_CACHE, @@ -232,15 +236,18 @@ import_keys (ctrl_t ctrl, char **fnames, int nnames, void *stats_handle, unsigned int options ) { import_keys_internal (ctrl, NULL, fnames, nnames, stats_handle, - NULL, NULL, options); + NULL, NULL, options, + NULL, NULL); } int import_keys_stream (ctrl_t ctrl, IOBUF inp, void *stats_handle, - unsigned char **fpr, size_t *fpr_len,unsigned int options) + unsigned char **fpr, size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg) { return import_keys_internal (ctrl, inp, NULL, 0, stats_handle, - fpr, fpr_len, options); + fpr, fpr_len, options, + filter, filter_arg); } @@ -248,7 +255,8 @@ import_keys_stream (ctrl_t ctrl, IOBUF inp, void *stats_handle, int import_keys_es_stream (ctrl_t ctrl, estream_t fp, void *stats_handle, unsigned char **fpr, size_t *fpr_len, - unsigned int options) + unsigned int options, + import_filter filter, void *filter_arg) { int rc; iobuf_t inp; @@ -262,7 +270,8 @@ import_keys_es_stream (ctrl_t ctrl, estream_t fp, void *stats_handle, } rc = import_keys_internal (ctrl, inp, NULL, 0, stats_handle, - fpr, fpr_len, options); + fpr, fpr_len, options, + filter, filter_arg); iobuf_close (inp); return rc; @@ -271,7 +280,8 @@ import_keys_es_stream (ctrl_t ctrl, estream_t fp, void *stats_handle, static int import (ctrl_t ctrl, IOBUF inp, const char* fname,struct stats_s *stats, - unsigned char **fpr,size_t *fpr_len,unsigned int options ) + unsigned char **fpr,size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg) { PACKET *pending_pkt = NULL; KBNODE keyblock = NULL; /* Need to initialize because gcc can't @@ -293,9 +303,10 @@ import (ctrl_t ctrl, IOBUF inp, const char* fname,struct stats_s *stats, while( !(rc = read_block( inp, &pending_pkt, &keyblock) )) { if( keyblock->pkt->pkttype == PKT_PUBLIC_KEY ) rc = import_one (ctrl, fname, keyblock, - stats, fpr, fpr_len, options, 0); + stats, fpr, fpr_len, options, 0, + filter, filter_arg); else if( keyblock->pkt->pkttype == PKT_SECRET_KEY ) - rc = import_secret_one (ctrl, fname, keyblock, stats, options); + rc = import_secret_one (ctrl, fname, keyblock, stats, options, filter, filter_arg); else if( keyblock->pkt->pkttype == PKT_SIGNATURE && keyblock->pkt->pkt.signature->sig_class == 0x20 ) rc = import_revoke_cert( fname, keyblock, stats ); @@ -780,7 +791,7 @@ static int import_one (ctrl_t ctrl, const char *fname, KBNODE keyblock, struct stats_s *stats, unsigned char **fpr,size_t *fpr_len,unsigned int options, - int from_sk ) + int from_sk, import_filter filter, void *filter_arg) { PKT_public_key *pk; PKT_public_key *pk_orig; @@ -823,6 +834,11 @@ import_one (ctrl_t ctrl, return 0; } + if (filter && filter(pk, filter_arg)) { + log_error( _("key %s: rejected by import filter\n"), keystr_from_pk(pk)); + return 0; + } + if (opt.interactive) { if(is_status_enabled()) print_import_check (pk, uidnode->pkt->pkt.user_id); @@ -1529,7 +1545,8 @@ sec_to_pub_keyblock (kbnode_t sec_keyblock) */ static int import_secret_one (ctrl_t ctrl, const char *fname, KBNODE keyblock, - struct stats_s *stats, unsigned int options) + struct stats_s *stats, unsigned int options, + import_filter filter, void *filter_arg ) { PKT_public_key *pk; struct seckey_info *ski; @@ -1611,7 +1628,7 @@ import_secret_one (ctrl_t ctrl, const char *fname, KBNODE keyblock, public key block, and below we will output another one for the secret keys. FIXME? */ import_one (ctrl, fname, pub_keyblock, stats, - NULL, NULL, options, 1); + NULL, NULL, options, 1, filter, filter_arg); /* Fixme: We should check for an invalid keyblock and cancel the secret key import in this case. */ diff --git a/g10/keyserver.c b/g10/keyserver.c index 0ec616b..7215c7c 100644 --- a/g10/keyserver.c +++ b/g10/keyserver.c @@ -829,6 +829,40 @@ show_prompt (ctrl_t ctrl, KEYDB_SEARCH_DESC *desc, int numdesc, return err; } +static int +keyserver_retrieval_filter(PKT_public_key *pk, void *arg) +{ + KEYDB_SEARCH_DESC *desc = arg; + u32 keyid[2]; + byte fpr[MAX_FINGERPRINT_LEN]; + size_t fpr_len = 0; + + fingerprint_from_pk(pk, fpr, &fpr_len); + keyid_from_pk(pk, keyid); + + /* compare requested and returned fingerprints if available */ + if (desc->mode == KEYDB_SEARCH_MODE_FPR20) { + if (fpr_len != 20 || memcmp(fpr, desc->u.fpr, 20)) { + return 1; + } + } + else if (desc->mode == KEYDB_SEARCH_MODE_FPR16) { + if (fpr_len != 16 || memcmp(fpr, desc->u.fpr, 16)) { + return 1; + } + } + else if (desc->mode == KEYDB_SEARCH_MODE_LONG_KID) { + if (memcmp(keyid, desc->u.kid, sizeof(keyid))) { + return 1; + } + } + else if (desc->mode == KEYDB_SEARCH_MODE_SHORT_KID) { + if (memcmp(&keyid[1], &desc->u.kid[1], 1)) { + return 1; + } + } + return 0; +} /* This is a callback used by call-dirmngr.c to process the result of KS_SEARCH command. LINE is the actual data line received with all @@ -1581,7 +1615,8 @@ keyserver_get (ctrl_t ctrl, KEYDB_SEARCH_DESC *desc, int ndesc, a temp iobuf for each key. */ import_keys_es_stream (ctrl, datastream, stats_handle, NULL, NULL, - opt.keyserver_options.import_options); + opt.keyserver_options.import_options, + &keyserver_retrieval_filter, desc); import_print_stats (stats_handle); import_release_stats_handle (stats_handle); @@ -1672,7 +1707,8 @@ keyserver_fetch (ctrl_t ctrl, strlist_t urilist) stats_handle = import_new_stats_handle(); import_keys_es_stream (ctrl, datastream, stats_handle, NULL, NULL, - opt.keyserver_options.import_options); + opt.keyserver_options.import_options, + NULL, NULL); import_print_stats (stats_handle); import_release_stats_handle (stats_handle); @@ -1721,7 +1757,8 @@ keyserver_import_cert (ctrl_t ctrl, opt.no_armor=1; err = import_keys_es_stream (ctrl, key, NULL, fpr, fpr_len, - opt.keyserver_options.import_options); + opt.keyserver_options.import_options, + NULL, NULL); opt.no_armor=armor_status; diff --git a/g10/main.h b/g10/main.h index 1b619e0..90e6caa 100644 --- a/g10/main.h +++ b/g10/main.h @@ -271,15 +271,18 @@ gcry_mpi_t encode_md_value (PKT_public_key *pk, gcry_md_hd_t md, int hash_algo ); /*-- import.c --*/ +typedef int (*import_filter)(PKT_public_key *pk, void *arg); int parse_import_options(char *str,unsigned int *options,int noisy); void import_keys (ctrl_t ctrl, char **fnames, int nnames, void *stats_hd, unsigned int options); int import_keys_stream (ctrl_t ctrl, iobuf_t inp, void *stats_hd, unsigned char **fpr, - size_t *fpr_len, unsigned int options); + size_t *fpr_len, unsigned int options, + import_filter constr, void *filter_arg); int import_keys_es_stream (ctrl_t ctrl, estream_t fp, void *stats_handle, unsigned char **fpr, size_t *fpr_len, - unsigned int options); + unsigned int options, + import_filter constr, void *filter_arg); void *import_new_stats_handle (void); void import_release_stats_handle (void *p); void import_print_stats (void *hd); -- 1.7.10.4 From tomanek at internet-sicherheit.de Sun Jan 19 19:46:48 2014 From: tomanek at internet-sicherheit.de (Stefan Tomanek) Date: Sun, 19 Jan 2014 19:46:48 +0100 Subject: [PATCH v5 (stable 2.0)] filter and verify keyserver responses Message-ID: <20140119184648.GC30808@zirkel.wertarbyte.de> This changes introduces import functions that apply a constraining filter to imported keys. These filters can verify the fingerprints of the keys returned before importing them into the keyring, ensuring that the keys fetched from the keyserver are in fact those selected by the user beforehand. This prevents malicious keyservers and men in the middle from creating confusion by planting unrequested keys in the keyrings. Signed-off-by: Stefan Tomanek --- g10/import.c | 52 ++++++++++++++++++++++++++++++++++++---------------- g10/keyserver.c | 48 ++++++++++++++++++++++++++++++++++++++++++++---- g10/main.h | 4 +++- 3 files changed, 83 insertions(+), 21 deletions(-) diff --git a/g10/import.c b/g10/import.c index 540b24b..00fe220 100644 --- a/g10/import.c +++ b/g10/import.c @@ -59,14 +59,17 @@ struct stats_s { static int import( IOBUF inp, const char* fname,struct stats_s *stats, - unsigned char **fpr,size_t *fpr_len,unsigned int options ); + unsigned char **fpr,size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg ); static int read_block( IOBUF a, PACKET **pending_pkt, KBNODE *ret_root ); static void revocation_present(KBNODE keyblock); static int import_one(const char *fname, KBNODE keyblock,struct stats_s *stats, unsigned char **fpr,size_t *fpr_len, - unsigned int options,int from_sk); + unsigned int options,int from_sk, + import_filter filter, void *filter_arg); static int import_secret_one( const char *fname, KBNODE keyblock, - struct stats_s *stats, unsigned int options); + struct stats_s *stats, unsigned int options, + import_filter filter, void *filter_arg ); static int import_revoke_cert( const char *fname, KBNODE node, struct stats_s *stats); static int chk_self_sigs( const char *fname, KBNODE keyblock, @@ -163,7 +166,8 @@ import_release_stats_handle (void *p) static int import_keys_internal( IOBUF inp, char **fnames, int nnames, void *stats_handle, unsigned char **fpr, size_t *fpr_len, - unsigned int options ) + unsigned int options, + import_filter filter, void *filter_arg ) { int i, rc = 0; struct stats_s *stats = stats_handle; @@ -172,7 +176,7 @@ import_keys_internal( IOBUF inp, char **fnames, int nnames, stats = import_new_stats_handle (); if (inp) { - rc = import( inp, "[stream]", stats, fpr, fpr_len, options); + rc = import( inp, "[stream]", stats, fpr, fpr_len, options, filter, filter_arg); } else { int once = (!fnames && !nnames); @@ -192,7 +196,7 @@ import_keys_internal( IOBUF inp, char **fnames, int nnames, log_error(_("can't open `%s': %s\n"), fname, strerror(errno) ); else { - rc = import( inp2, fname, stats, fpr, fpr_len, options ); + rc = import( inp2, fname, stats, fpr, fpr_len, options, NULL, NULL ); iobuf_close(inp2); /* Must invalidate that ugly cache to actually close it. */ iobuf_ioctl (NULL, 2, 0, (char*)fname); @@ -223,19 +227,21 @@ void import_keys( char **fnames, int nnames, void *stats_handle, unsigned int options ) { - import_keys_internal(NULL,fnames,nnames,stats_handle,NULL,NULL,options); + import_keys_internal(NULL,fnames,nnames,stats_handle,NULL,NULL,options,NULL,NULL); } int import_keys_stream( IOBUF inp, void *stats_handle, - unsigned char **fpr, size_t *fpr_len,unsigned int options ) + unsigned char **fpr, size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg ) { - return import_keys_internal(inp,NULL,0,stats_handle,fpr,fpr_len,options); + return import_keys_internal(inp,NULL,0,stats_handle,fpr,fpr_len,options,filter,filter_arg); } static int import( IOBUF inp, const char* fname,struct stats_s *stats, - unsigned char **fpr,size_t *fpr_len,unsigned int options ) + unsigned char **fpr,size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg ) { PACKET *pending_pkt = NULL; KBNODE keyblock = NULL; /* Need to initialize because gcc can't @@ -256,9 +262,11 @@ import( IOBUF inp, const char* fname,struct stats_s *stats, while( !(rc = read_block( inp, &pending_pkt, &keyblock) )) { if( keyblock->pkt->pkttype == PKT_PUBLIC_KEY ) - rc = import_one( fname, keyblock, stats, fpr, fpr_len, options, 0); + rc = import_one( fname, keyblock, stats, fpr, fpr_len, options, 0, + filter, filter_arg ); else if( keyblock->pkt->pkttype == PKT_SECRET_KEY ) - rc = import_secret_one( fname, keyblock, stats, options ); + rc = import_secret_one( fname, keyblock, stats, options, + filter, filter_arg ); else if( keyblock->pkt->pkttype == PKT_SIGNATURE && keyblock->pkt->pkt.signature->sig_class == 0x20 ) rc = import_revoke_cert( fname, keyblock, stats ); @@ -745,7 +753,7 @@ check_prefs(KBNODE keyblock) static int import_one( const char *fname, KBNODE keyblock, struct stats_s *stats, unsigned char **fpr,size_t *fpr_len,unsigned int options, - int from_sk ) + int from_sk, import_filter filter, void *filter_arg) { PKT_public_key *pk; PKT_public_key *pk_orig; @@ -787,7 +795,13 @@ import_one( const char *fname, KBNODE keyblock, struct stats_s *stats, log_error( _("key %s: no user ID\n"), keystr_from_pk(pk)); return 0; } - + + if (filter && filter(pk, NULL, filter_arg)) + { + log_error( _("key %s: rejected by import filter\n"), keystr_from_pk(pk)); + return 0; + } + if (opt.interactive) { if(is_status_enabled()) print_import_check (pk, uidnode->pkt->pkt.user_id); @@ -1166,7 +1180,8 @@ sec_to_pub_keyblock(KBNODE sec_keyblock) */ static int import_secret_one( const char *fname, KBNODE keyblock, - struct stats_s *stats, unsigned int options) + struct stats_s *stats, unsigned int options, + import_filter filter, void *filter_arg ) { PKT_secret_key *sk; KBNODE node, uidnode; @@ -1182,6 +1197,11 @@ import_secret_one( const char *fname, KBNODE keyblock, keyid_from_sk( sk, keyid ); uidnode = find_next_kbnode( keyblock, PKT_USER_ID ); + if (filter && filter(NULL, sk, filter_arg)) { + log_error( _("secret key %s: rejected by import filter\n"), keystr_from_sk(sk)); + return 0; + } + if( opt.verbose ) { log_info( "sec %4u%c/%s %s ", @@ -1261,7 +1281,7 @@ import_secret_one( const char *fname, KBNODE keyblock, if(pub_keyblock) { import_one(fname,pub_keyblock,stats, - NULL,NULL,opt.import_options,1); + NULL,NULL,opt.import_options,1,NULL,NULL); release_kbnode(pub_keyblock); } } diff --git a/g10/keyserver.c b/g10/keyserver.c index 7164f67..cfd16b6 100644 --- a/g10/keyserver.c +++ b/g10/keyserver.c @@ -982,6 +982,46 @@ direct_uri_map(const char *scheme,unsigned int is_direct) #define KEYSERVER_ARGS_NOKEEP " -o \"%o\" \"%i\"" static int +keyserver_retrieval_filter(PKT_public_key *pk, PKT_secret_key *sk, void *arg) +{ + KEYDB_SEARCH_DESC *desc = arg; + u32 keyid[2]; + byte fpr[MAX_FINGERPRINT_LEN]; + size_t fpr_len = 0; + + /* we definitely do not want to import secret keys! */ + if (sk) { + return 1; + } + + fingerprint_from_pk(pk, fpr, &fpr_len); + keyid_from_pk(pk, keyid); + + /* compare requested and returned fingerprints if available */ + if (desc->mode == KEYDB_SEARCH_MODE_FPR20) { + if (fpr_len != 20 || memcmp(fpr, desc->u.fpr, 20)) { + return 1; + } + } + else if (desc->mode == KEYDB_SEARCH_MODE_FPR16) { + if (fpr_len != 16 || memcmp(fpr, desc->u.fpr, 16)) { + return 1; + } + } + else if (desc->mode == KEYDB_SEARCH_MODE_LONG_KID) { + if (memcmp(keyid, desc->u.kid, sizeof(keyid))) { + return 1; + } + } + else if (desc->mode == KEYDB_SEARCH_MODE_SHORT_KID) { + if (memcmp(&keyid[1], &desc->u.kid[1], 1)) { + return 1; + } + } + return 0; +} + +static int keyserver_spawn(enum ks_action action,strlist_t list,KEYDB_SEARCH_DESC *desc, int count,int *prog,unsigned char **fpr,size_t *fpr_len, struct keyserver_spec *keyserver) @@ -1503,9 +1543,9 @@ keyserver_spawn(enum ks_action action,strlist_t list,KEYDB_SEARCH_DESC *desc, keyserver. Keyservers should never accept or send them but we better protect against rogue keyservers. */ - import_keys_stream (spawn->fromchild, stats_handle, fpr, fpr_len, - (opt.keyserver_options.import_options - | IMPORT_NO_SECKEY)); + import_keys_stream(spawn->fromchild,stats_handle,fpr,fpr_len, + (opt.keyserver_options.import_options | IMPORT_NO_SECKEY), + &keyserver_retrieval_filter, desc); import_print_stats(stats_handle); import_release_stats_handle(stats_handle); @@ -2045,7 +2085,7 @@ keyserver_import_cert(const char *name,unsigned char **fpr,size_t *fpr_len) rc=import_keys_stream (key, NULL, fpr, fpr_len, (opt.keyserver_options.import_options - | IMPORT_NO_SECKEY)); + | IMPORT_NO_SECKEY), NULL, NULL); opt.no_armor=armor_status; diff --git a/g10/main.h b/g10/main.h index 6876e0a..4cc56e6 100644 --- a/g10/main.h +++ b/g10/main.h @@ -259,11 +259,13 @@ gcry_mpi_t encode_md_value( PKT_public_key *pk, PKT_secret_key *sk, gcry_md_hd_t md, int hash_algo ); /*-- import.c --*/ +typedef int (*import_filter)(PKT_public_key *pk, PKT_secret_key *sk, void *arg); int parse_import_options(char *str,unsigned int *options,int noisy); void import_keys( char **fnames, int nnames, void *stats_hd, unsigned int options ); int import_keys_stream( iobuf_t inp,void *stats_hd,unsigned char **fpr, - size_t *fpr_len,unsigned int options ); + size_t *fpr_len,unsigned int options, + import_filter constr, void *filter_arg); void *import_new_stats_handle (void); void import_release_stats_handle (void *p); void import_print_stats (void *hd); -- 1.7.10.4 From dbaryshkov at gmail.com Sun Jan 19 23:25:15 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Mon, 20 Jan 2014 02:25:15 +0400 Subject: PKCS 12 support questions In-Reply-To: <87a9esyrxv.fsf@vigenere.g10code.de> References: <87a9esyrxv.fsf@vigenere.g10code.de> Message-ID: Hello, On Sun, Jan 19, 2014 at 6:19 PM, Werner Koch wrote: > On Sun, 19 Jan 2014 01:47, dbaryshkov at gmail.com said: > >> 1) Is there a reason, why minip12 is so limited on supported features? > > Because pkcs#12 is an entirely broken design and I did this only on > customer request for migrating existisng keys. Ah, pkcs#12 is one of two standards for key transport for GOST private keys (second one is pkcs#8). > >> 2) Why is it implemented in gnupg itself - i.e. not in libksba? Would >> it benefitable to push >> at least parts of ASN.1 parsing to libksba? > > Please keep that extra insane data format out of Libksba. pkcs#12 is > plain horror. > > Do you really need it? Isn't X.509 dead anyway? Russian cryptography is largely built around PKI and X.509. I will try adding PKCS#8 support to libksba (in some form). Hope you won't oppose it. -- With best wishes Dmitry From dbaryshkov at gmail.com Mon Jan 20 01:33:34 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Mon, 20 Jan 2014 04:33:34 +0400 Subject: [ksba][PATCH 1/2] Merge _ksba_keyinfo_to_sexp into cryptval_to_sexp Message-ID: <1390178015-22924-1-git-send-email-dbaryshkov@gmail.com> * src/keyinfo.c (cryptval_to_sexp): Add mode 2 support suitable to replace parse keyinfo data. * src/keyinfo.c (_ksba_keyinfo_to_sexp): Use new cryptval_to_sexp mode dedicated to keyinfo parsing. -- _ksba_keyinfo_to_sexp and cryptval_to_sexp share lots of common code. Merge them to be less error prone. Signed-off-by: Dmitry Eremin-Solenikov --- src/keyinfo.c | 356 +++++++++++++++++++++++----------------------------------- 1 file changed, 138 insertions(+), 218 deletions(-) diff --git a/src/keyinfo.c b/src/keyinfo.c index 02dc7ae..0f4f95f 100644 --- a/src/keyinfo.c +++ b/src/keyinfo.c @@ -640,213 +640,6 @@ get_stringbuf (struct stringbuf *sb) return p; } - -/* Assume that der is a buffer of length DERLEN with a DER encoded - Asn.1 structure like this: - - keyInfo ::= SEQUENCE { - SEQUENCE { - algorithm OBJECT IDENTIFIER, - parameters ANY DEFINED BY algorithm OPTIONAL } - publicKey BIT STRING } - - The function parses this structure and create a SEXP suitable to be - used as a public key in Libgcrypt. The S-Exp will be returned in a - string which the caller must free. - - We don't pass an ASN.1 node here but a plain memory block. */ - -gpg_error_t -_ksba_keyinfo_to_sexp (const unsigned char *der, size_t derlen, - ksba_sexp_t *r_string) -{ - gpg_error_t err; - int c; - size_t nread, off, len, parm_off, parm_len; - int parm_type; - char *parm_oid = NULL; - int algoidx; - int is_bitstr; - const unsigned char *parmder = NULL; - size_t parmderlen = 0; - const unsigned char *ctrl; - const char *elem; - struct stringbuf sb; - - *r_string = NULL; - - /* check the outer sequence */ - if (!derlen) - return gpg_error (GPG_ERR_INV_KEYINFO); - c = *der++; derlen--; - if ( c != 0x30 ) - return gpg_error (GPG_ERR_UNEXPECTED_TAG); /* not a SEQUENCE */ - TLV_LENGTH(der); - /* and now the inner part */ - err = get_algorithm (1, der, derlen, &nread, &off, &len, &is_bitstr, - &parm_off, &parm_len, &parm_type); - if (err) - return err; - - /* look into our table of supported algorithms */ - for (algoidx=0; pk_algo_table[algoidx].oid; algoidx++) - { - if ( len == pk_algo_table[algoidx].oidlen - && !memcmp (der+off, pk_algo_table[algoidx].oid, len)) - break; - } - if (!pk_algo_table[algoidx].oid) - return gpg_error (GPG_ERR_UNKNOWN_ALGORITHM); - if (!pk_algo_table[algoidx].supported) - return gpg_error (GPG_ERR_UNSUPPORTED_ALGORITHM); - - if (parm_off && parm_len && parm_type == TYPE_OBJECT_ID) - parm_oid = ksba_oid_to_str (der+parm_off, parm_len); - else if (parm_off && parm_len) - { - parmder = der + parm_off; - parmderlen = parm_len; - } - - der += nread; - derlen -= nread; - - if (is_bitstr) - { /* Funny: X.509 defines the signature value as a bit string but - CMS as an octet string - for ease of implementation we always - allow both */ - if (!derlen) - { - xfree (parm_oid); - return gpg_error (GPG_ERR_INV_KEYINFO); - } - c = *der++; derlen--; - if (c) - fprintf (stderr, "warning: number of unused bits is not zero\n"); - } - - /* fixme: we should calculate the initial length form the size of the - sequence, so that we don't need a realloc later */ - init_stringbuf (&sb, 100); - put_stringbuf (&sb, "(10:public-key("); - - /* fixme: we can also use the oidstring here and prefix it with - "oid." - this way we can pass more information into Libgcrypt or - whatever library is used */ - put_stringbuf_sexp (&sb, pk_algo_table[algoidx].algo_string); - - /* Insert the curve name for ECC. */ - if (pk_algo_table[algoidx].pkalgo == PKALGO_ECC && parm_oid) - { - put_stringbuf (&sb, "("); - put_stringbuf_sexp (&sb, "curve"); - put_stringbuf_sexp (&sb, parm_oid); - put_stringbuf (&sb, ")"); - } - - /* If parameters are given and we have a description for them, parse - them. */ - if (parmder && parmderlen - && pk_algo_table[algoidx].parmelem_string - && pk_algo_table[algoidx].parmctrl_string) - { - elem = pk_algo_table[algoidx].parmelem_string; - ctrl = pk_algo_table[algoidx].parmctrl_string; - for (; *elem; ctrl++, elem++) - { - int is_int; - - if ( (*ctrl & 0x80) && !elem[1] ) - { - /* Hack to allow reading a raw value. */ - is_int = 1; - len = parmderlen; - } - else - { - if (!parmderlen) - { - xfree (parm_oid); - return gpg_error (GPG_ERR_INV_KEYINFO); - } - c = *parmder++; parmderlen--; - if ( c != *ctrl ) - { - xfree (parm_oid); - return gpg_error (GPG_ERR_UNEXPECTED_TAG); - } - is_int = c == 0x02; - TLV_LENGTH (parmder); - } - if (is_int && *elem != '-') /* Take this integer. */ - { - char tmp[2]; - - put_stringbuf (&sb, "("); - tmp[0] = *elem; tmp[1] = 0; - put_stringbuf_sexp (&sb, tmp); - put_stringbuf_mem_sexp (&sb, parmder, len); - parmder += len; - parmderlen -= len; - put_stringbuf (&sb, ")"); - } - } - } - - - /* FIXME: We don't release the stringbuf in case of error - better let the macro jump to a label */ - elem = pk_algo_table[algoidx].elem_string; - ctrl = pk_algo_table[algoidx].ctrl_string; - for (; *elem; ctrl++, elem++) - { - int is_int; - - if ( (*ctrl & 0x80) && !elem[1] ) - { - /* Hack to allow reading a raw value. */ - is_int = 1; - len = derlen; - } - else - { - if (!derlen) - { - xfree (parm_oid); - return gpg_error (GPG_ERR_INV_KEYINFO); - } - c = *der++; derlen--; - if ( c != *ctrl ) - { - xfree (parm_oid); - return gpg_error (GPG_ERR_UNEXPECTED_TAG); - } - is_int = c == 0x02; - TLV_LENGTH (der); - } - if (is_int && *elem != '-') /* Take this integer. */ - { - char tmp[2]; - - put_stringbuf (&sb, "("); - tmp[0] = *elem; tmp[1] = 0; - put_stringbuf_sexp (&sb, tmp); - put_stringbuf_mem_sexp (&sb, der, len); - der += len; - derlen -= len; - put_stringbuf (&sb, ")"); - } - } - put_stringbuf (&sb, "))"); - xfree (parm_oid); - - *r_string = get_stringbuf (&sb); - if (!*r_string) - return gpg_error (GPG_ERR_ENOMEM); - - return 0; -} - /* Match the algorithm string given in BUF which is of length BUFLEN with the known algorithms from our table and returns the table @@ -1572,17 +1365,24 @@ _ksba_algoinfo_from_sexp (ksba_const_sexp_t sexp, /* Mode 0: work as described under _ksba_sigval_to_sexp - mode 1: work as described under _ksba_encval_to_sexp */ + Mode 1: work as described under _ksba_encval_to_sexp + Mode 1: work as described under _ksba_keyinfo_to_sexp + */ static gpg_error_t cryptval_to_sexp (int mode, const unsigned char *der, size_t derlen, ksba_sexp_t *r_string) { gpg_error_t err; const struct algo_table_s *algo_table; + const char *head; int c; - size_t nread, off, len; + size_t nread, off, len, parm_off, parm_len; + int parm_type; + char *parm_oid = NULL; int algoidx; int is_bitstr; + const unsigned char *parmder = NULL; + size_t parmderlen = 0; const unsigned char *ctrl; const char *elem; struct stringbuf sb; @@ -1590,14 +1390,34 @@ cryptval_to_sexp (int mode, const unsigned char *der, size_t derlen, /* FIXME: The entire function is very similar to keyinfo_to_sexp */ *r_string = NULL; - if (!mode) - algo_table = sig_algo_table; - else - algo_table = enc_algo_table; - + switch (mode) + { + case 0: + algo_table = sig_algo_table; + head = "(7:sig-val("; + break; + case 1: + algo_table = enc_algo_table; + head = "(7:enc-val("; + break; + case 2: + algo_table = pk_algo_table; + head = "(10:public-key("; + + /* check the outer sequence */ + if (!derlen) + return gpg_error (GPG_ERR_INV_KEYINFO); + c = *der++; derlen--; + if ( c != 0x30 ) + return gpg_error (GPG_ERR_UNEXPECTED_TAG); /* not a SEQUENCE */ + TLV_LENGTH(der); + break; + default: + return gpg_error (GPG_ERR_INV_KEYINFO); + } err = get_algorithm (1, der, derlen, &nread, &off, &len, &is_bitstr, - NULL, NULL, NULL); + &parm_off, &parm_len, &parm_type); if (err) return err; @@ -1613,6 +1433,14 @@ cryptval_to_sexp (int mode, const unsigned char *der, size_t derlen, if (!algo_table[algoidx].supported) return gpg_error (GPG_ERR_UNSUPPORTED_ALGORITHM); + if (parm_off && parm_len && parm_type == TYPE_OBJECT_ID) + parm_oid = ksba_oid_to_str (der+parm_off, parm_len); + else if (parm_off && parm_len) + { + parmder = der + parm_off; + parmderlen = parm_len; + } + der += nread; derlen -= nread; @@ -1630,9 +1458,71 @@ cryptval_to_sexp (int mode, const unsigned char *der, size_t derlen, /* fixme: we should calculate the initial length form the size of the sequence, so that we don't neen a realloc later */ init_stringbuf (&sb, 100); - put_stringbuf (&sb, mode? "(7:enc-val(":"(7:sig-val("); + put_stringbuf (&sb, head); + + /* fixme: in mode 2 we can also use the oidstring here and prefix it + with "oid." - this way we can pass more information into Libgcrypt or + whatever library is used */ put_stringbuf_sexp (&sb, algo_table[algoidx].algo_string); + /* Insert the curve name for ECC. */ + if (pk_algo_table[algoidx].pkalgo == PKALGO_ECC && parm_oid) + { + put_stringbuf (&sb, "("); + put_stringbuf_sexp (&sb, "curve"); + put_stringbuf_sexp (&sb, parm_oid); + put_stringbuf (&sb, ")"); + } + + /* If parameters are given and we have a description for them, parse + them. */ + if (parmder && parmderlen + && pk_algo_table[algoidx].parmelem_string + && pk_algo_table[algoidx].parmctrl_string) + { + elem = pk_algo_table[algoidx].parmelem_string; + ctrl = pk_algo_table[algoidx].parmctrl_string; + for (; *elem; ctrl++, elem++) + { + int is_int; + + if ( (*ctrl & 0x80) && !elem[1] ) + { + /* Hack to allow reading a raw value. */ + is_int = 1; + len = parmderlen; + } + else + { + if (!parmderlen) + { + xfree (parm_oid); + return gpg_error (GPG_ERR_INV_KEYINFO); + } + c = *parmder++; parmderlen--; + if ( c != *ctrl ) + { + xfree (parm_oid); + return gpg_error (GPG_ERR_UNEXPECTED_TAG); + } + is_int = c == 0x02; + TLV_LENGTH (parmder); + } + if (is_int && *elem != '-') /* Take this integer. */ + { + char tmp[2]; + + put_stringbuf (&sb, "("); + tmp[0] = *elem; tmp[1] = 0; + put_stringbuf_sexp (&sb, tmp); + put_stringbuf_mem_sexp (&sb, parmder, len); + parmder += len; + parmderlen -= len; + put_stringbuf (&sb, ")"); + } + } + } + /* FIXME: We don't release the stringbuf in case of error better let the macro jump to a label */ elem = algo_table[algoidx].elem_string; @@ -1649,10 +1539,16 @@ cryptval_to_sexp (int mode, const unsigned char *der, size_t derlen, else { if (!derlen) - return gpg_error (GPG_ERR_INV_KEYINFO); + { + xfree (parm_oid); + return gpg_error (GPG_ERR_INV_KEYINFO); + } c = *der++; derlen--; if ( c != *ctrl ) - return gpg_error (GPG_ERR_UNEXPECTED_TAG); + { + xfree (parm_oid); + return gpg_error (GPG_ERR_UNEXPECTED_TAG); + } is_int = c == 0x02; TLV_LENGTH (der); } @@ -1670,6 +1566,7 @@ cryptval_to_sexp (int mode, const unsigned char *der, size_t derlen, } } put_stringbuf (&sb, ")"); + xfree (parm_oid); if (!mode && algo_table[algoidx].digest_string) { /* Insert the hash algorithm if included in the OID. */ @@ -1744,3 +1641,26 @@ _ksba_encval_to_sexp (const unsigned char *der, size_t derlen, { return cryptval_to_sexp (1, der, derlen, r_string); } + + +/* Assume that der is a buffer of length DERLEN with a DER encoded + Asn.1 structure like this: + + keyInfo ::= SEQUENCE { + SEQUENCE { + algorithm OBJECT IDENTIFIER, + parameters ANY DEFINED BY algorithm OPTIONAL } + publicKey BIT STRING } + + The function parses this structure and create a SEXP suitable to be + used as a public key in Libgcrypt. The S-Exp will be returned in a + string which the caller must free. + + We don't pass an ASN.1 node here but a plain memory block. */ + +gpg_error_t +_ksba_keyinfo_to_sexp (const unsigned char *der, size_t derlen, + ksba_sexp_t *r_string) +{ + return cryptval_to_sexp (2, der, derlen, r_string); +} -- 1.8.5.2 From dbaryshkov at gmail.com Mon Jan 20 01:33:35 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Mon, 20 Jan 2014 04:33:35 +0400 Subject: [ksba][PATCH 2/2] Merge functions that convert from sexp to der In-Reply-To: <1390178015-22924-1-git-send-email-dbaryshkov@gmail.com> References: <1390178015-22924-1-git-send-email-dbaryshkov@gmail.com> Message-ID: <1390178015-22924-2-git-send-email-dbaryshkov@gmail.com> * src/keyinfo.c (cryptval_from_sexp): New. Contains code merged from _ksba_keyinfo_from_sexp and _ksba_algoinfo_from_sexp functions. * src/keyinfo.c (_ksba_algoinfo_from_sexp, _ksba_keyinfo_from_sexp): Use cryptval_from_sexp function. Merge two functions translating S-expressions to DER representation. They share great amount of code, so merge is benefitable. Signed-off-by: Dmitry Eremin-Solenikov --- src/keyinfo.c | 454 +++++++++++++--------------------------------------------- 1 file changed, 99 insertions(+), 355 deletions(-) diff --git a/src/keyinfo.c b/src/keyinfo.c index 0f4f95f..cdea1e6 100644 --- a/src/keyinfo.c +++ b/src/keyinfo.c @@ -702,12 +702,11 @@ oid_from_buffer (const unsigned char *buf, int buflen, int *oidlen, return pk_algo_table[i].oid; } - -/* Take a public-key S-Exp and convert it into a DER encoded - publicKeyInfo */ -gpg_error_t -_ksba_keyinfo_from_sexp (ksba_const_sexp_t sexp, - unsigned char **r_der, size_t *r_derlen) +/* Mode 0: work with public key + Mode 1: work with signature */ +static gpg_error_t +cryptval_from_sexp (int mode, ksba_const_sexp_t sexp, + unsigned char **r_der, size_t *r_derlen) { gpg_error_t err; const unsigned char *s; @@ -748,9 +747,13 @@ _ksba_keyinfo_from_sexp (ksba_const_sexp_t sexp, if (!n || *s != ':') return gpg_error (GPG_ERR_INV_SEXP); /* we don't allow empty lengths */ s++; - if (n != 10 || memcmp (s, "public-key", 10)) + if (n == 7 && !memcmp (s, "sig-val", 7)) + s += 7; + else if (n == 10 && !memcmp (s, "public-key", 10)) + s += 10; + else return gpg_error (GPG_ERR_UNKNOWN_SEXP); - s += 10; + if (*s != '(') return gpg_error (digitp (s)? GPG_ERR_UNKNOWN_SEXP : GPG_ERR_INV_SEXP); s++; @@ -761,7 +764,7 @@ _ksba_keyinfo_from_sexp (ksba_const_sexp_t sexp, if (!n || *s != ':') return gpg_error (GPG_ERR_INV_SEXP); /* we don't allow empty lengths */ s++; - oid = oid_from_buffer (s, n, &oidlen, &pkalgo, 0); + oid = oid_from_buffer (s, n, &oidlen, &pkalgo, mode); if (!oid) return gpg_error (GPG_ERR_UNSUPPORTED_ALGORITHM); s += n; @@ -809,9 +812,9 @@ _ksba_keyinfo_from_sexp (ksba_const_sexp_t sexp, algoparmdesc = NULL; switch (pkalgo) { - case PKALGO_RSA: parmdesc = "ne"; break; - case PKALGO_DSA: parmdesc = "y" ; algoparmdesc = "pqg"; break; - case PKALGO_ECC: parmdesc = "Cq"; break; + case PKALGO_RSA: parmdesc = mode ? "" : "ne"; break; + case PKALGO_DSA: parmdesc = mode ? "" : "y" ; algoparmdesc = "pqg"; break; + case PKALGO_ECC: parmdesc = mode ? "C" : "Cq"; break; default: return gpg_error (GPG_ERR_UNKNOWN_ALGORITHM); } @@ -868,71 +871,74 @@ _ksba_keyinfo_from_sexp (ksba_const_sexp_t sexp, 2. We create the outer sequence include the algorithm identifier and the bit string from step 1. */ - if (pkalgo == PKALGO_ECC) + if (!mode) { - /* Write the bit string header and the number of unused bits. */ - err = _ksba_ber_write_tl (writer, TYPE_BIT_STRING, CLASS_UNIVERSAL, - 0, parm[idxtbl[1]].valuelen + 1); - if (!err) - err = ksba_writer_write (writer, "", 1); - /* And the actual raw value. */ - if (!err) - err = ksba_writer_write (writer, parm[idxtbl[1]].value, - parm[idxtbl[1]].valuelen); - if (err) - goto leave; - - } - else /* RSA and DSA */ - { - /* Calculate the size of the sequence value and the size of the - bit string value. NOt ethat in case there is only one - integer to write, no sequence is used. */ - for (n=0, i=0; i < idxtbllen; i++ ) + if (pkalgo == PKALGO_ECC) { - n += _ksba_ber_count_tl (TYPE_INTEGER, CLASS_UNIVERSAL, 0, - parm[idxtbl[i]].valuelen); - n += parm[idxtbl[i]].valuelen; - } + /* Write the bit string header and the number of unused bits. */ + err = _ksba_ber_write_tl (writer, TYPE_BIT_STRING, CLASS_UNIVERSAL, + 0, parm[idxtbl[1]].valuelen + 1); + if (!err) + err = ksba_writer_write (writer, "", 1); + /* And the actual raw value. */ + if (!err) + err = ksba_writer_write (writer, parm[idxtbl[1]].value, + parm[idxtbl[1]].valuelen); + if (err) + goto leave; - n1 = 1; /* # of unused bits. */ - if (idxtbllen > 1) - n1 += _ksba_ber_count_tl (TYPE_SEQUENCE, CLASS_UNIVERSAL, 1, n); - n1 += n; + } + else /* RSA and DSA */ + { + /* Calculate the size of the sequence value and the size of the + bit string value. NOt ethat in case there is only one + integer to write, no sequence is used. */ + for (n=0, i=0; i < idxtbllen; i++ ) + { + n += _ksba_ber_count_tl (TYPE_INTEGER, CLASS_UNIVERSAL, 0, + parm[idxtbl[i]].valuelen); + n += parm[idxtbl[i]].valuelen; + } - /* Write the bit string header and the number of unused bits. */ - err = _ksba_ber_write_tl (writer, TYPE_BIT_STRING, CLASS_UNIVERSAL, - 0, n1); - if (!err) - err = ksba_writer_write (writer, "", 1); - if (err) - goto leave; + n1 = 1; /* # of unused bits. */ + if (idxtbllen > 1) + n1 += _ksba_ber_count_tl (TYPE_SEQUENCE, CLASS_UNIVERSAL, 1, n); + n1 += n; - /* Write the sequence tag and the integers. */ - if (idxtbllen > 1) - err = _ksba_ber_write_tl (writer, TYPE_SEQUENCE, CLASS_UNIVERSAL, 1,n); - if (err) - goto leave; - for (i=0; i < idxtbllen; i++) - { - /* fixme: we should make sure that the integer conforms to the - ASN.1 encoding rules. */ - err = _ksba_ber_write_tl (writer, TYPE_INTEGER, CLASS_UNIVERSAL, 0, - parm[idxtbl[i]].valuelen); + /* Write the bit string header and the number of unused bits. */ + err = _ksba_ber_write_tl (writer, TYPE_BIT_STRING, CLASS_UNIVERSAL, + 0, n1); if (!err) - err = ksba_writer_write (writer, parm[idxtbl[i]].value, - parm[idxtbl[i]].valuelen); + err = ksba_writer_write (writer, "", 1); + if (err) + goto leave; + + /* Write the sequence tag and the integers. */ + if (idxtbllen > 1) + err = _ksba_ber_write_tl (writer, TYPE_SEQUENCE, CLASS_UNIVERSAL, 1,n); if (err) goto leave; + for (i=0; i < idxtbllen; i++) + { + /* fixme: we should make sure that the integer conforms to the + ASN.1 encoding rules. */ + err = _ksba_ber_write_tl (writer, TYPE_INTEGER, CLASS_UNIVERSAL, 0, + parm[idxtbl[i]].valuelen); + if (!err) + err = ksba_writer_write (writer, parm[idxtbl[i]].value, + parm[idxtbl[i]].valuelen); + if (err) + goto leave; + } } - } - /* Get the encoded bit string. */ - bitstr_value = ksba_writer_snatch_mem (writer, &bitstr_len); - if (!bitstr_value) - { - err = gpg_error (GPG_ERR_ENOMEM); - goto leave; + /* Get the encoded bit string. */ + bitstr_value = ksba_writer_snatch_mem (writer, &bitstr_len); + if (!bitstr_value) + { + err = gpg_error (GPG_ERR_ENOMEM); + goto leave; + } } /* If the algorithmIdentifier requires a sequence with parameters, @@ -1017,14 +1023,17 @@ _ksba_keyinfo_from_sexp (ksba_const_sexp_t sexp, n += _ksba_ber_count_tl (TYPE_NULL, CLASS_UNIVERSAL, 0, 0); } - n1 = n; - n1 += _ksba_ber_count_tl (TYPE_SEQUENCE, CLASS_UNIVERSAL, 1, n); - n1 += bitstr_len; + if (!mode) + { + n1 = n; + n1 += _ksba_ber_count_tl (TYPE_SEQUENCE, CLASS_UNIVERSAL, 1, n); + n1 += bitstr_len; - /* The outer sequence. */ - err = _ksba_ber_write_tl (writer, TYPE_SEQUENCE, CLASS_UNIVERSAL, 1, n1); - if (err) - goto leave; + /* The outer sequence. */ + err = _ksba_ber_write_tl (writer, TYPE_SEQUENCE, CLASS_UNIVERSAL, 1, n1); + if (err) + goto leave; + } /* The sequence. */ err = _ksba_ber_write_tl (writer, TYPE_SEQUENCE, CLASS_UNIVERSAL, 1, n); @@ -1058,9 +1067,12 @@ _ksba_keyinfo_from_sexp (ksba_const_sexp_t sexp, goto leave; /* Append the pre-constructed bit string. */ - err = ksba_writer_write (writer, bitstr_value, bitstr_len); - if (err) - goto leave; + if (!mode) + { + err = ksba_writer_write (writer, bitstr_value, bitstr_len); + if (err) + goto leave; + } /* Get the result. */ *r_der = ksba_writer_snatch_mem (writer, r_derlen); @@ -1074,6 +1086,15 @@ _ksba_keyinfo_from_sexp (ksba_const_sexp_t sexp, return err; } +/* Take a public-key S-Exp and convert it into a DER encoded + publicKeyInfo */ +gpg_error_t +_ksba_keyinfo_from_sexp (ksba_const_sexp_t sexp, + unsigned char **r_der, size_t *r_derlen) +{ + return cryptval_from_sexp (0, sexp, r_der, r_derlen); +} + /* Take a sig-val s-expression and convert it into a DER encoded algorithmInfo. Unfortunately this function clones a lot of code @@ -1082,284 +1103,7 @@ gpg_error_t _ksba_algoinfo_from_sexp (ksba_const_sexp_t sexp, unsigned char **r_der, size_t *r_derlen) { - gpg_error_t err; - const unsigned char *s; - char *endp; - unsigned long n; - const unsigned char *oid; - int oidlen; - unsigned char *curve_oid = NULL; - size_t curve_oidlen; - pkalgo_t pkalgo; - int i; - struct { - const char *name; - int namelen; - const unsigned char *value; - int valuelen; - } parm[10]; - int parmidx; - int idxtbl[10]; - int idxtbllen; - const char *parmdesc, *algoparmdesc; - ksba_writer_t writer = NULL; - void *algoparmseq_value = NULL; - size_t algoparmseq_len; - - if (!sexp) - return gpg_error (GPG_ERR_INV_VALUE); - - s = sexp; - if (*s != '(') - return gpg_error (GPG_ERR_INV_SEXP); - s++; - - n = strtoul (s, &endp, 10); - s = endp; - if (!n || *s != ':') - return gpg_error (GPG_ERR_INV_SEXP); /* We don't allow empty lengths. */ - s++; - if (n == 7 && !memcmp (s, "sig-val", 7)) - s += 7; - else if (n == 10 && !memcmp (s, "public-key", 10)) - s += 10; - else - return gpg_error (GPG_ERR_UNKNOWN_SEXP); - - if (*s != '(') - return gpg_error (digitp (s)? GPG_ERR_UNKNOWN_SEXP : GPG_ERR_INV_SEXP); - s++; - - /* Break out the algorithm ID */ - n = strtoul (s, &endp, 10); - s = endp; - if (!n || *s != ':') - return gpg_error (GPG_ERR_INV_SEXP); /* We don't allow empty lengths. */ - s++; - oid = oid_from_buffer (s, n, &oidlen, &pkalgo, 1); - if (!oid) - return gpg_error (GPG_ERR_UNSUPPORTED_ALGORITHM); - s += n; - - /* Collect all the values */ - for (parmidx = 0; *s != ')' ; parmidx++) - { - if (parmidx >= DIM(parm)) - return gpg_error (GPG_ERR_GENERAL); - if (*s != '(') - return gpg_error (digitp(s)? GPG_ERR_UNKNOWN_SEXP:GPG_ERR_INV_SEXP); - s++; - n = strtoul (s, &endp, 10); - s = endp; - if (!n || *s != ':') - return gpg_error (GPG_ERR_INV_SEXP); - s++; - parm[parmidx].name = s; - parm[parmidx].namelen = n; - s += n; - if (!digitp(s)) - return gpg_error (GPG_ERR_UNKNOWN_SEXP); /* ... or invalid S-Exp. */ - - n = strtoul (s, &endp, 10); - s = endp; - if (!n || *s != ':') - return gpg_error (GPG_ERR_INV_SEXP); - s++; - parm[parmidx].value = s; - parm[parmidx].valuelen = n; - s += n; - if ( *s != ')') - return gpg_error (GPG_ERR_UNKNOWN_SEXP); /* ... or invalid S-Exp. */ - s++; - } - s++; - /* We need another closing parenthesis. */ - if ( *s != ')' ) - return gpg_error (GPG_ERR_INV_SEXP); - - /* Describe the parameters in the order we want them and construct - IDXTBL to access them. For DSA wie also set algoparmdesc so - that we can later build the parameters for the - algorithmIdentifier. */ - algoparmdesc = NULL; - switch (pkalgo) - { - case PKALGO_RSA: parmdesc = ""; break; - case PKALGO_DSA: parmdesc = "" ; algoparmdesc = "pqg"; break; - case PKALGO_ECC: parmdesc = "C"; break; - default: return gpg_error (GPG_ERR_UNKNOWN_ALGORITHM); - } - - idxtbllen = 0; - for (s = parmdesc; *s; s++) - { - for (i=0; i < parmidx; i++) - { - assert (idxtbllen < DIM (idxtbl)); - switch (*s) - { - case 'C': /* Magic value for "curve". */ - if (parm[i].namelen == 5 && !memcmp (parm[i].name, "curve", 5)) - { - idxtbl[idxtbllen++] = i; - i = parmidx; /* Break inner loop. */ - } - break; - default: - if (parm[i].namelen == 1 && parm[i].name[0] == *s) - { - idxtbl[idxtbllen++] = i; - i = parmidx; /* Break inner loop. */ - } - break; - } - } - } - if (idxtbllen != strlen (parmdesc)) - return gpg_error (GPG_ERR_UNKNOWN_SEXP); - - if (pkalgo == PKALGO_ECC) - { - curve_oid = get_ecc_curve_oid (parm[idxtbl[0]].value, - parm[idxtbl[0]].valuelen, - &curve_oidlen); - if (!curve_oid) - return gpg_error (GPG_ERR_UNKNOWN_SEXP); - } - - - /* Create write object. */ - err = ksba_writer_new (&writer); - if (err) - goto leave; - err = ksba_writer_set_mem (writer, 1024); - if (err) - goto leave; - - /* Create the sequence of the algorithm identifier. */ - - /* If the algorithmIdentifier requires a sequence with parameters, - build them now. We can reuse the IDXTBL for that. */ - if (algoparmdesc) - { - idxtbllen = 0; - for (s = algoparmdesc; *s; s++) - { - for (i=0; i < parmidx; i++) - { - assert (idxtbllen < DIM (idxtbl)); - if (parm[i].namelen == 1 && parm[i].name[0] == *s) - { - idxtbl[idxtbllen++] = i; - break; - } - } - } - if (idxtbllen != strlen (algoparmdesc)) - return gpg_error (GPG_ERR_UNKNOWN_SEXP); - - err = ksba_writer_set_mem (writer, 1024); - if (err) - goto leave; - - /* Calculate the size of the sequence. */ - for (n=0, i=0; i < idxtbllen; i++ ) - { - n += _ksba_ber_count_tl (TYPE_INTEGER, CLASS_UNIVERSAL, 0, - parm[idxtbl[i]].valuelen); - n += parm[idxtbl[i]].valuelen; - } - - /* Write the sequence tag followed by the integers. */ - err = _ksba_ber_write_tl (writer, TYPE_SEQUENCE, CLASS_UNIVERSAL, 1, n); - if (err) - goto leave; - for (i=0; i < idxtbllen; i++) - { - err = _ksba_ber_write_tl (writer, TYPE_INTEGER, CLASS_UNIVERSAL, 0, - parm[idxtbl[i]].valuelen); - if (!err) - err = ksba_writer_write (writer, parm[idxtbl[i]].value, - parm[idxtbl[i]].valuelen); - if (err) - goto leave; - } - - /* Get the encoded sequence. */ - algoparmseq_value = ksba_writer_snatch_mem (writer, &algoparmseq_len); - if (!algoparmseq_value) - { - err = gpg_error (GPG_ERR_ENOMEM); - goto leave; - } - } - else - algoparmseq_len = 0; - - /* Reinitialize the buffer to create the sequence. */ - err = ksba_writer_set_mem (writer, 1024); - if (err) - goto leave; - - /* Calulate lengths. */ - n = _ksba_ber_count_tl (TYPE_OBJECT_ID, CLASS_UNIVERSAL, 0, oidlen); - n += oidlen; - if (algoparmseq_len) - { - n += algoparmseq_len; - } - else if (pkalgo == PKALGO_ECC) - { - n += _ksba_ber_count_tl (TYPE_OBJECT_ID, CLASS_UNIVERSAL, - 0, curve_oidlen); - n += curve_oidlen; - } - else if (pkalgo == PKALGO_RSA) - { - n += _ksba_ber_count_tl (TYPE_NULL, CLASS_UNIVERSAL, 0, 0); - } - - /* Write the sequence. */ - err = _ksba_ber_write_tl (writer, TYPE_SEQUENCE, CLASS_UNIVERSAL, 1, n); - if (err) - goto leave; - - /* Write the object id. */ - err = _ksba_ber_write_tl (writer, TYPE_OBJECT_ID, CLASS_UNIVERSAL, 0, oidlen); - if (!err) - err = ksba_writer_write (writer, oid, oidlen); - if (err) - goto leave; - - /* Write the parameters. */ - if (algoparmseq_len) - { - err = ksba_writer_write (writer, algoparmseq_value, algoparmseq_len); - } - else if (pkalgo == PKALGO_ECC) - { - /* We only support the namedCuve choice for ECC parameters. */ - err = _ksba_ber_write_tl (writer, TYPE_OBJECT_ID, CLASS_UNIVERSAL, - 0, curve_oidlen); - if (!err) - err = ksba_writer_write (writer, curve_oid, curve_oidlen); - } - else if (pkalgo == PKALGO_RSA) - { - err = _ksba_ber_write_tl (writer, TYPE_NULL, CLASS_UNIVERSAL, 0, 0); - } - if (err) - goto leave; - - /* Get the result. */ - *r_der = ksba_writer_snatch_mem (writer, r_derlen); - if (!*r_der) - err = gpg_error (GPG_ERR_ENOMEM); - - leave: - ksba_writer_release (writer); - xfree (curve_oid); - return err; + return cryptval_from_sexp (1, sexp, r_der, r_derlen); } -- 1.8.5.2 From hans at guardianproject.info Mon Jan 20 16:39:08 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 20 Jan 2014 10:39:08 -0500 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52DB9A0D.4040900@iki.fi> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> Message-ID: <52DD431C.2010301@guardianproject.info> On 01/19/2014 04:25 AM, Jussi Kivilinna wrote: > On 19.01.2014 06:08, Hans-Christoph Steiner wrote: >> >> >> On 01/18/2014 06:31 AM, Jussi Kivilinna wrote: >>> On 17.01.2014 20:34, Hans-Christoph Steiner wrote: >>>> >>>> On GPG for Android, I've updated to the latest libgcrypt in master (or close >>>> to it, its commit 4b7db51ad5d1bf98fd08ca3048f258059eca61a4). Now it seems >>>> that any operation that needs a passphrase is crashing somewhere in libgcrypt. >>>> I've tried building with auto-detection of CPU which enables Padlock, Intelt >>>> DRNG, and NEON. I also tried with --disable-padlock-support >>>> --disable-drng-support --disable-neon-support, and seemed to get the same thing. >>>> >>>> I've also tried running gpg-agent with and without --enable-ssh-support, and >>>> same result each time. >>>> >>>> Here's the basic backtrace: >>> <..snip..> >>>> From the bug report in our tracker, you can download the complete build log, a >>>> debug log from the Android app, a log from gpg-agent, and a log from gpgme: >>>> >>>> https://dev.guardianproject.info/issues/2888 >>> >>> Have you configured gcc flags correctly for target platform? It seems that >>> compiler (and libgcrypt assembly) are configured to allow unaligned memory >>> accesses, but target does not support them. >>> > <...snip...> >>> -Jussi >>> >>> [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html >> >> I forget if I mentioned this before: the build flags are set by the default >> Android build system. >> >> So I built the whole thing again, manually adding -mno-unaligned-access to the >> libgcrypt build, and the tests seem to be failing in the same place. I tested >> head of master on the armv7a emulator, which failed a lot more, and the head >> of LIBGCRYPT-1-6-BRANCH on the Nexus 7 ARMv7 tablet, which failed in the same >> places. Any pointers for next steps? >> > > That's a bit strange. Do you have crash logs of these? > > -Jussi The crash log is here: https://dev.guardianproject.info/attachments/download/1130/gpg-agent-libgcrypt-mno-unaligned-access-crash-log.txt If you want to try running it on an Android device or emulator, you can find a recent build here, but one what does not have -mno-unaligned-access manually set: https://guardianproject.info/builds/GnuPrivacyGuard/ .hc >> FYI, I'm gathering all these log files on our bug tracker: >> https://dev.guardianproject.info/issues/2888 >> >> Attached are the latest test logs, including the full build log for head of >> master running tests on the armv7a emulator. >> >> .hc >> >> > -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From dbaryshkov at gmail.com Mon Jan 20 19:36:19 2014 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Mon, 20 Jan 2014 22:36:19 +0400 Subject: PKCS 12 support questions In-Reply-To: <87a9esyrxv.fsf@vigenere.g10code.de> References: <87a9esyrxv.fsf@vigenere.g10code.de> Message-ID: On Sun, Jan 19, 2014 at 6:19 PM, Werner Koch wrote: > On Sun, 19 Jan 2014 01:47, dbaryshkov at gmail.com said: > >> 1) Is there a reason, why minip12 is so limited on supported features? > > Because pkcs#12 is an entirely broken design and I did this only on > customer request for migrating existisng keys. By the way, what is so broken in pkcs#12 in your opinion? It looks like encrypted private keys follow the structure that looks like parts of pkcs#12. 80.112.143.48:80 -- With best wishes Dmitry From dkg at fifthhorseman.net Tue Jan 21 01:17:31 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 20 Jan 2014 19:17:31 -0500 Subject: unnumberedsec within enumerate in doc/gpl.texi ? Message-ID: <871u024290.fsf@alice.fifthhorseman.net> I'm trying to replicate a minimalist build pattern on a debian testing machine. I take the following steps: git clone --branch STABLE-BRANCH-1-4 git://git.gnupg.org/gnupg.git cd gnupg/ ./autogen.sh ./configure --enable-maintainer-mode && make and, i get the following error message when trying to compile the documentation. i find this weird, because i can't imagine that gpl.texi has changed much: [...] make[2]: Entering directory `/tmp/cdtemp.4EuYnI/gnupg/doc' Updating ./version.texi restore=: && backupdir=".am$$" && \ am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd . && \ rm -rf $backupdir && mkdir $backupdir && \ if (makeinfo --version) >/dev/null 2>&1; then \ for f in gnupg1.info gnupg1.info-[0-9] gnupg1.info-[0-9][0-9] gnupg1.i[0-9] gnupg1.i[0-9][0-9]; do \ if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \ done; \ else :; fi && \ cd "$am__cwd"; \ if makeinfo -I . --css-include=./texi.css -D gpgone -I . \ -o gnupg1.info gnupg1.texi; \ then \ rc=0; \ CDPATH="${ZSH_VERSION+.}:" && cd .; \ else \ rc=$?; \ CDPATH="${ZSH_VERSION+.}:" && cd . && \ $restore $backupdir/* `echo "./gnupg1.info" | sed 's|[^/]*$||'`; \ fi; \ rm -rf $backupdir; exit $rc ./gpl.texi:668: @unnumberedsec seen before @end enumerate ./gpl.texi:725: unmatched `@end enumerate' make[2]: *** [gnupg1.info] Error 1 make[2]: Leaving directory `/tmp/cdtemp.4EuYnI/gnupg/doc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/cdtemp.4EuYnI/gnupg' make: *** [all] Error 2 2 dkg at alice:/tmp/cdtemp.4EuYnI/gnupg$ the following diff seems to resolve the error message: -------------------------- diff --git a/doc/gpl.texi b/doc/gpl.texi index 7f9a48a..855ef18 100644 --- a/doc/gpl.texi +++ b/doc/gpl.texi @@ -665,6 +665,7 @@ copy of the Program in return for a fee. @ifinfo @center END OF TERMS AND CONDITIONS @end ifinfo + at end enumerate @unnumberedsec How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest @@ -722,4 +723,3 @@ applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read @url{http://www.gnu.org/philosophy/why-not-lgpl.html}. - at end enumerate -------------------------- Is there something wrong with my initial build invocation, or with my build environment? i'm having a hard time believing that doc/gpl.texi is likely to have a bug after all these years. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From gniibe at fsij.org Tue Jan 21 02:53:17 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 21 Jan 2014 10:53:17 +0900 Subject: unnumberedsec within enumerate in doc/gpl.texi ? In-Reply-To: <871u024290.fsf@alice.fifthhorseman.net> References: <871u024290.fsf@alice.fifthhorseman.net> Message-ID: <1390269197.1543.4.camel@cfw2.gniibe.org> On 2014-01-20 at 19:17 -0500, Daniel Kahn Gillmor wrote: > Is there something wrong with my initial build invocation, or with my > build environment? i'm having a hard time believing that doc/gpl.texi > is likely to have a bug after all these years. I checked the master branch and found a fix. commit ff6115227a1ced14e2fb3d160a12181b9dfbc502 Author: Werner Koch Date: Thu Apr 18 14:40:43 2013 +0200 doc: Formatting fixes. * doc/Makefile.am (.fig.jpg): Correct to use -L jpeg. * doc/gpg.texi: Fix cross reference for --options. * doc/gpgsm.texi: Likewise. * doc/gpl.texi: Fix enumerate and re-indent examples. -- Reported-by: Ian Abbott Signed-off-by: Werner Koch In my computer, I have another one, gpl-3.0.texi from www.gnu.org/licenses/ and it's a bit different for formatting. Latter uses '@.' for a period in 'Disclaimer of Warranty' and 'FITNESS FOR A PARTICULAR PURPOSE at .' in another section. The CVS log says: revision 1.7 date: 2012-12-04 04:24:55 +0900; author: karl; state: Exp; lines: +4 -4; commitid: QdJ2HnNGumFWwOuw; end-of-sentence spacing fixes from Paul Eggert (did not seem worth fixing every format and/or every version I think that it changes some formatting occasionally. -- From gniibe at fsij.org Tue Jan 21 03:30:24 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 21 Jan 2014 11:30:24 +0900 Subject: usage flags for bitcoin addresses on OpenPGP keys [was: Re: human readable key algorithm] In-Reply-To: <52D85684.7070808@fifthhorseman.net> References: <1389858516.16357.2.camel@cfw2.gniibe.org> <87bnzc430z.fsf@vigenere.g10code.de> <1389879021.4429.0.camel@latx1.gniibe.org> <87zjmv3k89.fsf@vigenere.g10code.de> <52D85684.7070808@fifthhorseman.net> Message-ID: <1390271424.1543.6.camel@cfw2.gniibe.org> On 2014-01-16 at 17:00 -0500, Daniel Kahn Gillmor wrote: > I agree with the suggestion to use a notation. In fact, i'd rather not > see such a key marked as authentication-capable, because that would > imply that it should be used in other authentication contexts (like > SSH). I also don't think the key is really used in bitcoin in > authentication contexts -- aiui, in bitcoin, the wallet's key is only > used for signing an outbound transaction. this isn't an authentication > step, it's clearly a digital signature. > > That said, it's not an OpenPGP digital signature, so maybe the > traditional signing flag doesn't make sense either. I certainly > wouldn't want attaching such a key to my OpenPGP certificate to make it > so that when i sent mail it signed my mail with my bitcoin wallet's key! Thank you for your suggestion. You are right (and I am a kind of stupid to have such a strange subkey, even for my own experiment :-). > I note that gpg's notion of "capabilities" doesn't map directly to the > usage-flags subpacket anyway (since E maps to multiple usage flags, and > some defined usage flags aren't settable). I wonder if gpg should > expose a "bitcoin address" capability (within --expert mode) and set > such a subkey up as having no usage flags set, and a notation like: > > extended-usage at gnupg.org=bitcoin > > in human-readable form, gpg could indicate this as "Usage: B" Makes sense. I think that no key usage flags set would be better than newly defined key flag, because it's out of scope of OpenPGP. I'm going to look the code for user interface when there's no key usage flags. By the way, let me speak about how I was stupid. Adding a secp256k1 subkey (and upload it to keyserver), I had expected advertising my Bitcoin address only to those who have the development version of GnuPG. No, I was wrong. Keyserver didn't accept my upload. Reading sks-keyserver implementation (parse_ecdsa_pubkey in parsePGP.ml), it handles curves defined in RFC6637, but fails at oid_to_psize if its OID is not listed in RFC6637. -- From dkg at fifthhorseman.net Tue Jan 21 04:15:21 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 20 Jan 2014 22:15:21 -0500 Subject: [PATCH] init trustdb before trying to clear it In-Reply-To: <87sisp51gp.fsf@alice.fifthhorseman.net> References: <87sisp51gp.fsf@alice.fifthhorseman.net> Message-ID: <1390274121-11876-1-git-send-email-dkg@fifthhorseman.net> This avoids failure when importing with --always-trust on gpg 1.4.16, as reported in http://bugs.debian.org/735363 --- g10/trustdb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/g10/trustdb.c b/g10/trustdb.c index 0bf92e4..828b90f 100644 --- a/g10/trustdb.c +++ b/g10/trustdb.c @@ -927,6 +927,8 @@ clear_ownertrusts (PKT_public_key *pk) TRUSTREC rec; int rc; + init_trustdb(); + if (trustdb_args.no_trustdb && opt.trust_model == TM_ALWAYS) return 0; -- 1.8.5.2 From chris.gilg at link-comm.com Tue Jan 21 16:03:33 2014 From: chris.gilg at link-comm.com (Chris) Date: Tue, 21 Jan 2014 15:03:33 +0000 (UTC) Subject: GPGME trouble finding gpg executable. Message-ID: I posted this to the incorrect mailing list. I'm reposting here instead, where it actually belongs. I have been attempting to use GPGME for a Qt app under Windows. I'm running into issues with two applications that use the same code finding the gpg executable. I set the engine info in both t-engine-info.c( exists in gpgme test directory ) and main.cpp ( exists in my Qt app directory ) applications using: gpgme_set_engine_info(GPGME_PROTOCOL_OpenPGP,"c:\\gnupg\\gpg.exe", "c:\\Users\\Chris\\AppData\\Roaming\\gnupg\\"); gpgme_check_version (NULL); err = gpgme_get_engine_info (&info); printf(" version = %s \n", info->version ); fail_if_err (err); The test app "t-engine-info" prints out " version = 1.4.9 ". My Qt app prints out " version = (null) ", The qt application throws a "GPGME: Invalid crypto engine" error on: err = gpgme_engine_check_version (GPGME_PROTOCOL_OpenPGP); fail_if_err (err); but the t-engine-info application does not. Why cannot it not find the executable in the my qt application but it can find the executable in the t-engine-info application? I've ran out of all possible ideas, and I am not sure what else I can try. Any tips or solutions would be great, as I really would like to use this in my app. From hans at guardianproject.info Tue Jan 21 16:56:23 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 21 Jan 2014 10:56:23 -0500 Subject: GPGME trouble finding gpg executable. In-Reply-To: References: Message-ID: <52DE98A7.3020104@guardianproject.info> "Invalid crypto engine" can mean a lot of things, I've found. Try turning on the debug log to get more info. You can do it with an env var, or this function: gpgme_set_global_flag("debug", "8:/path/to/gpgme.log"); .hc On 01/21/2014 10:03 AM, Chris wrote: > I posted this to the incorrect mailing list. I'm reposting here instead, > where it actually belongs. > > I have been attempting to use GPGME for a Qt app under Windows. I'm running > into issues with two applications that use the same code finding the gpg > executable. > > I set the engine info in both t-engine-info.c( exists in gpgme test > directory ) and main.cpp ( exists in my Qt app directory ) applications using: > > gpgme_set_engine_info(GPGME_PROTOCOL_OpenPGP,"c:\\gnupg\\gpg.exe", > "c:\\Users\\Chris\\AppData\\Roaming\\gnupg\\"); > gpgme_check_version (NULL); > err = gpgme_get_engine_info (&info); > printf(" version = %s \n", info->version ); > fail_if_err (err); > > The test app "t-engine-info" prints out " version = 1.4.9 ". > My Qt app prints out " version = (null) ", > > The qt application throws a "GPGME: Invalid crypto engine" error on: > err = gpgme_engine_check_version (GPGME_PROTOCOL_OpenPGP); > fail_if_err (err); > > but the t-engine-info application does not. > > Why cannot it not find the executable in the my qt application but it can > find the executable in the t-engine-info application? I've ran out of all > possible ideas, and I am not sure what else I can try. > > Any tips or solutions would be great, as I really would like to use this in > my app. > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From chris.gilg at link-comm.com Tue Jan 21 18:13:04 2014 From: chris.gilg at link-comm.com (chris) Date: Tue, 21 Jan 2014 17:13:04 +0000 (UTC) Subject: GPGME trouble finding gpg executable. References: <52DE98A7.3020104@guardianproject.info> Message-ID: Hans-Christoph Steiner guardianproject.info> writes: > > > "Invalid crypto engine" can mean a lot of things, I've found. Try turning on > the debug log to get more info. You can do it with an env var, or this function: > > gpgme_set_global_flag("debug", "8:/path/to/gpgme.log"); > > .hc > > I get: GPGME 2014-01-21 10:03:11 <0x10fc> gpgme_debug: level=9 GPGME 2014-01-21 10:03:11 <0x10fc> gpgme_check_version: call: 0=00000000, req_version=(null), VERSION=1.4.3 GPGME 2014-01-21 10:03:11 <0x10fc> gpgme_check_version_internal: call: 0=00000000, req_version=(null), offset_sig_validity= 32 GPGME 2014-01-21 10:03:11 <0x10fc> gpgme_check_version: call: 0=00000000, req_version=(null), VERSION=1.4.3 GPGME 2014-01-21 10:03:11 <0x10fc> gpgme_check_version_internal: call: 0=00000000, req_version=(null), offset_sig_validity= 32 GPGME 2014-01-21 10:03:11 <0x10fc> gpgme_set_locale: enter: ctx=00000000, category=2, value=English_United States.1252 GPGME 2014-01-21 10:03:11 <0x10fc> gpgme_set_locale: leave GPGME 2014-01-21 10:03:11 <0x10fc> engine.c:170: returning error: Invalid crypto engine I took a look at engine.c:170 : result = _gpgme_compare_versions (info->version, info->req_version); UNLOCK (engine_info_lock); Line 170: return result ? 0 : trace_gpg_error (GPG_ERR_INV_ENGINE); It would appear that the _gpgme_compare_versions() is returning false. I'm guessing since info->version is NULL, it can't compare the version numbers and returns false. From hans at guardianproject.info Tue Jan 21 18:24:43 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 21 Jan 2014 12:24:43 -0500 Subject: GPGME trouble finding gpg executable. In-Reply-To: References: <52DE98A7.3020104@guardianproject.info> Message-ID: <52DEAD5B.2050408@guardianproject.info> On 01/21/2014 12:13 PM, chris wrote: > Hans-Christoph Steiner guardianproject.info> writes: > >> >> >> "Invalid crypto engine" can mean a lot of things, I've found. Try turning on >> the debug log to get more info. You can do it with an env var, or this > function: >> >> gpgme_set_global_flag("debug", "8:/path/to/gpgme.log"); >> >> .hc >> >> > > I get: > > GPGME 2014-01-21 10:03:11 <0x10fc> gpgme_debug: level=9 > GPGME 2014-01-21 10:03:11 <0x10fc> gpgme_check_version: call: 0=00000000, > req_version=(null), VERSION=1.4.3 > GPGME 2014-01-21 10:03:11 <0x10fc> gpgme_check_version_internal: call: > 0=00000000, req_version=(null), offset_sig_validity= > 32 > GPGME 2014-01-21 10:03:11 <0x10fc> gpgme_check_version: call: 0=00000000, > req_version=(null), VERSION=1.4.3 > GPGME 2014-01-21 10:03:11 <0x10fc> gpgme_check_version_internal: call: > 0=00000000, req_version=(null), offset_sig_validity= > 32 > GPGME 2014-01-21 10:03:11 <0x10fc> gpgme_set_locale: enter: ctx=00000000, > category=2, value=English_United States.1252 > GPGME 2014-01-21 10:03:11 <0x10fc> gpgme_set_locale: leave > GPGME 2014-01-21 10:03:11 <0x10fc> engine.c:170: returning error: Invalid > crypto engine > > I took a look at engine.c:170 : > > result = _gpgme_compare_versions (info->version, > info->req_version); > UNLOCK (engine_info_lock); > Line 170: return result ? 0 : trace_gpg_error (GPG_ERR_INV_ENGINE); > > It would appear that the _gpgme_compare_versions() is returning false. I'm > guessing since info->version is NULL, it can't compare the version numbers > and returns false. If version is NULL, that probably means that the gpg command is not found, or is crashing or something like that. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From chris.gilg at link-comm.com Tue Jan 21 19:20:03 2014 From: chris.gilg at link-comm.com (chris) Date: Tue, 21 Jan 2014 18:20:03 +0000 (UTC) Subject: GPGME trouble finding gpg executable. References: <52DE98A7.3020104@guardianproject.info> <52DEAD5B.2050408@guardianproject.info> Message-ID: Hans-Christoph Steiner guardianproject.info> writes: > > If version is NULL, that probably means that the gpg command is not found, or > is crashing or something like that. > > .hc > That's the conclusion I came to. I know the gpg command is found because the other application uses it, and they are set to both look at the same location. Why the qt application has troubles using it is beyond me. From hans at guardianproject.info Tue Jan 21 19:23:53 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 21 Jan 2014 13:23:53 -0500 Subject: GPGME trouble finding gpg executable. In-Reply-To: References: <52DE98A7.3020104@guardianproject.info> <52DEAD5B.2050408@guardianproject.info> Message-ID: <52DEBB39.3010908@guardianproject.info> On 01/21/2014 01:20 PM, chris wrote: > Hans-Christoph Steiner guardianproject.info> writes: > >> >> If version is NULL, that probably means that the gpg command is not found, or >> is crashing or something like that. >> >> .hc >> > > That's the conclusion I came to. I know the gpg command is found because the > other application uses it, and they are set to both look at the same > location. Why the qt application has troubles using it is beyond me. In Android, LD_LIBRARY_PATH had to be set for gpg to find the libraries it needed. Try thinking about all the various possibilities that might make the command fail. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From chris.gilg at link-comm.com Wed Jan 22 04:00:42 2014 From: chris.gilg at link-comm.com (chris) Date: Wed, 22 Jan 2014 03:00:42 +0000 (UTC) Subject: GPGME trouble finding gpg executable. References: <52DE98A7.3020104@guardianproject.info> <52DEAD5B.2050408@guardianproject.info> <52DEBB39.3010908@guardianproject.info> Message-ID: Hans-Christoph Steiner guardianproject.info> writes: > > > On 01/21/2014 01:20 PM, chris wrote: > > Hans-Christoph Steiner guardianproject.info> writes: > > > >> > >> If version is NULL, that probably means that the gpg command is not found, or > >> is crashing or something like that. > >> > >> .hc > >> > > > > That's the conclusion I came to. I know the gpg command is found because the > > other application uses it, and they are set to both look at the same > > location. Why the qt application has troubles using it is beyond me. > > In Android, LD_LIBRARY_PATH had to be set for gpg to find the libraries it > needed. Try thinking about all the various possibilities that might make the > command fail. > > .hc > I've tried various things in an attempt to get this working. Unfortunately, I still can't get it to work under my qt application. Thanks for all the suggestions. It sure seems difficult to setup considering the name has "easy" in it. (ha ha) From wk at gnupg.org Thu Jan 23 10:50:22 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 23 Jan 2014 10:50:22 +0100 Subject: PKCS 12 support questions In-Reply-To: (Dmitry Eremin-Solenikov's message of "Mon, 20 Jan 2014 22:36:19 +0400") References: <87a9esyrxv.fsf@vigenere.g10code.de> Message-ID: <87ha8vf2n5.fsf@vigenere.g10code.de> On Mon, 20 Jan 2014 19:36, dbaryshkov at gmail.com said: >> Because pkcs#12 is an entirely broken design and I did this only on >> customer request for migrating existisng keys. > > By the way, what is so broken in pkcs#12 in your opinion? It looks like See Peter Gutmann's take on it: https://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html PFX - How Not to Design a Crypto Protocol/Standard This document was originally intended to be a companion to my X.509 style guide, containing various hints and tips on how best to implement PFX/PKCS #12. However after trying to read it several times over, I've come to the conclusion that if this came from anyone but Microsoft, it would probably be regarded as some kind of deliberate sabotage attempt on crypto PDU design. After a week or so of not being able to bring myself to touch it I'd think "It can't be that bad, it just can't be that bad", and then go back and start reading again and find that it really *was* that bad. As it turns out, because PFX is so comprehensively broken it's far easier to take the style guides "try and do this to demonstrate good style" and turn it around into PFX's "do this to demonstrate bad style". As a result, I've decided to do a rant instead of a proper discussion like the style guide. Rants are far more fun to write anyway. So, here's the PFX anti-style guide, or "How not to design a crypto protocol/standard". [...] Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dominik at heidler.eu Thu Jan 23 11:34:46 2014 From: dominik at heidler.eu (Dominik Heidler) Date: Thu, 23 Jan 2014 11:34:46 +0100 Subject: [PATCH] gpg: enable key-to-card upload for cert-only keys Message-ID: <52E0F046.309@heidler.eu> From: Dominik Heidler * g10/card-util.c (card_store_subkey): allow PUBKEY_USAGE_CERT -- GnuPG-bug-id: 1548 Signed-off-by: Dominik Heidler --- g10/card-util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/g10/card-util.c b/g10/card-util.c index add8eed..642843d 100644 --- a/g10/card-util.c +++ b/g10/card-util.c @@ -1569,7 +1569,7 @@ card_store_subkey (KBNODE node, int use) goto leave; } - allow_keyno[0] = (!use || (use & (PUBKEY_USAGE_SIG))); + allow_keyno[0] = (!use || (use & (PUBKEY_USAGE_SIG|PUBKEY_USAGE_CERT))); allow_keyno[1] = (!use || (use & (PUBKEY_USAGE_ENC))); allow_keyno[2] = (!use || (use & (PUBKEY_USAGE_SIG|PUBKEY_USAGE_AUTH))); -- 1.8.4.2 From nicholas.cole at gmail.com Fri Jan 24 10:13:42 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 24 Jan 2014 09:13:42 +0000 Subject: signature DETAILS Message-ID: Dear Werner, The DETAILS file is not currently very clear on the correct way to parse signatures. "GOODSIG, BADSIG or ERRSIG will be emitted and they may be used as a marker for a new signature." NEWSIG is not guaranteed to be issued at all (in fact, it doesn't seem to be issued if only one signature is present), and as a matter of fact, version 1.4 and version 2 frequently issue SIG_ID *before* issuing GOODSIG, BADSIG, ERRSIG or REVSIG line. Since the proper processing of these lines is really important, perhaps DETAILS should be made clearer. What is the proper way to detect a marker for a new signature? Best wishes, N. From pete at petertodd.org Fri Jan 24 09:41:29 2014 From: pete at petertodd.org (Peter Todd) Date: Fri, 24 Jan 2014 03:41:29 -0500 Subject: usage flags for bitcoin addresses on OpenPGP keys [was: Re: human readable key algorithm] In-Reply-To: <1390271424.1543.6.camel@cfw2.gniibe.org> References: <1389858516.16357.2.camel@cfw2.gniibe.org> <87bnzc430z.fsf@vigenere.g10code.de> <1389879021.4429.0.camel@latx1.gniibe.org> <87zjmv3k89.fsf@vigenere.g10code.de> <52D85684.7070808@fifthhorseman.net> <1390271424.1543.6.camel@cfw2.gniibe.org> Message-ID: <20140124084129.GA7755@savin> On Tue, Jan 21, 2014 at 11:30:24AM +0900, NIIBE Yutaka wrote: > On 2014-01-16 at 17:00 -0500, Daniel Kahn Gillmor wrote: > > That said, it's not an OpenPGP digital signature, so maybe the > > traditional signing flag doesn't make sense either. I certainly > > wouldn't want attaching such a key to my OpenPGP certificate to make it > > so that when i sent mail it signed my mail with my bitcoin wallet's key! > > Thank you for your suggestion. You are right (and I am a kind of > stupid to have such a strange subkey, even for my own experiment :-). FWIW the thinking in the Bitcoin community right now is that you would want to add a Bitcoin address to your OpenPGP key as a special type of UID. The reason why you want to do that is a key problem in Bitcoin is being sure that you're paying the person you think you are - not unlike the problem of being sure you're encrypting a message to the right person. Think of it as similar to how email addresses go in UID's. You could still include a Bitcoin ECC private key in your GnuPG keyring, but that's not actually all that important compared to the use-case of knowing for sure that you're paying the right address. Beyond that, we've come up with a scheme known as stealth addresses(1) that lets the payee tell the payor how to derive a fresh bitcoin addresss for every payment with ECDH so that from the stealth address itself an outside observer can't link the payments together. This privacy feature is considered to be very important. Now, pragmatic question: What's a decent way to add a new UID type for this? Seems that a User Attribute Packet is appropriate, I assume using one of the private subpackets for now. 1) http://www.mail-archive.com/bitcoin-development at lists.sourceforge.net/msg03613.html -- 'peter'[:-1]@petertodd.org 0000000000000000753b9cb3612c4ddcea1246fb314512aa195c17d109b60dfd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 685 bytes Desc: Digital signature URL: From daniele.athome at gmail.com Fri Jan 24 17:11:41 2014 From: daniele.athome at gmail.com (Daniele Ricci) Date: Fri, 24 Jan 2014 17:11:41 +0100 Subject: DCO for Daniele Ricci Message-ID: <52E290BD.5060607@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 GPGME Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GPGME project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Daniele Ricci -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREIAAYFAlLikHoACgkQBpwF+WEPgmOoYgEA1SonJeMsuyXUhjvDmaSr6vk4 OtfxUg8bXUgD+Nmsd7ABAJLvJ6wzOzH2aXTTMDvZzFrmI+xpLWXhHPjYzJ2G/Aau =4aWL -----END PGP SIGNATURE----- From alphazo at gmail.com Fri Jan 24 16:47:44 2014 From: alphazo at gmail.com (Alphazo) Date: Fri, 24 Jan 2014 16:47:44 +0100 Subject: Unable to create Curve25519 key Message-ID: Just compiled latest git version and tried to play around with ECC curves. I'm able to generated keys based upon NIST curve but not one base upon Curve 25519. I selected ECDSA and ECDH key, then Curve 25519. Got prompted for name/email/password and then could see random generator to get more entropy but the process then stopped with: gpg: writing self signature gpg: signing failed: No such file or directory gpg: make_keysig_packet failed: No such file or directory Key generation failed: No such file or directory ~ % What does that mean? Thanks Alphazo -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at guardianproject.info Fri Jan 24 18:08:57 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 24 Jan 2014 12:08:57 -0500 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52DD431C.2010301@guardianproject.info> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> Message-ID: <52E29E29.2090700@guardianproject.info> On 01/20/2014 10:39 AM, Hans-Christoph Steiner wrote: > > > On 01/19/2014 04:25 AM, Jussi Kivilinna wrote: >> On 19.01.2014 06:08, Hans-Christoph Steiner wrote: >>> >>> >>> On 01/18/2014 06:31 AM, Jussi Kivilinna wrote: >>>> On 17.01.2014 20:34, Hans-Christoph Steiner wrote: >>>>> >>>>> On GPG for Android, I've updated to the latest libgcrypt in master (or close >>>>> to it, its commit 4b7db51ad5d1bf98fd08ca3048f258059eca61a4). Now it seems >>>>> that any operation that needs a passphrase is crashing somewhere in libgcrypt. >>>>> I've tried building with auto-detection of CPU which enables Padlock, Intelt >>>>> DRNG, and NEON. I also tried with --disable-padlock-support >>>>> --disable-drng-support --disable-neon-support, and seemed to get the same thing. >>>>> >>>>> I've also tried running gpg-agent with and without --enable-ssh-support, and >>>>> same result each time. >>>>> >>>>> Here's the basic backtrace: >>>> <..snip..> >>>>> From the bug report in our tracker, you can download the complete build log, a >>>>> debug log from the Android app, a log from gpg-agent, and a log from gpgme: >>>>> >>>>> https://dev.guardianproject.info/issues/2888 >>>> >>>> Have you configured gcc flags correctly for target platform? It seems that >>>> compiler (and libgcrypt assembly) are configured to allow unaligned memory >>>> accesses, but target does not support them. >>>> >> <...snip...> >>>> -Jussi >>>> >>>> [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html >>> >>> I forget if I mentioned this before: the build flags are set by the default >>> Android build system. >>> >>> So I built the whole thing again, manually adding -mno-unaligned-access to the >>> libgcrypt build, and the tests seem to be failing in the same place. I tested >>> head of master on the armv7a emulator, which failed a lot more, and the head >>> of LIBGCRYPT-1-6-BRANCH on the Nexus 7 ARMv7 tablet, which failed in the same >>> places. Any pointers for next steps? >>> >> >> That's a bit strange. Do you have crash logs of these? >> >> -Jussi > > The crash log is here: > > https://dev.guardianproject.info/attachments/download/1130/gpg-agent-libgcrypt-mno-unaligned-access-crash-log.txt > > If you want to try running it on an Android device > or emulator, you can find a recent build here, but one what does not have > -mno-unaligned-access manually set: > > https://guardianproject.info/builds/GnuPrivacyGuard/ > > .hc Hey, Just checking in on this. This is the last blocker before we can push our big new release of Gnu Privacy Guard for Android. Unfortunately, our current funding for the GPG work ended in December. But I'm going to keep tabs on this in my spare time, and do what I can to help get to the bottom of this. I've never really worked in assembly, so there's not much I can do in terms of fixing that code. .hc >>> FYI, I'm gathering all these log files on our bug tracker: >>> https://dev.guardianproject.info/issues/2888 >>> >>> Attached are the latest test logs, including the full build log for head of >>> master running tests on the armv7a emulator. >>> >>> .hc >>> >>> >> > -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Jan 24 18:26:51 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 24 Jan 2014 12:26:51 -0500 Subject: usage flags for bitcoin addresses on OpenPGP keys [was: Re: human readable key algorithm] In-Reply-To: <20140124084129.GA7755@savin> References: <1389858516.16357.2.camel@cfw2.gniibe.org> <87bnzc430z.fsf@vigenere.g10code.de> <1389879021.4429.0.camel@latx1.gniibe.org> <87zjmv3k89.fsf@vigenere.g10code.de> <52D85684.7070808@fifthhorseman.net> <1390271424.1543.6.camel@cfw2.gniibe.org> <20140124084129.GA7755@savin> Message-ID: <52E2A25B.8060906@fifthhorseman.net> On 01/24/2014 03:41 AM, Peter Todd wrote: > FWIW the thinking in the Bitcoin community right now is that you would > want to add a Bitcoin address to your OpenPGP key as a special type of > UID. The reason why you want to do that is a key problem in Bitcoin is > being sure that you're paying the person you think you are - not unlike > the problem of being sure you're encrypting a message to the right > person. Think of it as similar to how email addresses go in UID's. but e-mail addresses are human-readable things, and are not cryptographic tokens themselves. a bitcoin address is not human-readable (modulo some very odd humans) and it is a cryptographic token. It fits the model of an OpenPGP Subkey much more closely than it fits an OpenPGP User ID. > Beyond that, we've come up with a scheme known as stealth addresses(1) > that lets the payee tell the payor how to derive a fresh bitcoin > addresss for every payment with ECDH so that from the stealth address > itself an outside observer can't link the payments together. This > privacy feature is considered to be very important. This is probably off-topic for this list, but i'd be curious to see the proposal for this scheme. If the payments are done to new purses, but the new purses are controlled by the same party, when they are grouped together for payment in the future the shared ownership becomes apparent. There has been quite a bit of discussion about how to de-anonymize bitcoin traffic, and i'm not sure that the proposal you've sketched combats the techniques that are already commonly being used in academic research. For example: http://eprint.iacr.org/2012/584.pdf > Now, pragmatic question: What's a decent way to add a new UID type for > this? Seems that a User Attribute Packet is appropriate, I assume using > one of the private subpackets for now. > > 1) http://www.mail-archive.com/bitcoin-development at lists.sourceforge.net/msg03613.html I think NIIBE Yutaka's proposal of treating it as a subkey with a usage extension is the right approach. I think it's inappropriate to use a User Attribute for this purpose. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From hans at guardianproject.info Fri Jan 24 18:55:15 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 24 Jan 2014 12:55:15 -0500 Subject: android build failure: `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory Message-ID: <52E2A903.1000609@guardianproject.info> This is from the jenkins build process, building everything from the HEAD of master. Full build log is attached. rm _mkerrcodes.h cc -I. -I. -o mkerrcodes ./mkerrcodes.c ./mkerrcodes | gawk -f ./mkerrcodes2.awk >code-from-errno.h gawk -f ./mkstrtable.awk -v textidx=2 -v nogettext=1 \ ./err-sources.h.in >err-sources-sym.h gawk -f ./mkstrtable.awk -v textidx=2 -v nogettext=1 \ ./err-codes.h.in >err-codes-sym.h gawk -f ./mkstrtable.awk -v textidx=2 -v nogettext=1 \ -v prefix=GPG_ERR_ -v namespace=errnos_ \ ./errnos.in >errnos-sym.h cc -g -O0 -I. -I. -o mkheader ./mkheader.c rm lock-obj-pub.native.h 2>/dev/null make[3]: [gpg-error.h] Error 1 (ignored) ./mkheader linux-androideabi arm-unknown-linux-androideabi ./gpg-error.h.in \ 1.13-beta16 0x010d00 >gpg-error.h ./gpg-error.h.in:289: error including `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory make[3]: *** [gpg-error.h] Error 1 make[3]: Leaving directory `/var/lib/jenkins/workspace/gnupg-for-android-git-master/external/libgpg-error/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/lib/jenkins/workspace/gnupg-for-android-git-master/external/libgpg-error' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/lib/jenkins/workspace/gnupg-for-android-git-master/external/libgpg-error' make: *** [libgpg-error/src/.libs/libgpg-error.so] Error 2 make: Leaving directory `/var/lib/jenkins/workspace/gnupg-for-android-git-master/external' -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-master-android-build-failure-log.txt.bz2 Type: application/x-bzip Size: 6260 bytes Desc: not available URL: From wk at gnupg.org Fri Jan 24 19:36:28 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Jan 2014 19:36:28 +0100 Subject: Unable to create Curve25519 key In-Reply-To: (alphazo@gmail.com's message of "Fri, 24 Jan 2014 16:47:44 +0100") References: Message-ID: <87wqhp8bwz.fsf@vigenere.g10code.de> On Fri, 24 Jan 2014 16:47, alphazo at gmail.com said: > What does that mean? That the code is not ready for use. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jan 24 22:02:37 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Jan 2014 22:02:37 +0100 Subject: android build failure: `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory In-Reply-To: <52E2A903.1000609@guardianproject.info> (Hans-Christoph Steiner's message of "Fri, 24 Jan 2014 12:55:15 -0500") References: <52E2A903.1000609@guardianproject.info> Message-ID: <87ppnh855e.fsf@vigenere.g10code.de> On Fri, 24 Jan 2014 18:55, hans at guardianproject.info said: > ./gpg-error.h.in:289: error including > `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory This is expected. From README. Cross-Compiling --------------- Libgpg-error needs to figure out some platform specific properties. These are used to build the platform specific gpg-error.h file. The detection is done during build time but can't be done when cross-compiling. Thus if you run into an error during building you need to figure out these values. You may use these commands: build="$(build-aux/config.guess)" ./configure --prefix=TARGETDIR --host=TARGET --build=$build cd src make gen-posix-lock-obj scp gen-posix-lock-obj TARGET: ssh TARGET ./gen-posix-lock-obj >tmp.h mv tmp.h "syscfg/$(awk 'NR==1 {print $2}' tmp.h)" If you are using a VPATH build adjust accordingly. If this all works for you (make sure to run the test programs on the target platform), please send the generated file to the gnupg-devel mailing list so that we can include it in the next release. The file would be very welcome. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Fri Jan 24 23:03:19 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 24 Jan 2014 17:03:19 -0500 Subject: android build failure: `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory In-Reply-To: <87ppnh855e.fsf@vigenere.g10code.de> References: <52E2A903.1000609@guardianproject.info> <87ppnh855e.fsf@vigenere.g10code.de> Message-ID: <52E2E327.9070205@guardianproject.info> On 01/24/2014 04:02 PM, Werner Koch wrote: > On Fri, 24 Jan 2014 18:55, hans at guardianproject.info said: > >> ./gpg-error.h.in:289: error including >> `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory > > This is expected. From README. > > Cross-Compiling > --------------- > > Libgpg-error needs to figure out some platform specific properties. > These are used to build the platform specific gpg-error.h file. The > detection is done during build time but can't be done when > cross-compiling. Thus if you run into an error during building you > need to figure out these values. You may use these commands: > > build="$(build-aux/config.guess)" > ./configure --prefix=TARGETDIR --host=TARGET --build=$build > cd src > make gen-posix-lock-obj > scp gen-posix-lock-obj TARGET: > ssh TARGET ./gen-posix-lock-obj >tmp.h > mv tmp.h "syscfg/$(awk 'NR==1 {print $2}' tmp.h)" > > If you are using a VPATH build adjust accordingly. If this all works > for you (make sure to run the test programs on the target platform), > please send the generated file to the gnupg-devel mailing list so that > we can include it in the next release. > > The file would be very welcome. > > > Salam-Shalom, > > Werner Is this something new? libgpg-error has been building fine for Android for a long while now. Its only head of master that has this issue. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From hans at guardianproject.info Fri Jan 24 23:11:40 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 24 Jan 2014 17:11:40 -0500 Subject: android build failure: `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory In-Reply-To: <87ppnh855e.fsf@vigenere.g10code.de> References: <52E2A903.1000609@guardianproject.info> <87ppnh855e.fsf@vigenere.g10code.de> Message-ID: <52E2E51C.1090200@guardianproject.info> On 01/24/2014 04:02 PM, Werner Koch wrote: > On Fri, 24 Jan 2014 18:55, hans at guardianproject.info said: > >> ./gpg-error.h.in:289: error including >> `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory > > This is expected. From README. > > Cross-Compiling > --------------- > > Libgpg-error needs to figure out some platform specific properties. > These are used to build the platform specific gpg-error.h file. The > detection is done during build time but can't be done when > cross-compiling. Thus if you run into an error during building you > need to figure out these values. You may use these commands: > > build="$(build-aux/config.guess)" > ./configure --prefix=TARGETDIR --host=TARGET --build=$build > cd src > make gen-posix-lock-obj > scp gen-posix-lock-obj TARGET: > ssh TARGET ./gen-posix-lock-obj >tmp.h > mv tmp.h "syscfg/$(awk 'NR==1 {print $2}' tmp.h)" > > If you are using a VPATH build adjust accordingly. If this all works > for you (make sure to run the test programs on the target platform), > please send the generated file to the gnupg-devel mailing list so that > we can include it in the next release. > > The file would be very welcome. I ran that procedure, but it produced a different file name than the error at the beginning of this thread. The file is attached. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: lock-obj.arm-unknown-linux-androideabi.h Type: text/x-chdr Size: 392 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From jussi.kivilinna at iki.fi Sat Jan 25 11:16:59 2014 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Sat, 25 Jan 2014 12:16:59 +0200 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52DD431C.2010301@guardianproject.info> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> Message-ID: <52E38F1B.809@iki.fi> On 20.01.2014 17:39, Hans-Christoph Steiner wrote: > > > On 01/19/2014 04:25 AM, Jussi Kivilinna wrote: >> On 19.01.2014 06:08, Hans-Christoph Steiner wrote: >>> >>> >>> On 01/18/2014 06:31 AM, Jussi Kivilinna wrote: >>>> On 17.01.2014 20:34, Hans-Christoph Steiner wrote: >>>>> >>>>> On GPG for Android, I've updated to the latest libgcrypt in master (or close >>>>> to it, its commit 4b7db51ad5d1bf98fd08ca3048f258059eca61a4). Now it seems >>>>> that any operation that needs a passphrase is crashing somewhere in libgcrypt. >>>>> I've tried building with auto-detection of CPU which enables Padlock, Intelt >>>>> DRNG, and NEON. I also tried with --disable-padlock-support >>>>> --disable-drng-support --disable-neon-support, and seemed to get the same thing. >>>>> >>>>> I've also tried running gpg-agent with and without --enable-ssh-support, and >>>>> same result each time. >>>>> >>>>> Here's the basic backtrace: >>>> <..snip..> >>>>> From the bug report in our tracker, you can download the complete build log, a >>>>> debug log from the Android app, a log from gpg-agent, and a log from gpgme: >>>>> >>>>> https://dev.guardianproject.info/issues/2888 >>>> >>>> Have you configured gcc flags correctly for target platform? It seems that >>>> compiler (and libgcrypt assembly) are configured to allow unaligned memory >>>> accesses, but target does not support them. >>>> >> <...snip...> >>>> -Jussi >>>> >>>> [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html >>> >>> I forget if I mentioned this before: the build flags are set by the default >>> Android build system. >>> >>> So I built the whole thing again, manually adding -mno-unaligned-access to the >>> libgcrypt build, and the tests seem to be failing in the same place. I tested >>> head of master on the armv7a emulator, which failed a lot more, and the head >>> of LIBGCRYPT-1-6-BRANCH on the Nexus 7 ARMv7 tablet, which failed in the same >>> places. Any pointers for next steps? >>> >> >> That's a bit strange. Do you have crash logs of these? >> >> -Jussi > > The crash log is here: > > https://dev.guardianproject.info/attachments/download/1130/gpg-agent-libgcrypt-mno-unaligned-access-crash-log.txt > > If you want to try running it on an Android device > or emulator, you can find a recent build here, but one what does not have > -mno-unaligned-access manually set: > > https://guardianproject.info/builds/GnuPrivacyGuard/ I disassembled the crash area ("code around pc:" section from crash-log) and it looks the same as without '-mno-unaligned-access': 0: e1866469 orr r6, r6, r9, ror #8 4: e8900f00 ldm r0, {r8, r9, sl, fp} 8: e0244008 eor r4, r4, r8 c: e0255009 eor r5, r5, r9 10: e026600a eor r6, r6, sl 14: e027700b eor r7, r7, fp 18: eafffded b 0xfffff7d4 1c: e92d5ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr} <<<< _gcry_aes_arm_decrypt_block 20: e89200f0 ldm r2, {r4, r5, r6, r7} <<<< crashing instruction (load four 32-bit input words) 24: e24dd010 sub sp, sp, #16 28: e59fe864 ldr lr, [pc, #2148] ; 0x894 2c: e3a0c0ff mov ip, #255 ; 0xff 30: e58d1004 str r1, [sp, #4] 34: e1a0c18c lsl ip, ip, #3 38: e353000c cmp r3, #12 3c: aa000215 bge 0x898 ... When I compile with CFLAGS="-O2 -mno-unaligned-access" for ARM, the assembly function ends up looking like this: 000011a8 <_gcry_aes_arm_decrypt_block>: 11a8: e92d5ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr} 11ac: e3120003 tst r2, #3 <<< Check if input is unaligned 11b0: 0a00001c beq 1228 <_gcry_aes_arm_decrypt_block+0x80> <<< Jump to aligned load 11b4: e5d24000 ldrb r4, [r2] <<< Input is not 32-bit aligned, so start unaligned load 11b8: e5d28001 ldrb r8, [r2, #1] 11bc: e1844408 orr r4, r4, r8, lsl #8 11c0: e5d28002 ldrb r8, [r2, #2] 11c4: e1844808 orr r4, r4, r8, lsl #16 11c8: e5d28003 ldrb r8, [r2, #3] 11cc: e1844c08 orr r4, r4, r8, lsl #24 11d0: e5d25004 ldrb r5, [r2, #4] 11d4: e5d29005 ldrb r9, [r2, #5] 11d8: e1855409 orr r5, r5, r9, lsl #8 11dc: e5d29006 ldrb r9, [r2, #6] 11e0: e1855809 orr r5, r5, r9, lsl #16 11e4: e5d29007 ldrb r9, [r2, #7] 11e8: e1855c09 orr r5, r5, r9, lsl #24 11ec: e5d26008 ldrb r6, [r2, #8] 11f0: e5d28009 ldrb r8, [r2, #9] 11f4: e1866408 orr r6, r6, r8, lsl #8 11f8: e5d2800a ldrb r8, [r2, #10] 11fc: e1866808 orr r6, r6, r8, lsl #16 1200: e5d2800b ldrb r8, [r2, #11] 1204: e1866c08 orr r6, r6, r8, lsl #24 1208: e5d2700c ldrb r7, [r2, #12] 120c: e5d2900d ldrb r9, [r2, #13] 1210: e1877409 orr r7, r7, r9, lsl #8 1214: e5d2900e ldrb r9, [r2, #14] 1218: e1877809 orr r7, r7, r9, lsl #16 121c: e5d2900f ldrb r9, [r2, #15] 1220: e1877c09 orr r7, r7, r9, lsl #24 <<< End unaligned load 1224: ea000000 b 122c <_gcry_aes_arm_decrypt_block+0x84> <<< Jump over aligned load 1228: e89200f0 ldm r2, {r4, r5, r6, r7} <<< Input is 32-bit aligned, so do aligned load 122c: e24dd010 sub sp, sp, #16 1230: e59fe8d8 ldr lr, [pc, #2264] ; 1b10 <_gcry_aes_arm_decrypt_block+0x968> 1234: e3a0c0ff mov ip, #255 ; 0xff 1238: e58d1004 str r1, [sp, #4] 123c: e1a0c18c lsl ip, ip, #3 1240: e353000c cmp r3, #12 1244: aa000234 bge 1b1c <_gcry_aes_arm_decrypt_block+0x974> ... Are you sure that new binaries built with '-mno-unaligned-access' are included to the Android application? -Jussi > > .hc > > > > >>> FYI, I'm gathering all these log files on our bug tracker: >>> https://dev.guardianproject.info/issues/2888 >>> >>> Attached are the latest test logs, including the full build log for head of >>> master running tests on the armv7a emulator. >>> >>> .hc >>> >>> >> > From jussi.kivilinna at iki.fi Sat Jan 25 11:18:21 2014 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Sat, 25 Jan 2014 12:18:21 +0200 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52E29E29.2090700@guardianproject.info> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E29E29.2090700@guardianproject.info> Message-ID: <52E38F6D.3090509@iki.fi> On 24.01.2014 19:08, Hans-Christoph Steiner wrote: > > > On 01/20/2014 10:39 AM, Hans-Christoph Steiner wrote: >> >> >> On 01/19/2014 04:25 AM, Jussi Kivilinna wrote: >>> On 19.01.2014 06:08, Hans-Christoph Steiner wrote: >>>> >>>> >>>> On 01/18/2014 06:31 AM, Jussi Kivilinna wrote: >>>>> On 17.01.2014 20:34, Hans-Christoph Steiner wrote: >>>>>> >>>>>> On GPG for Android, I've updated to the latest libgcrypt in master (or close >>>>>> to it, its commit 4b7db51ad5d1bf98fd08ca3048f258059eca61a4). Now it seems >>>>>> that any operation that needs a passphrase is crashing somewhere in libgcrypt. >>>>>> I've tried building with auto-detection of CPU which enables Padlock, Intelt >>>>>> DRNG, and NEON. I also tried with --disable-padlock-support >>>>>> --disable-drng-support --disable-neon-support, and seemed to get the same thing. >>>>>> >>>>>> I've also tried running gpg-agent with and without --enable-ssh-support, and >>>>>> same result each time. >>>>>> >>>>>> Here's the basic backtrace: >>>>> <..snip..> >>>>>> From the bug report in our tracker, you can download the complete build log, a >>>>>> debug log from the Android app, a log from gpg-agent, and a log from gpgme: >>>>>> >>>>>> https://dev.guardianproject.info/issues/2888 >>>>> >>>>> Have you configured gcc flags correctly for target platform? It seems that >>>>> compiler (and libgcrypt assembly) are configured to allow unaligned memory >>>>> accesses, but target does not support them. >>>>> >>> <...snip...> >>>>> -Jussi >>>>> >>>>> [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html >>>> >>>> I forget if I mentioned this before: the build flags are set by the default >>>> Android build system. >>>> >>>> So I built the whole thing again, manually adding -mno-unaligned-access to the >>>> libgcrypt build, and the tests seem to be failing in the same place. I tested >>>> head of master on the armv7a emulator, which failed a lot more, and the head >>>> of LIBGCRYPT-1-6-BRANCH on the Nexus 7 ARMv7 tablet, which failed in the same >>>> places. Any pointers for next steps? >>>> >>> >>> That's a bit strange. Do you have crash logs of these? >>> >>> -Jussi >> >> The crash log is here: >> >> https://dev.guardianproject.info/attachments/download/1130/gpg-agent-libgcrypt-mno-unaligned-access-crash-log.txt >> >> If you want to try running it on an Android device >> or emulator, you can find a recent build here, but one what does not have >> -mno-unaligned-access manually set: >> >> https://guardianproject.info/builds/GnuPrivacyGuard/ >> >> .hc > > > Hey, > > Just checking in on this. This is the last blocker before we can push our big > new release of Gnu Privacy Guard for Android. Unfortunately, our current > funding for the GPG work ended in December. But I'm going to keep tabs on this > in my spare time, and do what I can to help get to the bottom of this. Sorry for not checking the new logs and answering sooner. I did plan to do so, but didn't quite find the time until now. -Jussi > > I've never really worked in assembly, so there's not much I can do in terms of > fixing that code. > > .hc > > > > > > > > > > > > >>>> FYI, I'm gathering all these log files on our bug tracker: >>>> https://dev.guardianproject.info/issues/2888 >>>> >>>> Attached are the latest test logs, including the full build log for head of >>>> master running tests on the armv7a emulator. >>>> >>>> .hc >>>> >>>> >>> >> > From wk at gnupg.org Sat Jan 25 12:48:02 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 25 Jan 2014 12:48:02 +0100 Subject: android build failure: `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory In-Reply-To: <52E2E51C.1090200@guardianproject.info> (Hans-Christoph Steiner's message of "Fri, 24 Jan 2014 17:11:40 -0500") References: <52E2A903.1000609@guardianproject.info> <87ppnh855e.fsf@vigenere.g10code.de> <52E2E51C.1090200@guardianproject.info> Message-ID: <87eh3w8eq5.fsf@vigenere.g10code.de> On Fri, 24 Jan 2014 23:11, hans at guardianproject.info said: > I ran that procedure, but it produced a different file name than the error at > the beginning of this thread. The file is attached. Thanks. Commited. The tool first tries the full host triplet and then falls back to the os name: incfname = mk_include_name (name, repl_flag? host_triplet : NULL); fp = fopen (incfname, "r"); if (!fp && repl_flag) { /* Try again using the OS string. */ free (incfname); incfname = mk_include_name (name, host_os); fp = fopen (incfname, "r"); } Let me know if this works. I suggest to run the "tests/t-lock --verbose" on the target. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From daniele.athome at gmail.com Sat Jan 25 13:18:16 2014 From: daniele.athome at gmail.com (Daniele Ricci) Date: Sat, 25 Jan 2014 13:18:16 +0100 Subject: [PATCH] Implement more export options (clean, no-export-attributes) Message-ID: <1390652296-13815-1-git-send-email-daniele.athome@gmail.com> * src/engine-gpg.c: add_to_last_arg() is used to append more data to the last added argument, namely export-clean and no-export-attributes * src/export.c: handle the relevant export mode flags * src/gpgme.h.in: added more export mode flags * tests/run-export.c: added test cases for the new export modes and fixed some other constant names * doc/gpgme.texi: document new export mode flags Signed-off-by: Daniele Ricci --- doc/gpgme.texi | 6 ++++++ src/engine-gpg.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++--- src/export.c | 8 +++++-- src/gpgme.h.in | 2 ++ tests/run-export.c | 26 ++++++++++++++++++---- 5 files changed, 96 insertions(+), 9 deletions(-) diff --git a/doc/gpgme.texi b/doc/gpgme.texi index 3f31492..1aabbea 100644 --- a/doc/gpgme.texi +++ b/doc/gpgme.texi @@ -3547,6 +3547,12 @@ If this bit is set, the smallest possible key is exported. For OpenPGP keys it removes all signatures except for the latest self-signatures. For X.509 keys it has no effect. + at item GPGME_EXPORT_MODE_CLEAN +If this bit is set, key is exported with only usable signatures. More +specifically, it will exclude all signatures from unusable user IDs and +all unusable signatures, including signatures from keys not present on +the keyring. This is currently only allowed for OpenPGP keys. + @end table diff --git a/src/engine-gpg.c b/src/engine-gpg.c index 2f59bb9..c0e1b77 100644 --- a/src/engine-gpg.c +++ b/src/engine-gpg.c @@ -261,6 +261,46 @@ add_arg (engine_gpg_t gpg, const char *arg) static gpgme_error_t +add_to_last_arg (engine_gpg_t gpg, const char *arg) +{ + struct arg_and_data_s *a; + struct arg_and_data_s *prev; + + assert (gpg); + assert (arg); + + /* Iterate to the last argument. */ + a = prev = gpg->arglist; + while (a) + { + if (!a->next) + break; + + prev = a; + a = a->next; + } + + /* This function can be used only after the first call to add_arg. */ + if (!a) + return gpg_error (GPG_ERR_INV_VALUE); + + a = realloc (a, sizeof *a + strlen (a->arg) + strlen (arg)); + if (!a) + return gpg_error_from_syserror (); + + strcat (a->arg, arg); + + if (prev) + prev->next = a; + + *gpg->argtail = a; + gpg->argtail = &a->next; + + return 0; +} + + +static gpgme_error_t add_data (engine_gpg_t gpg, gpgme_data_t data, int dup_to, int inbound) { struct arg_and_data_s *a; @@ -973,6 +1013,7 @@ build_argv (engine_gpg_t gpg) gpg->argv = argv; gpg->fd_data_map = fd_data_map; + return 0; } @@ -1762,11 +1803,27 @@ export_common (engine_gpg_t gpg, gpgme_export_mode_t mode, gpgme_error_t err = 0; if ((mode & ~(GPGME_EXPORT_MODE_EXTERN - |GPGME_EXPORT_MODE_MINIMAL))) + |GPGME_EXPORT_MODE_MINIMAL + |GPGME_EXPORT_MODE_CLEAN + |GPGME_EXPORT_MODE_NO_ATTRIBUTES))) return gpg_error (GPG_ERR_NOT_SUPPORTED); - if ((mode & GPGME_EXPORT_MODE_MINIMAL)) - err = add_arg (gpg, "--export-options=export-minimal"); + if ((mode & GPGME_EXPORT_MODE_MINIMAL) | + (mode & GPGME_EXPORT_MODE_CLEAN) | + (mode & GPGME_EXPORT_MODE_NO_ATTRIBUTES)) + { + err = add_arg(gpg, "--export-options="); + + if (!err && (mode & GPGME_EXPORT_MODE_MINIMAL)) + err = add_to_last_arg(gpg, "export-minimal,"); + + if (!err && (mode & GPGME_EXPORT_MODE_CLEAN)) + err = add_to_last_arg(gpg, "export-clean,"); + + if (!err && (mode & GPGME_EXPORT_MODE_NO_ATTRIBUTES)) + err = add_to_last_arg(gpg, "no-export-attributes,"); + + } if (err) ; diff --git a/src/export.c b/src/export.c index 81a23b0..9151087 100644 --- a/src/export.c +++ b/src/export.c @@ -45,7 +45,9 @@ export_start (gpgme_ctx_t ctx, int synchronous, const char *pattern, gpgme_error_t err; if ((mode & ~(GPGME_EXPORT_MODE_EXTERN - |GPGME_EXPORT_MODE_MINIMAL))) + |GPGME_EXPORT_MODE_MINIMAL + |GPGME_EXPORT_MODE_CLEAN + |GPGME_EXPORT_MODE_NO_ATTRIBUTES))) return gpg_error (GPG_ERR_INV_VALUE); /* Invalid flags in MODE. */ @@ -116,7 +118,9 @@ export_ext_start (gpgme_ctx_t ctx, int synchronous, const char *pattern[], gpgme_error_t err; if ((mode & ~(GPGME_EXPORT_MODE_EXTERN - |GPGME_EXPORT_MODE_MINIMAL))) + |GPGME_EXPORT_MODE_MINIMAL + |GPGME_EXPORT_MODE_CLEAN + |GPGME_EXPORT_MODE_NO_ATTRIBUTES))) return gpg_error (GPG_ERR_INV_VALUE); /* Invalid flags in MODE. */ if ((mode & GPGME_EXPORT_MODE_EXTERN)) diff --git a/src/gpgme.h.in b/src/gpgme.h.in index 5c4de6b..551ed60 100644 --- a/src/gpgme.h.in +++ b/src/gpgme.h.in @@ -388,6 +388,8 @@ gpgme_pinentry_mode_t; /* The available export mode flags. */ #define GPGME_EXPORT_MODE_EXTERN 2 #define GPGME_EXPORT_MODE_MINIMAL 4 +#define GPGME_EXPORT_MODE_CLEAN 8 +#define GPGME_EXPORT_MODE_NO_ATTRIBUTES 16 typedef unsigned int gpgme_export_mode_t; diff --git a/tests/run-export.c b/tests/run-export.c index 4333208..b0e0771 100644 --- a/tests/run-export.c +++ b/tests/run-export.c @@ -43,6 +43,9 @@ show_usage (int ex) fputs ("usage: " PGM " [options] USERIDS\n\n" "Options:\n" " --verbose run in verbose mode\n" + " --clean remove any unusable user IDs and signatures\n" + " --minimal remove all signatures except self-signatures\n" + " --no-attributes do not include any user attribute\n" " --extern send keys to the keyserver (TAKE CARE!)\n" , stderr); exit (ex); @@ -81,7 +84,22 @@ main (int argc, char **argv) } else if (!strcmp (*argv, "--extern")) { - mode |= GPGME_KEYLIST_MODE_EXTERN; + mode |= GPGME_EXPORT_MODE_EXTERN; + argc--; argv++; + } + else if (!strcmp (*argv, "--clean")) + { + mode |= GPGME_EXPORT_MODE_CLEAN; + argc--; argv++; + } + else if (!strcmp (*argv, "--minimal")) + { + mode |= GPGME_EXPORT_MODE_MINIMAL; + argc--; argv++; + } + else if (!strcmp (*argv, "--no-attributes")) + { + mode |= GPGME_EXPORT_MODE_NO_ATTRIBUTES; argc--; argv++; } else if (!strncmp (*argv, "--", 2)) @@ -131,7 +149,7 @@ main (int argc, char **argv) } /* Now for the actual export. */ - if ((mode & GPGME_KEYLIST_MODE_EXTERN)) + if ((mode & GPGME_EXPORT_MODE_EXTERN)) printf ("sending keys to keyserver\n"); err = gpgme_data_new (&out); @@ -139,11 +157,11 @@ main (int argc, char **argv) gpgme_set_armor (ctx, 1); err = gpgme_op_export_keys (ctx, keyarray, mode, - (mode & GPGME_KEYLIST_MODE_EXTERN)? NULL:out); + (mode & GPGME_EXPORT_MODE_EXTERN)? NULL:out); fail_if_err (err); fflush (NULL); - if (!(mode & GPGME_KEYLIST_MODE_EXTERN)) + if (!(mode & GPGME_EXPORT_MODE_EXTERN)) { fputs ("Begin Result:\n", stdout); print_data (out); -- 1.8.5.2 From chris.gilg at link-comm.com Tue Jan 28 06:53:15 2014 From: chris.gilg at link-comm.com (chris) Date: Tue, 28 Jan 2014 05:53:15 +0000 (UTC) Subject: GPGME trouble finding gpg executable. References: <52DE98A7.3020104@guardianproject.info> <52DEAD5B.2050408@guardianproject.info> <52DEBB39.3010908@guardianproject.info> Message-ID: > Hans-Christoph Steiner guardianproject.info> writes: > > > > > > > On 01/21/2014 01:20 PM, chris wrote: > > > Hans-Christoph Steiner guardianproject.info> writes: > > > > > >> > > >> If version is NULL, that probably means that the gpg command is not > found, or > > >> is crashing or something like that. > > >> > > >> .hc > > >> > > > > > > That's the conclusion I came to. I know the gpg command is found because the > > > other application uses it, and they are set to both look at the same > > > location. Why the qt application has troubles using it is beyond me. > > > > In Android, LD_LIBRARY_PATH had to be set for gpg to find the libraries it > > needed. Try thinking about all the various possibilities that might make the > > command fail. > > > > .hc > > I think I figured out my problem. Apparently, it requires "gpgme-w32spawn.exe" and it looks only ( as far as I have discovered ) for it in "C:\Program Files (x86)\GNU\GnuPG\" otherwise I get "invalid crypto engine". Still can't figure why that is the case, I was hoping there was a way to set where it looks for that executable. Thought I would update this for anyone else who might have this issue. From wk at gnupg.org Tue Jan 28 08:29:49 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Jan 2014 08:29:49 +0100 Subject: GPGME trouble finding gpg executable. In-Reply-To: (chris's message of "Tue, 28 Jan 2014 05:53:15 +0000 (UTC)") References: <52DE98A7.3020104@guardianproject.info> <52DEAD5B.2050408@guardianproject.info> <52DEBB39.3010908@guardianproject.info> Message-ID: <87r47s5zte.fsf@vigenere.g10code.de> On Tue, 28 Jan 2014 06:53, chris.gilg at link-comm.com said: > I think I figured out my problem. Apparently, it requires > "gpgme-w32spawn.exe" and it looks only ( as far as I have discovered ) for > it in "C:\Program Files (x86)\GNU\GnuPG\" otherwise I get "invalid crypto GPGME expects this helper to be installed in the same directory as the gpgme DLL. IF it can't be found there it tries the default GnuPG installation directory - which is usually the above. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From chris.gilg at link-comm.com Tue Jan 28 18:09:51 2014 From: chris.gilg at link-comm.com (Chris) Date: Tue, 28 Jan 2014 17:09:51 +0000 (UTC) Subject: GPGME trouble finding gpg executable. References: <52DE98A7.3020104@guardianproject.info> <52DEAD5B.2050408@guardianproject.info> <52DEBB39.3010908@guardianproject.info> <87r47s5zte.fsf@vigenere.g10code.de> Message-ID: Werner Koch gnupg.org> writes: > GPGME expects this helper to be installed in the same directory as the > gpgme DLL. IF it can't be found there it tries the default GnuPG > installation directory - which is usually the above. > > Salam-Shalom, > > Werner OH. I can't believe I didn't try that combination. It works! Thanks. :) From hans at guardianproject.info Tue Jan 28 18:37:33 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 28 Jan 2014 12:37:33 -0500 Subject: android build failure: `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory In-Reply-To: <87eh3w8eq5.fsf@vigenere.g10code.de> References: <52E2A903.1000609@guardianproject.info> <87ppnh855e.fsf@vigenere.g10code.de> <52E2E51C.1090200@guardianproject.info> <87eh3w8eq5.fsf@vigenere.g10code.de> Message-ID: <52E7EADD.70205@guardianproject.info> On 01/25/2014 06:48 AM, Werner Koch wrote: > On Fri, 24 Jan 2014 23:11, hans at guardianproject.info said: > >> I ran that procedure, but it produced a different file name than the error at >> the beginning of this thread. The file is attached. > > Thanks. Commited. > > The tool first tries the full host triplet and then falls back to the os > name: > > incfname = mk_include_name (name, repl_flag? host_triplet : NULL); > fp = fopen (incfname, "r"); > if (!fp && repl_flag) > { > /* Try again using the OS string. */ > free (incfname); > incfname = mk_include_name (name, host_os); > fp = fopen (incfname, "r"); > } > > Let me know if this works. I suggest to run the "tests/t-lock > --verbose" on the target. Still the same compile error: cc -I. -I. -o mkerrcodes ./mkerrcodes.c ./mkerrcodes | gawk -f ./mkerrcodes2.awk >code-from-errno.h gawk -f ./mkstrtable.awk -v textidx=2 -v nogettext=1 \ ./err-sources.h.in >err-sources-sym.h gawk -f ./mkstrtable.awk -v textidx=2 -v nogettext=1 \ ./err-codes.h.in >err-codes-sym.h gawk -f ./mkstrtable.awk -v textidx=2 -v nogettext=1 \ -v prefix=GPG_ERR_ -v namespace=errnos_ \ ./errnos.in >errnos-sym.h cc -g -O0 -I. -I. -o mkheader ./mkheader.c rm lock-obj-pub.native.h 2>/dev/null make[3]: [gpg-error.h] Error 1 (ignored) ./mkheader linux-androideabi arm-unknown-linux-androideabi ./gpg-error.h.in \ 1.13-beta19 0x010d00 >gpg-error.h ./gpg-error.h.in:289: error including `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Tue Jan 28 19:25:35 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Jan 2014 19:25:35 +0100 Subject: android build failure: `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory In-Reply-To: <52E7EADD.70205@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 28 Jan 2014 12:37:33 -0500") References: <52E2A903.1000609@guardianproject.info> <87ppnh855e.fsf@vigenere.g10code.de> <52E2E51C.1090200@guardianproject.info> <87eh3w8eq5.fsf@vigenere.g10code.de> <52E7EADD.70205@guardianproject.info> Message-ID: <87a9eg3qw0.fsf@vigenere.g10code.de> On Tue, 28 Jan 2014 18:37, hans at guardianproject.info said: > make[3]: [gpg-error.h] Error 1 (ignored) > ./mkheader linux-androideabi arm-unknown-linux-androideabi ./gpg-error.h.in \ > 1.13-beta19 0x010d00 >gpg-error.h > ./gpg-error.h.in:289: error including > `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory Please apply this patch: diff --git a/src/mkheader.c b/src/mkheader.c index 43e7fd8..ae29213 100644 --- a/src/mkheader.c +++ b/src/mkheader.c @@ -165,6 +165,7 @@ mk_include_name (const char *name, const char *repl) *p++ = *s; } *p = 0; + fprintf (stderr,"note: incname is '%s'\n", incfname); return incfname; } and try again. According to your log mkheader is run correctly and thus should first try to include the new file. With the pacth we can better control that. You did re-built libgpg-error from scratch, right? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Tue Jan 28 20:09:52 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 28 Jan 2014 14:09:52 -0500 Subject: android build failure: `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory In-Reply-To: <87a9eg3qw0.fsf@vigenere.g10code.de> References: <52E2A903.1000609@guardianproject.info> <87ppnh855e.fsf@vigenere.g10code.de> <52E2E51C.1090200@guardianproject.info> <87eh3w8eq5.fsf@vigenere.g10code.de> <52E7EADD.70205@guardianproject.info> <87a9eg3qw0.fsf@vigenere.g10code.de> Message-ID: <52E80080.1020703@guardianproject.info> On 01/28/2014 01:25 PM, Werner Koch wrote: > On Tue, 28 Jan 2014 18:37, hans at guardianproject.info said: > >> make[3]: [gpg-error.h] Error 1 (ignored) >> ./mkheader linux-androideabi arm-unknown-linux-androideabi ./gpg-error.h.in \ >> 1.13-beta19 0x010d00 >gpg-error.h >> ./gpg-error.h.in:289: error including >> `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory > > Please apply this patch: > > diff --git a/src/mkheader.c b/src/mkheader.c > index 43e7fd8..ae29213 100644 > --- a/src/mkheader.c > +++ b/src/mkheader.c > @@ -165,6 +165,7 @@ mk_include_name (const char *name, const char *repl) > *p++ = *s; > } > *p = 0; > + fprintf (stderr,"note: incname is '%s'\n", incfname); > return incfname; > } > > > and try again. According to your log mkheader is run correctly and > thus should first try to include the new file. With the pacth we can > better control that. cc -g -O0 -I. -I. -o mkheader ./mkheader.c rm lock-obj-pub.native.h 2>/dev/null make[3]: [gpg-error.h] Error 1 (ignored) ./mkheader linux-androideabi arm-unknown-linux-androideabi ./gpg-error.h.in \ 1.13-beta19 0x010d00 >gpg-error.h note: incname is './err-sources.h.in' note: incname is './err-codes.h.in' note: incname is './errnos.in' note: incname is './lock-obj-pub.native.h' note: incname is './syscfg/lock-obj-pub.arm-unknown-linux-androideabi.h' note: incname is './syscfg/lock-obj-pub.linux-androideabi.h' ./gpg-error.h.in:289: error including `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory > You did re-built libgpg-error from scratch, right? This is built and tested by a fully automated jenkins build system that runs 'git clean' at the beginning of the process. For the record, these kinds of build hacks are easy to do on UNIX systems, but can be extraordinarily painful on Android, which is far from UNIX. A big part of the GPG Android porting effort was dealing with these kinds of things. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From hans at guardianproject.info Tue Jan 28 20:41:39 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 28 Jan 2014 14:41:39 -0500 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52E38F1B.809@iki.fi> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> Message-ID: <52E807F3.9000706@guardianproject.info> On 01/25/2014 05:16 AM, Jussi Kivilinna wrote: > On 20.01.2014 17:39, Hans-Christoph Steiner wrote: >> >> >> On 01/19/2014 04:25 AM, Jussi Kivilinna wrote: >>> On 19.01.2014 06:08, Hans-Christoph Steiner wrote: >>>> >>>> >>>> On 01/18/2014 06:31 AM, Jussi Kivilinna wrote: >>>>> On 17.01.2014 20:34, Hans-Christoph Steiner wrote: >>>>>> >>>>>> On GPG for Android, I've updated to the latest libgcrypt in master (or close >>>>>> to it, its commit 4b7db51ad5d1bf98fd08ca3048f258059eca61a4). Now it seems >>>>>> that any operation that needs a passphrase is crashing somewhere in libgcrypt. >>>>>> I've tried building with auto-detection of CPU which enables Padlock, Intelt >>>>>> DRNG, and NEON. I also tried with --disable-padlock-support >>>>>> --disable-drng-support --disable-neon-support, and seemed to get the same thing. >>>>>> >>>>>> I've also tried running gpg-agent with and without --enable-ssh-support, and >>>>>> same result each time. >>>>>> >>>>>> Here's the basic backtrace: >>>>> <..snip..> >>>>>> From the bug report in our tracker, you can download the complete build log, a >>>>>> debug log from the Android app, a log from gpg-agent, and a log from gpgme: >>>>>> >>>>>> https://dev.guardianproject.info/issues/2888 >>>>> >>>>> Have you configured gcc flags correctly for target platform? It seems that >>>>> compiler (and libgcrypt assembly) are configured to allow unaligned memory >>>>> accesses, but target does not support them. >>>>> >>> <...snip...> >>>>> -Jussi >>>>> >>>>> [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html >>>> >>>> I forget if I mentioned this before: the build flags are set by the default >>>> Android build system. >>>> >>>> So I built the whole thing again, manually adding -mno-unaligned-access to the >>>> libgcrypt build, and the tests seem to be failing in the same place. I tested >>>> head of master on the armv7a emulator, which failed a lot more, and the head >>>> of LIBGCRYPT-1-6-BRANCH on the Nexus 7 ARMv7 tablet, which failed in the same >>>> places. Any pointers for next steps? >>>> >>> >>> That's a bit strange. Do you have crash logs of these? >>> >>> -Jussi >> >> The crash log is here: >> >> https://dev.guardianproject.info/attachments/download/1130/gpg-agent-libgcrypt-mno-unaligned-access-crash-log.txt >> >> If you want to try running it on an Android device >> or emulator, you can find a recent build here, but one what does not have >> -mno-unaligned-access manually set: >> >> https://guardianproject.info/builds/GnuPrivacyGuard/ > > I disassembled the crash area ("code around pc:" section from crash-log) and it looks > the same as without '-mno-unaligned-access': > > 0: e1866469 orr r6, r6, r9, ror #8 > 4: e8900f00 ldm r0, {r8, r9, sl, fp} > 8: e0244008 eor r4, r4, r8 > c: e0255009 eor r5, r5, r9 > 10: e026600a eor r6, r6, sl > 14: e027700b eor r7, r7, fp > 18: eafffded b 0xfffff7d4 > 1c: e92d5ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr} <<<< _gcry_aes_arm_decrypt_block > 20: e89200f0 ldm r2, {r4, r5, r6, r7} <<<< crashing instruction (load four 32-bit input words) > 24: e24dd010 sub sp, sp, #16 > 28: e59fe864 ldr lr, [pc, #2148] ; 0x894 > 2c: e3a0c0ff mov ip, #255 ; 0xff > 30: e58d1004 str r1, [sp, #4] > 34: e1a0c18c lsl ip, ip, #3 > 38: e353000c cmp r3, #12 > 3c: aa000215 bge 0x898 > ... > > When I compile with CFLAGS="-O2 -mno-unaligned-access" for ARM, the assembly function > ends up looking like this: > > 000011a8 <_gcry_aes_arm_decrypt_block>: > 11a8: e92d5ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr} > 11ac: e3120003 tst r2, #3 <<< Check if input is unaligned > 11b0: 0a00001c beq 1228 <_gcry_aes_arm_decrypt_block+0x80> <<< Jump to aligned load > 11b4: e5d24000 ldrb r4, [r2] <<< Input is not 32-bit aligned, so start unaligned load > 11b8: e5d28001 ldrb r8, [r2, #1] > 11bc: e1844408 orr r4, r4, r8, lsl #8 > 11c0: e5d28002 ldrb r8, [r2, #2] > 11c4: e1844808 orr r4, r4, r8, lsl #16 > 11c8: e5d28003 ldrb r8, [r2, #3] > 11cc: e1844c08 orr r4, r4, r8, lsl #24 > 11d0: e5d25004 ldrb r5, [r2, #4] > 11d4: e5d29005 ldrb r9, [r2, #5] > 11d8: e1855409 orr r5, r5, r9, lsl #8 > 11dc: e5d29006 ldrb r9, [r2, #6] > 11e0: e1855809 orr r5, r5, r9, lsl #16 > 11e4: e5d29007 ldrb r9, [r2, #7] > 11e8: e1855c09 orr r5, r5, r9, lsl #24 > 11ec: e5d26008 ldrb r6, [r2, #8] > 11f0: e5d28009 ldrb r8, [r2, #9] > 11f4: e1866408 orr r6, r6, r8, lsl #8 > 11f8: e5d2800a ldrb r8, [r2, #10] > 11fc: e1866808 orr r6, r6, r8, lsl #16 > 1200: e5d2800b ldrb r8, [r2, #11] > 1204: e1866c08 orr r6, r6, r8, lsl #24 > 1208: e5d2700c ldrb r7, [r2, #12] > 120c: e5d2900d ldrb r9, [r2, #13] > 1210: e1877409 orr r7, r7, r9, lsl #8 > 1214: e5d2900e ldrb r9, [r2, #14] > 1218: e1877809 orr r7, r7, r9, lsl #16 > 121c: e5d2900f ldrb r9, [r2, #15] > 1220: e1877c09 orr r7, r7, r9, lsl #24 <<< End unaligned load > 1224: ea000000 b 122c <_gcry_aes_arm_decrypt_block+0x84> <<< Jump over aligned load > 1228: e89200f0 ldm r2, {r4, r5, r6, r7} <<< Input is 32-bit aligned, so do aligned load > 122c: e24dd010 sub sp, sp, #16 > 1230: e59fe8d8 ldr lr, [pc, #2264] ; 1b10 <_gcry_aes_arm_decrypt_block+0x968> > 1234: e3a0c0ff mov ip, #255 ; 0xff > 1238: e58d1004 str r1, [sp, #4] > 123c: e1a0c18c lsl ip, ip, #3 > 1240: e353000c cmp r3, #12 > 1244: aa000234 bge 1b1c <_gcry_aes_arm_decrypt_block+0x974> > ... > > Are you sure that new binaries built with '-mno-unaligned-access' are included to > the Android application? For the tests that happen in the emulator, the whole build/test process is automated. The .so files are automatically installed by the normal Android process, which will overwrite the previous ones. And just to be sure, the process tries to uninstall first, which fails since the emulator is run in a way that it doesn't save its state. Just to be sure, I wiped out all the files, and had it start from scratch including the 'git clone' of all the repos. As for the tests on a tablet, I took the same APK as was used on the emulator and installed it onto a Nexus 7. The result was the same. I don't know if you saw this, but the current builds have these ./configure flags in them: --disable-padlock-support --disable-drng-support --disable-neon-support. The crashes in libgcrypt also happen without those ./configure flags. A simpler, more direct test harness would help here, but the cross-compiling part makes it difficult. Anyone have any ideas of how to make GNU autotools 'make check' setup handle running the tests in the emulator? Also, it is easy to set up the Android tools and emulator on a Debian or Ubuntu system, I'm happy to help you get that going via email, IRC, XMPP, etc. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Tue Jan 28 21:13:43 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Jan 2014 21:13:43 +0100 Subject: android build failure: `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory In-Reply-To: <52E80080.1020703@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 28 Jan 2014 14:09:52 -0500") References: <52E2A903.1000609@guardianproject.info> <87ppnh855e.fsf@vigenere.g10code.de> <52E2E51C.1090200@guardianproject.info> <87eh3w8eq5.fsf@vigenere.g10code.de> <52E7EADD.70205@guardianproject.info> <87a9eg3qw0.fsf@vigenere.g10code.de> <52E80080.1020703@guardianproject.info> Message-ID: <8761p350g8.fsf@vigenere.g10code.de> On Tue, 28 Jan 2014 20:09, hans at guardianproject.info said: > note: incname is './errnos.in' This included a file - oviously successful. > note: incname is './lock-obj-pub.native.h' This is: if (try_include_file (fname, lnr, "./lock-obj-pub.native.h", write_line)) include_file (fname, lnr, "syscfg/lock-obj-pub.&.h", write_line); The condition failed and thus mkheader tries to include > note: incname is './syscfg/lock-obj-pub.arm-unknown-linux-androideabi.h' this one [1] (& is substituted). It failed and thus the '&' forces mkheader to try > note: incname is './syscfg/lock-obj-pub.linux-androideabi.h' this one instead. Which also does not exist and thus: > ./gpg-error.h.in:289: error including > `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory So far so bad. But why didn't it found [1] ? Can you please double check that the file is available and readable. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Tue Jan 28 23:00:30 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 28 Jan 2014 17:00:30 -0500 Subject: android build failure: `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory In-Reply-To: <8761p350g8.fsf@vigenere.g10code.de> References: <52E2A903.1000609@guardianproject.info> <87ppnh855e.fsf@vigenere.g10code.de> <52E2E51C.1090200@guardianproject.info> <87eh3w8eq5.fsf@vigenere.g10code.de> <52E7EADD.70205@guardianproject.info> <87a9eg3qw0.fsf@vigenere.g10code.de> <52E80080.1020703@guardianproject.info> <8761p350g8.fsf@vigenere.g10code.de> Message-ID: <52E8287E.7030403@guardianproject.info> On 01/28/2014 03:13 PM, Werner Koch wrote: > On Tue, 28 Jan 2014 20:09, hans at guardianproject.info said: > >> note: incname is './errnos.in' > > This included a file - oviously successful. > >> note: incname is './lock-obj-pub.native.h' > > This is: > > if (try_include_file (fname, lnr, "./lock-obj-pub.native.h", write_line)) > include_file (fname, lnr, "syscfg/lock-obj-pub.&.h", write_line); > > The condition failed and thus mkheader tries to include > >> note: incname is './syscfg/lock-obj-pub.arm-unknown-linux-androideabi.h' > > this one [1] (& is substituted). It failed and thus the '&' forces > mkheader to try > >> note: incname is './syscfg/lock-obj-pub.linux-androideabi.h' > > this one instead. Which also does not exist and thus: > >> ./gpg-error.h.in:289: error including >> `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory > > So far so bad. But why didn't it found [1] ? Can you please double > check that the file is available and readable. $ ls -l external/libgpg-error/src/syscfg/ total 8 -rw-rw-r-- 1 hans hans 392 Jan 28 14:07 lock-obj.arm-unknown-linux-androideabi.h -rw-rw-r-- 1 hans hans 1457 Jan 28 14:07 lock-obj-pub.mingw32.h Is src/syscfg/lock-obj.arm-unknown-linux-androideabi.h misnamed? Should it be lock-obj-pub.arm-unknown-linux-androideabi.h ? .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Tue Jan 28 23:46:18 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Jan 2014 23:46:18 +0100 Subject: android build failure: `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory In-Reply-To: <52E8287E.7030403@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 28 Jan 2014 17:00:30 -0500") References: <52E2A903.1000609@guardianproject.info> <87ppnh855e.fsf@vigenere.g10code.de> <52E2E51C.1090200@guardianproject.info> <87eh3w8eq5.fsf@vigenere.g10code.de> <52E7EADD.70205@guardianproject.info> <87a9eg3qw0.fsf@vigenere.g10code.de> <52E80080.1020703@guardianproject.info> <8761p350g8.fsf@vigenere.g10code.de> <52E8287E.7030403@guardianproject.info> Message-ID: <87wqhj3eth.fsf@vigenere.g10code.de> On Tue, 28 Jan 2014 23:00, hans at guardianproject.info said: > Is src/syscfg/lock-obj.arm-unknown-linux-androideabi.h misnamed? Should it be > lock-obj-pub.arm-unknown-linux-androideabi.h ? Yeah. I just fixed that comment in the generated output. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jan 28 23:48:42 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Jan 2014 23:48:42 +0100 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52E807F3.9000706@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 28 Jan 2014 14:41:39 -0500") References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> Message-ID: <87sis73eph.fsf@vigenere.g10code.de> On Tue, 28 Jan 2014 20:41, hans at guardianproject.info said: > I don't know if you saw this, but the current builds have these ./configure > flags in them: > --disable-padlock-support --disable-drng-support --disable-neon-support. The FWIW: --disable-neon-support was not working until I fixed that in master this afternoon. > A simpler, more direct test harness would help here, but the cross-compiling > part makes it difficult. Anyone have any ideas of how to make GNU autotools > 'make check' setup handle running the tests in the emulator? libtool needs to take of this. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Wed Jan 29 01:34:00 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 28 Jan 2014 19:34:00 -0500 Subject: android build failure: `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory In-Reply-To: <87wqhj3eth.fsf@vigenere.g10code.de> References: <52E2A903.1000609@guardianproject.info> <87ppnh855e.fsf@vigenere.g10code.de> <52E2E51C.1090200@guardianproject.info> <87eh3w8eq5.fsf@vigenere.g10code.de> <52E7EADD.70205@guardianproject.info> <87a9eg3qw0.fsf@vigenere.g10code.de> <52E80080.1020703@guardianproject.info> <8761p350g8.fsf@vigenere.g10code.de> <52E8287E.7030403@guardianproject.info> <87wqhj3eth.fsf@vigenere.g10code.de> Message-ID: <52E84C78.1040202@guardianproject.info> On 01/28/2014 05:46 PM, Werner Koch wrote: > On Tue, 28 Jan 2014 23:00, hans at guardianproject.info said: > >> Is src/syscfg/lock-obj.arm-unknown-linux-androideabi.h misnamed? Should it be >> lock-obj-pub.arm-unknown-linux-androideabi.h ? > > Yeah. I just fixed that comment in the generated output. > > > Salam-Shalom, > > Werner The file that I sent you also needs to be corrected, right? Its in git as: src/syscfg/lock-obj.arm-unknown-linux-androideabi.h .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Wed Jan 29 08:43:17 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jan 2014 08:43:17 +0100 Subject: android build failure: `./syscfg/lock-obj-pub.linux-androideabi.h': No such file or directory In-Reply-To: <52E84C78.1040202@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 28 Jan 2014 19:34:00 -0500") References: <52E2A903.1000609@guardianproject.info> <87ppnh855e.fsf@vigenere.g10code.de> <52E2E51C.1090200@guardianproject.info> <87eh3w8eq5.fsf@vigenere.g10code.de> <52E7EADD.70205@guardianproject.info> <87a9eg3qw0.fsf@vigenere.g10code.de> <52E80080.1020703@guardianproject.info> <8761p350g8.fsf@vigenere.g10code.de> <52E8287E.7030403@guardianproject.info> <87wqhj3eth.fsf@vigenere.g10code.de> <52E84C78.1040202@guardianproject.info> Message-ID: <87eh3r2pyi.fsf@vigenere.g10code.de> On Wed, 29 Jan 2014 01:34, hans at guardianproject.info said: > The file that I sent you also needs to be corrected, right? Its in git as: Ooops. Done. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jan 29 14:49:12 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jan 2014 14:49:12 +0100 Subject: [Announce] Libgcrypt 1.6.1 released Message-ID: <87iot2290n.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.6.1. This is a maintenance release to fix problems found in the recently released 1.6.0 version. Libgcrypt is a general purpose library of cryptographic building blocks. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required for proper use Libgcrypt. Noteworthy changes in version 1.6.1 (2014-01-29) ================================================ * Added emulation for broken Whirlpool code prior to 1.6.0. * Improved performance of KDF functions. * Improved ECDSA compliance. * Fixed locking for Windows and non-ELF Pthread systems (regression in 1.6.0) * Fixed message digest lookup by OID (regression in 1.6.0). * Fixed a build problem on NetBSD. * Fixed memory leaks in ECC code. * Fixed some asm build problems and feature detection bugs. * Interface changes relative to the 1.6.0 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GCRY_MD_FLAG_BUGEMU1 NEW (minor API change). Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source tarball and its digital signature are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.1.tar.bz2 (2413k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.1.tar.bz2.sig That file is bzip2 compressed. A gzip compressed version is here: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.1.tar.gz (2872k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.1.tar.gz.sig Alternativley you may upgrade using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.0-1.6.1.diff.bz2 (244k) In order to check that the version of Libgcrypt you are going to build is an original and unmodified one, you can do it in one of the following ways: * Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.6.1.tar.bz2 you would use this command: gpg --verify libgcrypt-1.6.1.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by the release signing key 4F25E3B6 which is certified by my well known key 1E42B367. To retrieve the keys you may use the command "gpg --fetch-key finger:wk at g10code.com". * If you are not able to use GnuPG, you have to verify the SHA-1 checksum: sha1sum libgcrypt-1.6.1.tar.bz2 and check that the output matches the first line from the following list: f03d9b63ac3b17a6972fc11150d136925b702f02 libgcrypt-1.6.1.tar.bz2 fe6d442881a28a37d16348cdbf96b41b8ef38ced libgcrypt-1.6.1.tar.gz 35d002247186884ba3730c91f196a5de48c3fcf8 libgcrypt-1.6.0-1.6.1.diff.bz2 Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. The driving force behind the development of Libgcrypt is my company g10 Code. Maintenance and improvement of Libgcrypt and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Thanks ====== Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] http://lists.gnupg.org/mailman/listinfo/gcrypt-devel [2] http://www.gnupg.org/service.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 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 hans at guardianproject.info Wed Jan 29 16:58:27 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 29 Jan 2014 10:58:27 -0500 Subject: libgcrypt fails to build on Android: error: unknown type name 'pthread_t' Message-ID: <52E92523.10709@guardianproject.info> It looks like there were some recent changes to the pthread detection which break building the libgcrypt tests on Android: /opt/android-ndk/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc --sysroot=/opt/android-ndk/platforms/android-9/arch-arm -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/var/lib/jenkins/workspace/gnupg-for-android-git-master/external/data/data/info.guardianproject.gpg/app_opt/include -DANDROID -I/var/lib/jenkins/workspace/gnupg-for-android-git-master/external/data/data/info.guardianproject.gpg/app_opt/include -fpic -ffunction-sections -funwind-tables -fstack-protector -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -O2 -g -DNDEBUG -fomit-frame-pointer -fstrict-aliasing -funswitch-loops -finline-limit=300 -fvisibility=hidden -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wextra -Wbad-function-cast -Wwrite-strings -Wdeclaration-after-statement -Wno-missing-field-initializers -Wno-sign-compare -Wpointer-arith -MT t_lock-t-lock.o -MD -MP -MF .deps/t_lock-t-lock.Tpo -c -o t_lock-t-lock.o `test -f 't-lock.c' || echo './'`t-lock.c t-lock.c: In function 'check_nonce_lock': t-lock.c:169:24: warning: unused variable 'arg' [-Wunused-variable] struct thread_arg_s *arg; ^ t-lock.c: In function 'run_test': t-lock.c:364:3: error: unknown type name 'pthread_t' pthread_t rthread; ^ t-lock.c:365:3: error: unknown type name 'pthread_t' pthread_t athreads[N_ACCOUNTANTS]; ^ t-lock.c:370:3: warning: implicit declaration of function 'pthread_create' [-Wimplicit-function-declaration] pthread_create (&rthread, NULL, revision_thread, NULL); ^ t-lock.c:377:7: warning: implicit declaration of function 'pthread_join' [-Wimplicit-function-declaration] rc = pthread_join (athreads[i], NULL); ^ t-lock.c: In function 'main': t-lock.c:434:3: warning: implicit declaration of function 'time' [-Wimplicit-function-declaration] srand (time(NULL)*getpid()); ^ t-lock.c: At top level: t-lock.c:145:1: warning: 'nonce_thread' defined but not used [-Wunused-function] nonce_thread (void *argarg) ^ make[3]: *** [t_lock-t-lock.o] Error 1 make[3]: Leaving directory `/var/lib/jenkins/workspace/gnupg-for-android-git-master/external/libgcrypt/tests' -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From hans at guardianproject.info Wed Jan 29 17:15:08 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 29 Jan 2014 11:15:08 -0500 Subject: libgcrypt fails to build on Android: error: unknown type name 'pthread_t' In-Reply-To: <52E92523.10709@guardianproject.info> References: <52E92523.10709@guardianproject.info> Message-ID: <52E9290C.1030108@guardianproject.info> I forgot to add, this builds fine in the libgcrypt 1.6 branch. .hc On 01/29/2014 10:58 AM, Hans-Christoph Steiner wrote: > > It looks like there were some recent changes to the pthread detection which > break building the libgcrypt tests on Android: > > > /opt/android-ndk/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc > --sysroot=/opt/android-ndk/platforms/android-9/arch-arm -DHAVE_CONFIG_H -I. > -I.. -I../src -I../src > -I/var/lib/jenkins/workspace/gnupg-for-android-git-master/external/data/data/info.guardianproject.gpg/app_opt/include > -DANDROID > -I/var/lib/jenkins/workspace/gnupg-for-android-git-master/external/data/data/info.guardianproject.gpg/app_opt/include > -fpic -ffunction-sections -funwind-tables -fstack-protector > -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -O2 > -g -DNDEBUG -fomit-frame-pointer -fstrict-aliasing -funswitch-loops > -finline-limit=300 -fvisibility=hidden -Wall -Wcast-align -Wshadow > -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wextra > -Wbad-function-cast -Wwrite-strings -Wdeclaration-after-statement > -Wno-missing-field-initializers -Wno-sign-compare -Wpointer-arith -MT > t_lock-t-lock.o -MD -MP -MF .deps/t_lock-t-lock.Tpo -c -o t_lock-t-lock.o > `test -f 't-lock.c' || echo './'`t-lock.c > t-lock.c: In function 'check_nonce_lock': > t-lock.c:169:24: warning: unused variable 'arg' [-Wunused-variable] > struct thread_arg_s *arg; > ^ > t-lock.c: In function 'run_test': > t-lock.c:364:3: error: unknown type name 'pthread_t' > pthread_t rthread; > ^ > t-lock.c:365:3: error: unknown type name 'pthread_t' > pthread_t athreads[N_ACCOUNTANTS]; > ^ > t-lock.c:370:3: warning: implicit declaration of function 'pthread_create' > [-Wimplicit-function-declaration] > pthread_create (&rthread, NULL, revision_thread, NULL); > ^ > t-lock.c:377:7: warning: implicit declaration of function 'pthread_join' > [-Wimplicit-function-declaration] > rc = pthread_join (athreads[i], NULL); > ^ > t-lock.c: In function 'main': > t-lock.c:434:3: warning: implicit declaration of function 'time' > [-Wimplicit-function-declaration] > srand (time(NULL)*getpid()); > ^ > t-lock.c: At top level: > t-lock.c:145:1: warning: 'nonce_thread' defined but not used [-Wunused-function] > nonce_thread (void *argarg) > ^ > make[3]: *** [t_lock-t-lock.o] Error 1 > make[3]: Leaving directory > `/var/lib/jenkins/workspace/gnupg-for-android-git-master/external/libgcrypt/tests' > > > -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Wed Jan 29 17:39:17 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jan 2014 17:39:17 +0100 Subject: libgcrypt fails to build on Android: error: unknown type name 'pthread_t' In-Reply-To: <52E92523.10709@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 29 Jan 2014 10:58:27 -0500") References: <52E92523.10709@guardianproject.info> Message-ID: <87d2ja2156.fsf@vigenere.g10code.de> On Wed, 29 Jan 2014 16:58, hans at guardianproject.info said: > It looks like there were some recent changes to the pthread detection which > break building the libgcrypt tests on Android: Libgcrypt master is currently in a state of continuous change ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Wed Jan 29 17:54:30 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 29 Jan 2014 11:54:30 -0500 Subject: libgcrypt fails to build on Android: error: unknown type name 'pthread_t' In-Reply-To: <87d2ja2156.fsf@vigenere.g10code.de> References: <52E92523.10709@guardianproject.info> <87d2ja2156.fsf@vigenere.g10code.de> Message-ID: <52E93246.3080709@guardianproject.info> On 01/29/2014 11:39 AM, Werner Koch wrote: > On Wed, 29 Jan 2014 16:58, hans at guardianproject.info said: >> It looks like there were some recent changes to the pthread detection which >> break building the libgcrypt tests on Android: > > Libgcrypt master is currently in a state of continuous change ;-) No complaints here, just conveying the information. I've been fine-tuning the GPGA (GPG for Android) automated jenkins builds from the master branches, and a separate job that builds from the libgcrypt 1.6.x branch. Once they prove reliable, I'm planning on turning on the emailing again, so when a build breaks, it emails the committers since the last successful build. Then you can do what you want with this info. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From adi at hexapodia.org Wed Jan 29 21:21:50 2014 From: adi at hexapodia.org (Andy Isaacson) Date: Wed, 29 Jan 2014 12:21:50 -0800 Subject: fetching the requested key from keyservers Message-ID: <20140129202149.GA19019@hexapodia.org> If the user asks for a specific fingerprint (giving the full hash to --recv-key), it would be nice if gnupg checked the returned data from the keyserver and only accepted keys matching the requested fingerprint. Currently (1.4.14 and 2.0.20) whatever the keyserver returns is added to pubring, without filtering. https://bugs.g10code.com/gnupg/issue1579 It would be really lovely to get the patch for this issue merged; while I'm not a gnupg developer, I did review the patch and it looks good to me. -andy From hans at guardianproject.info Wed Jan 29 23:59:55 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 29 Jan 2014 17:59:55 -0500 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <87sis73eph.fsf@vigenere.g10code.de> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> <87sis73eph.fsf@vigenere.g10code.de> Message-ID: <52E987EB.3000305@guardianproject.info> On 01/28/2014 05:48 PM, Werner Koch wrote: > On Tue, 28 Jan 2014 20:41, hans at guardianproject.info said: > >> I don't know if you saw this, but the current builds have these ./configure >> flags in them: >> --disable-padlock-support --disable-drng-support --disable-neon-support. The > > FWIW: --disable-neon-support was not working until I fixed that in > master this afternoon. That was very helpful! Now all the tests so far pass on the emulator. The problem is that is has gotten stuck on libgcrypt/tests/random for over an hour. Its stuck here: random: now running with options '--early-rng-check --prefer-system-rng' random: checking whether RNG type switching works in the early stage random: checking whether RNG type switching works random: now running with options '--prefer-standard-rng' random: checking whether RNG type switching works random: now running with options '--prefer-fips-rng' random: checking whether RNG type switching works The full test log is attached, the build log is here: https://dev.guardianproject.info/attachments/download/1138/gpga-build_with-working---disable-neon-support.txt.bz2 It would be great to also continue to debug the NEON support, since it'll make a huge difference on Android devices. I think this change above confirms that the process is working properly, sounds like the next step is getting Jussi setup with an Android SDK/NDK and emulator. I'm happy to help with that process, it shouldn't take longer than an hour. In my experience, it generally much easier to do on Debian/Ubuntu. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: gpga-test-log_with-working---disable-neon-support.txt.bz2 Type: application/x-bzip Size: 10345 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Jan 30 00:14:48 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 Jan 2014 00:14:48 +0100 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52E987EB.3000305@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 29 Jan 2014 17:59:55 -0500") References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> <87sis73eph.fsf@vigenere.g10code.de> <52E987EB.3000305@guardianproject.info> Message-ID: <87zjmez8gn.fsf@vigenere.g10code.de> On Wed, 29 Jan 2014 23:59, hans at guardianproject.info said: > That was very helpful! Now all the tests so far pass on the emulator. The > problem is that is has gotten stuck on libgcrypt/tests/random for over an > hour. Its stuck here: Collecting entropy is a major problem on embedded devices. For some weeks now there is a discussion about this going on at coderpunks (ie. cryptography at metzdowd.com) > random: checking whether RNG type switching works You may want to run the random test manually: ./random --verbose --progress BTW, is anyone from the guardianproject at FOSDEM? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tomanek at internet-sicherheit.de Thu Jan 30 00:44:49 2014 From: tomanek at internet-sicherheit.de (Stefan Tomanek) Date: Thu, 30 Jan 2014 00:44:49 +0100 Subject: DCO Message-ID: <20140129234449.GY30808@zirkel.wertarbyte.de> GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Stefan Tomanek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 828 bytes Desc: Digital signature URL: From tomanek at internet-sicherheit.de Thu Jan 30 00:57:31 2014 From: tomanek at internet-sicherheit.de (Stefan Tomanek) Date: Thu, 30 Jan 2014 00:57:31 +0100 Subject: [PATCH v6 (master)] filter and verify keyserver responses Message-ID: <20140129235730.GZ30808@zirkel.wertarbyte.de> * g10/main.h: typedef import_filter for filter callbacks * g10/import.c (import): add filter callbacks to param list (import_one): ditto. (import_secret_one): ditto. (import_keys_internal): ditto. (import_keys_es_stream): ditto. (import_keys_stream): ditto. * g10/keyserver.c (keyserver_retrieval_filter): add function (keyserver_get): pass filter to import_keys_es_stream() -- This changes introduces import functions that apply a constraining filter to imported keys. These filters can verify the fingerprints of the keys returned before importing them into the keyring, ensuring that the keys fetched from the keyserver are in fact those selected by the user beforehand. Signed-off-by: Stefan Tomanek --- g10/import.c | 52 +++++++++++++++++++++++++++++++++++----------------- g10/keyserver.c | 43 ++++++++++++++++++++++++++++++++++++++++--- g10/main.h | 7 +++++-- 3 files changed, 80 insertions(+), 22 deletions(-) diff --git a/g10/import.c b/g10/import.c index 3846c21..15099b5 100644 --- a/g10/import.c +++ b/g10/import.c @@ -62,15 +62,18 @@ struct stats_s { static int import (ctrl_t ctrl, IOBUF inp, const char* fname, struct stats_s *stats, - unsigned char **fpr, size_t *fpr_len, unsigned int options); + unsigned char **fpr, size_t *fpr_len, unsigned int options, + import_filter filter, void *filter_arg); static int read_block( IOBUF a, PACKET **pending_pkt, KBNODE *ret_root ); static void revocation_present (ctrl_t ctrl, kbnode_t keyblock); static int import_one (ctrl_t ctrl, const char *fname, KBNODE keyblock,struct stats_s *stats, unsigned char **fpr,size_t *fpr_len, - unsigned int options,int from_sk); + unsigned int options,int from_sk, + import_filter filter, void *filter_arg); static int import_secret_one (ctrl_t ctrl, const char *fname, KBNODE keyblock, - struct stats_s *stats, unsigned int options); + struct stats_s *stats, unsigned int options, + import_filter filter, void *filter_arg); static int import_revoke_cert( const char *fname, KBNODE node, struct stats_s *stats); static int chk_self_sigs( const char *fname, KBNODE keyblock, @@ -167,7 +170,8 @@ import_release_stats_handle (void *p) static int import_keys_internal (ctrl_t ctrl, iobuf_t inp, char **fnames, int nnames, void *stats_handle, unsigned char **fpr, size_t *fpr_len, - unsigned int options ) + unsigned int options, + import_filter filter, void *filter_arg) { int i, rc = 0; struct stats_s *stats = stats_handle; @@ -176,7 +180,7 @@ import_keys_internal (ctrl_t ctrl, iobuf_t inp, char **fnames, int nnames, stats = import_new_stats_handle (); if (inp) { - rc = import (ctrl, inp, "[stream]", stats, fpr, fpr_len, options); + rc = import (ctrl, inp, "[stream]", stats, fpr, fpr_len, options, filter, filter_arg); } else { if( !fnames && !nnames ) @@ -197,7 +201,7 @@ import_keys_internal (ctrl_t ctrl, iobuf_t inp, char **fnames, int nnames, log_error(_("can't open '%s': %s\n"), fname, strerror(errno) ); else { - rc = import (ctrl, inp2, fname, stats, fpr, fpr_len, options); + rc = import (ctrl, inp2, fname, stats, fpr, fpr_len, options, NULL, NULL); iobuf_close(inp2); /* Must invalidate that ugly cache to actually close it. */ iobuf_ioctl (NULL, IOBUF_IOCTL_INVALIDATE_CACHE, @@ -232,15 +236,18 @@ import_keys (ctrl_t ctrl, char **fnames, int nnames, void *stats_handle, unsigned int options ) { import_keys_internal (ctrl, NULL, fnames, nnames, stats_handle, - NULL, NULL, options); + NULL, NULL, options, + NULL, NULL); } int import_keys_stream (ctrl_t ctrl, IOBUF inp, void *stats_handle, - unsigned char **fpr, size_t *fpr_len,unsigned int options) + unsigned char **fpr, size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg) { return import_keys_internal (ctrl, inp, NULL, 0, stats_handle, - fpr, fpr_len, options); + fpr, fpr_len, options, + filter, filter_arg); } @@ -248,7 +255,8 @@ import_keys_stream (ctrl_t ctrl, IOBUF inp, void *stats_handle, int import_keys_es_stream (ctrl_t ctrl, estream_t fp, void *stats_handle, unsigned char **fpr, size_t *fpr_len, - unsigned int options) + unsigned int options, + import_filter filter, void *filter_arg) { int rc; iobuf_t inp; @@ -262,7 +270,8 @@ import_keys_es_stream (ctrl_t ctrl, estream_t fp, void *stats_handle, } rc = import_keys_internal (ctrl, inp, NULL, 0, stats_handle, - fpr, fpr_len, options); + fpr, fpr_len, options, + filter, filter_arg); iobuf_close (inp); return rc; @@ -271,7 +280,8 @@ import_keys_es_stream (ctrl_t ctrl, estream_t fp, void *stats_handle, static int import (ctrl_t ctrl, IOBUF inp, const char* fname,struct stats_s *stats, - unsigned char **fpr,size_t *fpr_len,unsigned int options ) + unsigned char **fpr,size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg) { PACKET *pending_pkt = NULL; KBNODE keyblock = NULL; /* Need to initialize because gcc can't @@ -293,9 +303,10 @@ import (ctrl_t ctrl, IOBUF inp, const char* fname,struct stats_s *stats, while( !(rc = read_block( inp, &pending_pkt, &keyblock) )) { if( keyblock->pkt->pkttype == PKT_PUBLIC_KEY ) rc = import_one (ctrl, fname, keyblock, - stats, fpr, fpr_len, options, 0); + stats, fpr, fpr_len, options, 0, + filter, filter_arg); else if( keyblock->pkt->pkttype == PKT_SECRET_KEY ) - rc = import_secret_one (ctrl, fname, keyblock, stats, options); + rc = import_secret_one (ctrl, fname, keyblock, stats, options, filter, filter_arg); else if( keyblock->pkt->pkttype == PKT_SIGNATURE && keyblock->pkt->pkt.signature->sig_class == 0x20 ) rc = import_revoke_cert( fname, keyblock, stats ); @@ -780,7 +791,7 @@ static int import_one (ctrl_t ctrl, const char *fname, KBNODE keyblock, struct stats_s *stats, unsigned char **fpr,size_t *fpr_len,unsigned int options, - int from_sk ) + int from_sk, import_filter filter, void *filter_arg) { PKT_public_key *pk; PKT_public_key *pk_orig; @@ -823,6 +834,12 @@ import_one (ctrl_t ctrl, return 0; } + if (filter && filter(pk, filter_arg)) + { + log_error( _("key %s: rejected by import filter\n"), keystr_from_pk(pk)); + return 0; + } + if (opt.interactive) { if(is_status_enabled()) print_import_check (pk, uidnode->pkt->pkt.user_id); @@ -1529,7 +1546,8 @@ sec_to_pub_keyblock (kbnode_t sec_keyblock) */ static int import_secret_one (ctrl_t ctrl, const char *fname, KBNODE keyblock, - struct stats_s *stats, unsigned int options) + struct stats_s *stats, unsigned int options, + import_filter filter, void *filter_arg) { PKT_public_key *pk; struct seckey_info *ski; @@ -1611,7 +1629,7 @@ import_secret_one (ctrl_t ctrl, const char *fname, KBNODE keyblock, public key block, and below we will output another one for the secret keys. FIXME? */ import_one (ctrl, fname, pub_keyblock, stats, - NULL, NULL, options, 1); + NULL, NULL, options, 1, filter, filter_arg); /* Fixme: We should check for an invalid keyblock and cancel the secret key import in this case. */ diff --git a/g10/keyserver.c b/g10/keyserver.c index 0ec616b..a2e575c 100644 --- a/g10/keyserver.c +++ b/g10/keyserver.c @@ -829,6 +829,40 @@ show_prompt (ctrl_t ctrl, KEYDB_SEARCH_DESC *desc, int numdesc, return err; } +static int +keyserver_retrieval_filter(PKT_public_key *pk, void *arg) +{ + KEYDB_SEARCH_DESC *desc = arg; + u32 keyid[2]; + byte fpr[MAX_FINGERPRINT_LEN]; + size_t fpr_len = 0; + + fingerprint_from_pk(pk, fpr, &fpr_len); + keyid_from_pk(pk, keyid); + + /* compare requested and returned fingerprints if available */ + if (desc->mode == KEYDB_SEARCH_MODE_FPR20) + { + if (fpr_len != 20 || memcmp(fpr, desc->u.fpr, 20)) + return 1; + } + else if (desc->mode == KEYDB_SEARCH_MODE_FPR16) + { + if (fpr_len != 16 || memcmp(fpr, desc->u.fpr, 16)) + return 1; + } + else if (desc->mode == KEYDB_SEARCH_MODE_LONG_KID) + { + if (memcmp(keyid, desc->u.kid, sizeof(keyid))) + return 1; + } + else if (desc->mode == KEYDB_SEARCH_MODE_SHORT_KID) + { + if (memcmp(&keyid[1], &desc->u.kid[1], 1)) + return 1; + } + return 0; +} /* This is a callback used by call-dirmngr.c to process the result of KS_SEARCH command. LINE is the actual data line received with all @@ -1581,7 +1615,8 @@ keyserver_get (ctrl_t ctrl, KEYDB_SEARCH_DESC *desc, int ndesc, a temp iobuf for each key. */ import_keys_es_stream (ctrl, datastream, stats_handle, NULL, NULL, - opt.keyserver_options.import_options); + opt.keyserver_options.import_options, + &keyserver_retrieval_filter, desc); import_print_stats (stats_handle); import_release_stats_handle (stats_handle); @@ -1672,7 +1707,8 @@ keyserver_fetch (ctrl_t ctrl, strlist_t urilist) stats_handle = import_new_stats_handle(); import_keys_es_stream (ctrl, datastream, stats_handle, NULL, NULL, - opt.keyserver_options.import_options); + opt.keyserver_options.import_options, + NULL, NULL); import_print_stats (stats_handle); import_release_stats_handle (stats_handle); @@ -1721,7 +1757,8 @@ keyserver_import_cert (ctrl_t ctrl, opt.no_armor=1; err = import_keys_es_stream (ctrl, key, NULL, fpr, fpr_len, - opt.keyserver_options.import_options); + opt.keyserver_options.import_options, + NULL, NULL); opt.no_armor=armor_status; diff --git a/g10/main.h b/g10/main.h index 1b619e0..b49d10e 100644 --- a/g10/main.h +++ b/g10/main.h @@ -271,15 +271,18 @@ gcry_mpi_t encode_md_value (PKT_public_key *pk, gcry_md_hd_t md, int hash_algo ); /*-- import.c --*/ +typedef int (*import_filter)(PKT_public_key *pk, void *arg); int parse_import_options(char *str,unsigned int *options,int noisy); void import_keys (ctrl_t ctrl, char **fnames, int nnames, void *stats_hd, unsigned int options); int import_keys_stream (ctrl_t ctrl, iobuf_t inp, void *stats_hd, unsigned char **fpr, - size_t *fpr_len, unsigned int options); + size_t *fpr_len, unsigned int options, + import_filter constr, void *filter_arg); int import_keys_es_stream (ctrl_t ctrl, estream_t fp, void *stats_handle, unsigned char **fpr, size_t *fpr_len, - unsigned int options); + unsigned int options, + import_filter constr, void *filter_arg); void *import_new_stats_handle (void); void import_release_stats_handle (void *p); void import_print_stats (void *hd); -- 1.7.10.4 From tomanek at internet-sicherheit.de Thu Jan 30 00:57:43 2014 From: tomanek at internet-sicherheit.de (Stefan Tomanek) Date: Thu, 30 Jan 2014 00:57:43 +0100 Subject: [PATCH v6 (stable-1-4)] filter and verify keyserver responses Message-ID: <20140129235743.GA30808@zirkel.wertarbyte.de> * g10/main.h: typedef import_filter for filter callbacks * g10/import.c (import): add filter callbacks to param list (import_one): ditto. (import_secret_one): ditto. (import_keys_internal): ditto. (import_keys_stream): ditto. * g10/keyserver.c (keyserver_retrieval_filter): add function (keyserver_spawn): pass filter to import_keys_stream() -- This changes introduces import functions that apply a constraining filter to imported keys. These filters can verify the fingerprints of the keys returned before importing them into the keyring, ensuring that the keys fetched from the keyserver are in fact those selected by the user beforehand. It also prevents the accidental import of secret keys through key server responses. Signed-off-by: Stefan Tomanek --- g10/import.c | 49 ++++++++++++++++++++++++++++++++++--------------- g10/keyserver.c | 48 ++++++++++++++++++++++++++++++++++++++++++++---- g10/main.h | 4 +++- 3 files changed, 81 insertions(+), 20 deletions(-) diff --git a/g10/import.c b/g10/import.c index 441dcca..7a941ac 100644 --- a/g10/import.c +++ b/g10/import.c @@ -59,14 +59,17 @@ struct stats_s { static int import( IOBUF inp, const char* fname,struct stats_s *stats, - unsigned char **fpr,size_t *fpr_len,unsigned int options ); + unsigned char **fpr,size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg ); static int read_block( IOBUF a, PACKET **pending_pkt, KBNODE *ret_root ); static void revocation_present(KBNODE keyblock); static int import_one(const char *fname, KBNODE keyblock,struct stats_s *stats, unsigned char **fpr,size_t *fpr_len, - unsigned int options,int from_sk); + unsigned int options,int from_sk, + import_filter filter, void *filter_arg); static int import_secret_one( const char *fname, KBNODE keyblock, - struct stats_s *stats, unsigned int options); + struct stats_s *stats, unsigned int options, + import_filter filter, void *filter_arg); static int import_revoke_cert( const char *fname, KBNODE node, struct stats_s *stats); static int chk_self_sigs( const char *fname, KBNODE keyblock, @@ -163,7 +166,8 @@ import_release_stats_handle (void *p) static int import_keys_internal( IOBUF inp, char **fnames, int nnames, void *stats_handle, unsigned char **fpr, size_t *fpr_len, - unsigned int options ) + unsigned int options, + import_filter filter, void *filter_arg) { int i, rc = 0; struct stats_s *stats = stats_handle; @@ -172,7 +176,7 @@ import_keys_internal( IOBUF inp, char **fnames, int nnames, stats = import_new_stats_handle (); if (inp) { - rc = import( inp, "[stream]", stats, fpr, fpr_len, options); + rc = import( inp, "[stream]", stats, fpr, fpr_len, options, filter, filter_arg); } else { int once = (!fnames && !nnames); @@ -192,7 +196,7 @@ import_keys_internal( IOBUF inp, char **fnames, int nnames, log_error(_("can't open `%s': %s\n"), fname, strerror(errno) ); else { - rc = import( inp2, fname, stats, fpr, fpr_len, options ); + rc = import( inp2, fname, stats, fpr, fpr_len, options, NULL, NULL ); iobuf_close(inp2); /* Must invalidate that ugly cache to actually close it. */ iobuf_ioctl (NULL, 2, 0, (char*)fname); @@ -223,19 +227,21 @@ void import_keys( char **fnames, int nnames, void *stats_handle, unsigned int options ) { - import_keys_internal(NULL,fnames,nnames,stats_handle,NULL,NULL,options); + import_keys_internal(NULL,fnames,nnames,stats_handle,NULL,NULL,options,NULL,NULL); } int import_keys_stream( IOBUF inp, void *stats_handle, - unsigned char **fpr, size_t *fpr_len,unsigned int options ) + unsigned char **fpr, size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg ) { - return import_keys_internal(inp,NULL,0,stats_handle,fpr,fpr_len,options); + return import_keys_internal(inp,NULL,0,stats_handle,fpr,fpr_len,options,filter,filter_arg); } static int import( IOBUF inp, const char* fname,struct stats_s *stats, - unsigned char **fpr,size_t *fpr_len,unsigned int options ) + unsigned char **fpr,size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg ) { PACKET *pending_pkt = NULL; KBNODE keyblock = NULL; @@ -252,9 +258,10 @@ import( IOBUF inp, const char* fname,struct stats_s *stats, while( !(rc = read_block( inp, &pending_pkt, &keyblock) )) { if( keyblock->pkt->pkttype == PKT_PUBLIC_KEY ) - rc = import_one( fname, keyblock, stats, fpr, fpr_len, options, 0); + rc = import_one( fname, keyblock, stats, fpr, fpr_len, options, 0, + filter, filter_arg); else if( keyblock->pkt->pkttype == PKT_SECRET_KEY ) - rc = import_secret_one( fname, keyblock, stats, options ); + rc = import_secret_one( fname, keyblock, stats, options, filter, filter_arg ); else if( keyblock->pkt->pkttype == PKT_SIGNATURE && keyblock->pkt->pkt.signature->sig_class == 0x20 ) rc = import_revoke_cert( fname, keyblock, stats ); @@ -738,7 +745,7 @@ check_prefs(KBNODE keyblock) static int import_one( const char *fname, KBNODE keyblock, struct stats_s *stats, unsigned char **fpr,size_t *fpr_len,unsigned int options, - int from_sk ) + int from_sk, import_filter filter, void *filter_arg) { PKT_public_key *pk; PKT_public_key *pk_orig; @@ -778,6 +785,12 @@ import_one( const char *fname, KBNODE keyblock, struct stats_s *stats, return 0; } + if (filter && filter(pk, NULL, filter_arg)) + { + log_error( _("key %s: rejected by import filter\n"), keystr_from_pk(pk)); + return 0; + } + if (opt.interactive) { if(is_status_enabled()) print_import_check (pk, uidnode->pkt->pkt.user_id); @@ -1146,7 +1159,8 @@ sec_to_pub_keyblock(KBNODE sec_keyblock) */ static int import_secret_one( const char *fname, KBNODE keyblock, - struct stats_s *stats, unsigned int options) + struct stats_s *stats, unsigned int options, + import_filter filter, void *filter_arg) { PKT_secret_key *sk; KBNODE node, uidnode; @@ -1162,6 +1176,11 @@ import_secret_one( const char *fname, KBNODE keyblock, keyid_from_sk( sk, keyid ); uidnode = find_next_kbnode( keyblock, PKT_USER_ID ); + if (filter && filter(NULL, sk, filter_arg)) { + log_error( _("secret key %s: rejected by import filter\n"), keystr_from_sk(sk)); + return 0; + } + if( opt.verbose ) { log_info( "sec %4u%c/%s %s ", @@ -1241,7 +1260,7 @@ import_secret_one( const char *fname, KBNODE keyblock, if(pub_keyblock) { import_one(fname,pub_keyblock,stats, - NULL,NULL,opt.import_options,1); + NULL,NULL,opt.import_options,1,NULL,NULL); release_kbnode(pub_keyblock); } } diff --git a/g10/keyserver.c b/g10/keyserver.c index 7bf9830..a0ac258 100644 --- a/g10/keyserver.c +++ b/g10/keyserver.c @@ -959,6 +959,46 @@ direct_uri_map(const char *scheme,unsigned int is_direct) #define KEYSERVER_ARGS_KEEP " -o \"%O\" \"%I\"" #define KEYSERVER_ARGS_NOKEEP " -o \"%o\" \"%i\"" +static int +keyserver_retrieval_filter(PKT_public_key *pk, PKT_secret_key *sk, void *arg) +{ + KEYDB_SEARCH_DESC *desc = arg; + u32 keyid[2]; + byte fpr[MAX_FINGERPRINT_LEN]; + size_t fpr_len = 0; + + /* we definitely do not want to import secret keys! */ + if (sk) { + return 1; + } + + fingerprint_from_pk(pk, fpr, &fpr_len); + keyid_from_pk(pk, keyid); + + /* compare requested and returned fingerprints if available */ + if (desc->mode == KEYDB_SEARCH_MODE_FPR20) + { + if (fpr_len != 20 || memcmp(fpr, desc->u.fpr, 20)) + return 1; + } + else if (desc->mode == KEYDB_SEARCH_MODE_FPR16) + { + if (fpr_len != 16 || memcmp(fpr, desc->u.fpr, 16)) + return 1; + } + else if (desc->mode == KEYDB_SEARCH_MODE_LONG_KID) + { + if (memcmp(keyid, desc->u.kid, sizeof(keyid))) + return 1; + } + else if (desc->mode == KEYDB_SEARCH_MODE_SHORT_KID) + { + if (memcmp(&keyid[1], &desc->u.kid[1], 1)) + return 1; + } + return 0; +} + static int keyserver_spawn(enum ks_action action,STRLIST list,KEYDB_SEARCH_DESC *desc, int count,int *prog,unsigned char **fpr,size_t *fpr_len, @@ -1508,9 +1548,9 @@ keyserver_spawn(enum ks_action action,STRLIST list,KEYDB_SEARCH_DESC *desc, keyserver. Keyservers should never accept or send them but we better protect against rogue keyservers. */ - import_keys_stream (spawn->fromchild, stats_handle, fpr, fpr_len, - (opt.keyserver_options.import_options - | IMPORT_NO_SECKEY)); + import_keys_stream(spawn->fromchild,stats_handle,fpr,fpr_len, + (opt.keyserver_options.import_options | IMPORT_NO_SECKEY), + &keyserver_retrieval_filter, desc); import_print_stats(stats_handle); import_release_stats_handle(stats_handle); @@ -2043,7 +2083,7 @@ keyserver_import_cert(const char *name,unsigned char **fpr,size_t *fpr_len) rc=import_keys_stream (key, NULL, fpr, fpr_len, (opt.keyserver_options.import_options - | IMPORT_NO_SECKEY)); + | IMPORT_NO_SECKEY), NULL, NULL); opt.no_armor=armor_status; diff --git a/g10/main.h b/g10/main.h index 784ade0..71affff 100644 --- a/g10/main.h +++ b/g10/main.h @@ -207,11 +207,13 @@ MPI encode_md_value( PKT_public_key *pk, PKT_secret_key *sk, MD_HANDLE md, int hash_algo ); /*-- import.c --*/ +typedef int (*import_filter)(PKT_public_key *pk, PKT_secret_key *sk, void *arg); int parse_import_options(char *str,unsigned int *options,int noisy); void import_keys( char **fnames, int nnames, void *stats_hd, unsigned int options ); int import_keys_stream( IOBUF inp,void *stats_hd,unsigned char **fpr, - size_t *fpr_len,unsigned int options ); + size_t *fpr_len,unsigned int options, + import_filter constr, void *filter_arg); void *import_new_stats_handle (void); void import_release_stats_handle (void *p); void import_print_stats (void *hd); -- 1.7.10.4 From tomanek at internet-sicherheit.de Thu Jan 30 00:57:52 2014 From: tomanek at internet-sicherheit.de (Stefan Tomanek) Date: Thu, 30 Jan 2014 00:57:52 +0100 Subject: [PATCH v6 (stable-2-0)] filter and verify keyserver responses Message-ID: <20140129235752.GB30808@zirkel.wertarbyte.de> * g10/main.h: typedef import_filter for filter callbacks * g10/import.c (import): add filter callbacks to param list (import_one): ditto. (import_secret_one): ditto. (import_keys_internal): ditto. (import_keys_stream): ditto. * g10/keyserver.c (keyserver_retrieval_filter): add function (keyserver_spawn): pass filter to import_keys_stream() -- This changes introduces import functions that apply a constraining filter to imported keys. These filters can verify the fingerprints of the keys returned before importing them into the keyring, ensuring that the keys fetched from the keyserver are in fact those selected by the user beforehand. It also prevents the accidental import of secret keys through key server responses. Signed-off-by: Stefan Tomanek --- g10/import.c | 52 ++++++++++++++++++++++++++++++++++++---------------- g10/keyserver.c | 48 ++++++++++++++++++++++++++++++++++++++++++++---- g10/main.h | 4 +++- 3 files changed, 83 insertions(+), 21 deletions(-) diff --git a/g10/import.c b/g10/import.c index 540b24b..95ccd82 100644 --- a/g10/import.c +++ b/g10/import.c @@ -59,14 +59,17 @@ struct stats_s { static int import( IOBUF inp, const char* fname,struct stats_s *stats, - unsigned char **fpr,size_t *fpr_len,unsigned int options ); + unsigned char **fpr,size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg ); static int read_block( IOBUF a, PACKET **pending_pkt, KBNODE *ret_root ); static void revocation_present(KBNODE keyblock); static int import_one(const char *fname, KBNODE keyblock,struct stats_s *stats, unsigned char **fpr,size_t *fpr_len, - unsigned int options,int from_sk); + unsigned int options,int from_sk, + import_filter filter, void *filter_arg); static int import_secret_one( const char *fname, KBNODE keyblock, - struct stats_s *stats, unsigned int options); + struct stats_s *stats, unsigned int options, + import_filter filter, void *filter_arg); static int import_revoke_cert( const char *fname, KBNODE node, struct stats_s *stats); static int chk_self_sigs( const char *fname, KBNODE keyblock, @@ -163,7 +166,8 @@ import_release_stats_handle (void *p) static int import_keys_internal( IOBUF inp, char **fnames, int nnames, void *stats_handle, unsigned char **fpr, size_t *fpr_len, - unsigned int options ) + unsigned int options, + import_filter filter, void *filter_arg) { int i, rc = 0; struct stats_s *stats = stats_handle; @@ -172,7 +176,7 @@ import_keys_internal( IOBUF inp, char **fnames, int nnames, stats = import_new_stats_handle (); if (inp) { - rc = import( inp, "[stream]", stats, fpr, fpr_len, options); + rc = import( inp, "[stream]", stats, fpr, fpr_len, options, filter, filter_arg); } else { int once = (!fnames && !nnames); @@ -192,7 +196,7 @@ import_keys_internal( IOBUF inp, char **fnames, int nnames, log_error(_("can't open `%s': %s\n"), fname, strerror(errno) ); else { - rc = import( inp2, fname, stats, fpr, fpr_len, options ); + rc = import( inp2, fname, stats, fpr, fpr_len, options, NULL, NULL ); iobuf_close(inp2); /* Must invalidate that ugly cache to actually close it. */ iobuf_ioctl (NULL, 2, 0, (char*)fname); @@ -223,19 +227,21 @@ void import_keys( char **fnames, int nnames, void *stats_handle, unsigned int options ) { - import_keys_internal(NULL,fnames,nnames,stats_handle,NULL,NULL,options); + import_keys_internal(NULL,fnames,nnames,stats_handle,NULL,NULL,options,NULL,NULL); } int import_keys_stream( IOBUF inp, void *stats_handle, - unsigned char **fpr, size_t *fpr_len,unsigned int options ) + unsigned char **fpr, size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg ) { - return import_keys_internal(inp,NULL,0,stats_handle,fpr,fpr_len,options); + return import_keys_internal(inp,NULL,0,stats_handle,fpr,fpr_len,options,filter,filter_arg); } static int import( IOBUF inp, const char* fname,struct stats_s *stats, - unsigned char **fpr,size_t *fpr_len,unsigned int options ) + unsigned char **fpr,size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg ) { PACKET *pending_pkt = NULL; KBNODE keyblock = NULL; /* Need to initialize because gcc can't @@ -256,9 +262,11 @@ import( IOBUF inp, const char* fname,struct stats_s *stats, while( !(rc = read_block( inp, &pending_pkt, &keyblock) )) { if( keyblock->pkt->pkttype == PKT_PUBLIC_KEY ) - rc = import_one( fname, keyblock, stats, fpr, fpr_len, options, 0); + rc = import_one( fname, keyblock, stats, fpr, fpr_len, options, 0, + filter, filter_arg ); else if( keyblock->pkt->pkttype == PKT_SECRET_KEY ) - rc = import_secret_one( fname, keyblock, stats, options ); + rc = import_secret_one( fname, keyblock, stats, options, + filter, filter_arg ); else if( keyblock->pkt->pkttype == PKT_SIGNATURE && keyblock->pkt->pkt.signature->sig_class == 0x20 ) rc = import_revoke_cert( fname, keyblock, stats ); @@ -745,7 +753,7 @@ check_prefs(KBNODE keyblock) static int import_one( const char *fname, KBNODE keyblock, struct stats_s *stats, unsigned char **fpr,size_t *fpr_len,unsigned int options, - int from_sk ) + int from_sk, import_filter filter, void *filter_arg) { PKT_public_key *pk; PKT_public_key *pk_orig; @@ -787,7 +795,13 @@ import_one( const char *fname, KBNODE keyblock, struct stats_s *stats, log_error( _("key %s: no user ID\n"), keystr_from_pk(pk)); return 0; } - + + if (filter && filter(pk, NULL, filter_arg)) + { + log_error( _("key %s: rejected by import filter\n"), keystr_from_pk(pk)); + return 0; + } + if (opt.interactive) { if(is_status_enabled()) print_import_check (pk, uidnode->pkt->pkt.user_id); @@ -1166,7 +1180,8 @@ sec_to_pub_keyblock(KBNODE sec_keyblock) */ static int import_secret_one( const char *fname, KBNODE keyblock, - struct stats_s *stats, unsigned int options) + struct stats_s *stats, unsigned int options, + import_filter filter, void *filter_arg) { PKT_secret_key *sk; KBNODE node, uidnode; @@ -1182,6 +1197,11 @@ import_secret_one( const char *fname, KBNODE keyblock, keyid_from_sk( sk, keyid ); uidnode = find_next_kbnode( keyblock, PKT_USER_ID ); + if (filter && filter(NULL, sk, filter_arg)) { + log_error( _("secret key %s: rejected by import filter\n"), keystr_from_sk(sk)); + return 0; + } + if( opt.verbose ) { log_info( "sec %4u%c/%s %s ", @@ -1261,7 +1281,7 @@ import_secret_one( const char *fname, KBNODE keyblock, if(pub_keyblock) { import_one(fname,pub_keyblock,stats, - NULL,NULL,opt.import_options,1); + NULL,NULL,opt.import_options,1,NULL,NULL); release_kbnode(pub_keyblock); } } diff --git a/g10/keyserver.c b/g10/keyserver.c index 7164f67..c00b362 100644 --- a/g10/keyserver.c +++ b/g10/keyserver.c @@ -982,6 +982,46 @@ direct_uri_map(const char *scheme,unsigned int is_direct) #define KEYSERVER_ARGS_NOKEEP " -o \"%o\" \"%i\"" static int +keyserver_retrieval_filter(PKT_public_key *pk, PKT_secret_key *sk, void *arg) +{ + KEYDB_SEARCH_DESC *desc = arg; + u32 keyid[2]; + byte fpr[MAX_FINGERPRINT_LEN]; + size_t fpr_len = 0; + + /* we definitely do not want to import secret keys! */ + if (sk) { + return 1; + } + + fingerprint_from_pk(pk, fpr, &fpr_len); + keyid_from_pk(pk, keyid); + + /* compare requested and returned fingerprints if available */ + if (desc->mode == KEYDB_SEARCH_MODE_FPR20) + { + if (fpr_len != 20 || memcmp(fpr, desc->u.fpr, 20)) + return 1; + } + else if (desc->mode == KEYDB_SEARCH_MODE_FPR16) + { + if (fpr_len != 16 || memcmp(fpr, desc->u.fpr, 16)) + return 1; + } + else if (desc->mode == KEYDB_SEARCH_MODE_LONG_KID) + { + if (memcmp(keyid, desc->u.kid, sizeof(keyid))) + return 1; + } + else if (desc->mode == KEYDB_SEARCH_MODE_SHORT_KID) + { + if (memcmp(&keyid[1], &desc->u.kid[1], 1)) + return 1; + } + return 0; +} + +static int keyserver_spawn(enum ks_action action,strlist_t list,KEYDB_SEARCH_DESC *desc, int count,int *prog,unsigned char **fpr,size_t *fpr_len, struct keyserver_spec *keyserver) @@ -1503,9 +1543,9 @@ keyserver_spawn(enum ks_action action,strlist_t list,KEYDB_SEARCH_DESC *desc, keyserver. Keyservers should never accept or send them but we better protect against rogue keyservers. */ - import_keys_stream (spawn->fromchild, stats_handle, fpr, fpr_len, - (opt.keyserver_options.import_options - | IMPORT_NO_SECKEY)); + import_keys_stream(spawn->fromchild,stats_handle,fpr,fpr_len, + (opt.keyserver_options.import_options | IMPORT_NO_SECKEY), + &keyserver_retrieval_filter, desc); import_print_stats(stats_handle); import_release_stats_handle(stats_handle); @@ -2045,7 +2085,7 @@ keyserver_import_cert(const char *name,unsigned char **fpr,size_t *fpr_len) rc=import_keys_stream (key, NULL, fpr, fpr_len, (opt.keyserver_options.import_options - | IMPORT_NO_SECKEY)); + | IMPORT_NO_SECKEY), NULL, NULL); opt.no_armor=armor_status; diff --git a/g10/main.h b/g10/main.h index 6876e0a..4cc56e6 100644 --- a/g10/main.h +++ b/g10/main.h @@ -259,11 +259,13 @@ gcry_mpi_t encode_md_value( PKT_public_key *pk, PKT_secret_key *sk, gcry_md_hd_t md, int hash_algo ); /*-- import.c --*/ +typedef int (*import_filter)(PKT_public_key *pk, PKT_secret_key *sk, void *arg); int parse_import_options(char *str,unsigned int *options,int noisy); void import_keys( char **fnames, int nnames, void *stats_hd, unsigned int options ); int import_keys_stream( iobuf_t inp,void *stats_hd,unsigned char **fpr, - size_t *fpr_len,unsigned int options ); + size_t *fpr_len,unsigned int options, + import_filter constr, void *filter_arg); void *import_new_stats_handle (void); void import_release_stats_handle (void *p); void import_print_stats (void *hd); -- 1.7.10.4 From hans at guardianproject.info Thu Jan 30 01:36:26 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 29 Jan 2014 19:36:26 -0500 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <87zjmez8gn.fsf@vigenere.g10code.de> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> <87sis73eph.fsf@vigenere.g10code.de> <52E987EB.3000305@guardianproject.info> <87zjmez8gn.fsf@vigenere.g10code.de> Message-ID: <52E99E8A.1060200@guardianproject.info> On 01/29/2014 06:14 PM, Werner Koch wrote: > On Wed, 29 Jan 2014 23:59, hans at guardianproject.info said: > >> That was very helpful! Now all the tests so far pass on the emulator. The >> problem is that is has gotten stuck on libgcrypt/tests/random for over an >> hour. Its stuck here: > > Collecting entropy is a major problem on embedded devices. For some > weeks now there is a discussion about this going on at coderpunks > (ie. cryptography at metzdowd.com) > >> random: checking whether RNG type switching works > > You may want to run the random test manually: > > ./random --verbose --progress Adding --progress. I canceled the test after it was running for 4 hours. I know that entropy is bad on mobile devices, but this is an emulator/VM. And yes, its bad there, but really 4 hours bad? > BTW, is anyone from the guardianproject at FOSDEM? Unfortunately, no. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From hans at guardianproject.info Thu Jan 30 03:59:39 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 29 Jan 2014 21:59:39 -0500 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52E99E8A.1060200@guardianproject.info> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> <87sis73eph.fsf@vigenere.g10code.de> <52E987EB.3000305@guardianproject.info> <87zjmez8gn.fsf@vigenere.g10code.de> <52E99E8A.1060200@guardianproject.info> Message-ID: <52E9C01B.2000506@guardianproject.info> On 01/29/2014 07:36 PM, Hans-Christoph Steiner wrote: > > > On 01/29/2014 06:14 PM, Werner Koch wrote: >> On Wed, 29 Jan 2014 23:59, hans at guardianproject.info said: >> >>> That was very helpful! Now all the tests so far pass on the emulator. The >>> problem is that is has gotten stuck on libgcrypt/tests/random for over an >>> hour. Its stuck here: >> >> Collecting entropy is a major problem on embedded devices. For some >> weeks now there is a discussion about this going on at coderpunks >> (ie. cryptography at metzdowd.com) >> >>> random: checking whether RNG type switching works >> >> You may want to run the random test manually: >> >> ./random --verbose --progress > > Adding --progress. I canceled the test after it was running for 4 hours. I > know that entropy is bad on mobile devices, but this is an emulator/VM. And > yes, its bad there, but really 4 hours bad? Good news! Now that --disable-neon-support works, the Android build is passing all of the tests except for libgcrypt/random, which hangs on that prefer-fips-rng test, and libassuan/fdpassing, which I am not sure is needed on Android. Also, the gnupg/tests are not run because they require a UNIX shell environment which Android does not have (things like /usr/bin/test, /usr/bin/[, etc) .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Thu Jan 30 13:38:36 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 Jan 2014 13:38:36 +0100 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52E9C01B.2000506@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 29 Jan 2014 21:59:39 -0500") References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> <87sis73eph.fsf@vigenere.g10code.de> <52E987EB.3000305@guardianproject.info> <87zjmez8gn.fsf@vigenere.g10code.de> <52E99E8A.1060200@guardianproject.info> <52E9C01B.2000506@guardianproject.info> Message-ID: <87ha8lzltf.fsf@vigenere.g10code.de> On Thu, 30 Jan 2014 03:59, hans at guardianproject.info said: > Good news! Now that --disable-neon-support works, the Android build is > passing all of the tests except for libgcrypt/random, which hangs on that > prefer-fips-rng test, and libassuan/fdpassing, which I am not sure is needed FD passing should work on Android because that is a kernel property. I took the easy way to implement the test by using system() which requires a shell. This can be fixed. > on Android. Also, the gnupg/tests are not run because they require a UNIX > shell environment which Android does not have (things like /usr/bin/test, > /usr/bin/[, etc) Good point. Given that with Windows, VMS, and Android we have a couple of non-Unix targets, we may want to rework the test suite. After all the current automake problems may demand a new test driver anyway. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From brf at hoi-polloi.org Thu Jan 30 13:30:57 2014 From: brf at hoi-polloi.org (Bernd Fix) Date: Thu, 30 Jan 2014 13:30:57 +0100 Subject: failure in go.crypto and GnuPG interoperability Message-ID: <52EA4601.2010507@hoi-polloi.org> I am working on an application that is encrypting content with the openpgp functions from the go.crypto framework. This content is later to be decrypted using the GnuPG application on a Linux box. There seems to be an incompatibility between go.crypto and the GnuPG that fails to decrypt the original content correctly - the decrypted content for larger files is smaller than the original input. I am using Debian7 with the tip version of Go, the current go.crypto repository and GnuPG 1.4.12. The following steps will reproduce the problem: (1) create a file with random content (1MB in this case): dd if=/dev/urandom of=xxx.in count=2048 (2) create a local keyring for testing: gpg --home . --gen-key I used RSA-4096 keys and "testtest" as a password; if you use a different password, change the source code of the test app; create only one key in the keyring! (3) compile the test app from the source code below: go build test.go (4) Run the test app: ./test The output "Compare: 0" indicates that the encryption/decryption cycle in go.crypto worked fine and delivered the expected result. (5) Decrypt output using GnuPG: gpg --home . -o xxx.out -d xxx.in.gpg Compare the two files; you will see something like: -rw-r--r-- 1 test test 1048576 Jan 30 13:06 xxx.in -rw-r--r-- 1 test test 1044505 Jan 30 13:18 xxx.out The two files don't match and neither the test app nor GnuPG showed any warning or error message. Am I doing something wrong or what is going on here? Regards, Bernd. =====[test.go]================================================= package main import ( "bytes" "code.google.com/p/go.crypto/openpgp" "fmt" "io" "io/ioutil" "os" ) const ( FILE = "xxx.in" GNUPG = "secring.gpg" PASSP = "testtest" ) func main() { rdr, err := os.Open(GNUPG) if err != nil { panic(err.Error()) } defer rdr.Close() ents, err := openpgp.ReadKeyRing(rdr) if err != nil { panic(err.Error()) } f, err := os.Open(FILE) if err != nil { panic(err.Error()) } plain, err := ioutil.ReadAll(f) if err != nil { panic(err.Error()) } cBuf := new(bytes.Buffer) cWrt, err := openpgp.Encrypt(cBuf, ents, nil, nil, nil) if err != nil { panic(err.Error()) } cWrt.Write(plain) cWrt.Close() cipher := cBuf.Bytes() out, err := os.Create(FILE + ".gpg") if err != nil { panic(err.Error()) } out.Write(cipher) out.Close() cBuf = bytes.NewBuffer(cipher) pBuf := new(bytes.Buffer) md, err := openpgp.ReadMessage( cBuf, ents, func(keys []openpgp.Key, symmetric bool) ([]byte, error) { priv := keys[0].PrivateKey if priv.Encrypted { priv.Decrypt([]byte(PASSP)) } buf := new(bytes.Buffer) priv.Serialize(buf) return buf.Bytes(), nil }, nil) if err != nil { panic(err.Error()) } buf := make([]byte, 1024) for { n, err := md.UnverifiedBody.Read(buf) pBuf.Write(buf[:n]) if err != nil { if err == io.EOF { err = nil break } panic(err.Error()) } } plain2 := pBuf.Bytes() fmt.Printf("Compare: %d\n", bytes.Compare(plain, plain2)) } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 551 bytes Desc: OpenPGP digital signature URL: From jussi.kivilinna at iki.fi Thu Jan 30 16:43:25 2014 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Thu, 30 Jan 2014 17:43:25 +0200 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52E987EB.3000305@guardianproject.info> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> <87sis73eph.fsf@vigenere.g10code.de> <52E987EB.3000305@guardianproject.info> Message-ID: <52EA731D.20109@iki.fi> On 30.01.2014 00:59, Hans-Christoph Steiner wrote: > > > On 01/28/2014 05:48 PM, Werner Koch wrote: >> On Tue, 28 Jan 2014 20:41, hans at guardianproject.info said: >> >>> I don't know if you saw this, but the current builds have these ./configure >>> flags in them: >>> --disable-padlock-support --disable-drng-support --disable-neon-support. The >> >> FWIW: --disable-neon-support was not working until I fixed that in >> master this afternoon. > > That was very helpful! Now all the tests so far pass on the emulator. Good news. > The > problem is that is has gotten stuck on libgcrypt/tests/random for over an > hour. Its stuck here: > > random: now running with options '--early-rng-check --prefer-system-rng' > random: checking whether RNG type switching works in the early stage > random: checking whether RNG type switching works > random: now running with options '--prefer-standard-rng' > random: checking whether RNG type switching works > random: now running with options '--prefer-fips-rng' > random: checking whether RNG type switching works > > The full test log is attached, the build log is here: > https://dev.guardianproject.info/attachments/download/1138/gpga-build_with-working---disable-neon-support.txt.bz2 > > It would be great to also continue to debug the NEON support, since it'll make > a huge difference on Android devices. I think this change above confirms that > the process is working properly, sounds like the next step is getting Jussi > setup with an Android SDK/NDK and emulator. I'm happy to help with that > process, it shouldn't take longer than an hour. In my experience, it > generally much easier to do on Debian/Ubuntu. I setup SDK&NDK yesterday and managed to build 'make -C external/' and ndk-build stages. ant clean debug fails with: debug: -code-gen: [mergemanifest] Merging AndroidManifest files into one. [mergemanifest] Manifest merger disabled. Using project manifest only. [echo] Handling aidl files... [aidl] No AIDL files to compile. [echo] ---------- [echo] Handling RenderScript files... [echo] ---------- [echo] Handling Resources... [aapt] Generating resource IDs... [aapt] /home/jussi/kernel/gnupg-for-android/res/layout/first_run_setup_activity.xml:21: error: No resource identifier found for attribute 'textAlignment' in package 'android' [aapt] /home/jussi/kernel/gnupg-for-android/res/layout/first_run_welcome_activity.xml:22: error: No resource identifier found for attribute 'textAlignment' in package 'android' [aapt] /home/jussi/kernel/gnupg-for-android/res/layout/first_run_welcome_activity.xml:37: error: No resource identifier found for attribute 'textAlignment' in package 'android' [aapt] aapt: warning: string 'dialog_share_file_using' has no default translation in /home/jussi/kernel/gnupg-for-android/libs/appcompat/res; found: cs de es pl BUILD FAILED /home/jussi/android-sdk-linux/tools/ant/build.xml:653: The following error occurred while executing this line: /home/jussi/android-sdk-linux/tools/ant/build.xml:698: null returned: 1 Total time: 3 seconds I'll look more closely at this on weekend. -Jussi > > .hc > From hans at guardianproject.info Thu Jan 30 17:48:52 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 30 Jan 2014 11:48:52 -0500 Subject: updating test suites WAS: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <87ha8lzltf.fsf@vigenere.g10code.de> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> <87sis73eph.fsf@vigenere.g10code.de> <52E987EB.3000305@guardianproject.info> <87zjmez8gn.fsf@vigenere.g10code.de> <52E99E8A.1060200@guardianproject.info> <52E9C01B.2000506@guardianproject.info> <87ha8lzltf.fsf@vigenere.g10code.de> Message-ID: <52EA8274.9010901@guardianproject.info> On 01/30/2014 07:38 AM, Werner Koch wrote: > On Thu, 30 Jan 2014 03:59, hans at guardianproject.info said: > >> Good news! Now that --disable-neon-support works, the Android build is >> passing all of the tests except for libgcrypt/random, which hangs on that >> prefer-fips-rng test, and libassuan/fdpassing, which I am not sure is needed > > FD passing should work on Android because that is a kernel property. > I took the easy way to implement the test by using system() which > requires a shell. This can be fixed. > >> on Android. Also, the gnupg/tests are not run because they require a UNIX >> shell environment which Android does not have (things like /usr/bin/test, >> /usr/bin/[, etc) > > Good point. Given that with Windows, VMS, and Android we have a couple > of non-Unix targets, we may want to rework the test suite. After all > the current automake problems may demand a new test driver anyway. I hope to be able to contribute to the effort of improving the test suite by integrating Android support in, so I don't need to run them from an external Makefile, and instead everything needed is included in each gnupg subproject's build system. How much time I'll be able to spend on that depends on a lot of things, including our hiring, whether we get some grants, etc. I'll keep you posted. Another possibility is us finding funds to pay someone who is well situated to work on integrating the Android bits. Let us know if you know anyone who might be interested. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From casey.marshall at gmail.com Thu Jan 30 18:28:13 2014 From: casey.marshall at gmail.com (Casey Marshall) Date: Thu, 30 Jan 2014 11:28:13 -0600 Subject: failure in go.crypto and GnuPG interoperability In-Reply-To: <52EA4601.2010507@hoi-polloi.org> References: <52EA4601.2010507@hoi-polloi.org> Message-ID: <52EA8BAD.6030605@gmail.com> go.crypto is interpreting the plaintext input as text and mangling it, as the input is binary. If you encrypt with: cWrt, err := openpgp.Encrypt(cBuf, ents, nil, &openpgp.FileHints{IsBinary: true}, nil) you should see output identical to the input. -Casey On 01/30/2014 06:30 AM, Bernd Fix wrote: > I am working on an application that is encrypting content with the > openpgp functions from the go.crypto framework. This content is later to > be decrypted using the GnuPG application on a Linux box. There seems to > be an incompatibility between go.crypto and the GnuPG that fails to > decrypt the original content correctly - the decrypted content for > larger files is smaller than the original input. > > I am using Debian7 with the tip version of Go, the current go.crypto > repository and GnuPG 1.4.12. The following steps will reproduce the problem: > > (1) create a file with random content (1MB in this case): > > dd if=/dev/urandom of=xxx.in count=2048 > > (2) create a local keyring for testing: > > gpg --home . --gen-key > > I used RSA-4096 keys and "testtest" as a password; if you use a > different password, change the source code of the test app; create only > one key in the keyring! > > (3) compile the test app from the source code below: > > go build test.go > > (4) Run the test app: > > ./test > > The output "Compare: 0" indicates that the encryption/decryption cycle > in go.crypto worked fine and delivered the expected result. > > (5) Decrypt output using GnuPG: > > gpg --home . -o xxx.out -d xxx.in.gpg > > Compare the two files; you will see something like: > > -rw-r--r-- 1 test test 1048576 Jan 30 13:06 xxx.in > -rw-r--r-- 1 test test 1044505 Jan 30 13:18 xxx.out > > > The two files don't match and neither the test app nor GnuPG showed any > warning or error message. Am I doing something wrong or what is going on > here? > > Regards, Bernd. > > =====[test.go]================================================= > > package main > > import ( > "bytes" > "code.google.com/p/go.crypto/openpgp" > "fmt" > "io" > "io/ioutil" > "os" > ) > > const ( > FILE = "xxx.in" > GNUPG = "secring.gpg" > PASSP = "testtest" > ) > > func main() { > rdr, err := os.Open(GNUPG) > if err != nil { > panic(err.Error()) > } > defer rdr.Close() > ents, err := openpgp.ReadKeyRing(rdr) > if err != nil { > panic(err.Error()) > } > > f, err := os.Open(FILE) > if err != nil { > panic(err.Error()) > } > plain, err := ioutil.ReadAll(f) > if err != nil { > panic(err.Error()) > } > > cBuf := new(bytes.Buffer) > cWrt, err := openpgp.Encrypt(cBuf, ents, nil, nil, nil) > if err != nil { > panic(err.Error()) > } > cWrt.Write(plain) > cWrt.Close() > cipher := cBuf.Bytes() > > out, err := os.Create(FILE + ".gpg") > if err != nil { > panic(err.Error()) > } > out.Write(cipher) > out.Close() > > cBuf = bytes.NewBuffer(cipher) > pBuf := new(bytes.Buffer) > md, err := openpgp.ReadMessage( > cBuf, > ents, > func(keys []openpgp.Key, symmetric bool) ([]byte, error) { > priv := keys[0].PrivateKey > if priv.Encrypted { > priv.Decrypt([]byte(PASSP)) > } > buf := new(bytes.Buffer) > priv.Serialize(buf) > return buf.Bytes(), nil > }, > nil) > if err != nil { > panic(err.Error()) > } > buf := make([]byte, 1024) > for { > n, err := md.UnverifiedBody.Read(buf) > pBuf.Write(buf[:n]) > if err != nil { > if err == io.EOF { > err = nil > break > } > panic(err.Error()) > } > } > plain2 := pBuf.Bytes() > fmt.Printf("Compare: %d\n", bytes.Compare(plain, plain2)) > } > > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From hans at guardianproject.info Thu Jan 30 20:49:40 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 30 Jan 2014 14:49:40 -0500 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52EA731D.20109@iki.fi> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> <87sis73eph.fsf@vigenere.g10code.de> <52E987EB.3000305@guardianproject.info> <52EA731D.20109@iki.fi> Message-ID: <52EAACD4.3090908@guardianproject.info> On 01/30/2014 10:43 AM, Jussi Kivilinna wrote: > On 30.01.2014 00:59, Hans-Christoph Steiner wrote: >> >> >> On 01/28/2014 05:48 PM, Werner Koch wrote: >>> On Tue, 28 Jan 2014 20:41, hans at guardianproject.info said: >>> >>>> I don't know if you saw this, but the current builds have these ./configure >>>> flags in them: >>>> --disable-padlock-support --disable-drng-support --disable-neon-support. The >>> >>> FWIW: --disable-neon-support was not working until I fixed that in >>> master this afternoon. >> >> That was very helpful! Now all the tests so far pass on the emulator. > > Good news. > >> The >> problem is that is has gotten stuck on libgcrypt/tests/random for over an >> hour. Its stuck here: >> >> random: now running with options '--early-rng-check --prefer-system-rng' >> random: checking whether RNG type switching works in the early stage >> random: checking whether RNG type switching works >> random: now running with options '--prefer-standard-rng' >> random: checking whether RNG type switching works >> random: now running with options '--prefer-fips-rng' >> random: checking whether RNG type switching works >> >> The full test log is attached, the build log is here: >> https://dev.guardianproject.info/attachments/download/1138/gpga-build_with-working---disable-neon-support.txt.bz2 >> >> It would be great to also continue to debug the NEON support, since it'll make >> a huge difference on Android devices. I think this change above confirms that >> the process is working properly, sounds like the next step is getting Jussi >> setup with an Android SDK/NDK and emulator. I'm happy to help with that >> process, it shouldn't take longer than an hour. In my experience, it >> generally much easier to do on Debian/Ubuntu. > > I setup SDK&NDK yesterday and managed to build 'make -C external/' and ndk-build stages. > > ant clean debug fails with: > > debug: > > -code-gen: > [mergemanifest] Merging AndroidManifest files into one. > [mergemanifest] Manifest merger disabled. Using project manifest only. > [echo] Handling aidl files... > [aidl] No AIDL files to compile. > [echo] ---------- > [echo] Handling RenderScript files... > [echo] ---------- > [echo] Handling Resources... > [aapt] Generating resource IDs... > [aapt] /home/jussi/kernel/gnupg-for-android/res/layout/first_run_setup_activity.xml:21: error: No resource identifier found for attribute 'textAlignment' in package 'android' > [aapt] /home/jussi/kernel/gnupg-for-android/res/layout/first_run_welcome_activity.xml:22: error: No resource identifier found for attribute 'textAlignment' in package 'android' > [aapt] /home/jussi/kernel/gnupg-for-android/res/layout/first_run_welcome_activity.xml:37: error: No resource identifier found for attribute 'textAlignment' in package 'android' > [aapt] aapt: warning: string 'dialog_share_file_using' has no default translation in /home/jussi/kernel/gnupg-for-android/libs/appcompat/res; found: cs de es pl > > BUILD FAILED > /home/jussi/android-sdk-linux/tools/ant/build.xml:653: The following error occurred while executing this line: > /home/jussi/android-sdk-linux/tools/ant/build.xml:698: null returned: 1 > > Total time: 3 seconds > > I'll look more closely at this on weekend. Odd that this didn't fail on our build server, but I pushed a fix for this anyhow. Here is the whole procedure for including the tests in the APK: make -C external/ distclean clean-assets make -C external/ make -C external/ assets-tests ndk-build clean ndk-build ./setup-ant.sh ant clean debug Then to run the tests, first install the APK and run it so that it sets up all of its included assets. Once the Android app has completed its initial setup, run: ./assets/tests/launch_run-tests_on-android.sh Since the whole thing is quite a big package, I find it easier to copy only the tests that changed into place using `adb push`. That only works if you have root access to your device, which you do for an emulator. You can also use `adb shell` to get a shell and run things there. Keep in mind that the only way an executable can find shared libraries is by setting LD_LIBRARY_PATH, so you'll probably need to set that in `adb shell` in order for the tests to find the shared libraries. That would look something like this: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/data/data/info.guardianproject/gpg/lib:\ /data/data/info.guardianproject/gpg/app_opt/lib .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From hans at guardianproject.info Thu Jan 30 20:56:18 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 30 Jan 2014 14:56:18 -0500 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52EAACD4.3090908@guardianproject.info> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> <87sis73eph.fsf@vigenere.g10code.de> <52E987EB.3000305@guardianproject.info> <52EA731D.20109@iki.fi> <52EAACD4.3090908@guardianproject.info> Message-ID: <52EAAE62.4060005@guardianproject.info> On 01/30/2014 02:49 PM, Hans-Christoph Steiner wrote: > > > On 01/30/2014 10:43 AM, Jussi Kivilinna wrote: >> On 30.01.2014 00:59, Hans-Christoph Steiner wrote: >>> >>> >>> On 01/28/2014 05:48 PM, Werner Koch wrote: >>>> On Tue, 28 Jan 2014 20:41, hans at guardianproject.info said: >>>> >>>>> I don't know if you saw this, but the current builds have these ./configure >>>>> flags in them: >>>>> --disable-padlock-support --disable-drng-support --disable-neon-support. The >>>> >>>> FWIW: --disable-neon-support was not working until I fixed that in >>>> master this afternoon. >>> >>> That was very helpful! Now all the tests so far pass on the emulator. >> >> Good news. >> >>> The >>> problem is that is has gotten stuck on libgcrypt/tests/random for over an >>> hour. Its stuck here: >>> >>> random: now running with options '--early-rng-check --prefer-system-rng' >>> random: checking whether RNG type switching works in the early stage >>> random: checking whether RNG type switching works >>> random: now running with options '--prefer-standard-rng' >>> random: checking whether RNG type switching works >>> random: now running with options '--prefer-fips-rng' >>> random: checking whether RNG type switching works >>> >>> The full test log is attached, the build log is here: >>> https://dev.guardianproject.info/attachments/download/1138/gpga-build_with-working---disable-neon-support.txt.bz2 >>> >>> It would be great to also continue to debug the NEON support, since it'll make >>> a huge difference on Android devices. I think this change above confirms that >>> the process is working properly, sounds like the next step is getting Jussi >>> setup with an Android SDK/NDK and emulator. I'm happy to help with that >>> process, it shouldn't take longer than an hour. In my experience, it >>> generally much easier to do on Debian/Ubuntu. >> >> I setup SDK&NDK yesterday and managed to build 'make -C external/' and ndk-build stages. >> >> ant clean debug fails with: >> >> debug: >> >> -code-gen: >> [mergemanifest] Merging AndroidManifest files into one. >> [mergemanifest] Manifest merger disabled. Using project manifest only. >> [echo] Handling aidl files... >> [aidl] No AIDL files to compile. >> [echo] ---------- >> [echo] Handling RenderScript files... >> [echo] ---------- >> [echo] Handling Resources... >> [aapt] Generating resource IDs... >> [aapt] /home/jussi/kernel/gnupg-for-android/res/layout/first_run_setup_activity.xml:21: error: No resource identifier found for attribute 'textAlignment' in package 'android' >> [aapt] /home/jussi/kernel/gnupg-for-android/res/layout/first_run_welcome_activity.xml:22: error: No resource identifier found for attribute 'textAlignment' in package 'android' >> [aapt] /home/jussi/kernel/gnupg-for-android/res/layout/first_run_welcome_activity.xml:37: error: No resource identifier found for attribute 'textAlignment' in package 'android' >> [aapt] aapt: warning: string 'dialog_share_file_using' has no default translation in /home/jussi/kernel/gnupg-for-android/libs/appcompat/res; found: cs de es pl >> >> BUILD FAILED >> /home/jussi/android-sdk-linux/tools/ant/build.xml:653: The following error occurred while executing this line: >> /home/jussi/android-sdk-linux/tools/ant/build.xml:698: null returned: 1 >> >> Total time: 3 seconds >> >> I'll look more closely at this on weekend. > > Odd that this didn't fail on our build server, but I pushed a fix for this > anyhow. Here is the whole procedure for including the tests in the APK: > > make -C external/ distclean clean-assets > make -C external/ > make -C external/ assets-tests > ndk-build clean > ndk-build > ./setup-ant.sh > ant clean debug > > Then to run the tests, first install the APK and run it so that it sets up all > of its included assets. Once the Android app has completed its initial setup, run: > > ./assets/tests/launch_run-tests_on-android.sh > > Since the whole thing is quite a big package, I find it easier to copy only > the tests that changed into place using `adb push`. That only works if you > have root access to your device, which you do for an emulator. > > You can also use `adb shell` to get a shell and run things there. Keep in > mind that the only way an executable can find shared libraries is by setting > LD_LIBRARY_PATH, so you'll probably need to set that in `adb shell` in order > for the tests to find the shared libraries. That would look something like this: > > export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/data/data/info.guardianproject/gpg/lib:\ > /data/data/info.guardianproject/gpg/app_opt/lib > > .hc I forgot to add, I attached two patches which I use for the testing setup. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-REMOVE-ME-debug-flags-for-native-builds.patch Type: text/x-patch Size: 1972 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-REMOVE-ME-enable-debug-logs.patch Type: text/x-patch Size: 2335 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From brf at hoi-polloi.org Thu Jan 30 22:47:34 2014 From: brf at hoi-polloi.org (Bernd Fix) Date: Thu, 30 Jan 2014 22:47:34 +0100 Subject: [go-nuts] Re: failure in go.crypto and GnuPG interoperability In-Reply-To: <52EA8BAD.6030605@gmail.com> References: <52EA4601.2010507@hoi-polloi.org> <52EA8BAD.6030605@gmail.com> Message-ID: <52EAC876.7030704@hoi-polloi.org> Am 30.01.2014 18:28, schrieb Casey Marshall: > go.crypto is interpreting the plaintext input as text and mangling it, > as the input is binary. If you encrypt with: > > cWrt, err := openpgp.Encrypt(cBuf, ents, nil, > &openpgp.FileHints{IsBinary: true}, nil) > > you should see output identical to the input. Indeed - that solved the problem. Thanks a lot. Cheers, Bernd. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 551 bytes Desc: OpenPGP digital signature URL: From hans at guardianproject.info Fri Jan 31 03:20:24 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 30 Jan 2014 21:20:24 -0500 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52EAAE62.4060005@guardianproject.info> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> <87sis73eph.fsf@vigenere.g10code.de> <52E987EB.3000305@guardianproject.info> <52EA731D.20109@iki.fi> <52EAACD4.3090908@guardianproject.info> <52EAAE62.4060005@guardianproject.info> Message-ID: <52EB0868.1090805@guardianproject.info> On 01/30/2014 02:56 PM, Hans-Christoph Steiner wrote: > > On 01/30/2014 02:49 PM, Hans-Christoph Steiner wrote: >> >> >> On 01/30/2014 10:43 AM, Jussi Kivilinna wrote: >>> On 30.01.2014 00:59, Hans-Christoph Steiner wrote: >>>> >>>> >>>> On 01/28/2014 05:48 PM, Werner Koch wrote: >>>>> On Tue, 28 Jan 2014 20:41, hans at guardianproject.info said: >>>>> >>>>>> I don't know if you saw this, but the current builds have these ./configure >>>>>> flags in them: >>>>>> --disable-padlock-support --disable-drng-support --disable-neon-support. The >>>>> >>>>> FWIW: --disable-neon-support was not working until I fixed that in >>>>> master this afternoon. >>>> >>>> That was very helpful! Now all the tests so far pass on the emulator. >>> >>> Good news. >>> >>>> The >>>> problem is that is has gotten stuck on libgcrypt/tests/random for over an >>>> hour. Its stuck here: >>>> >>>> random: now running with options '--early-rng-check --prefer-system-rng' >>>> random: checking whether RNG type switching works in the early stage >>>> random: checking whether RNG type switching works >>>> random: now running with options '--prefer-standard-rng' >>>> random: checking whether RNG type switching works >>>> random: now running with options '--prefer-fips-rng' >>>> random: checking whether RNG type switching works >>>> >>>> The full test log is attached, the build log is here: >>>> https://dev.guardianproject.info/attachments/download/1138/gpga-build_with-working---disable-neon-support.txt.bz2 >>>> >>>> It would be great to also continue to debug the NEON support, since it'll make >>>> a huge difference on Android devices. I think this change above confirms that >>>> the process is working properly, sounds like the next step is getting Jussi >>>> setup with an Android SDK/NDK and emulator. I'm happy to help with that >>>> process, it shouldn't take longer than an hour. In my experience, it >>>> generally much easier to do on Debian/Ubuntu. >>> >>> I setup SDK&NDK yesterday and managed to build 'make -C external/' and ndk-build stages. >>> >>> ant clean debug fails with: >>> >>> debug: >>> >>> -code-gen: >>> [mergemanifest] Merging AndroidManifest files into one. >>> [mergemanifest] Manifest merger disabled. Using project manifest only. >>> [echo] Handling aidl files... >>> [aidl] No AIDL files to compile. >>> [echo] ---------- >>> [echo] Handling RenderScript files... >>> [echo] ---------- >>> [echo] Handling Resources... >>> [aapt] Generating resource IDs... >>> [aapt] /home/jussi/kernel/gnupg-for-android/res/layout/first_run_setup_activity.xml:21: error: No resource identifier found for attribute 'textAlignment' in package 'android' >>> [aapt] /home/jussi/kernel/gnupg-for-android/res/layout/first_run_welcome_activity.xml:22: error: No resource identifier found for attribute 'textAlignment' in package 'android' >>> [aapt] /home/jussi/kernel/gnupg-for-android/res/layout/first_run_welcome_activity.xml:37: error: No resource identifier found for attribute 'textAlignment' in package 'android' >>> [aapt] aapt: warning: string 'dialog_share_file_using' has no default translation in /home/jussi/kernel/gnupg-for-android/libs/appcompat/res; found: cs de es pl >>> >>> BUILD FAILED >>> /home/jussi/android-sdk-linux/tools/ant/build.xml:653: The following error occurred while executing this line: >>> /home/jussi/android-sdk-linux/tools/ant/build.xml:698: null returned: 1 >>> >>> Total time: 3 seconds >>> >>> I'll look more closely at this on weekend. >> >> Odd that this didn't fail on our build server, but I pushed a fix for this >> anyhow. Here is the whole procedure for including the tests in the APK: >> >> make -C external/ distclean clean-assets >> make -C external/ >> make -C external/ assets-tests >> ndk-build clean >> ndk-build >> ./setup-ant.sh >> ant clean debug >> >> Then to run the tests, first install the APK and run it so that it sets up all >> of its included assets. Once the Android app has completed its initial setup, run: >> >> ./assets/tests/launch_run-tests_on-android.sh >> >> Since the whole thing is quite a big package, I find it easier to copy only >> the tests that changed into place using `adb push`. That only works if you >> have root access to your device, which you do for an emulator. >> >> You can also use `adb shell` to get a shell and run things there. Keep in >> mind that the only way an executable can find shared libraries is by setting >> LD_LIBRARY_PATH, so you'll probably need to set that in `adb shell` in order >> for the tests to find the shared libraries. That would look something like this: >> >> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/data/data/info.guardianproject/gpg/lib:\ >> /data/data/info.guardianproject/gpg/app_opt/lib >> >> .hc > > I forgot to add, I attached two patches which I use for the testing setup. > > .hc Ok, I removed --prefer-fips-rng from the random test, and all the rest work fine, and complete in well under an hour. So its just fdpassing and 'random --prefer-fips-rng' that are still failing. As for the NEON build, I removed -mno-unaligned-access from libgcrypt CFLAGS, and removed --disable-padlock-support --disable-drng-support --disable-neon-support from libgcrypt ./configure, and it detects NEON support, and all of the same tests pass. Since the failures, I've switched libgcrypt from master to the 1.6.x branch, which does not include "Parse /proc/cpuinfo for ARM HW features". So its likely building with NEON instructions, but not running with them on the device. Here's the submodule change list from master to 1.6.x: > cipher: Take care of ENABLE_NEON_SUPPORT. > Post release updates. > Release 1.6.1. > Reserve control code for FIPS extensions. > Support non weak symbol pthread platforms. > tests: Remove non-portable format specifiers. > Fix RSA Blinding. > sexp: Fix broken gcry_sexp_nth. > mpi: Minor fix for Atari-mint. > tests: Pass -no-install to libtool > Fix most of memory leaks in tests code > Fix memory leaks in ecc code > Check compiler features only for the relevant platform. > Truncate hash values for ECDSA signature scheme > Support locking under Windows. > cipher: Fix commit 77f28793 > md: Add Whirlpool bug emulation feature. > PBKDF2: Use gcry_md_reset to speed up calculation. > Update NEWS. > Fix macro conflict in NetBSD > Fix typo in search_oid > Correct formatting of gcry_mac_get_algo_keylen documentation > * cipher/Makefile.am: Add 'blowfish-arm.S' and 'serpent-armv7-neon.S'. -- > Fix buggy/incomplete detection of AVX/AVX2 support > Use the generic autogen.sh script. > Move all helper scripts to build-aux/ < Fix another minor typo. < Typo fixes. < Add blowfish/serpent ARM assembly files to Makefile.am < Add AMD64 assembly implementation for arcfour < Parse /proc/cpuinfo for ARM HW features < Fix buggy/incomplete detection of AVX/AVX2 support < Change utf-8 copyright characters to '(C)' < Add ARM/NEON implementation for SHA-1 < Improve performance of SHA-512/ARM/NEON implementation < Add AVX and AVX2/BMI implementations for SHA-256 < Add AVX and AVX/BMI2 implementations for SHA-1 < SHA-1/SSSE3: Improve performance on large buffers < Add bulk processing for hash transform functions < Open new development branch. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Fri Jan 31 04:46:57 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 31 Jan 2014 12:46:57 +0900 Subject: Catch 22 in ECC support of OpenPGP? Message-ID: <1391140017.2806.7.camel@cfw2.gniibe.org> Hello, Andrey and Werner, Cc-ed to GnuPG Development List. I'm currently considering adding other curves and EdDSA signature scheme to Gnuk. I'm also considering update of GnuPG's smartcard support for ECC. I think that adding curves would be no problem against RFC6637, as OID is unique. Currently, development version of GnuPG supports curves defined by RFC6637 as well as three curves of Brainpool, and secp256k1. I think that adding new signature scheme requires its algorithm ID. Writing this mail today, I did some research. Then, I found the discussion in OpenPGP at ietf.org: (1) Possible algorithm ID 22 for ECDH+ECDSA: http://www.ietf.org/mail-archive/web/openpgp/current/msg07163.html (2) Possible algorithm ID 22 for EdDSA: http://www.ietf.org/mail-archive/web/openpgp/current/msg07194.html It's better to sort it out now. Algorithm ID 22 for ECDH+ECDSA Algorithm ID 23 for EdDSA ? Sorry for interference, but I need Algorithm ID 22 (and 23) defined, indeed. -- From openpgp at brainhub.org Fri Jan 31 07:17:18 2014 From: openpgp at brainhub.org (Andrey Jivsov) Date: Thu, 30 Jan 2014 22:17:18 -0800 Subject: Catch 22 in ECC support of OpenPGP? In-Reply-To: <1391140017.2806.7.camel@cfw2.gniibe.org> References: <1391140017.2806.7.camel@cfw2.gniibe.org> Message-ID: <52EB3FEE.9070205@brainhub.org> On 01/30/2014 07:46 PM, NIIBE Yutaka wrote: > Hello, Andrey and Werner, > Cc-ed to GnuPG Development List. > > I'm currently considering adding other curves and EdDSA signature > scheme to Gnuk. I'm also considering update of GnuPG's smartcard > support for ECC. > > I think that adding curves would be no problem against RFC6637, as OID > is unique. Currently, development version of GnuPG supports curves > defined by RFC6637 as well as three curves of Brainpool, and > secp256k1. > > I think that adding new signature scheme requires its algorithm ID. > > Writing this mail today, I did some research. Then, I found the > discussion in OpenPGP at ietf.org: > > (1) Possible algorithm ID 22 for ECDH+ECDSA: > http://www.ietf.org/mail-archive/web/openpgp/current/msg07163.html > > (2) Possible algorithm ID 22 for EdDSA: > http://www.ietf.org/mail-archive/web/openpgp/current/msg07194.html > > It's better to sort it out now. > > Algorithm ID 22 for ECDH+ECDSA > Algorithm ID 23 for EdDSA > > ? > > Sorry for interference, but I need Algorithm ID 22 (and 23) defined, > indeed. I am fine with 22. I think it's premature to think that the 23 EdDSA is ready to go along the side of ECDSA. I am not saying that this will never happen, but rather that this needs to be discussed and benefits stated. ( Would it work to perhaps claim some higher-numbered ID in the mean time? If it turns to be popular, we can "upgrade" it later to the permanent number) As for compact representation, I recently updated http://http://tools.ietf.org/html/draft-jivsov-ecc-compact to include curves other than simple Weierstrass curves. I would recommend it as a format for OpenPGP. NIIBE, perhaps you could double-check that you are OK with the representation for Curve25519. To use the draft-jivsov-ecc-compact in OpenPGP there could be a separate draft, but its value will be mostly procedural because it will basically refer the reader to the draft-jivsov-ecc-compact (so one knows what to do without such a second draft already when, for example, a single "x" is encountered). From gniibe at fsij.org Fri Jan 31 08:50:01 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 31 Jan 2014 16:50:01 +0900 Subject: Catch 22 in ECC support of OpenPGP? In-Reply-To: <52EB3FEE.9070205@brainhub.org> References: <1391140017.2806.7.camel@cfw2.gniibe.org> <52EB3FEE.9070205@brainhub.org> Message-ID: <1391154601.2806.10.camel@cfw2.gniibe.org> Thank you for comments. On 2014-01-30 at 22:17 -0800, Andrey Jivsov wrote: > I am fine with 22. Good. > I think it's premature to think that the 23 EdDSA is ready to go along > the side of ECDSA. I am not saying that this will never happen, but > rather that this needs to be discussed and benefits stated. ( Would it > work to perhaps claim some higher-numbered ID in the mean time? If it > turns to be popular, we can "upgrade" it later to the permanent number) Thank you for your suggestion. It's good idea. (I had an experience of analyzing a bug report of gnupg which was in fact kernel incompatibility issue. It was caused by newly introduced system call number difference [0].) It seems for me that OpenSSH are adopting EdDSA, so, GnuPG users will want to use EdDSA soon through gpg-agent's feature of SSH authentication. > As for compact representation, I recently updated > http://http://tools.ietf.org/html/draft-jivsov-ecc-compact to include > curves other than simple Weierstrass curves. I would recommend it as a > format for OpenPGP. NIIBE, perhaps you could double-check that you are > OK with the representation for Curve25519. Thank you for the reference. I didn't know you have updated it. Let me explain my understandings for current situation of Curve25519 and Ed25519 in libgcrypt. In libgcrypt, there's no support for Curve25519 yet, but Ed25519 (specifically for EdDSA). Ed25519 has its own compact representation for elliptic curve point. Namely, because x can be represented in 255-bit, we have another bit to represent the sign in 256th-bit. When Curve25519 will be supported in GnuPG, I think that it's only for ECDH (since people use EdDSA with Ed25519, instead of ECDSA with Curve25519). Thus, there will be no problem with the compact representation (even though there is no condition p mod 4 == 3). [0] Debian bug report to gnupg: http://bugs.debian.org/714107 -- From wk at gnupg.org Fri Jan 31 08:43:41 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 31 Jan 2014 08:43:41 +0100 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52EB0868.1090805@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 30 Jan 2014 21:20:24 -0500") References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> <87sis73eph.fsf@vigenere.g10code.de> <52E987EB.3000305@guardianproject.info> <52EA731D.20109@iki.fi> <52EAACD4.3090908@guardianproject.info> <52EAAE62.4060005@guardianproject.info> <52EB0868.1090805@guardianproject.info> Message-ID: <87wqhgy4sy.fsf@vigenere.g10code.de> On Fri, 31 Jan 2014 03:20, hans at guardianproject.info said: > libgcrypt from master to the 1.6.x branch, which does not include "Parse > /proc/cpuinfo for ARM HW features". So its likely building with NEON I'll have a look at it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jan 31 08:40:52 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 31 Jan 2014 08:40:52 +0100 Subject: Catch 22 in ECC support of OpenPGP? In-Reply-To: <1391140017.2806.7.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Fri, 31 Jan 2014 12:46:57 +0900") References: <1391140017.2806.7.camel@cfw2.gniibe.org> Message-ID: <871tzozji3.fsf@vigenere.g10code.de> On Fri, 31 Jan 2014 04:46, gniibe at fsij.org said: > I think that adding new signature scheme requires its algorithm ID. Right, for EdDSA we should have a new id. Yesterday I changed the GnuPG code and replaced the EdDSA hacks with new experimental algorithm id. The code is not finished and actually the whole ECC stuff is currently broken. I'll fix that soon. For EdDSA we need a new RFC to have the IANA assign a new algorithm id. While doing that we should also address two questions: 1. Shall we keep the OID field or shall we replace it with either a curve size parameter or maybe assign a single algorithm identifier for Ed25519/EdDSA? 2. Does the use of MPIs make sense? Bernstein defines the key as well as the signature material as octet strings and not as MPIs. A reason to drop the OID field would be smaller key material which may help with key backup or direct use of the key. However, it complicates parsing because we would need two methods. I am fine with the OIDs (after all I suggested them) because for key backup we can use our own format. Such a format should be URI encoded for use in QR codes anyway. The problem with fitting an EdDSA key or signature material into an MPI is the usual leading zero problem. Thus for processing the red MPIs needs to be left-padded with zeroes up to the size indirecty specified by the OID. Note that we do not have the compression flag byte in plain EdDsA (but see below). For GnuPG/Libgcrypt this is not a big problem because we already have code in place to do that. New OpenPGP implementations may benefit from a simpler scheme. Related to question 1, a length byte could also be used to distinguish between different curves (i.e. Ed25519 and Curve41417). RFC-4880 describes the key material as a series of MPIs, which would rule out the above idea. However, RFC-6637 already uses non-MPIs for the OID and the KDF params. > (1) Possible algorithm ID 22 for ECDH+ECDSA: > http://www.ietf.org/mail-archive/web/openpgp/current/msg07163.html I am not in favor of mixing them. Encryption, and in particular DH, is different from signing. Having different algorithms ids also helps to avoid mixing encryption and signing keys due to implicit capabilities. > (2) Possible algorithm ID 22 for EdDSA: > http://www.ietf.org/mail-archive/web/openpgp/current/msg07194.html Before we can request the assignment of a new algo id, we need to write the specs. This is why I am currently using 105 for EdDSA. Some of you may have noticed that the CFRG (the IRTF crypto research group) is currently discussing standardization of non-Weierstrass curves (e.g. Curve25519 an its variants). Watson Ladd is working on an I-D[1]. The TLS WG is also discussing these curves. There are many ideas floating around and it would be useful to wait until we have a clear picture. This will help to solve the problem of missing standard documents for the Bernstein (aka Chicago) curves. The available papers are not suitable for normative use in an RFC (maybe with the exception of the Ed25519 paper). Of course we could informally agree on an algorithm id for EdDSA, as we always did in the OpenPGP WG. However, a new algorithm id is not sufficient as long as we do not have answers to the above questions. We better go in lock-step with the Ladd I-D. Is there anyone with free time to write an I-D? Shouldn't we continue this discussing at the IETF OpenPGP mailing list? Salam-Shalom, Werner [1] http://www.ietf.org/id/draft-ladd-safecurves-03.txt -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri Jan 31 09:11:27 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 31 Jan 2014 17:11:27 +0900 Subject: Catch 22 in ECC support of OpenPGP? In-Reply-To: <871tzozji3.fsf@vigenere.g10code.de> References: <1391140017.2806.7.camel@cfw2.gniibe.org> <871tzozji3.fsf@vigenere.g10code.de> Message-ID: <1391155887.8877.1.camel@cfw2.gniibe.org> On 2014-01-31 at 08:40 +0100, Werner Koch wrote: > Shouldn't we continue this discussing at the IETF OpenPGP mailing list? Yes, we should. Sorry, it was me who should have started there. My message was originally specific to GnuPG and Gnuk, but it turned into different focus. -- From wk at gnupg.org Fri Jan 31 09:44:02 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 31 Jan 2014 09:44:02 +0100 Subject: Catch 22 in ECC support of OpenPGP? In-Reply-To: <1391154601.2806.10.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Fri, 31 Jan 2014 16:50:01 +0900") References: <1391140017.2806.7.camel@cfw2.gniibe.org> <52EB3FEE.9070205@brainhub.org> <1391154601.2806.10.camel@cfw2.gniibe.org> Message-ID: <87mwicy20d.fsf@vigenere.g10code.de> On Fri, 31 Jan 2014 08:50, gniibe at fsij.org said: > When Curve25519 will be supported in GnuPG, I think that it's only for > ECDH (since people use EdDSA with Ed25519, instead of ECDSA with I think it makes more sense to use an Ed25519 based ECDH in OpenPGP than to require the implementation of its Montgomery variant Curve25519. This would benefit small OpenPGP implementation which won't do the current MUST algorithms but anyway provide compatibility with general purpose OpenPGP tools. There might be a small performance drawback but can be justified by a more compact implementation. The current ECDH algo ID can still be used for this if we go without point compression. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jan 31 09:49:54 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 31 Jan 2014 09:49:54 +0100 Subject: Catch 22 in ECC support of OpenPGP? In-Reply-To: <1391155887.8877.1.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Fri, 31 Jan 2014 17:11:27 +0900") References: <1391140017.2806.7.camel@cfw2.gniibe.org> <871tzozji3.fsf@vigenere.g10code.de> <1391155887.8877.1.camel@cfw2.gniibe.org> Message-ID: <878utwy1ql.fsf@vigenere.g10code.de> Hi, I forwarded my reply to the openpgp at ietf.org ML. Let's follow up there. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.