From jorgelonus at hotmail.com Fri Oct 1 01:00:33 2010 From: jorgelonus at hotmail.com (Jorge Barriga Piedra) Date: Thu, 30 Sep 2010 18:00:33 -0500 Subject: Help with addphoto in single line please Message-ID: Hi every one, Regards From Mexico. Im english beginner, so please excuse. Mi name is Jorge Barriga and Im doing a litle Front End in Java (purpose:obtain my degree), Of course I release soon as possible, so eventualy I'll need a domain. for give mi work FREE ;). Im using GnuPG 1.4.9 version and I need help to add photo in single line.(without --edit-key menu). and revoke key in single line to. I'll been trying some like: gpg --batch --passphrase xxxx --yes --output /home/urs/file.asc --gen-revoke mail at domain but it say its imposible in this way. "Imposible hacer esto en modo de proceso por lotes" I'll been trying using the batch mode without successful. Somebody knows how? Thanks for reading. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.brinkmann at ruhr-uni-bochum.de Fri Oct 1 04:13:37 2010 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 1 Oct 2010 04:13:37 +0200 Subject: Scute - pkcs11.h is outdated In-Reply-To: <8E4035E3-0A58-4038-9E34-88B693C9440D@iis.se> References: <8E4035E3-0A58-4038-9E34-88B693C9440D@iis.se> Message-ID: <4CA543D1.60408@ruhr-uni-bochum.de> On 09/24/2010 04:05 PM, Rickard Bellgrim wrote: > Hi > > The PKCS#11 header file you are using in the Scute project is missing the latest amendments for PKCS#11 v2.20. > > ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/otp-pkcs11.h > ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/ct-kip.h > ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20a3.h > > And the following defines was also missing They were included in the original v2.20: If you send a patch I'll put it in. Thanks, Marcus From rickard.bellgrim at iis.se Fri Oct 1 08:06:45 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 1 Oct 2010 08:06:45 +0200 Subject: Scute - pkcs11.h is outdated In-Reply-To: <4CA543D1.60408@ruhr-uni-bochum.de> References: <8E4035E3-0A58-4038-9E34-88B693C9440D@iis.se> <4CA543D1.60408@ruhr-uni-bochum.de> Message-ID: <0E890BB5-763E-4F05-81C0-E3F0A6C0C82F@iis.se> On 1 okt 2010, at 04.13, Marcus Brinkmann wrote: > If you send a patch I'll put it in. Ok, I will have a look on that next week. We are using it in OpenDNSSEC and SoftHSM. This pkcs11.h is the only BSD-license friendly file that I know of. But I read somewhere that PKCS#11 v.2.30 will have a more open license than the current version. (If they ever release it) // Rickard From flameeyes at gmail.com Fri Oct 1 16:47:58 2010 From: flameeyes at gmail.com (=?UTF-8?q?Diego=20Elio=20Petten=C3=B2?=) Date: Fri, 1 Oct 2010 16:47:58 +0200 Subject: Make GnuPG more PIE-friendly Message-ID: <1285944481-21529-1-git-send-email-flameeyes@gmail.com> Hi, since I have been looking at the GnuPG sources for the card issues I got, I took a bit of time to pass the object files through my cowstats[1] script (on a PIE[2],[3] build). The result is in these three patches that move some data structures to .rodata to avoid relocations due to pointers, reduce resident memory size, and add extra safety (as overflows can't risk changing seed data for instance). HTH, -- Diego Elio Petten? From flameeyes at gmail.com Fri Oct 1 16:47:59 2010 From: flameeyes at gmail.com (=?UTF-8?q?Diego=20Elio=20Petten=C3=B2?=) Date: Fri, 1 Oct 2010 16:47:59 +0200 Subject: [PATCH 1/3] Mark tables, strings, arrays as constant where no real code is changed. In-Reply-To: <1285944481-21529-1-git-send-email-flameeyes@gmail.com> References: <1285944481-21529-1-git-send-email-flameeyes@gmail.com> Message-ID: <1285944481-21529-2-git-send-email-flameeyes@gmail.com> This patch changes as many data structures as possible to be constant (or static constant) without any code change. The only change in non-structure declaration is adapting the functions' parameters to accept the pointer to constant (which is the stricter option). --- agent/command-ssh.c | 8 ++++---- agent/gpg-agent.c | 2 +- agent/preset-passphrase.c | 2 +- agent/protect-tool.c | 2 +- g10/armor.c | 8 ++++---- g10/gpg.c | 4 ++-- g10/gpgv.c | 2 +- g10/main.h | 2 +- g10/misc.c | 2 +- jnlib/argparse.c | 12 ++++++------ jnlib/argparse.h | 4 ++-- kbx/kbxutil.c | 2 +- scd/app-dinsig.c | 6 +++--- scd/app-nks.c | 6 +++--- scd/app-openpgp.c | 16 ++++++++-------- scd/app-p15.c | 4 ++-- scd/sc-copykeys.c | 2 +- scd/scdaemon.c | 2 +- sm/base64.c | 4 ++-- sm/certreqgen.c | 6 +++--- sm/gpgsm.c | 2 +- tools/gpg-check-pattern.c | 2 +- tools/gpg-connect-agent.c | 2 +- tools/gpgconf.c | 2 +- tools/gpgsplit.c | 2 +- tools/symcryptrun.c | 2 +- 26 files changed, 54 insertions(+), 54 deletions(-) diff --git a/agent/command-ssh.c b/agent/command-ssh.c index 12fe60a..d5ebfc4 100644 --- a/agent/command-ssh.c +++ b/agent/command-ssh.c @@ -198,7 +198,7 @@ static gpg_error_t ssh_signature_encoder_dsa (estream_t signature_blob, /* Associating request types with the corresponding request handlers. */ -static ssh_request_spec_t request_specs[] = +static const ssh_request_spec_t request_specs[] = { #define REQUEST_SPEC_DEFINE(id, name, secret_input) \ { SSH_REQUEST_##id, ssh_handler_##name, #name, secret_input } @@ -2717,10 +2717,10 @@ ssh_handler_unlock (ctrl_t ctrl, estream_t request, estream_t response) /* Return the request specification for the request identified by TYPE or NULL in case the requested request specification could not be found. */ -static ssh_request_spec_t * +static const ssh_request_spec_t * request_spec_lookup (int type) { - ssh_request_spec_t *spec; + const ssh_request_spec_t *spec; unsigned int i; for (i = 0; i < DIM (request_specs); i++) @@ -2744,7 +2744,7 @@ request_spec_lookup (int type) static int ssh_request_process (ctrl_t ctrl, estream_t stream_sock) { - ssh_request_spec_t *spec; + const ssh_request_spec_t *spec; estream_t response; estream_t request; unsigned char request_type; diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index 7e35947..b05ad82 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -111,7 +111,7 @@ enum cmd_and_opt_values -static ARGPARSE_OPTS opts[] = { +static const ARGPARSE_OPTS opts[] = { { aGPGConfList, "gpgconf-list", 256, "@" }, { aGPGConfTest, "gpgconf-test", 256, "@" }, diff --git a/agent/preset-passphrase.c b/agent/preset-passphrase.c index 72de91b..0657252 100644 --- a/agent/preset-passphrase.c +++ b/agent/preset-passphrase.c @@ -67,7 +67,7 @@ aTest }; static const char *opt_homedir; static const char *opt_passphrase; -static ARGPARSE_OPTS opts[] = { +static const ARGPARSE_OPTS opts[] = { { 301, NULL, 0, N_("@Options:\n ") }, diff --git a/agent/protect-tool.c b/agent/protect-tool.c index dc040f9..fb2563e 100644 --- a/agent/protect-tool.c +++ b/agent/protect-tool.c @@ -109,7 +109,7 @@ static int store_private_key (const unsigned char *grip, const void *buffer, size_t length, int force); -static ARGPARSE_OPTS opts[] = { +static const ARGPARSE_OPTS opts[] = { ARGPARSE_group (300, N_("@Commands:\n ")), ARGPARSE_c (oProtect, "protect", "protect a private key"), diff --git a/g10/armor.c b/g10/armor.c index 652ef3a..30213a2 100644 --- a/g10/armor.c +++ b/g10/armor.c @@ -46,9 +46,9 @@ a &= 0x00ffffff; \ } while(0) static u32 crc_table[256]; -static byte bintoasc[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" - "abcdefghijklmnopqrstuvwxyz" - "0123456789+/"; +static const byte bintoasc[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" + "abcdefghijklmnopqrstuvwxyz" + "0123456789+/"; static byte asctobin[256]; /* runtime initialized */ static int is_initialized; @@ -165,7 +165,7 @@ initialize(void) { int i, j; u32 t; - byte *s; + const byte *s; /* init the crc lookup table */ crc_table[0] = 0; diff --git a/g10/gpg.c b/g10/gpg.c index 7e648fb..b2a0524 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -368,7 +368,7 @@ enum cmd_and_opt_values }; -static ARGPARSE_OPTS opts[] = { +static const ARGPARSE_OPTS opts[] = { ARGPARSE_group (300, N_("@Commands:\n ")), @@ -2694,7 +2694,7 @@ main (int argc, char **argv) break; case oVerifyOptions: { - struct parse_options vopts[]= + static const struct parse_options vopts[]= { {"show-photos",VERIFY_SHOW_PHOTOS,NULL, N_("display photo IDs during signature verification")}, diff --git a/g10/gpgv.c b/g10/gpgv.c index 747b05f..cd4afd6 100644 --- a/g10/gpgv.c +++ b/g10/gpgv.c @@ -65,7 +65,7 @@ enum cmd_and_opt_values { }; -static ARGPARSE_OPTS opts[] = { +static const ARGPARSE_OPTS opts[] = { ARGPARSE_group (300, N_("@\nOptions:\n ")), ARGPARSE_s_n (oVerbose, "verbose", N_("verbose")), diff --git a/g10/main.h b/g10/main.h index 3a42137..49ebb16 100644 --- a/g10/main.h +++ b/g10/main.h @@ -138,7 +138,7 @@ struct parse_options char *optsep(char **stringp); char *argsplit(char *string); int parse_options(char *str,unsigned int *options, - struct parse_options *opts,int noisy); + const struct parse_options *opts,int noisy); int has_invalid_email_chars (const char *s); int is_valid_mailbox (const char *name); const char *get_libexecdir (void); diff --git a/g10/misc.c b/g10/misc.c index 8cc63ba..9eb8b99 100644 --- a/g10/misc.c +++ b/g10/misc.c @@ -1120,7 +1120,7 @@ optlen(const char *s) int parse_options(char *str,unsigned int *options, - struct parse_options *opts,int noisy) + const struct parse_options *opts,int noisy) { char *tok; diff --git a/jnlib/argparse.c b/jnlib/argparse.c index 8b2a9f4..7f9df26 100644 --- a/jnlib/argparse.c +++ b/jnlib/argparse.c @@ -146,7 +146,7 @@ struct alias_def_s { static const char *(*strusage_handler)( int ) = NULL; static int set_opt_arg(ARGPARSE_ARGS *arg, unsigned flags, char *s); -static void show_help(ARGPARSE_OPTS *opts, unsigned flags); +static void show_help(const ARGPARSE_OPTS *opts, unsigned flags); static void show_version(void); @@ -263,7 +263,7 @@ store_alias( ARGPARSE_ARGS *arg, char *name, char *value ) */ int optfile_parse (FILE *fp, const char *filename, unsigned *lineno, - ARGPARSE_ARGS *arg, ARGPARSE_OPTS *opts) + ARGPARSE_ARGS *arg, const ARGPARSE_OPTS *opts) { int state, i, c; int idx=0; @@ -508,7 +508,7 @@ optfile_parse (FILE *fp, const char *filename, unsigned *lineno, static int find_long_option( ARGPARSE_ARGS *arg, - ARGPARSE_OPTS *opts, const char *keyword ) + const ARGPARSE_OPTS *opts, const char *keyword ) { int i; size_t n; @@ -555,7 +555,7 @@ find_long_option( ARGPARSE_ARGS *arg, } int -arg_parse( ARGPARSE_ARGS *arg, ARGPARSE_OPTS *opts) +arg_parse( ARGPARSE_ARGS *arg, const ARGPARSE_OPTS *opts) { int idx; int argc; @@ -833,7 +833,7 @@ set_opt_arg(ARGPARSE_ARGS *arg, unsigned flags, char *s) static size_t -long_opt_strlen( ARGPARSE_OPTS *o ) +long_opt_strlen( const ARGPARSE_OPTS *o ) { size_t n = strlen (o->long_opt); @@ -872,7 +872,7 @@ long_opt_strlen( ARGPARSE_OPTS *o ) * bar and the next one as arguments of the long option. */ static void -show_help (ARGPARSE_OPTS *opts, unsigned int flags) +show_help (const ARGPARSE_OPTS *opts, unsigned int flags) { const char *s; diff --git a/jnlib/argparse.h b/jnlib/argparse.h index b211e5f..d06fa10 100644 --- a/jnlib/argparse.h +++ b/jnlib/argparse.h @@ -173,9 +173,9 @@ typedef struct #define ARGPARSE_OUT_OF_CORE (-11) -int arg_parse( ARGPARSE_ARGS *arg, ARGPARSE_OPTS *opts); +int arg_parse( ARGPARSE_ARGS *arg, const ARGPARSE_OPTS *opts); int optfile_parse( FILE *fp, const char *filename, unsigned *lineno, - ARGPARSE_ARGS *arg, ARGPARSE_OPTS *opts); + ARGPARSE_ARGS *arg, const ARGPARSE_OPTS *opts); void usage( int level ); const char *strusage( int level ); void set_strusage( const char *(*f)( int ) ); diff --git a/kbx/kbxutil.c b/kbx/kbxutil.c index 4592811..66ca614 100644 --- a/kbx/kbxutil.c +++ b/kbx/kbxutil.c @@ -67,7 +67,7 @@ enum cmd_and_opt_values { }; -static ARGPARSE_OPTS opts[] = { +static const ARGPARSE_OPTS opts[] = { { 300, NULL, 0, N_("@Commands:\n ") }, /* { aFindByFpr, "find-by-fpr", 0, "|FPR| find key using it's fingerprnt" }, */ diff --git a/scd/app-dinsig.c b/scd/app-dinsig.c index 46e9a6a..a9c78f2 100644 --- a/scd/app-dinsig.c +++ b/scd/app-dinsig.c @@ -393,13 +393,13 @@ do_sign (app_t app, const char *keyidstr, int hashalgo, const void *indata, size_t indatalen, unsigned char **outdata, size_t *outdatalen ) { - static unsigned char sha1_prefix[15] = /* Object ID is 1.3.14.3.2.26 */ + static const unsigned char sha1_prefix[15] = /* Object ID is 1.3.14.3.2.26 */ { 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0e, 0x03, 0x02, 0x1a, 0x05, 0x00, 0x04, 0x14 }; - static unsigned char rmd160_prefix[15] = /* Object ID is 1.3.36.3.2.1 */ + static const unsigned char rmd160_prefix[15] = /* Object ID is 1.3.36.3.2.1 */ { 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x24, 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 }; - static unsigned char sha256_prefix[19] = /* OID is 2.16.840.1.101.3.4.2.1 */ + static const unsigned char sha256_prefix[19] = /* OID is 2.16.840.1.101.3.4.2.1 */ { 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20 }; diff --git a/scd/app-nks.c b/scd/app-nks.c index 076b913..068ccef 100644 --- a/scd/app-nks.c +++ b/scd/app-nks.c @@ -333,7 +333,7 @@ do_getattr (app_t app, ctrl_t ctrl, const char *name) signing. it might work anyway but it has not yet been tested - fixme. Thus for now we use the NKS signature key for authentication. */ - char const tmp[] = "NKS-NKS3.4531"; + static const char tmp[] = "NKS-NKS3.4531"; send_status_info (ctrl, table[idx].name, tmp, strlen (tmp), NULL, 0); } break; @@ -852,10 +852,10 @@ do_sign (app_t app, const char *keyidstr, int hashalgo, const void *indata, size_t indatalen, unsigned char **outdata, size_t *outdatalen ) { - static unsigned char sha1_prefix[15] = /* Object ID is 1.3.14.3.2.26 */ + static const unsigned char sha1_prefix[15] = /* Object ID is 1.3.14.3.2.26 */ { 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0e, 0x03, 0x02, 0x1a, 0x05, 0x00, 0x04, 0x14 }; - static unsigned char rmd160_prefix[15] = /* Object ID is 1.3.36.3.2.1 */ + static const unsigned char rmd160_prefix[15] = /* Object ID is 1.3.36.3.2.1 */ { 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x24, 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 }; int rc, i; diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index d468591..eed6600 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -69,7 +69,7 @@ /* A table describing the DOs of the card. */ -static struct { +static const struct { int tag; int constructed; int get_from; /* Constructed DO with this DO or 0 for direct access. */ @@ -84,7 +84,7 @@ static struct { status bytes. */ int try_extlen:1; /* Large object; try to use an extended length APDU. */ - char *desc; + const char *desc; } data_objects[] = { { 0x005E, 0, 0, 1, 0, 0, 0, 0, "Login Data" }, { 0x5F50, 0, 0, 0, 0, 0, 0, 0, "URL" }, @@ -3026,25 +3026,25 @@ do_sign (app_t app, const char *keyidstr, int hashalgo, const void *indata, size_t indatalen, unsigned char **outdata, size_t *outdatalen ) { - static unsigned char rmd160_prefix[15] = /* Object ID is 1.3.36.3.2.1 */ + static const unsigned char rmd160_prefix[15] = /* Object ID is 1.3.36.3.2.1 */ { 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x24, 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 }; - static unsigned char sha1_prefix[15] = /* (1.3.14.3.2.26) */ + static const unsigned char sha1_prefix[15] = /* (1.3.14.3.2.26) */ { 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0e, 0x03, 0x02, 0x1a, 0x05, 0x00, 0x04, 0x14 }; - static unsigned char sha224_prefix[19] = /* (2.16.840.1.101.3.4.2.4) */ + static const unsigned char sha224_prefix[19] = /* (2.16.840.1.101.3.4.2.4) */ { 0x30, 0x2D, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05, 0x00, 0x04, 0x1C }; - static unsigned char sha256_prefix[19] = /* (2.16.840.1.101.3.4.2.1) */ + static const unsigned char sha256_prefix[19] = /* (2.16.840.1.101.3.4.2.1) */ { 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20 }; - static unsigned char sha384_prefix[19] = /* (2.16.840.1.101.3.4.2.2) */ + static const unsigned char sha384_prefix[19] = /* (2.16.840.1.101.3.4.2.2) */ { 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, 0x00, 0x04, 0x30 }; - static unsigned char sha512_prefix[19] = /* (2.16.840.1.101.3.4.2.3) */ + static const unsigned char sha512_prefix[19] = /* (2.16.840.1.101.3.4.2.3) */ { 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, 0x00, 0x04, 0x40 }; diff --git a/scd/app-p15.c b/scd/app-p15.c index 8322617..512476b 100644 --- a/scd/app-p15.c +++ b/scd/app-p15.c @@ -2850,10 +2850,10 @@ do_sign (app_t app, const char *keyidstr, int hashalgo, const void *indata, size_t indatalen, unsigned char **outdata, size_t *outdatalen ) { - static unsigned char sha1_prefix[15] = /* Object ID is 1.3.14.3.2.26 */ + static const unsigned char sha1_prefix[15] = /* Object ID is 1.3.14.3.2.26 */ { 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0e, 0x03, 0x02, 0x1a, 0x05, 0x00, 0x04, 0x14 }; - static unsigned char rmd160_prefix[15] = /* Object ID is 1.3.36.3.2.1 */ + static const unsigned char rmd160_prefix[15] = /* Object ID is 1.3.36.3.2.1 */ { 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x24, 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 }; diff --git a/scd/sc-copykeys.c b/scd/sc-copykeys.c index b863b01..b0a748c 100644 --- a/scd/sc-copykeys.c +++ b/scd/sc-copykeys.c @@ -50,7 +50,7 @@ enum cmd_and_opt_values aTest }; -static ARGPARSE_OPTS opts[] = { +static const ARGPARSE_OPTS opts[] = { { 301, NULL, 0, "@Options:\n " }, diff --git a/scd/scdaemon.c b/scd/scdaemon.c index 5b7ecf2..8a0a3c5 100644 --- a/scd/scdaemon.c +++ b/scd/scdaemon.c @@ -96,7 +96,7 @@ enum cmd_and_opt_values -static ARGPARSE_OPTS opts[] = { +static const ARGPARSE_OPTS opts[] = { ARGPARSE_c (aGPGConfList, "gpgconf-list", "@"), ARGPARSE_c (aGPGConfTest, "gpgconf-test", "@"), diff --git a/sm/base64.c b/sm/base64.c index b0c8dc8..8b88821 100644 --- a/sm/base64.c +++ b/sm/base64.c @@ -103,12 +103,12 @@ struct base64_context_s { /* The base-64 character list */ -static char bintoasc[64] = +static const char bintoasc[64] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" "abcdefghijklmnopqrstuvwxyz" "0123456789+/"; /* The reverse base-64 list */ -static unsigned char asctobin[256] = { +static const unsigned char asctobin[256] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, diff --git a/sm/certreqgen.c b/sm/certreqgen.c index 49b2b92..57f9515 100644 --- a/sm/certreqgen.c +++ b/sm/certreqgen.c @@ -417,9 +417,9 @@ static int has_invalid_email_chars (const char *s) { int at_seen=0; - static char valid_chars[] = "01234567890_-." - "abcdefghijklmnopqrstuvwxyz" - "ABCDEFGHIJKLMNOPQRSTUVWXYZ"; + static const char valid_chars[] = "01234567890_-." + "abcdefghijklmnopqrstuvwxyz" + "ABCDEFGHIJKLMNOPQRSTUVWXYZ"; for (; *s; s++) { if (*s & 0x80) diff --git a/sm/gpgsm.c b/sm/gpgsm.c index 6388d90..90e364e 100644 --- a/sm/gpgsm.c +++ b/sm/gpgsm.c @@ -181,7 +181,7 @@ enum cmd_and_opt_values { }; -static ARGPARSE_OPTS opts[] = { +static const ARGPARSE_OPTS opts[] = { ARGPARSE_group (300, N_("@Commands:\n ")), diff --git a/tools/gpg-check-pattern.c b/tools/gpg-check-pattern.c index 8d15263..e797869 100644 --- a/tools/gpg-check-pattern.c +++ b/tools/gpg-check-pattern.c @@ -65,7 +65,7 @@ enum cmd_and_opt_values /* The list of commands and options. */ -static ARGPARSE_OPTS opts[] = { +static const ARGPARSE_OPTS opts[] = { { 301, NULL, 0, N_("@Options:\n ") }, diff --git a/tools/gpg-connect-agent.c b/tools/gpg-connect-agent.c index 4acda01..dbc86aa 100644 --- a/tools/gpg-connect-agent.c +++ b/tools/gpg-connect-agent.c @@ -63,7 +63,7 @@ enum cmd_and_opt_values /* The list of commands and options. */ -static ARGPARSE_OPTS opts[] = { +static const ARGPARSE_OPTS opts[] = { ARGPARSE_group (301, N_("@\nOptions:\n ")), ARGPARSE_s_n (oVerbose, "verbose", N_("verbose")), diff --git a/tools/gpgconf.c b/tools/gpgconf.c index eb7e9c9..f8d1b2d 100644 --- a/tools/gpgconf.c +++ b/tools/gpgconf.c @@ -55,7 +55,7 @@ enum cmd_and_opt_values /* The list of commands and options. */ -static ARGPARSE_OPTS opts[] = +static const ARGPARSE_OPTS opts[] = { { 300, NULL, 0, N_("@Commands:\n ") }, diff --git a/tools/gpgsplit.c b/tools/gpgsplit.c index 3f093c3..f7b4902 100644 --- a/tools/gpgsplit.c +++ b/tools/gpgsplit.c @@ -63,7 +63,7 @@ enum cmd_and_opt_values { }; -static ARGPARSE_OPTS opts[] = { +static const ARGPARSE_OPTS opts[] = { { 301, NULL, 0, "@Options:\n " }, diff --git a/tools/symcryptrun.c b/tools/symcryptrun.c index 7eeff97..f80522a 100644 --- a/tools/symcryptrun.c +++ b/tools/symcryptrun.c @@ -146,7 +146,7 @@ enum cmd_and_opt_values /* The list of commands and options. */ -static ARGPARSE_OPTS opts[] = +static const ARGPARSE_OPTS opts[] = { { 301, NULL, 0, N_("@\nCommands:\n ") }, -- 1.7.3.1 From flameeyes at gmail.com Fri Oct 1 16:48:01 2010 From: flameeyes at gmail.com (=?UTF-8?q?Diego=20Elio=20Petten=C3=B2?=) Date: Fri, 1 Oct 2010 16:48:01 +0200 Subject: [PATCH 3/3] Simplify lookup of key purpose names. In-Reply-To: <1285944481-21529-1-git-send-email-flameeyes@gmail.com> References: <1285944481-21529-1-git-send-email-flameeyes@gmail.com> Message-ID: <1285944481-21529-4-git-send-email-flameeyes@gmail.com> Again, use a completely static, read-only table (non-relocated) for the translation of oid to name. At the same time, instead of replicating the same loop in three places, simplify it with a static looping function, and use that in two of the three places. The third place only drops the loop because its result weren't used at all; it might have to be changed to fix that issue as well. --- sm/keylist.c | 37 +++++++++++++++++++------------------ 1 files changed, 19 insertions(+), 18 deletions(-) diff --git a/sm/keylist.c b/sm/keylist.c index fe2fb9f..cb54a92 100644 --- a/sm/keylist.c +++ b/sm/keylist.c @@ -50,10 +50,10 @@ struct list_external_parm_s /* This table is to map Extended Key Usage OIDs to human readable names. */ -struct +static const struct { - const char *oid; - const char *name; + char oid[32]; + char name[32]; } key_purpose_map[] = { { "1.3.6.1.5.5.7.3.1", "serverAuth" }, { "1.3.6.1.5.5.7.3.2", "clientAuth" }, @@ -72,11 +72,21 @@ struct { "2.16.840.1.113730.4.1", "serverGatedCrypto.ns" }, /* Netscape. */ { "1.3.6.1.4.1.311.10.3.3", "serverGatedCrypto.ms"}, /* Microsoft. */ - { "1.3.6.1.5.5.7.48.1.5", "ocspNoCheck" }, - - { NULL, NULL } + { "1.3.6.1.5.5.7.48.1.5", "ocspNoCheck" } }; +static const char * +find_key_name(const char *oid) +{ + int i; + + for (i=0; i References: <1285944481-21529-1-git-send-email-flameeyes@gmail.com> Message-ID: <1285944481-21529-3-git-send-email-flameeyes@gmail.com> By using this method, while (some) structures increase in final size, they are defined directly in the output ELF file and mapped from there (from .rodata) rather than requiring relocations and thus Copy-on-Write memory for each process. Out of those changed, the only one which really increases a lot is oidtranstbl, while others even decrease in size on 64-bit systems (where a pointer is 8-bytes). Since it's no longer possible to check for the pointer to be non-NULL, rather than terminating the table with an invalid entry, check against the computed size of the table and its members, which should also make it theoretically possible for the compiler to unroll the loops if needed. --- g10/armor.c | 15 ++++++--------- scd/app-nks.c | 9 ++++----- scd/app-openpgp.c | 22 ++++++++++------------ scd/app-p15.c | 34 +++++++++++++++------------------- sm/certreqgen.c | 11 +++++------ sm/keylist.c | 12 +++++------- 6 files changed, 45 insertions(+), 58 deletions(-) diff --git a/g10/armor.c b/g10/armor.c index 30213a2..105c4a8 100644 --- a/g10/armor.c +++ b/g10/armor.c @@ -90,17 +90,16 @@ typedef enum { * into a mode which fakes packets and wait for the next armor */ #define BEGIN_SIGNATURE 2 #define BEGIN_SIGNED_MSG_IDX 3 -static char *head_strings[] = { +static const char head_strings[][32] = { "BEGIN PGP MESSAGE", "BEGIN PGP PUBLIC KEY BLOCK", "BEGIN PGP SIGNATURE", "BEGIN PGP SIGNED MESSAGE", "BEGIN PGP ARMORED FILE", /* gnupg extension */ "BEGIN PGP PRIVATE KEY BLOCK", - "BEGIN PGP SECRET KEY BLOCK", /* only used by pgp2 */ - NULL + "BEGIN PGP SECRET KEY BLOCK" /* only used by pgp2 */ }; -static char *tail_strings[] = { +static const char tail_strings[][32] = { "END PGP MESSAGE", "END PGP PUBLIC KEY BLOCK", "END PGP SIGNATURE", @@ -108,7 +107,6 @@ static char *tail_strings[] = { "END PGP ARMORED FILE", "END PGP PRIVATE KEY BLOCK", "END PGP SECRET KEY BLOCK", - NULL }; @@ -330,7 +328,6 @@ is_armor_tag(const char *line) static int is_armor_header( byte *line, unsigned len ) { - const char *s; byte *save_p, *p; int save_c; int i; @@ -368,11 +365,11 @@ is_armor_header( byte *line, unsigned len ) return -1; /* garbage after dashes */ save_c = *save_p; *save_p = 0; p = line+5; - for(i=0; (s=head_strings[i]); i++ ) - if( !strcmp(s, p) ) + for(i=0; i < DIM(head_strings); i++ ) + if( !strcmp(head_strings[i], p) ) break; *save_p = save_c; - if( !s ) + if( i >= DIM(head_strings) ) return -1; /* unknown armor line */ if( opt.verbose > 1 ) diff --git a/scd/app-nks.c b/scd/app-nks.c index 068ccef..e27ffd4 100644 --- a/scd/app-nks.c +++ b/scd/app-nks.c @@ -302,14 +302,13 @@ get_chv_status (app_t app, int sigg, int pwid) static gpg_error_t do_getattr (app_t app, ctrl_t ctrl, const char *name) { - static struct { - const char *name; + static const struct { + char name[16]; int special; } table[] = { { "$AUTHKEYID", 1 }, { "NKS-VERSION", 2 }, { "CHV-STATUS", 3 }, - { NULL, 0 } }; gpg_error_t err = 0; int idx; @@ -319,9 +318,9 @@ do_getattr (app_t app, ctrl_t ctrl, const char *name) if (err) return err; - for (idx=0; table[idx].name && strcmp (table[idx].name, name); idx++) + for (idx=0; idx < DIM(table) && strcmp (table[idx].name, name); idx++) ; - if (!table[idx].name) + if (idx >= DIM(table)) return gpg_error (GPG_ERR_INV_NAME); switch (table[idx].special) diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index eed6600..44b76bd 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -795,8 +795,8 @@ send_key_attr (ctrl_t ctrl, app_t app, const char *keyword, int number) static gpg_error_t do_getattr (app_t app, ctrl_t ctrl, const char *name) { - static struct { - const char *name; + static const struct { + char name[16]; int tag; int special; } table[] = { @@ -819,17 +819,16 @@ do_getattr (app_t app, ctrl_t ctrl, const char *name) { "PRIVATE-DO-3", 0x0103 }, { "PRIVATE-DO-4", 0x0104 }, { "$AUTHKEYID", 0x0000, -3 }, - { "$DISPSERIALNO",0x0000, -4 }, - { NULL, 0 } + { "$DISPSERIALNO",0x0000, -4 } }; int idx, i, rc; void *relptr; unsigned char *value; size_t valuelen; - for (idx=0; table[idx].name && strcmp (table[idx].name, name); idx++) + for (idx=0; idx < DIM(table) && strcmp (table[idx].name, name); idx++) ; - if (!table[idx].name) + if (idx >= DIM(table)) return gpg_error (GPG_ERR_INV_NAME); if (table[idx].special == -1) @@ -1773,8 +1772,8 @@ do_setattr (app_t app, const char *name, { gpg_error_t rc; int idx; - static struct { - const char *name; + static const struct { + char name[16]; int tag; int need_chv; int special; @@ -1796,14 +1795,13 @@ do_setattr (app_t app, const char *name, { "CERT-3", 0x7F21, 3, 0, 1 }, { "SM-KEY-ENC", 0x00D1, 3, 0, 1 }, { "SM-KEY-MAC", 0x00D2, 3, 0, 1 }, - { "KEY-ATTR", 0, 0, 3, 1 }, - { NULL, 0 } + { "KEY-ATTR", 0, 0, 3, 1 } }; int exmode; - for (idx=0; table[idx].name && strcmp (table[idx].name, name); idx++) + for (idx=0; idx < DIM(table) && strcmp (table[idx].name, name); idx++) ; - if (!table[idx].name) + if (idx >= DIM(table)) return gpg_error (GPG_ERR_INV_NAME); if (table[idx].need_v2 && !app->app_local->extcap.is_v2) return gpg_error (GPG_ERR_NOT_SUPPORTED); /* Not yet supported. */ diff --git a/scd/app-p15.c b/scd/app-p15.c index 512476b..e7737c7 100644 --- a/scd/app-p15.c +++ b/scd/app-p15.c @@ -54,35 +54,31 @@ typedef enum card_type_t; /* A list card types with ATRs noticed with these cards. */ -#define X(a) ((unsigned char const *)(a)) -static struct +static const struct { size_t atrlen; - unsigned char const *atr; + unsigned char const atr[32]; card_type_t type; } card_atr_list[] = { - { 19, X("\x3B\xBA\x13\x00\x81\x31\x86\x5D\x00\x64\x05\x0A\x02\x01\x31\x80" - "\x90\x00\x8B"), + { 19, "\x3B\xBA\x13\x00\x81\x31\x86\x5D\x00\x64\x05\x0A\x02\x01\x31\x80" + "\x90\x00\x8B", CARD_TYPE_TCOS }, /* SLE44 */ - { 19, X("\x3B\xBA\x14\x00\x81\x31\x86\x5D\x00\x64\x05\x14\x02\x02\x31\x80" - "\x90\x00\x91"), + { 19, "\x3B\xBA\x14\x00\x81\x31\x86\x5D\x00\x64\x05\x14\x02\x02\x31\x80" + "\x90\x00\x91", CARD_TYPE_TCOS }, /* SLE66S */ - { 19, X("\x3B\xBA\x96\x00\x81\x31\x86\x5D\x00\x64\x05\x60\x02\x03\x31\x80" - "\x90\x00\x66"), + { 19, "\x3B\xBA\x96\x00\x81\x31\x86\x5D\x00\x64\x05\x60\x02\x03\x31\x80" + "\x90\x00\x66", CARD_TYPE_TCOS }, /* SLE66P */ - { 27, X("\x3B\xFF\x94\x00\xFF\x80\xB1\xFE\x45\x1F\x03\x00\x68\xD2\x76\x00" - "\x00\x28\xFF\x05\x1E\x31\x80\x00\x90\x00\x23"), + { 27, "\x3B\xFF\x94\x00\xFF\x80\xB1\xFE\x45\x1F\x03\x00\x68\xD2\x76\x00" + "\x00\x28\xFF\x05\x1E\x31\x80\x00\x90\x00\x23", CARD_TYPE_MICARDO }, /* German BMI card */ - { 19, X("\x3B\x6F\x00\xFF\x00\x68\xD2\x76\x00\x00\x28\xFF\x05\x1E\x31\x80" - "\x00\x90\x00"), + { 19, "\x3B\x6F\x00\xFF\x00\x68\xD2\x76\x00\x00\x28\xFF\x05\x1E\x31\x80" + "\x00\x90\x00", CARD_TYPE_MICARDO }, /* German BMI card (ATR due to reader problem) */ - { 26, X("\x3B\xFE\x94\x00\xFF\x80\xB1\xFA\x45\x1F\x03\x45\x73\x74\x45\x49" - "\x44\x20\x76\x65\x72\x20\x31\x2E\x30\x43"), + { 26, "\x3B\xFE\x94\x00\xFF\x80\xB1\xFA\x45\x1F\x03\x45\x73\x74\x45\x49" + "\x44\x20\x76\x65\x72\x20\x31\x2E\x30\x43", CARD_TYPE_MICARDO }, /* EstEID (Estonian Big Brother card) */ - - { 0 } }; -#undef X /* The AID of PKCS15. */ @@ -3334,7 +3330,7 @@ app_select_p15 (app_t app) rc = gpg_error (GPG_ERR_INV_CARD); else { - for (i=0; card_atr_list[i].atrlen; i++) + for (i=0; i < DIM(card_atr_list); i++) if (card_atr_list[i].atrlen == atrlen && !memcmp (card_atr_list[i].atr, atr, atrlen)) { diff --git a/sm/certreqgen.c b/sm/certreqgen.c index 57f9515..efc7eec 100644 --- a/sm/certreqgen.c +++ b/sm/certreqgen.c @@ -249,8 +249,8 @@ get_parameter_uint (struct para_data_s *para, enum para_name key) static int read_parameters (ctrl_t ctrl, estream_t fp, ksba_writer_t writer) { - static struct { - const char *name; + static const struct { + char name[16]; enum para_name key; int allow_dups; } keywords[] = { @@ -261,8 +261,7 @@ read_parameters (ctrl_t ctrl, estream_t fp, ksba_writer_t writer) { "Name-DN", pNAMEDN }, { "Name-Email", pNAMEEMAIL, 1 }, { "Name-DNS", pNAMEDNS, 1 }, - { "Name-URI", pNAMEURI, 1 }, - { NULL, 0 } + { "Name-URI", pNAMEURI, 1 } }; char line[1024], *p; const char *err = NULL; @@ -339,10 +338,10 @@ read_parameters (ctrl_t ctrl, estream_t fp, ksba_writer_t writer) value = p; trim_trailing_spaces (value); - for (i=0; (keywords[i].name + for (i=0; (i < DIM(keywords) && ascii_strcasecmp (keywords[i].name, keyword)); i++) ; - if (!keywords[i].name) + if (i >= DIM(keywords)) { err = "unknown keyword"; break; diff --git a/sm/keylist.c b/sm/keylist.c index 9b8538c..fe2fb9f 100644 --- a/sm/keylist.c +++ b/sm/keylist.c @@ -85,10 +85,10 @@ struct #define OID_FLAG_UTF8 2 /* A table mapping OIDs to a descriptive string. */ -static struct +static const struct { - char *oid; - char *name; + char oid[32]; + char name[44]; unsigned int flag; /* A flag as described above. */ } oidtranstbl[] = { @@ -188,9 +188,7 @@ static struct { "1.3.6.1.4.1.11591.2.1.1", "pkaAddress" }, /* Extensions used by the Bundesnetzagentur. */ - { "1.3.6.1.4.1.8301.3.5", "validityModel" }, - - { NULL } + { "1.3.6.1.4.1.8301.3.5", "validityModel" } }; @@ -202,7 +200,7 @@ get_oid_desc (const char *oid, unsigned int *flag) int i; if (oid) - for (i=0; oidtranstbl[i].oid; i++) + for (i=0; i References: <1285944481-21529-1-git-send-email-flameeyes@gmail.com> Message-ID: <1285944573.6591.594.camel@yamato.local> Il giorno ven, 01/10/2010 alle 16.47 +0200, Diego Elio Petten? ha scritto: > > took a bit of time to pass the object files through my cowstats[1] > script > (on a PIE[2],[3] build). > Whoops, forgot the references [1] http://flameeyes.eu/projects/ruby-elf [2] http://blog.flameeyes.eu/2008/02/24/should-only-libraries-be-concerned-about-pic [3] http://blog.flameeyes.eu/2009/11/02/the-pie-is-not-exactly-a-lie -- Diego Elio Petten? ? ?Flameeyes? http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ From wk at gnupg.org Fri Oct 1 22:40:40 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 01 Oct 2010 22:40:40 +0200 Subject: Exporting secret keys now works for 2.1 (was: The last 9 months ...) In-Reply-To: <87k4mgu2mw.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 20 Sep 2010 12:32:07 +0200") References: <87k4mgu2mw.fsf@vigenere.g10code.de> Message-ID: <874od5zlx3.fsf@vigenere.g10code.de> On Mon, 20 Sep 2010 12:32, wk at gnupg.org said: > This part is not finished; for example I am currently working on the > OpenPGP export command and I also need to make some changes for Exporting secret keys is now basically implemented. Missing stuff: * v3 keys are not supported. I am not sure whether it makes sense to add the code for these legacy keys. You may import them to gpg-agent, though. * Keys may only be exported in a protected form. A passphrase must be given for each key. * Passphrases are not yet cached between subkeys. * Stats are not correct * Smartcard stubs are not well tested. We need to do more tests but real adventurers may want to try the new system (SVN trunk). Use TEST KEYS ! The file agent/keyformat.txt has a short description of the secret key exchange format used between gpg and gpg-agent. We also use an additional key wrapping layer with the agent's export and import commands; it adds no security at the moment, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Oct 8 13:21:48 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Oct 2010 13:21:48 +0200 Subject: Exporting secret keys now works for 2.1 In-Reply-To: <874od5zlx3.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 01 Oct 2010 22:40:40 +0200") References: <87k4mgu2mw.fsf@vigenere.g10code.de> <874od5zlx3.fsf@vigenere.g10code.de> Message-ID: <877hht6ib7.fsf@vigenere.g10code.de> Hi, just want to let you know that I started to use gpg 2.1 with my keys managed by gpg-agent. I *do not suggest* to use production keys with this latest development version but I myself love experimental stuff. Well, my primary key is offline, thus any possible damage is somewhat limited. Migration of existing secret keys is easy: gpg2 --import ~/.gnupg/secring.gpg You need to enter all your passphrases - or if you don;t want to import a particular key or subkey, just hit cancel in the pinentry. If you have a lot of secret keys, you may want to install the latest pinentry for svn - this allows to click on the close-window button to cancel the entire import command and not just the key currently asked for. Do not delete the secring.gpg - GnuPG 1.4 and 2.0 still need them. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: From f.schwind at chili-radiology.com Fri Oct 8 11:08:30 2010 From: f.schwind at chili-radiology.com (Florian Schwind) Date: Fri, 08 Oct 2010 11:08:30 +0200 Subject: Issue 1179 and release if gpg 1.4.11 Message-ID: <4CAEDF8E.4080208@chili-radiology.com> Hi all, is there a patch available for bug 1179? (https://bugs.g10code.com/gnupg/issue1179) And when will 1.4.11 be released? Thanks Florian -- Florian Schwind Softwareentwicklung CHILI GmbH ? Burgstrasse 61 ? D-69121 Heidelberg, Germany Registergericht Mannheim, HRB 337363 ? Gesch?ftsf?hrer: Peter Kayser Fon: (+49) 6221 - 1 80 79 10 ? Fax: (+49) 6221 - 1 80 79 11 mailto:f.schwind at chili-radiology.com ? http://www.chili-radiology.com From wk at gnupg.org Fri Oct 8 17:13:33 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Oct 2010 17:13:33 +0200 Subject: Issue 1179 and release if gpg 1.4.11 In-Reply-To: <4CAEDF8E.4080208@chili-radiology.com> (Florian Schwind's message of "Fri, 08 Oct 2010 11:08:30 +0200") References: <4CAEDF8E.4080208@chili-radiology.com> Message-ID: <8739sg7m5e.fsf@vigenere.g10code.de> On Fri, 8 Oct 2010 11:08, f.schwind at chili-radiology.com said: > is there a patch available for bug 1179? I don't think so. > And when will 1.4.11 be released? As time permits. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sms at antinode.info Sun Oct 10 00:49:55 2010 From: sms at antinode.info (Steven M. Schweda) Date: Sat, 9 Oct 2010 17:49:55 -0500 (CDT) Subject: 1.4.11 release candidate Message-ID: <10100917495577_202004A6@antinode.info> From: Werner Koch Re: VMS-related changes. > I went over the diffs from 1.4.10b and hopefully applied all of the > *.[ch] changes. I have no way to check them. Please let me know if I > missed something. (svn rev5425 in branches/STABLE-BRANCH-1-4). Sorry it took so long to get back to you on these changes. After a visual check, I think that you got almost everything (or else I missed it, too.) Many thanks. (It would be easier for me to check the next release candidate than to try to establish all the infrastructure needed to get a Subversion kit here, so a true test may have to wait a while.) An exception seems to be some VMS-specific file-name and -suffix changes in "config.h.in" and "g10/keyring.c". The old ODS2 file system (still commonly used) on VMS doesn't do well with "~" or multiple dots, so I'd like to switch from (ODS2-hostile) constants in "g10/keyring.c" to macros defined in "config.h.in" (and "vms/config.h_vms", for me). Again, I believe that this will cause no trouble on non-VMS systems. --- config.h.in_orig 2009-12-03 13:27:10 -0600 +++ config.h.in 2009-12-06 15:06:55 -0600 @@ -893,12 +893,23 @@ # define GNUPG_HOMEDIR "c:\\\\gnupg" #else # ifdef __VMS -# define GNUPG_HOMEDIR "/SYS\$LOGIN/gnupg" +# define GNUPG_DATADIR "/SYS$MANAGER/gnupg_share" +# define GNUPG_HOMEDIR "/SYS$LOGIN/gnupg" +# define GNUPG_LIBDIR "/SYS$MANAGER/gnupg_share" +# define GNUPG_LIBEXECDIR "" # else # define GNUPG_HOMEDIR "~/.gnupg" # endif #endif +#ifdef __VMS +# define BAK_SFX "_bak" +# define TMP_SFX "_tmp" +#else /* def __VMS */ +# define BAK_SFX "~" +# define TMP_SFX ".tmp" /* EXTSEP_S + "tmp" */ +#endif /* def __VMS [else] */ + /* Hack used for W32: ldap.m4 also tests for the ASCII version of ldap_start_tls_s because that is the actual symbol used in the library. winldap.h redefines it to our commonly used value, --- g10/keyring.c_orig 2009-07-17 05:15:40 -0500 +++ g10/keyring.c 2009-12-03 14:26:08 -0600 @@ -1182,11 +1182,11 @@ strcpy (stpcpy(tmpfname, template), EXTSEP_S "tmp"); } # else /* Posix file names */ - bakfname = xmalloc (strlen( template ) + 2); - strcpy (stpcpy (bakfname,template),"~"); + bakfname = xmalloc (strlen( template ) + sizeof( BAK_SFX)); + strcpy (stpcpy (bakfname, template), BAK_SFX); - tmpfname = xmalloc (strlen( template ) + 5); - strcpy (stpcpy(tmpfname,template), EXTSEP_S "tmp"); + tmpfname = xmalloc (strlen( template ) + sizeof( TMP_SFX)); + strcpy (stpcpy(tmpfname, template), TMP_SFX); # endif /* Posix filename */ /* Create the temp file with limited access */ You might want to check to see if I counted those characters correctly. ------------------------------------------------------------------------ Steven M. Schweda sms at antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 From wk at gnupg.org Sun Oct 10 12:02:17 2010 From: wk at gnupg.org (Werner Koch) Date: Sun, 10 Oct 2010 12:02:17 +0200 Subject: 1.4.11 release candidate In-Reply-To: <10100917495577_202004A6@antinode.info> (Steven M. Schweda's message of "Sat, 9 Oct 2010 17:49:55 -0500 (CDT)") References: <10100917495577_202004A6@antinode.info> Message-ID: <87wrpq5psm.fsf@vigenere.g10code.de> On Sun, 10 Oct 2010 00:49, sms at antinode.info said: > it, too.) Many thanks. (It would be easier for me to check the next > release candidate than to try to establish all the infrastructure needed > to get a Subversion kit here, so a true test may have to wait a while.) I did a snapshot: ftp://ftp.gnupg/org/gcrypt/alpha/gnupg/gnupg-1.4.11-svn5442.tar.bz2 sha1sum is: b6ebcb6ed296f0ae61b8bb5c7f0f4c6e26e67b72 gnupg-1.4.11-svn5442.tar.bz2 > to macros defined in "config.h.in" (and "vms/config.h_vms", for me). > Again, I believe that this will cause no trouble on non-VMS systems. > > --- config.h.in_orig 2009-12-03 13:27:10 -0600 > +++ config.h.in 2009-12-06 15:06:55 -0600 Included in the snapshot. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Oct 11 09:08:15 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 11 Oct 2010 03:08:15 -0400 Subject: documentation for bug 903 Message-ID: <4CB2B7DF.6060008@fifthhorseman.net> a couple years ago, bug 903 was resolved, including the possibility to document calculated validity in the --photo-viewer output. https://bugs.g10code.com/gnupg/issue903 however, this was never documented in the man pages. The attached patch should update the documentation to reflect the functionality. Thanks, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: followup-on-903.diff Type: text/x-diff Size: 694 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Oct 11 14:28:13 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Oct 2010 14:28:13 +0200 Subject: documentation for bug 903 In-Reply-To: <4CB2B7DF.6060008@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 11 Oct 2010 03:08:15 -0400") References: <4CB2B7DF.6060008@fifthhorseman.net> Message-ID: <87k4lo6hia.fsf@vigenere.g10code.de> On Mon, 11 Oct 2010 09:08, dkg at fifthhorseman.net said: > The attached patch should update the documentation to reflect the > functionality. Commited. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Mon Oct 11 16:28:57 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 11 Oct 2010 10:28:57 -0400 Subject: --list-options show-photos does not work with --with-colons [PATCH] Message-ID: <4CB31F29.8060701@fifthhorseman.net> Hi folks-- i'm just now realizing that --list-options show-photos does not invoke --photo-viewer if --with-colons is set. Since most automated frontends hopefully use --with-colons to enumerate keys by now, this fix should enable those frontends to properly extract the relevant User Attributes for display in a graphical UI, while logically associating them with the rest of the information. Attached are two patches: the first against 1.4.10 (tested, resolves the issue), and the other against trunk (which i haven't tested directly, but i believe should resolve the issue). Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: show-photos-with-colons.1.4.10.diff Type: text/x-diff Size: 585 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: show-photos-with-colons.trunk.diff Type: text/x-diff Size: 523 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From nicholas.cole at gmail.com Mon Oct 11 17:45:59 2010 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 11 Oct 2010 16:45:59 +0100 Subject: --list-options show-photos does not work with --with-colons [PATCH] In-Reply-To: <4CB31F29.8060701@fifthhorseman.net> References: <4CB31F29.8060701@fifthhorseman.net> Message-ID: On Mon, Oct 11, 2010 at 3:28 PM, Daniel Kahn Gillmor wrote: > Hi folks-- > > i'm just now realizing that --list-options show-photos does not invoke > --photo-viewer if --with-colons is set. I don't think I quite understand this fix. I thought that the "right" way to do this was to use --attribute-fd Best wishes, Nicholas From dkg at fifthhorseman.net Mon Oct 11 18:32:37 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 11 Oct 2010 12:32:37 -0400 Subject: --list-options show-photos does not work with --with-colons [PATCH] In-Reply-To: References: <4CB31F29.8060701@fifthhorseman.net> Message-ID: <4CB33C25.6030204@fifthhorseman.net> On 10/11/2010 11:45 AM, Nicholas Cole wrote: > On Mon, Oct 11, 2010 at 3:28 PM, Daniel Kahn Gillmor wrote: >> >> i'm just now realizing that --list-options show-photos does not invoke >> --photo-viewer if --with-colons is set. > > I don't think I quite understand this fix. I thought that the > "right" way to do this was to use > > --attribute-fd if that's the intention, then the documentation should indicate that show-photos will not work when --with-colons is enabled. There's currently no indication that this interaction is expected (or useful). (a pointer within the docs to the "right" way to do it would be handy also) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Oct 15 09:37:01 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 Oct 2010 09:37:01 +0200 Subject: Ready for 1.4.11 Message-ID: <87iq133o0y.fsf@vigenere.g10code.de> Hi! Meanwhile 3 weeks passed since the 1.4.11 release candidate and I have seen no complaints. I plan to get 1.4.11 out early next week. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Oct 18 13:33:51 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Oct 2010 13:33:51 +0200 Subject: [Announce] GnuPG 1.4.11 released Message-ID: <87pqv7zqe8.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-1 release: Version 1.4.11. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility, samrtcard support and is compliant with the OpenPGP Internet standard as described by RFC-4880. Note that this version is from the GnuPG-1 series and thus smaller than those from the GnuPG-2 series, easier to build and also better portable. In contrast to GnuPG-2 (e.g version 2.0.16) it comes with no support for S/MIME or other tools useful for desktop environments. Fortunately you may install both versions alongside on the same system without any conflict. What's New =========== * Bug fixes and portability changes. * Minor changes for better interoperability with GnuPG-2. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 1.4.11 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the following files in the *gnupg* directory: gnupg-1.4.11.tar.bz2 (3327k) gnupg-1.4.11.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.4.11.tar.gz (4603k) gnupg-1.4.11.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.4.10-1.4.11.diff.bz2 (205k) A patch file to upgrade a 1.4.10 GnuPG source tree. This patch does not include updates of the language files. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. In the *binary* directory, you should find these files: gnupg-w32cli-1.4.11.exe (1588k) gnupg-w32cli-1.4.11.exe.sig GnuPG compiled for Microsoft Windows and OpenPGP signature. This is a command line only version; the source files are the same as given above. Note, that this is a minimal installer and unless you are just in need for the gpg binary, you are better off using the full featured installer at http://www.gpg4win.org . Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.4.11.tar.bz2 you would use this command: gpg --verify gnupg-1.4.11.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com | gpg --import or using a keyserver like gpg --recv-key 1CE0C630 The distribution key 1CE0C630 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-1.4.11.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-1.4.11.tar.bz2 and check that the output matches the first line from the following list: 78e22f5cca88514ee71034aafff539c33f3c6676 gnupg-1.4.11.tar.bz2 bffb0c60b2e702980f7148ee3a060f29adc82331 gnupg-1.4.11.tar.gz 631b5129f918b7d30247ade8bcc27908951eaea0 gnupg-w32cli-1.4.11.exe f17729146c18d9288005ac0d93489c333c729345 gnupg-1.4.10-1.4.11.diff.bz2 Internationalization ==================== GnuPG comes with support for 28 languages. Due to a lot of new and changed strings some translations are not entirely complete. The Chinese (Simple and Traditional), Czech, Dutch, French, German, Norwegian, Polish, Romanian, Russian, Spanish, Swedish and Turkish translations are close to be complete. Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, order extensions or support or more general by donating money to the Free Software movement (e.g. http://www.fsfeurope.org/help/donate.en.html). Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by gpg's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. A service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team (David, Werner and the other contributors) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 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 wk at gnupg.org Mon Oct 18 15:30:14 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Oct 2010 15:30:14 +0200 Subject: IMPORT_RES In-Reply-To: (Nicholas Cole's message of "Fri, 9 Jul 2010 18:49:20 +0100") References: Message-ID: <87aambzl09.fsf@vigenere.g10code.de> On Fri, 9 Jul 2010 19:49, nicholas.cole at gmail.com said: > But gpg actually produces 14 numbers. Looking at the source code, the > extra number is for , which is the penultimate Right, the docs are wrong. Fixed in trunk. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From smujohnson at gmail.com Tue Oct 19 22:42:20 2010 From: smujohnson at gmail.com (smu johnson) Date: Tue, 19 Oct 2010 13:42:20 -0700 Subject: SHA1 being used despite public key preferences Message-ID: Hello, I wish to bring up a serious issue I hope will get some discussion. I'll try to be "to the point" in hopes more people read this. I have posted about this before, but AFAIK, none of the developers for GnuPG saw it. Some facts: 1) SHA-1 was considered broken by Bruce Schneier in 2005. http://www.schneier.com/blog/archives/2005/02/sha1_broken.html 2) An attack with a complexity of 2^51 was published in 2008 for collisions. http://eprint.iacr.org/2008/469.pdf 3) The 2010 book "Cryptography Engineering" recommends people do NOT use SHA-1. So, why are we still using SHA-1 in GnuPG? Worse yet, why is GnuPG picking it as the default hash signing algorithm, when people like myself have taken the time to explicitly set SHA-2 to be used before SHA-1 in a public key pref? If I'm sending something to Joe with the "-se -r joe" arguments, I think it should look at Joe's public key preferences for the digest-algo. It already does this with the cipher-algo, so why not the digest? If Joe is paranoid enough to put SHA-2 algorithms first on his prefs, and they're being ignored... what is the security in that? No matter what he does, his requests are being ignored on any GnuPG default install from people sending him signed messages, unless he has to bother them with manually changing it to something else which would obviously be a very tiresome process, and likely the recipient of this instructions won't even care or know what Joe is talking about. Needless to say, it is very frustrating for Joe. This has been brought up a few times on this mailing list, but I haven't seen any of the coders really give any thoughts on the matter. Here is a screenshot I made proving that TWOFISH is being adhered to, but SHA-2 digests being ignored. I colour-coded it with MSPAINT to help you see the relevant stuff. Screenshot here: http://members.shaw.ca/smujohnson/img/gnupg-sha1-problem.png Some final words: This is not an argument to remove SHA-1 from GnuPG. I know that the OpenPGP rfc says it must have it. I'm simply saying that if people put it at the "back of the list", then it shouldn't still pick it first if the key preferences say otherwise. Although I would definitely be in favour of the OpenPGP standard changing to actually remove SHA-1, I doubt I have enough clout to single-handedly make that happen. The above solution would probably make me happy enough for a while. Or at the very least, it would be a step in the right direction. Thank you for reading. -- smu johnson -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshaw at jabberwocky.com Wed Oct 20 01:01:50 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 19 Oct 2010 19:01:50 -0400 Subject: SHA1 being used despite public key preferences In-Reply-To: References: Message-ID: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> On Oct 19, 2010, at 4:42 PM, smu johnson wrote: > Hello, > > I wish to bring up a serious issue I hope will get some discussion. I'll try to be "to the point" in hopes more people read this. I have posted about this before, but AFAIK, none of the developers for GnuPG saw it. > > Some facts: > > 1) SHA-1 was considered broken by Bruce Schneier in 2005. http://www.schneier.com/blog/archives/2005/02/sha1_broken.html > 2) An attack with a complexity of 2^51 was published in 2008 for collisions. http://eprint.iacr.org/2008/469.pdf > 3) The 2010 book "Cryptography Engineering" recommends people do NOT use SHA-1. > > So, why are we still using SHA-1 in GnuPG? Worse yet, why is GnuPG picking it as the default hash signing algorithm, when people like myself have taken the time to explicitly set SHA-2 to be used before SHA-1 in a public key pref? > > If I'm sending something to Joe with the "-se -r joe" arguments, I think it should look at Joe's public key preferences for the digest-algo. It already does this with the cipher-algo, so why not the digest? If Joe is paranoid enough to put SHA-2 algorithms first on his prefs, and they're being ignored... what is the security in that? Because the ultimate authority on which algorithms to use is the sender, not the receiver. Joe may *ask* for certain algorithms, but the sender must be both willing and able to use them. If the sender doesn't like SHA-256 (or whatever), Joe can't have it, even if he asks for it. In this particular case of the signing digest, GnuPG does in fact honor the preferences of the recipient, but for historical reasons, the only algorithm that the sender will allow is SHA-1 (thus effectively disabling the feature). The reason behind this is that old versions of GnuPG generated keys with a standard hash preference of RIPEMD/160 before SHA-1. When GnuPG got the ability to use that preference to decide which hash to pick, people who were expecting SHA-1 suddenly got RIPEMD/160. In order to not violate the law of least surprise, we stuck a SHA-1 preference in personal-digest-preferences. If you want to issue signatures using the choices of your recipient, put this in your gpg.conf: personal-digest-preferences none (i.e. you have no preference yourself, so allow the recipient to chose) Alternately, you can list whatever preferences you do have, and the recipient will be allowed to pick among them. David From dkg at fifthhorseman.net Wed Oct 20 19:02:57 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 20 Oct 2010 13:02:57 -0400 Subject: SHA1 being used despite public key preferences In-Reply-To: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> Message-ID: <4CBF20C1.5050802@fifthhorseman.net> On 10/19/2010 07:01 PM, David Shaw wrote: > In this particular case of the signing digest, GnuPG does in fact honor the > preferences of the recipient, but for historical reasons, the only algorithm > that the sender will allow is SHA-1 (thus effectively disabling the feature). > The reason behind this is that old versions of GnuPG generated keys with a > standard hash preference of RIPEMD/160 before SHA-1. When GnuPG got the ability > to use that preference to decide which hash to pick, people who were expecting > SHA-1 suddenly got RIPEMD/160. In order to not violate the law of least surprise, > we stuck a SHA-1 preference in personal-digest-preferences. Thanks for explaining the historical background, David. So it sounds like people had published preferences in their public keys stating a preference for RIPEMD160 over SHA1, and then they were surprised to get signed docs that used RIPEMD160? That strikes me as a strange thing to be surprised by, given that they presumably would have had to explicitly change their published digest preferences (e.g. with --edit-key setpref). Anyway, it looks like the outcome of this decision is documented as the default for personal-digest-preferences in gpg(1): >> --personal-digest-preferences string >> Set the list of personal digest preferences to string. Use gpg >> --version to get a list of available algorithms, and use none to >> set no preference at all. This allows the user to safely over? >> ride the algorithm chosen by the recipient key preferences, as >> GPG will only select an algorithm that is usable by all recipi? >> ents. The most highly ranked digest algorithm in this list is >> also used when signing without encryption (e.g. --clearsign or >> --sign). The default value is SHA-1. given that the --default-preference-list for GnuPG (that is, the default for selfcert-published preferences for each newly-created key) now lists at least one SHA-2 algorithm (SHA-256) ahead of SHA-1, perhaps it would make more sense for the default --personal-digest-preferences to be updated to match? I personally think that the --personal-digest-preferences should default to the strongest supported algorithm: SHA512 SHA384 SHA256 SHA224 SHA1 The current --default-preference-list defaults for digest algorithms are: SHA256 SHA1 SHA384 SHA512 SHA224 While i continue to think this sequence of digest algorithms is not the ideal for --default-preference-list [0], i think it is a better --personal-digest-preferences than the current default value of "SHA1". geez, these options are confusing. I *think* i got all the names referring to the things i intended in the text above :p --dkg [0] http://article.gmane.org/gmane.comp.encryption.gpg.devel/15399 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed Oct 20 19:29:45 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 20 Oct 2010 13:29:45 -0400 Subject: SHA1 being used despite public key preferences In-Reply-To: <4CBF20C1.5050802@fifthhorseman.net> References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> <4CBF20C1.5050802@fifthhorseman.net> Message-ID: <4CBF2709.6020301@sixdemonbag.org> On 10/20/2010 1:02 PM, Daniel Kahn Gillmor wrote: > I personally think that the --personal-digest-preferences should default > to the strongest supported algorithm: Why? SHA224+ is required for DSA-2k; SHA256+ is required for DSA-3k. If SHA256 is the official NIST recommendation for DSA-3k, why should we default to SHA512? Ultimately this amounts to bikeshedding -- SHA256 will do the job perfectly well, as will SHA512. My question, though, is sincere: although I have a natural aversion to going past NIST recommendations just to be able to say we're using stronger crypto fairy dust, I think it's quite possible there are other factors you're considering that I'm unaware of. (On the larger point, that of replacing SHA-1 with a stronger hash wherever possible, I am in full agreement.) From dshaw at jabberwocky.com Wed Oct 20 20:52:34 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 20 Oct 2010 14:52:34 -0400 Subject: SHA1 being used despite public key preferences In-Reply-To: <4CBF20C1.5050802@fifthhorseman.net> References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> <4CBF20C1.5050802@fifthhorseman.net> Message-ID: On Oct 20, 2010, at 1:02 PM, Daniel Kahn Gillmor wrote: > On 10/19/2010 07:01 PM, David Shaw wrote: >> In this particular case of the signing digest, GnuPG does in fact honor the >> preferences of the recipient, but for historical reasons, the only > algorithm >> that the sender will allow is SHA-1 (thus effectively disabling the > feature). >> The reason behind this is that old versions of GnuPG generated keys with a >> standard hash preference of RIPEMD/160 before SHA-1. When GnuPG got > the ability >> to use that preference to decide which hash to pick, people who were expecting >> SHA-1 suddenly got RIPEMD/160. In order to not violate the law of > least surprise, >> we stuck a SHA-1 preference in personal-digest-preferences. > > Thanks for explaining the historical background, David. So it sounds > like people had published preferences in their public keys stating a > preference for RIPEMD160 over SHA1, and then they were surprised to get > signed docs that used RIPEMD160? That strikes me as a strange thing to > be surprised by, given that they presumably would have had to explicitly > change their published digest preferences (e.g. with --edit-key setpref). GnuPG itself defaulted to "RIPEMD/160 SHA-1" when generating keys. The surprise was from those people who hadn't changed anything on their key - one day they were using SHA-1, then after upgrading GnuPG to the version that actually made use of the hash preferences, they would suddenly find themselves using RIPEMD/160. > given that the --default-preference-list for GnuPG (that is, the default > for selfcert-published preferences for each newly-created key) now lists > at least one SHA-2 algorithm (SHA-256) ahead of SHA-1, perhaps it would > make more sense for the default --personal-digest-preferences to be > updated to match? > > I personally think that the --personal-digest-preferences should default > to the strongest supported algorithm: > > SHA512 SHA384 SHA256 SHA224 SHA1 > > The current --default-preference-list defaults for digest algorithms are: > > SHA256 SHA1 SHA384 SHA512 SHA224 Isn't this sort of saying one thing with default-preference-list ("these are our ranked ordering of hashes..."), and then saying something else with personal-digest-preferences ("...but ignore that ranking and use this ranking instead") ? I'm not yet convinced a change is necessary here, but if something really needs to change, I would say that a better answer would be to make personal-digest-preferences not default to anything at all. This would make it match the other personal-XXX-preferences, and allow the recipient keys to specify whatever the like (as is true for ciphers). If a user chooses to restrict this list further, that's up to them. (Note that this does not mean that people can request MD5 - MD5 is deprecated, so if the algorithm picking math settles on MD5, and SHA-1 is also available, we'll use SHA-1). David From smujohnson at gmail.com Wed Oct 20 21:08:29 2010 From: smujohnson at gmail.com (smu johnson) Date: Wed, 20 Oct 2010 12:08:29 -0700 Subject: SHA1 being used despite public key preferences In-Reply-To: References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> <4CBF20C1.5050802@fifthhorseman.net> Message-ID: Hi, On Wed, Oct 20, 2010 at 11:52 AM, David Shaw wrote: > > GnuPG itself defaulted to "RIPEMD/160 SHA-1" when generating keys. The > surprise was from those people who hadn't changed anything on their key - > one day they were using SHA-1, then after upgrading GnuPG to the version > that actually made use of the hash preferences, they would suddenly find > themselves using RIPEMD/160. > > Sure, this is confusing, but since experts such as Bruce Schneier say to quit using SHA-1, I don't think this is a good enough reason to justify using to a broken algorithm. Maybe it was set up beforehand and simply hasn't changed yet... if so, this is the reason for the thread I started, and I am not blaming anyone. > I'm not yet convinced a change is necessary here, but if something really > needs to change, I would say that a better answer would be to make > personal-digest-preferences not default to anything at all. This would make > it match the other personal-XXX-preferences, and allow the recipient keys to > specify whatever the like (as is true for ciphers). If a user chooses to > restrict this list further, that's up to them. > This is my favourite solution. This way, I won't have to ask every single newcomer to GnuPG sending me signed messages to request my key prefs for digest algorithms. I do think the change is necessary however... simply because of the reason I gave above. If someone like Bruce Schneier said to change it in 2005 and 2010, and he's not the only one to agree on this point, and because he obviously knows way more about cryptography security than I do... then the need for change sounds like a no-brainer to me. If that isn't enough, what about the paper published in 2008 showing 2^51 complexity for a collision? With those reasons, I can't think of a single case for defaulting to SHA-1 in this day-and-age... even if it might cause a small amount of confusion for some people. I think it's worth the price. The people who it might confuse might learn to update their prefs anyway... all I see is good coming from that change. It might educate some people a bit on the safe hashes to use in 2010, I don't know. Thanks for your continued input. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Wed Oct 20 21:33:27 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 20 Oct 2010 15:33:27 -0400 Subject: SHA1 being used despite public key preferences In-Reply-To: References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> <4CBF20C1.5050802@fifthhorseman.net> Message-ID: <4CBF4407.70700@sixdemonbag.org> On 10/20/2010 3:08 PM, smu johnson wrote: > Sure, this is confusing, but since experts such as Bruce Schneier > say to quit using SHA-1... I like Bruce, and I think he does good work -- but appealing to authority here is simply a non-starter. In real-world systems you can't simply stop using an algorithm cold and start using something new. The overwhelming majority of times you have to establish a migration path to allow the system to continue operating as new capabilities are added to it and old capabilities removed. This process can take decades. Consider, e.g., that MD5 is still supported in GnuPG today -- it's hard for me to think of a hash algorithm more deprecated than MD5 (maybe, what, MD2, MD4?), but we've still got to support MD5. Maybe someday we can remove MD5 support altogether, but that won't be happening for a while yet. > This is my favourite solution. This way, I won't have to ask every > single newcomer to GnuPG sending me signed messages to request my key > prefs for digest algorithms. Why should your preferences affect what algorithms they elect to use for their signatures? That would be like telling me, "Rob, I like WHIRLPOOL. Therefore, use WHIRLPOOL when signing data." To heck with that: I'm going to use SHA256, or whatever algorithm I like. From smujohnson at gmail.com Wed Oct 20 21:45:31 2010 From: smujohnson at gmail.com (smu johnson) Date: Wed, 20 Oct 2010 12:45:31 -0700 Subject: SHA1 being used despite public key preferences In-Reply-To: <4CBF4407.70700@sixdemonbag.org> References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> <4CBF20C1.5050802@fifthhorseman.net> <4CBF4407.70700@sixdemonbag.org> Message-ID: On Wed, Oct 20, 2010 at 12:33 PM, Robert J. Hansen wrote: > On 10/20/2010 3:08 PM, smu johnson wrote: > > Sure, this is confusing, but since experts such as Bruce Schneier > > say to quit using SHA-1... > > I like Bruce, and I think he does good work -- but appealing to > authority here is simply a non-starter. > I think it makes perfect sense. An expert says not to use SHA-1 and gives a good argument. To me, it seems like it's okay in this case. > > In real-world systems you can't simply stop using an algorithm cold and > start using something new. The overwhelming majority of times you have > to establish a migration path to allow the system to continue operating > as new capabilities are added to it and old capabilities removed. > > That may be true for a lot of systems but as we've seen from responses it seems like an easy change in GnuPG's case. > > Why should your preferences affect what algorithms they elect to use for > their signatures? That would be like telling me, "Rob, I like > WHIRLPOOL. Therefore, use WHIRLPOOL when signing data." To heck > with that: I'm going to use SHA256, or whatever algorithm I like. > I didn't say there is a problem with that. In fact, the solution I agreed on still lets you do that. I'm talking about the people who simply don't care and install GnuPG with the default settings, and use it from that point on without changing anything. In that case, which I believe is a huge majority, the prefs you picked in your public key will be used by default instead of SHA-1. If you want to do use something else, the freedom is still there, and I haven't once said on this thread that we should disallow that. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Oct 20 22:11:03 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 20 Oct 2010 16:11:03 -0400 Subject: SHA1 being used despite public key preferences In-Reply-To: References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> <4CBF20C1.5050802@fifthhorseman.net> Message-ID: <4CBF4CD7.1080303@fifthhorseman.net> On 10/20/2010 02:52 PM, David Shaw wrote: > GnuPG itself defaulted to "RIPEMD/160 SHA-1" when generating keys. The surprise was from those people who hadn't changed anything on their key - one day they were using SHA-1, then after upgrading GnuPG to the version that actually made use of the hash preferences, they would suddenly find themselves using RIPEMD/160. If it's a key that people had been using already, then upgrading gpg wouldn't affect their key's published preferences -- they'd have to manually adjust that themselves. So it sounds to me like you're saying people were surprised that they were suddenly respecting *other* people's stated preferences for digest algorithms that their OpenPGP implementation happens to support. That doesn't seem too bad to me. I'd call that a featureful upgrade :) > [dkg wrote:] >> I personally think that the --personal-digest-preferences should default >> to the strongest supported algorithm: >> >> SHA512 SHA384 SHA256 SHA224 SHA1 >> >> The current --default-preference-list defaults for digest algorithms are: >> >> SHA256 SHA1 SHA384 SHA512 SHA224 > > Isn't this sort of saying one thing with default-preference-list ("these are our ranked ordering of hashes..."), and then saying something else with personal-digest-preferences ("...but ignore that ranking and use this ranking instead") ? let me see if i've got this right: default-preference-list determines what the stated preference should be, which is published in the self-sig on the user's own key. That is, it's for other people who want to sign things for me to verify. For example, on my key, it answers the question "what digest would dkg prefer people to use when sending him signed mail?" personal-digest-preferences determines what digests the *user* would prefer to use. In my own GnuPG configuration, it says "which digests would i prefer to make signatures over?" The choice of a digest for any particular signature takes into account the published preferences of the recipients, along with the --personal-digest-preferences of the signer. I personally have mine set to the same thing -- that is, i prefer to receive signatures made with stronger digests, and i prefer to *make* signatures with stronger digests. I think that's reasonable. However, GnuPG's current --default-preference-list says "i prefer to receive signatures made with SHA1 over signatures made with SHA512 (or SHA384 or SHA224)". I think this is a mistake -- if the signing party for whatever reason prefers not to use SHA256, we are asking them to fall back to a known-weaker algorithm, even if they have a known-stronger algorithm available. It would likewise be a mistake to have the personal-digest-preferences rank SHA1 ahead of any stronger digest, particularly since SHA1 is universally implemented. In effect, using "SHA256 SHA1 SHA384 SHA512 SHA224" for the default personal-digest-preferences would say "never make any signatures using SHA384, SHA512, or SHA224, even if the recipient supports these digests". So yes: i support having these orderings be the same; but i'd rather that we not list stronger algorithms as lower-rated than the universally-implemented-but-weakening SHA1. I'd prefer to have inconsistent internal defaults than to propagate what i see as a suboptimal ordering from --default-preference-list into --personal-digest-preferences. I'd be even happier to have them both align, and list all the SHA-2 family ahead of SHA-1 (in whatever order). > I'm not yet convinced a change is necessary here, but if something really needs to change, I would say that a better answer would be to make personal-digest-preferences not default to anything at all. This would make it match the other personal-XXX-preferences, and allow the recipient keys to specify whatever the like (as is true for ciphers). If a user chooses to restrict this list further, that's up to them. That seems like an acceptable decision to me, though i'd prefer something that more strongly defaults to something stronger than SHA-1. i imagine most GnuPG users (were they aware of the choice) would prefer to make signatures using digests stronger than SHA-1 where acceptable, even if (for whatever reason) the recipient claims to prefer SHA-1 over digests from the SHA-2 family. > (Note that this does not mean that people can request MD5 - MD5 is deprecated, so if the algorithm picking math settles on MD5, and SHA-1 is also available, we'll use SHA-1). yup, that's good. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed Oct 20 23:48:00 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 20 Oct 2010 17:48:00 -0400 Subject: SHA1 being used despite public key preferences In-Reply-To: <4CBF57A1.80206@Mozilla-Enigmail.org> References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> <4CBF20C1.5050802@fifthhorseman.net> <4CBF4407.70700@sixdemonbag.org> <4CBF57A1.80206@Mozilla-Enigmail.org> Message-ID: <4CBF6390.1060508@sixdemonbag.org> On 10/20/2010 4:57 PM, John Clizbe wrote: > One other little thing I got from our IETF friend Jeff: MD5 and SHA1 > are both hard-wired into a BUNCH of silicon as well as required by a > lot of protocols. THAT is the sort of change that will require > decades. As another example, MD5 is still /the/ hash algorithm of choice for digital forensics. There are a ton of judicial opinions recognizing MD5's capabilities, and so far none recognizing its limitations -- so if you want to present evidence ("the images found on the defendant's hard drive matched MD5s of images in the National Exploited Children Imagery Database"), you do it with MD5. There's some push afoot to move to SHA256, but this is being heavily resisted by prosecutors. Their attitude is simple: why should they risk a conviction on introducing a new kind of digital evidence in court, when they can use an older and more accepted method that has exactly zero opinions advising against its use? I often hear people talk about the need for pragmatism, but really, we have to be even more pragmatic than that. We have to be wise enough to balance *our* pragmatic concerns with *our users'* pragmatic concerns. The two will rarely be identical, but if we're lucky we can find solutions that target both. From John at Mozilla-Enigmail.org Wed Oct 20 22:57:05 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Wed, 20 Oct 2010 15:57:05 -0500 Subject: SHA1 being used despite public key preferences In-Reply-To: <4CBF4407.70700@sixdemonbag.org> References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> <4CBF20C1.5050802@fifthhorseman.net> <4CBF4407.70700@sixdemonbag.org> Message-ID: <4CBF57A1.80206@Mozilla-Enigmail.org> Robert J. Hansen wrote: > On 10/20/2010 3:08 PM, smu johnson wrote: >> Sure, this is confusing, but since experts such as Bruce Schneier >> say to quit using SHA-1... > > I like Bruce, and I think he does good work -- but appealing to > authority here is simply a non-starter. > > In real-world systems you can't simply stop using an algorithm cold and > start using something new. The overwhelming majority of times you have > to establish a migration path to allow the system to continue operating > as new capabilities are added to it and old capabilities removed. Exactly Rob, there are still a lot of users out there whose PGP software cannot handle the SHA-2 hashes. We shouldn't just throw them overboard and sail on. I like Bruce too, but I think the recommendation being cited should be extended with the clause "/for new work/". I have always sensed a strong sense of pragmatism in the advice from the crypto gurus. I think it's well recommended here as well. > This process can take decades. Consider, e.g., that MD5 is still > supported in GnuPG today -- it's hard for me to think of a hash > algorithm more deprecated than MD5 (maybe, what, MD2, MD4?), but we've > still got to support MD5. Maybe someday we can remove MD5 support > altogether, but that won't be happening for a while yet. One other little thing I got from our IETF friend Jeff: MD5 and SHA1 are both hard-wired into a BUNCH of silicon as well as required by a lot of protocols. THAT is the sort of change that will require decades. -John -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 499 bytes Desc: OpenPGP digital signature URL: From smujohnson at gmail.com Thu Oct 21 00:38:28 2010 From: smujohnson at gmail.com (smu johnson) Date: Wed, 20 Oct 2010 15:38:28 -0700 Subject: SHA1 being used despite public key preferences In-Reply-To: <4CBF57A1.80206@Mozilla-Enigmail.org> References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> <4CBF20C1.5050802@fifthhorseman.net> <4CBF4407.70700@sixdemonbag.org> <4CBF57A1.80206@Mozilla-Enigmail.org> Message-ID: On Wed, Oct 20, 2010 at 1:57 PM, John Clizbe wrote: > Robert J. Hansen wrote: > > On 10/20/2010 3:08 PM, smu johnson wrote: > > > In real-world systems you can't simply stop using an algorithm cold and > > start using something new. The overwhelming majority of times you have > > to establish a migration path to allow the system to continue operating > > as new capabilities are added to it and old capabilities removed. > > Exactly Rob, there are still a lot of users out there whose PGP software > cannot > handle the SHA-2 hashes. We shouldn't just throw them overboard and sail > on. > > With the solution I mentioned and David Shaw mentioned, namely: "... I would say that a better answer would be to make personal-digest-preferences not default to anything at all.", this wouldn't be an issue at all. It would look at the PGP user's prefs to pick one, if nothing was defaulted out-of-the-box. This also solves Roberts concern, where he said hypothetically "To heck with that: I'm going to use SHA256, or whatever algorithm I like.". If you want to use whatever you like, setting the "personal-digest-preferences" from nothing to whatever you like solves this. > > One other little thing I got from our IETF friend Jeff: MD5 and SHA1 are > both > hard-wired into a BUNCH of silicon as well as required by a lot of > protocols. > THAT is the sort of change that will require decades. > I'm not sure how this is related. Maybe I'm interrupting a different subject discussion? If not, all I'm suggesting is the default out-of-the-box GnuPG install does not default to anything for personal digest preferences. I'm not suggesting we remove any digests from GnuPG. I'm not suggesting that public keyprefs override personal preferences. Lastly, I'm not sure how the hardware issues are a concern for this suggested GnuPG change. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Oct 21 03:57:12 2010 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 21 Oct 2010 10:57:12 +0900 Subject: authentication subkey Message-ID: <4CBF9DF8.7040805@fsij.org> Now, Gnuk[0] supports the "INTERNAL AUTHENTICATE" command of OpenPGP card protocol 2.0. While I tested the "INTERNAL AUTHENTICATE" command, I generated authentication subkey, using monkeysphere[1]. Reading "Use OpenPGP Keys for OpenSSH, how to use gpg with ssh" [2], I can use Gnuk Token for OpenSSH authentication. Then, I found that it is possible for GnuPG to generate authentication subkey with --expert option. Does this mean using GnuPG for authentication is not that popular? Anyhow, I am happyly using GnuPG authentication subkey for OpenSSH. [0] http://www.fsij.org/gnuk/ [1] http://web.monkeysphere.info/ [2] http://www.programmierecke.net/howto/gpg-ssh.html -- From dshaw at jabberwocky.com Thu Oct 21 04:41:03 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 20 Oct 2010 22:41:03 -0400 Subject: SHA1 being used despite public key preferences In-Reply-To: <4CBF4407.70700@sixdemonbag.org> References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> <4CBF20C1.5050802@fifthhorseman.net> <4CBF4407.70700@sixdemonbag.org> Message-ID: <9E82A4AB-7637-4136-94E9-84177A9B9AAF@jabberwocky.com> On Oct 20, 2010, at 3:33 PM, Robert J. Hansen wrote: > On 10/20/2010 3:08 PM, smu johnson wrote: >> Sure, this is confusing, but since experts such as Bruce Schneier >> say to quit using SHA-1... > > I like Bruce, and I think he does good work -- but appealing to > authority here is simply a non-starter. > > In real-world systems you can't simply stop using an algorithm cold and > start using something new. The overwhelming majority of times you have > to establish a migration path to allow the system to continue operating > as new capabilities are added to it and old capabilities removed. There is not an issue here about removing algorithms. There is no way to remove SHA-1 without serious work, and nobody is suggesting such a thing here (nor would it even make sense to discuss it here rather than on the IETF list anyway). This is more of a question as to the most generally useful default for signing: a) SHA-1 (current behavior) b) No preference (allows recipient to pick from available algorithms, including SHA-1, and defaulting to SHA-1 in case of disagreement) c) Something else (a) is current behavior. I can see a reasonable case for (b) to help spread the use of other algorithms. I'd love to hear about anyone's (c), especially if it is better than (a) or (b). This is, of course, only the default behavior. The signer is always free to change it to something they prefer. > This process can take decades. Consider, e.g., that MD5 is still > supported in GnuPG today -- it's hard for me to think of a hash > algorithm more deprecated than MD5 (maybe, what, MD2, MD4?), but we've > still got to support MD5. Maybe someday we can remove MD5 support > altogether, but that won't be happening for a while yet. > >> This is my favourite solution. This way, I won't have to ask every >> single newcomer to GnuPG sending me signed messages to request my key >> prefs for digest algorithms. > > Why should your preferences affect what algorithms they elect to use for > their signatures? That would be like telling me, "Rob, I like > WHIRLPOOL. Therefore, use WHIRLPOOL when signing data." To heck > with that: I'm going to use SHA256, or whatever algorithm I like. Well, sure. You're the one originating the message, so you get to do whatever you like. The recipient can only tell you what they can understand, and within that set, which they like the best. You don't have to listen to them, but in some cases (like if they are telling you they can't understand a particular algorithm), you're best served by taking their information into consideration. David From dshaw at jabberwocky.com Thu Oct 21 04:56:24 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 20 Oct 2010 22:56:24 -0400 Subject: SHA1 being used despite public key preferences In-Reply-To: <4CBF4CD7.1080303@fifthhorseman.net> References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> <4CBF20C1.5050802@fifthhorseman.net> <4CBF4CD7.1080303@fifthhorseman.net> Message-ID: <99EC4931-8867-438B-9D4F-9340DD5E8E69@jabberwocky.com> On Oct 20, 2010, at 4:11 PM, Daniel Kahn Gillmor wrote: > On 10/20/2010 02:52 PM, David Shaw wrote: >> GnuPG itself defaulted to "RIPEMD/160 SHA-1" when generating keys. The surprise was from those people who hadn't changed anything on their key - one day they were using SHA-1, then after upgrading GnuPG to the version that actually made use of the hash preferences, they would suddenly find themselves using RIPEMD/160. > So it sounds to me like you're saying people were surprised that they > were suddenly respecting *other* people's stated preferences for digest > algorithms that their OpenPGP implementation happens to support. Yes, exactly. I meant it as "...find themselves using RIPEMD/160 when issuing signatures for those recipients". > let me see if i've got this right: > > default-preference-list determines what the stated preference should be, > which is published in the self-sig on the user's own key. That is, it's > for other people who want to sign things for me to verify. For example, > on my key, it answers the question "what digest would dkg prefer people > to use when sending him signed mail?" Yes. > personal-digest-preferences determines what digests the *user* would > prefer to use. In my own GnuPG configuration, it says "which digests > would i prefer to make signatures over?" Yes. > The choice of a digest for any particular signature takes into account > the published preferences of the recipients, along with the > --personal-digest-preferences of the signer. Yes, that's it. The algorithm works by finding all of the digest algorithms that are listed for all recipients. SHA-1 is always part of this set, even if nobody explicitly lists it. Then, if the signer has personal-digest-preferences set, we work our way down that list in ranked order until we find an algorithm that is in the set and is usable at all (remember that a large DSA key can't use smaller hashes). If the signer does not have personal-digest-preferences set, we pick the most highly ranked usable algorithm for all the recipients (i.e. we try and make the recipients happy by picking their more-favored algorithms rather than their least-favored). The end result of this guarantees that a) we pick an algorithm that everyone can handle, and b) we pick what the sender desires, if the sender expresses an opinion, and a generally high-ranked algorithm otherwise. David From dshaw at jabberwocky.com Thu Oct 21 04:59:20 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 20 Oct 2010 22:59:20 -0400 Subject: SHA1 being used despite public key preferences In-Reply-To: <4CBF57A1.80206@Mozilla-Enigmail.org> References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> <4CBF20C1.5050802@fifthhorseman.net> <4CBF4407.70700@sixdemonbag.org> <4CBF57A1.80206@Mozilla-Enigmail.org> Message-ID: <883D6385-6284-4303-A2AE-B2C0F34F36CD@jabberwocky.com> On Oct 20, 2010, at 4:57 PM, John Clizbe wrote: > Robert J. Hansen wrote: >> On 10/20/2010 3:08 PM, smu johnson wrote: >>> Sure, this is confusing, but since experts such as Bruce Schneier >>> say to quit using SHA-1... >> >> I like Bruce, and I think he does good work -- but appealing to >> authority here is simply a non-starter. >> >> In real-world systems you can't simply stop using an algorithm cold and >> start using something new. The overwhelming majority of times you have >> to establish a migration path to allow the system to continue operating >> as new capabilities are added to it and old capabilities removed. > > Exactly Rob, there are still a lot of users out there whose PGP software cannot > handle the SHA-2 hashes. We shouldn't just throw them overboard and sail on. The preferences system handles this case automatically. If one of these users is a recipient, then the new hashes will not be used. If one of these users is the signer, then (naturally) the new hashes will not be used. New hashes are only used if both the sender and recipients agree they can handle them. David From smujohnson at gmail.com Thu Oct 21 11:16:11 2010 From: smujohnson at gmail.com (smu johnson) Date: Thu, 21 Oct 2010 02:16:11 -0700 Subject: SHA1 being used despite public key preferences In-Reply-To: <4A95670D-F78E-4C44-8DD1-A2635AB01C67@sixdemonbag.org> References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> <4CBF20C1.5050802@fifthhorseman.net> <4CBF4407.70700@sixdemonbag.org> <4A95670D-F78E-4C44-8DD1-A2635AB01C67@sixdemonbag.org> Message-ID: On Wed, Oct 20, 2010 at 6:50 PM, Robert J. Hansen wrote: > The problem comes from saying, "well, Bruce says?". > > A good argument stands on its own legs: it doesn't rely on any external > authority for its soundness. A lot of people in the crypto community are > extraordinarily sensitive to what's called "appeal to authority" ? since > this one person says so, it must be so. It's far better to give an argument > that stands on its own, rather than appeal to "it's what Bruce says." > > Two things. First, "Bruce says.." was meant to be sort of like a bibliography, when you try to find experts in the field who have said the same things you are saying. Usually it's good to give a bit of evidence for some of the arguments you are making. It is at least a better argument than me writing to the list without anything to back it up. So, I quoted some stuff Bruce said. Would you go around telling people who have citations in bibliographic form that "A good argument stands on its own legs: it doesn't rely on any external authority for its soundness."? Second thing: I already gave a good argument. Let's forget what Bruce said. And forget that I gave him as source. Let's go back to the basic message: SHA-1 is broken. It has been public knowledge for 5 years, and 2 years ago, a better attack was published. That is the basis for this whole thread, more or less. Ignore everything else I've said, except this one thing: SHA-1 is broken. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Oct 21 11:24:13 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Oct 2010 11:24:13 +0200 Subject: authentication subkey In-Reply-To: <4CBF9DF8.7040805@fsij.org> (NIIBE Yutaka's message of "Thu, 21 Oct 2010 10:57:12 +0900") References: <4CBF9DF8.7040805@fsij.org> Message-ID: <87y69rucea.fsf@vigenere.g10code.de> On Thu, 21 Oct 2010 03:57, gniibe at fsij.org said: > Then, I found that it is possible for GnuPG to generate authentication > subkey with --expert option. Does this mean using GnuPG for > authentication is not that popular? I don't know. If you use one of the OpenPGP smartcards the default is to create a signing main key, an encryption subkey and an authentication subkey. Thus there should be some authentication subkeys out there. Regarding ssh, there is no actual need for gpg. You can use it but it is not required because usually you import an existing ssh key into gpg-agent. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Thu Oct 21 16:18:58 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 21 Oct 2010 10:18:58 -0400 Subject: monkeysphere [was: Re: authentication subkey] In-Reply-To: <87y69rucea.fsf@vigenere.g10code.de> References: <4CBF9DF8.7040805@fsij.org> <87y69rucea.fsf@vigenere.g10code.de> Message-ID: <4CC04BD2.9060105@fifthhorseman.net> On 10/21/2010 05:24 AM, Werner Koch wrote: > Regarding ssh, there is no actual need for gpg. You can use it but it > is not required because usually you import an existing ssh key into > gpg-agent. To be clear, Monkeysphere uses GnuPG to have the SSH RSA key bound to the user's OpenPGP identity. Monkeysphere uses this to allow service administrators to enable access to services by User ID (and to permit re-keying, revocation, expiration, etc), using the WoT as the certificate verification mechanism (and the keyservers as a certificate distribution system). Monkeysphere also works to let users identify servers (any ssh and https server at the moment) through the OpenPGP web of trust. Here's how to publish your services' keys if you're interested: http://www.debian-administration.org/article/660/Publishing_host_services_to_OpenPGP_with_Monkeysphere Regards, --dkg, one of the monkeysphere upstream developers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From jrollins at finestructure.net Thu Oct 21 15:39:28 2010 From: jrollins at finestructure.net (Jameson Rollins) Date: Thu, 21 Oct 2010 09:39:28 -0400 Subject: authentication subkey In-Reply-To: <87y69rucea.fsf@vigenere.g10code.de> References: <4CBF9DF8.7040805@fsij.org> <87y69rucea.fsf@vigenere.g10code.de> Message-ID: <87bp6nd5rj.fsf@servo.finestructure.net> On Thu, 21 Oct 2010 11:24:13 +0200, Werner Koch wrote: > Regarding ssh, there is no actual need for gpg. You can use it but it > is not required because usually you import an existing ssh key into > gpg-agent. Hi, Werner. There is need for authentication subkeys with Monkeysphere [0]. The point of Monkeysphere is to use OpenPGP and the Web of Trust as a PKI for ssh. So it therefore uses OpenPGP authentication subkeys as ssh keys, affording users the ability to set expiration dates on them, expire them, more easily rekey them, etc. jamie. [0] http://web.monkeysphere.info/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From jason.woodward at timesys.com Fri Oct 22 01:37:12 2010 From: jason.woodward at timesys.com (Woodward, Jason) Date: Thu, 21 Oct 2010 19:37:12 -0400 Subject: patch for gnupg 1.4.11 on mips Message-ID: The attached fixes a typo in longlong.h for a mips32 check and updates the mips64 asm to account for the deprecated =h constraint (derived from mpfr sources). thanks, jason woodward -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-1.4.11-mips_asm.patch Type: application/octet-stream Size: 1869 bytes Desc: gnupg-1.4.11-mips_asm.patch URL: From wk at gnupg.org Fri Oct 22 09:28:22 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Oct 2010 09:28:22 +0200 Subject: patch for gnupg 1.4.11 on mips In-Reply-To: (Jason Woodward's message of "Thu, 21 Oct 2010 19:37:12 -0400") References: Message-ID: <87d3r2u1nt.fsf@vigenere.g10code.de> On Fri, 22 Oct 2010 01:37, jason.woodward at timesys.com said: > The attached fixes a typo in longlong.h for a mips32 check and updates the mips64 asm to account for the deprecated =h constraint (derived from mpfr sources). Thanks. I changed it to use #elif instead. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Sat Oct 23 04:53:44 2010 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 23 Oct 2010 11:53:44 +0900 Subject: Gnuk version 0.3 Message-ID: <4CC24E38.9080700@fsij.org> Gnuk is a software for USB Token which follows OpenPGP card protocol. I just release version 0.3 of Gnuk at: http://www.gniibe.org/oitoite/gnuk/ Highlights are: * Authentication key is supported. * Added 'configure' to select targets and features. * Added target support of CQ STARM and STBee Mini. * DFU (Device Firmware Update) Support is added for them. * Bug fixes. DFU support is added, that would be important. Now, people just get CQ STARM, STBee Mini (or other boards like that) and can test Gnuk with no JTAG debugger. Unfortunately, it seems (for me) that there is no good Free Software tool which supports DFU of STM32. Perhaps, I will need to write a DFU tool by myself. I am new to STM32, please let me know if I'm wrong. Please visit http://www.fsij.org/gnuk/ for Gnuk news. -- From wk at gnupg.org Tue Oct 26 18:32:34 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Oct 2010 18:32:34 +0200 Subject: GnuPG 2.1 beta released Message-ID: <87ocagzzh9.fsf@vigenere.g10code.de> Hello! We just released the first *beta version* of GnuPG 2.1. It has been released to give you the opportunity to check out the new features. It is marked as a beta versions and the plan is to release a couple more betas in the next months before we can declare 2.1.0 stable enough for general use. In any case the 2.1 series won't replace the 2.0 series. If you need stable and fully maintained version of GnuPG, you should in general use 2.0.x or even 1.4.x. Eventually we will release 2.2 as the new stable version but that may take some time. Noteworthy changes in version 2.1.0beta1 ======================================== * GPG does not anymore use secring.gpg but delegates all secret key operations to gpg-agent. The import command moves secret keys to the agent. * The OpenPGP import command is now able to merge secret keys. * The G13 tool for disk encryption key management has been added. * If the agent's --use-standard-socket option is active, all tools try to start and daemonize the agent on the fly. In the past this was only supported on W32; on non-W32 systems the new configure option --disable-standard-socket may now be used to disable this new default. * Dirmngr is now a part of this package. Dirmngr is now also expected to run as a system service and the configuration directories are changed to the GnuPG name space. * Removed GPG options: --export-options: export-secret-subkey-passwd --simple-sk-checksum * New GPG options: --try-secret-key * Support DNS lookups for SRV, PKA and CERT on W32. * The default for --include-cert is now to include all certificates in the chain except for the root certificate. * Numerical values may now be used as an alternative to the debug-level keywords. * New GPGSM option --ignore-cert-extension. * Support for Windows CE. * Given sufficient permissions Dirmngr is started automagically. * Bug fixes. Migration from 1.4 or 2.0 ========================= The major change in 2.1 is that gpg-agent now takes care of the OpenPGP secret keys (those managed by GPG). The former secring.gpg will not be used anymore. Newly generated keys are generated and stored in the agent's key store (~/.gnupg/private-keys-v1.d/). To migrate your existing keys to the agent you should run this command gpg2 --import ~/.gnupg/secring.gpg The agent will you ask for the passphrase of each key. You may use the Cancel button of the Pinentry to skip importing this key. If you want to stop the import process and you use one of the latest pinentries, you should close the pinentry window instead of hitting the cancel button. Secret keys already imported are skipped by the import command. It is advisable to keep the secring.gpg for use with older versions of GPG. Note that gpg-agent now uses a fixed socket by default. All tools will start the gpg-agent as needed. In general there is no more need to set the GPG_AGENT_INFO environment variable. The SSH_AUTH_SOCK environment variable should be set to a fixed value. GPG's smartcard commands --card-edit and --card-status as well as the card related sub-commands of --edit-key are not yet supported. However, signing and decryption with a smartcard does work. The Dirmngr is now part of GnuPG proper. Thus there is no more need to install the separate dirmngr package. The directroy layout of Dirmngr changed to make use of the GnuPG directories; for example you use /etc/gnupg/trusted-certs and /var/lib/gnupg/extra-certs. Dirmngr needs to be started as a system daemon. Getting the Software ==================== GnuPG 2.1 is available at ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0beta1.tar.bz2 ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0beta1.tar.bz2.sig and soon on all mirrors . Note, that GnuPG is not available at ftp.gnu.org. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * You are expected to have a trusted version of GnuPG installed, thus you may simply check the supplied signature. For example to check the signature of the file gnupg-2.1.0.tar.bz2 you would use this command: gpg --verify gnupg-2.1.0.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a key server like gpg --recv-key 1CE0C630 The distribution key 1CE0C630 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! Internationalization ==================== This version comes only with support for English and German. More languages will be added for the real release. Documentation ============= We are currently working on an installation guide to explain in more detail how to configure the new features. As of now the chapters on gpg-agent and gpgsm include brief information on how to set up the whole thing. Please watch the GnuPG website for updates of the documentation. In the meantime you may search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Future Plans ============ Some taks we would like to do before a 2.1 release: * Re-enable full smartcard support * Add ECC algorithms to GPG * Replace the pubring.gpg public key store with the keybox format. Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or by donating money. Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. A service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From flameeyes at gmail.com Tue Oct 26 21:12:04 2010 From: flameeyes at gmail.com (Diego Elio =?ISO-8859-1?Q?Petten=F2?=) Date: Tue, 26 Oct 2010 21:12:04 +0200 Subject: GnuPG 2.1 beta released In-Reply-To: <87ocagzzh9.fsf@vigenere.g10code.de> References: <87ocagzzh9.fsf@vigenere.g10code.de> Message-ID: <1288120324.4076.103.camel@yamato.local> Il giorno mar, 26/10/2010 alle 18.32 +0200, Werner Koch ha scritto: > > Note that gpg-agent now uses a fixed socket by default. All tools > will start the gpg-agent as needed. In general there is no more need > to set the GPG_AGENT_INFO environment variable. The SSH_AUTH_SOCK > environment variable should be set to a fixed value. > Does it now respect TMPDIR environment variable as per GNU coding standards or does it still hardcode /tmp? > -- Diego Elio Petten? ? ?Flameeyes? http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From wk at gnupg.org Wed Oct 27 09:21:40 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 27 Oct 2010 09:21:40 +0200 Subject: GnuPG 2.1 beta released In-Reply-To: <1288120324.4076.103.camel@yamato.local> ("Diego Elio =?utf-8?Q?Petten=C3=B2=22's?= message of "Tue, 26 Oct 2010 21:12:04 +0200") References: <87ocagzzh9.fsf@vigenere.g10code.de> <1288120324.4076.103.camel@yamato.local> Message-ID: <878w1kyubf.fsf@vigenere.g10code.de> On Tue, 26 Oct 2010 21:12, flameeyes at gmail.com said: > Does it now respect TMPDIR environment variable as per GNU coding > standards or does it still hardcode /tmp? I didn't noticed that. Changed it right now. However, /tmp or TMPDIR is not anymore used by default. We start gpg-agent on demand and for that we need to use a fixed socket name. IT makes everything much easier. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From daniel.leidert.spam at gmx.net Wed Oct 27 18:02:48 2010 From: daniel.leidert.spam at gmx.net (Daniel Leidert) Date: Wed, 27 Oct 2010 18:02:48 +0200 Subject: [Fwd: failed mipsel build of gnupg 1.4.11-1] Message-ID: <1288195368.6580.1.camel@haktar.wgdd.de> There is a build failure for gnupg 1.4.11 on mipsel architecture: > gcc -DHAVE_CONFIG_H -I. -I../../mpi -I.. -I.. -I../../include -g -O2 -Wall -Wno-pointer-sign -MT mpih-cmp.o -MD -MP -MF .deps/mpih-cmp.Tpo -c -o mpih-cmp.o ../../mpi/mpih-cmp.c > mv -f .deps/mpih-cmp.Tpo .deps/mpih-cmp.Po > gcc -DHAVE_CONFIG_H -I. -I../../mpi -I.. -I.. -I../../include -g -O2 -Wall -Wno-pointer-sign -MT mpih-div.o -MD -MP -MF .deps/mpih-div.Tpo -c -o mpih-div.o ../../mpi/mpih-div.c > ../../mpi/mpih-div.c: In function 'mpihelp_mod_1': > ../../mpi/mpih-div.c:99: error: impossible constraint in 'asm' > ../../mpi/mpih-div.c:99: error: impossible constraint in 'asm' > ../../mpi/mpih-div.c:105: error: impossible constraint in 'asm' > ../../mpi/mpih-div.c:105: error: impossible constraint in 'asm' > ../../mpi/mpih-div.c:135: error: impossible constraint in 'asm' > ../../mpi/mpih-div.c:135: error: impossible constraint in 'asm' > make[3]: *** [mpih-div.o] Error 1 > make[3]: Leaving directory `/build/buildd-gnupg_1.4.11-1-mipsel-rhMw25/gnupg-1.4.11/build-deb/mpi' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/build/buildd-gnupg_1.4.11-1-mipsel-rhMw25/gnupg-1.4.11/build-deb' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/build/buildd-gnupg_1.4.11-1-mipsel-rhMw25/gnupg-1.4.11/build-deb' For the full build log see below. Regards, Daniel -------- Weitergeleitete Nachricht -------- > Von: Debian buildds > An: gnupg at packages.qa.debian.org > Betreff: failed mipsel build of gnupg 1.4.11-1 > Datum: Tue, 26 Oct 2010 23:00:06 +0000 > > * Source package: gnupg > * Version: 1.4.11-1 > * Architecture: mipsel > * State: failed > * Suite: experimental > * Builder: monteverdi.ayous.org > * Build log: https://buildd.debian.org/fetch.cgi?pkg=gnupg&arch=mipsel&ver=1.4.11-1&stamp=1288133918&file=log > > Please note that these notifications do not necessarily mean bug reports > in your package but could also be caused by other packages, temporary > uninstallabilities and arch-specific breakages. A look at the build log > despite this disclaimer would be appreciated however. > > From thijs at debian.org Wed Oct 27 20:31:47 2010 From: thijs at debian.org (Thijs Kinkhorst) Date: Wed, 27 Oct 2010 20:31:47 +0200 Subject: [Fwd: failed mipsel build of gnupg 1.4.11-1] In-Reply-To: <1288195368.6580.1.camel@haktar.wgdd.de> References: <1288195368.6580.1.camel@haktar.wgdd.de> Message-ID: <38c2f97697f247ffc39da188ba1edebf.squirrel@wm.kinkhorst.nl> On Wed, October 27, 2010 18:02, Daniel Leidert wrote: > There is a build failure for gnupg 1.4.11 on mipsel architecture: > >> gcc -DHAVE_CONFIG_H -I. -I../../mpi -I.. -I.. -I../../include -g -O2 >> -Wall -Wno-pointer-sign -MT mpih-cmp.o -MD -MP -MF .deps/mpih-cmp.Tpo -c >> -o mpih-cmp.o ../../mpi/mpih-cmp.c >> mv -f .deps/mpih-cmp.Tpo .deps/mpih-cmp.Po >> gcc -DHAVE_CONFIG_H -I. -I../../mpi -I.. -I.. -I../../include -g -O2 >> -Wall -Wno-pointer-sign -MT mpih-div.o -MD -MP -MF .deps/mpih-div.Tpo -c >> -o mpih-div.o ../../mpi/mpih-div.c >> ../../mpi/mpih-div.c: In function 'mpihelp_mod_1': >> ../../mpi/mpih-div.c:99: error: impossible constraint in 'asm' >> ../../mpi/mpih-div.c:99: error: impossible constraint in 'asm' >> ../../mpi/mpih-div.c:105: error: impossible constraint in 'asm' >> ../../mpi/mpih-div.c:105: error: impossible constraint in 'asm' >> ../../mpi/mpih-div.c:135: error: impossible constraint in 'asm' >> ../../mpi/mpih-div.c:135: error: impossible constraint in 'asm' >> make[3]: *** [mpih-div.o] Error 1 >> make[3]: Leaving directory >> `/build/buildd-gnupg_1.4.11-1-mipsel-rhMw25/gnupg-1.4.11/build-deb/mpi' >> make[2]: *** [all-recursive] Error 1 >> make[2]: Leaving directory >> `/build/buildd-gnupg_1.4.11-1-mipsel-rhMw25/gnupg-1.4.11/build-deb' >> make[1]: *** [all] Error 2 >> make[1]: Leaving directory >> `/build/buildd-gnupg_1.4.11-1-mipsel-rhMw25/gnupg-1.4.11/build-deb' > > For the full build log see below. This looks like it is https://bugs.g10code.com/gnupg/issue1231 which supposedly was fixed in 1.4.11 as far as I understood. Apparently the fix isn't complete... Cheers, Thijs From wk at gnupg.org Thu Oct 28 10:48:13 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Oct 2010 10:48:13 +0200 Subject: [Fwd: failed mipsel build of gnupg 1.4.11-1] In-Reply-To: <38c2f97697f247ffc39da188ba1edebf.squirrel@wm.kinkhorst.nl> (Thijs Kinkhorst's message of "Wed, 27 Oct 2010 20:31:47 +0200") References: <1288195368.6580.1.camel@haktar.wgdd.de> <38c2f97697f247ffc39da188ba1edebf.squirrel@wm.kinkhorst.nl> Message-ID: <874oc6ya7m.fsf@vigenere.g10code.de> On Wed, 27 Oct 2010 20:31, thijs at debian.org said: > This looks like it is > https://bugs.g10code.com/gnupg/issue1231 > which supposedly was fixed in 1.4.11 as far as I understood. Apparently > the fix isn't complete... Lacking a mips box, I was not able to test this change. Here is the code we now have in gnupg14: #if defined (__mips__) && W_TYPE_SIZE == 32 #if __GNUC__ > 4 || ( __GNUC__ == 4 && __GNUC_MINOR__ >= 4 ) #define umul_ppmm(w1, w0, u, v) \ do { \ UDItype __ll = (UDItype)(u) * (v); \ w1 = __ll >> 32; \ w0 = __ll; \ } while (0) #elif __GNUC__ > 2 || __GNUC_MINOR__ >= 7 However in libgcrypt 1.4.6 we have this code (by Aurelien Jarno): #if defined (__mips__) && W_TYPE_SIZE == 32 #if (__GNUC__ >= 5) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) #define umul_ppmm(w1, w0, u, v) \ do { \ UDItype _r; \ _r = (UDItype) u * v; \ (w1) = _r >> 32; \ (w0) = (USItype) _r; \ } while (0) The type definitions are indentical and the cpp conditionals have the same effect. libgcrypt 1.4.6 seems to build fine in experimental thus we should replace the code in gnupg by the one from libgcrypt. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Oct 28 11:15:05 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Oct 2010 11:15:05 +0200 Subject: Fix for GnuPG 1.4.11 on MIPS using gcc In-Reply-To: <38c2f97697f247ffc39da188ba1edebf.squirrel@wm.kinkhorst.nl> (Thijs Kinkhorst's message of "Wed, 27 Oct 2010 20:31:47 +0200") References: <1288195368.6580.1.camel@haktar.wgdd.de> <38c2f97697f247ffc39da188ba1edebf.squirrel@wm.kinkhorst.nl> Message-ID: <87zktywuee.fsf_-_@vigenere.g10code.de> Hi, While building GnuPG 1.4.11 on MIPS a build problem was encountred. Please try the patch below which should fix the problem. Salam-Shalom, Werner 2010-10-28 Werner Koch * longlong.h: Revert last two changes and replace by code from libgcrypt 1.4.6. --- mpi/longlong.h (revision 5466) +++ mpi/longlong.h (working copy) @@ -710,12 +710,13 @@ ************** MIPS ***************** ***************************************/ #if defined (__mips__) && W_TYPE_SIZE == 32 -#if __GNUC__ > 4 || ( __GNUC__ == 4 && __GNUC_MINOR__ >= 4 ) -#define umul_ppmm(w1, w0, u, v) \ +#if (__GNUC__ >= 5) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) +#define umul_ppmm(w1, w0, u, v) \ do { \ - UDItype __ll = (UDItype)(u) * (v); \ - w1 = __ll >> 32; \ - w0 = __ll; \ + UDItype _r; \ + _r = (UDItype) u * v; \ + (w1) = _r >> 32; \ + (w0) = (USItype) _r; \ } while (0) #elif __GNUC__ > 2 || __GNUC_MINOR__ >= 7 #define umul_ppmm(w1, w0, u, v) \ @@ -742,14 +743,15 @@ ************** MIPS/64 ************** ***************************************/ #if (defined (__mips) && __mips >= 3) && W_TYPE_SIZE == 64 -# if __GNUC__ > 4 || ( __GNUC__ == 4 && __GNUC_MINOR__ >= 4 ) +# if (__GNUC__ >= 5) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) + typedef unsigned int UTItype __attribute__ ((mode (TI))); # define umul_ppmm(w1, w0, u, v) \ - do { \ - typedef unsigned int __ll_UTItype __attribute__((mode(TI))); \ - __ll_UTItype __ll = (__ll_UTItype)(u) * (v); \ - w1 = __ll >> 64; \ - w0 = __ll; \ - } while (0) + do { \ + UTItype _r; \ + _r = (UTItype) u * v; \ + (w1) = _r >> 64; \ + (w0) = (UDItype) _r; \ + } while (0) # elif if __GNUC__ > 2 || __GNUC_MINOR__ >= 7 # define umul_ppmm(w1, w0, u, v) \ __asm__ ("dmultu %2,%3" \ -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From thijs at debian.org Thu Oct 28 22:14:14 2010 From: thijs at debian.org (Thijs Kinkhorst) Date: Thu, 28 Oct 2010 22:14:14 +0200 Subject: [Fwd: failed mipsel build of gnupg 1.4.11-1] In-Reply-To: <874oc6ya7m.fsf@vigenere.g10code.de> References: <1288195368.6580.1.camel@haktar.wgdd.de> <38c2f97697f247ffc39da188ba1edebf.squirrel@wm.kinkhorst.nl> <874oc6ya7m.fsf@vigenere.g10code.de> Message-ID: <201010282214.14846.thijs@debian.org> On Thursday 28 October 2010 10:48:13 Werner Koch wrote: > On Wed, 27 Oct 2010 20:31, thijs at debian.org said: > > This looks like it is > > https://bugs.g10code.com/gnupg/issue1231 > > which supposedly was fixed in 1.4.11 as far as I understood. Apparently > > the fix isn't complete... > > Lacking a mips box, I was not able to test this change. Understandable; Debian does but unfortunately due to holidays I was unable to test the release candidate so we only discovered this after 1.4.11 was released. > The type definitions are indentical and the cpp conditionals have the > same effect. libgcrypt 1.4.6 seems to build fine in experimental thus > we should replace the code in gnupg by the one from libgcrypt. I tested it and confirms that GnuPG now builds fine on MIPS with this patch. Thanks! Cheers, Thijs From dshaw at jabberwocky.com Fri Oct 29 21:57:08 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 29 Oct 2010 15:57:08 -0400 Subject: SHA1 being used despite public key preferences In-Reply-To: References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> <4CBF20C1.5050802@fifthhorseman.net> <4CBF4407.70700@sixdemonbag.org> <4A95670D-F78E-4C44-8DD1-A2635AB01C67@sixdemonbag.org> Message-ID: On Oct 21, 2010, at 5:16 AM, smu johnson wrote: > On Wed, Oct 20, 2010 at 6:50 PM, Robert J. Hansen wrote: > > The problem comes from saying, "well, Bruce says?". > > A good argument stands on its own legs: it doesn't rely on any external authority for its soundness. A lot of people in the crypto community are extraordinarily sensitive to what's called "appeal to authority" ? since this one person says so, it must be so. It's far better to give an argument that stands on its own, rather than appeal to "it's what Bruce says." > > > Two things. First, "Bruce says.." was meant to be sort of like a bibliography, when you try to find experts in the field who have said the same things you are saying. Usually it's good to give a bit of evidence for some of the arguments you are making. It is at least a better argument than me writing to the list without anything to back it up. So, I quoted some stuff Bruce said. Would you go around telling people who have citations in bibliographic form that "A good argument stands on its own legs: it doesn't rely on any external authority for its soundness."? > > Second thing: I already gave a good argument. Let's forget what Bruce said. And forget that I gave him as source. Let's go back to the basic message: SHA-1 is broken. It has been public knowledge for 5 years, and 2 years ago, a better attack was published. That is the basis for this whole thread, more or less. Ignore everything else I've said, except this one thing: SHA-1 is broken. I've made the change. Incidentally, this was already true for GnuPG 2.0. 1.4 now matches the 2.0 behavior of not having any default for personal-digest-preferences. While I was in there, I also made a small change in how MD5 is handled. Previously, if the algorithm selection ran and ended up with MD5 as the winning algorithm, GnuPG would replace it with SHA-1 (if available). Now, as long as there is at least one other digest available, MD5 is simply removed from the available algorithm list. This means that the next-highest ranked algorithm will be chosen, instead of forcing it to SHA-1. David From smujohnson at gmail.com Sat Oct 30 00:51:35 2010 From: smujohnson at gmail.com (smu johnson) Date: Fri, 29 Oct 2010 15:51:35 -0700 Subject: SHA1 being used despite public key preferences In-Reply-To: References: <74E750DE-5286-4B7D-AB23-C2E128A36317@jabberwocky.com> <4CBF20C1.5050802@fifthhorseman.net> <4CBF4407.70700@sixdemonbag.org> <4A95670D-F78E-4C44-8DD1-A2635AB01C67@sixdemonbag.org> Message-ID: Excellent, keep up the great work! Looking forward to the new version. On Fri, Oct 29, 2010 at 12:57 PM, David Shaw wrote: > > I've made the change. Incidentally, this was already true for GnuPG 2.0. > 1.4 now matches the 2.0 behavior of not having any default for > personal-digest-preferences. > > While I was in there, I also made a small change in how MD5 is handled. > Previously, if the algorithm selection ran and ended up with MD5 as the > winning algorithm, GnuPG would replace it with SHA-1 (if available). Now, > as long as there is at least one other digest available, MD5 is simply > removed from the available algorithm list. This means that the next-highest > ranked algorithm will be chosen, instead of forcing it to SHA-1. > > David > > -- smu johnson -------------- next part -------------- An HTML attachment was scrubbed... URL: