From wk at gnupg.org Mon Sep 4 18:27:14 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 4 18:31:32 2006 Subject: [Announce] dirmngr 0.9.6 released Message-ID: <87k64jlhr1.fsf@wheatstone.g10code.de> Hi! We are pleased to announce the availability of Dirmngr 0.9.6. Dirmngr is a server for managing and downloading certificate revocation lists (CRLs) for X.509 certificates and for downloading the certificates themselves. Dirmngr also handles OCSP requests as an alternative to CRLs. Dirmngr is either invoked internaly by gpgsm (from gnupg 1.9) or when running as a system daemon through the dirmngr-client tool. Get it from: ftp://ftp.gnupg.org/gcrypt/alpha/dirmngr/dirmngr-0.9.6.tar.bz2 (488k) ftp://ftp.gnupg.org/gcrypt/alpha/dirmngr/dirmngr-0.9.6.tar.bz2.sig or as a patch against the previous version: ftp://ftp.gnupg.org/gcrypt/alpha/dirmngr/dirmngr-0.9.5-0.9.6.diff.bz2 (60k) SHA1 checkums are: 954e1dbed96a2bccfbdb1bee446fa75337a156ea dirmngr-0.9.6.tar.bz2 b8ad93a2aeca323431d8143f797c00f2ab782fe9 dirmngr-0.9.5-0.9.6.diff.bz2 Whats new in this release ========================= * A couple of bug fixes for OCSP. * OCSP does now make use of the responder ID and optionally included certificates in the response to locate certificates. * No more lost file descriptors when loading CRLs via HTTP. * HTTP redirection for CRL and OCSP has been implemented. * Man pages are now build and installed from the texinfo source. Note, that you need to update libksba to version 1.0.0 for this release. If this release works as expected a 1.0 release will be pretty close. Commercial support contracts for Dirmngr are available, and they help finance continued maintenance. g10 Code, a Duesseldorf based company owned and headed by libksba's maintainer, is currently funding its development. We are always looking for interesting development projects. Happy Hacking, Werner -- Werner Koch The GnuPG Experts http://g10code.com Join the Fellowship and protect your Freedom! http://www.fsfe.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20060904/dfe708cd/attachment.pgp From bob at xyzzy.org.uk Tue Sep 5 10:50:14 2006 From: bob at xyzzy.org.uk (Bob Dunlop) Date: Tue Sep 5 10:49:01 2006 Subject: Cryptoflex 32K support patch Message-ID: <20060905085014.GA9651@xyzzy.org.uk> Hi, I've been trying to use a new Cryptoflex 32K card (sold as a Cryptoflex for Windows card) working with GnuPG under Gentoo linux. The resultant patch to the scd directory below works for me. The base I started from was 1.9.22. All the code and changes are released under GPL2 although as I post this I realise I've not added the statement to the new file cryptofex.h but then again it might be better to merge this file with one of the existing headers. It works for me in the areas I need/have tested. I'd strongly recommend review and further testing. diff -Naur scd/apdu.c scd-new/apdu.c --- scd/apdu.c 2006-09-05 08:16:50.000000000 +0000 +++ scd-new/apdu.c 2006-09-05 08:15:18.000000000 +0000 @@ -64,6 +64,7 @@ #include "apdu.h" #include "dynload.h" #include "ccid-driver.h" +#include "cryptoflex.h" /* Due to conflicting use of threading libraries we usually can't link @@ -152,6 +153,9 @@ /* A global table to keep track of active readers. */ static struct reader_table_s reader_table[MAX_READER]; +/* Additional info for Cryptoflex 32K cards that needs to be public */ +struct cf32k_info cryptoflex_info[ MAX_READER ]; + /* ct API function pointer. */ static char (* DLSTDCALL CT_init) (unsigned short ctn, unsigned short Pn); @@ -789,6 +793,8 @@ unsigned int dummy_status; int sw = SW_HOST_CARD_IO_ERROR; + cryptoflex_info[slot].cf32k_mode = unknown; + slotp = reader_table + slot; if (slotp->pcsc.req_fd == -1 @@ -1255,6 +1261,8 @@ return 0; } + cryptoflex_info[slot].cf32k_mode = unknown; + msgbuf[0] = 0x02; /* CLOSE command. */ len = 0; msgbuf[1] = (len >> 24); @@ -2638,7 +2646,8 @@ assert (sizeof (apdu) >= apdulen); /* As safeguard don't pass any garbage from the stack to the driver. */ memset (apdu+apdulen, 0, sizeof (apdu) - apdulen); - resultlen = RESULTLEN; + /* Allow for a 256 byte response + 2 byte status */ + resultlen = RESULTLEN+2; rc = send_apdu (slot, apdu, apdulen, result, &resultlen, pininfo); if (rc || resultlen < 2) { @@ -2706,7 +2715,7 @@ apdu[apdulen++] = 0; apdu[apdulen++] = len; memset (apdu+apdulen, 0, sizeof (apdu) - apdulen); - resultlen = RESULTLEN; + resultlen = RESULTLEN+2; rc = send_apdu (slot, apdu, apdulen, result, &resultlen, NULL); if (rc || resultlen < 2) { @@ -2729,6 +2738,9 @@ || sw == SW_SUCCESS || sw == SW_EOF_REACHED ) { + /* Grab what might be the file length for Cryptoflex cards */ + cryptoflex_info[slot].cf32k_efsize = (result[2]<<8) | result[3]; + if (retbuf && resultlen) { if (p - *retbuf + resultlen > bufsize) @@ -2878,7 +2890,7 @@ memcpy (apdu, apdudata, apdudatalen); class = apdulen? *apdu : 0; - resultlen = RESULTLEN; + resultlen = RESULTLEN+2; rc = send_apdu (slot, apdu, apdulen, result, &resultlen, NULL); if (rc || resultlen < 2) { @@ -2932,7 +2944,7 @@ apdu[apdulen++] = 0; apdu[apdulen++] = len; memset (apdu+apdulen, 0, sizeof (apdu) - apdulen); - resultlen = RESULTLEN; + resultlen = RESULTLEN+2; rc = send_apdu (slot, apdu, apdulen, result, &resultlen, NULL); if (rc || resultlen < 2) { diff -Naur scd/app-p15.c scd-new/app-p15.c --- scd/app-p15.c 2006-09-05 08:16:50.000000000 +0000 +++ scd-new/app-p15.c 2006-09-05 08:15:18.000000000 +0000 @@ -44,6 +44,7 @@ #include "tlv.h" #include "apdu.h" /* fixme: we should move the card detection to a separate file */ +#include "cryptoflex.h" /* Types of cards we know and which needs special treatment. */ typedef enum @@ -51,7 +52,8 @@ CARD_TYPE_UNKNOWN, CARD_TYPE_TCOS, CARD_TYPE_MICARDO, - CARD_TYPE_BELPIC /* Belgian eID card specs. */ + CARD_TYPE_BELPIC, /* Belgian eID card specs. */ + CARD_TYPE_CRYPTOFLEX /* Newer 32K cards */ } card_type_t; @@ -3152,6 +3154,10 @@ /* TCOS creates signatures always using the local key 0. MSE may not be used. */ } + else if (app->app_local->card_type == CARD_TYPE_CRYPTOFLEX) + { + /* Don't know how to handle MSE with Cryptoflex so ignore */ + } else if (app->app_local->card_type == CARD_TYPE_MICARDO) { if (!prkdf->pathlen) @@ -3358,7 +3364,10 @@ /* Store the card type. FIXME: We might want to put this into the common APP structure. */ - app->app_local->card_type = card_type; + if (is_cryptoflex(slot)) + app->app_local->card_type = CARD_TYPE_CRYPTOFLEX; + else + app->app_local->card_type = card_type; /* Store whether we may and should use direct path selection. */ app->app_local->direct_path_selection = direct; diff -Naur scd/cryptoflex.h scd-new/cryptoflex.h --- scd/cryptoflex.h 1970-01-01 00:00:00.000000000 +0000 +++ scd-new/cryptoflex.h 2006-09-05 08:16:50.000000000 +0000 @@ -0,0 +1,35 @@ + +/* The newer Cryptoflex 32K cards are PKCS#15 cards but have a somewhat + different command set when compared to the cards already supported by GnuPG. + In particular Class often has to be set to a non-zero value and the cards + only support raw RSA operations. */ + +/* This card declares additional information and functions necessary to support + the card. The structure parallels the reader_table[] in apdu.c which is + unfortunatly declared static. */ + +/* This should match the setting in apdu.c The fact that it is in two places + probably indicates that it should be in a global header somewhere. */ +#define MAX_READER 4 /* Number of readers we support concurrently. */ + + +enum cf32k_mode { + unknown, /* Havn't tested card yet */ + yes, /* Yes it's a Cryptoflex 32K */ + no /* Not a Cryptoflex 32K */ +}; + +struct cf32k_info { + enum cf32k_mode cf32k_mode; + int cf32k_efsize; /* Size of last EF file selected */ + int cf32k_keysize; /* Number of bytes in RSA key */ +}; + +extern struct cf32k_info cryptoflex_info[ MAX_READER ]; + +#define is_cryptoflex(slot) ( cryptoflex_info[slot].cf32k_mode == yes ) +#define maybe_cryptoflex(slot) ( cryptoflex_info[slot].cf32k_mode == unknown ) + + +/* Reserved tag for the RSA private keys file */ +#define EF_RSA_PRI_TAG 0x0012 diff -Naur scd/iso7816.c scd-new/iso7816.c --- scd/iso7816.c 2006-09-05 08:16:50.000000000 +0000 +++ scd-new/iso7816.c 2006-09-05 08:23:47.000000000 +0000 @@ -44,6 +44,7 @@ #include "iso7816.h" #include "apdu.h" +#include "cryptoflex.h" #define CMD_SELECT_FILE 0xA4 @@ -132,6 +133,9 @@ unsigned int flags) { int sw; + + if (is_cryptoflex(slot)) + flags |= 1; sw = apdu_send_simple (slot, 0x00, CMD_SELECT_FILE, 4, (flags&1)? 0 :0x0c, aidlen, aid); return map_sw (sw); @@ -142,7 +146,7 @@ iso7816_select_file (int slot, int tag, int is_dir, unsigned char **result, size_t *resultlen) { - int sw, p0, p1; + int sw, class, p0, p1; unsigned char tagbuf[2]; tagbuf[0] = (tag >> 8) & 0xff; @@ -156,10 +160,59 @@ } else { - p0 = (tag == 0x3F00)? 0: is_dir? 1:2; - p1 = 0x0c; /* No FC return. */ - sw = apdu_send_simple (slot, 0x00, CMD_SELECT_FILE, + if (is_cryptoflex(slot)) + { + class = 0xC0; + p0 = 0; + p1 = 0; + } + else + { + class = 0x00; + p0 = (tag == 0x3F00)? 0: is_dir? 1:2; + p1 = 0x0c; /* No FC return. */ + } + sw = apdu_send_simple (slot, class, CMD_SELECT_FILE, p0, p1, 2, (char*)tagbuf ); + /* If we've not already tried, test if Cryptoflex style commands might + work */ + if (maybe_cryptoflex(slot)) + { + if (sw == SW_INS_NOT_SUP) + { + log_debug ("Trying Cryptoflex file select\n"); + sw = apdu_send_le (slot, 0xC0, CMD_SELECT_FILE, + 0, 0, 2, (char*)tagbuf,-1, result, resultlen ); + if ( sw == SW_SUCCESS || (sw & 0xFF00) == SW_MORE_DATA ) + cryptoflex_info[slot].cf32k_mode = yes; + else + cryptoflex_info[slot].cf32k_mode = no; + } + else + { + cryptoflex_info[slot].cf32k_mode = no; + } + } + /* Nasty side effect for Cryptoflex cards. The size of the private keys + file indicates the size of the RSA key assuming we've only stored one + key in it anyway. With more than one key we'd have to get the key + size by some other means like parsing the file */ + if ( tag == EF_RSA_PRI_TAG && is_cryptoflex(slot)) + { + switch ( cryptoflex_info[slot].cf32k_efsize ) + { + case 647: case 646: cryptoflex_info[slot].cf32k_keysize = 256; + break; + case 327: case 326: cryptoflex_info[slot].cf32k_keysize = 128; + break; + case 247: case 246: cryptoflex_info[slot].cf32k_keysize = 96; + break; + case 167: case 166: cryptoflex_info[slot].cf32k_keysize = 64; + break; + } + log_debug ("Cryptoflex key size %d bits\n", + cryptoflex_info[slot].cf32k_keysize * 8 ); + } return map_sw (sw); } @@ -247,15 +300,16 @@ iso7816_pininfo_t *pininfo) { int sw; + int class = is_cryptoflex(slot)? 0xC0: 0x00; if (pininfo && pininfo->mode) - sw = apdu_send_simple_kp (slot, 0x00, CMD_VERIFY, 0, chvno, chvlen, chv, + sw = apdu_send_simple_kp (slot, class, CMD_VERIFY, 0, chvno, chvlen, chv, pininfo->mode, pininfo->minlen, pininfo->maxlen, pininfo->padlen); else - sw = apdu_send_simple (slot, 0x00, CMD_VERIFY, 0, chvno, chvlen, chv); + sw = apdu_send_simple (slot, class, CMD_VERIFY, 0, chvno, chvlen, chv); return map_sw (sw); } @@ -281,6 +335,7 @@ { int sw; char *buf; + int class = is_cryptoflex(slot)? 0xF0: 0x00; if ((!oldchv && oldchvlen) || (oldchv && !oldchvlen) @@ -295,14 +350,14 @@ memcpy (buf+oldchvlen, newchv, newchvlen); if (pininfo && pininfo->mode) - sw = apdu_send_simple_kp (slot, 0x00, CMD_CHANGE_REFERENCE_DATA, + sw = apdu_send_simple_kp (slot, class, CMD_CHANGE_REFERENCE_DATA, oldchvlen? 0 : 1, chvno, oldchvlen+newchvlen, buf, pininfo->mode, pininfo->minlen, pininfo->maxlen, pininfo->padlen); else - sw = apdu_send_simple (slot, 0x00, CMD_CHANGE_REFERENCE_DATA, + sw = apdu_send_simple (slot, class, CMD_CHANGE_REFERENCE_DATA, oldchvlen? 0 : 1, chvno, oldchvlen+newchvlen, buf); xfree (buf); return map_sw (sw); @@ -330,19 +385,20 @@ iso7816_pininfo_t *pininfo) { int sw; + int class = is_cryptoflex(slot)? 0xF0: 0x00; if (!newchv || !newchvlen ) return gpg_error (GPG_ERR_INV_VALUE); if (pininfo && pininfo->mode) - sw = apdu_send_simple_kp (slot, 0x00, CMD_RESET_RETRY_COUNTER, + sw = apdu_send_simple_kp (slot, class, CMD_RESET_RETRY_COUNTER, 2, chvno, newchvlen, newchv, pininfo->mode, pininfo->minlen, pininfo->maxlen, pininfo->padlen); else - sw = apdu_send_simple (slot, 0x00, CMD_RESET_RETRY_COUNTER, + sw = apdu_send_simple (slot, class, CMD_RESET_RETRY_COUNTER, 2, chvno, newchvlen, newchv); return map_sw (sw); } @@ -410,16 +466,33 @@ const unsigned char *data, size_t datalen) { int sw; + int class = is_cryptoflex(slot)? 0xF0: 0x00; if (p1 < 0 || p1 > 255 || p2 < 0 || p2 > 255 ) return gpg_error (GPG_ERR_INV_VALUE); - sw = apdu_send_simple (slot, 0x00, CMD_MSE, p1, p2, + sw = apdu_send_simple (slot, class, CMD_MSE, p1, p2, data? datalen : -1, (const char*)data); return map_sw (sw); } +/* Reverse bytes in a buffer given start and length */ +static void +reverse_buffer (unsigned char *start, size_t len) +{ + unsigned char *end = start + len - 1; + unsigned char tmp; + + while ( start < end ) + { + tmp = *start; + *start++ = *end; + *end-- = tmp; + } +} + + /* Perform the security operation COMPUTE DIGITAL SIGANTURE. On success 0 is returned and the data is availavle in a newly allocated buffer stored at RESULT with its length stored at @@ -429,14 +502,53 @@ unsigned char **result, size_t *resultlen) { int sw; + unsigned char padded_buf[256]; + int keylen; if (!data || !datalen || !result || !resultlen) return gpg_error (GPG_ERR_INV_VALUE); *result = NULL; *resultlen = 0; - sw = apdu_send (slot, 0x00, CMD_PSO, 0x9E, 0x9A, datalen, (const char*)data, - result, resultlen); + if (is_cryptoflex(slot)) + { + keylen = cryptoflex_info[slot].cf32k_keysize; + + /* Need space for PKCS#1 RSA padding */ + if ( datalen + 11 > keylen ) + return gpg_error (GPG_ERR_INV_VALUE); + + /* Build PKCS#1 RSA padded version of the data */ + padded_buf[0] = 0x00; + padded_buf[1] = 0x01; + memset (padded_buf+2, 0xFF, keylen-datalen-3 ); + padded_buf[keylen-datalen-1] = 0x00; + memcpy (padded_buf+keylen-datalen, data, datalen ); + + /* The command needs and returns the data LSB first */ + reverse_buffer (padded_buf, keylen ); + + /* If the key is 2048 bits then we have to send the data in 2 chunks */ + if ( keylen >= 256 ) + { + sw = apdu_send_simple (slot, 0x10, CMD_INTERNAL_AUTHENTICATE, 0x00, + 0x00, 10, padded_buf ); + sw = apdu_send (slot, 0x00, CMD_INTERNAL_AUTHENTICATE, 0x00, 0x00, + keylen-10, padded_buf+10, result, resultlen ); + } + else + { + sw = apdu_send (slot, 0x00, CMD_INTERNAL_AUTHENTICATE, 0x00, 0x00, + keylen, padded_buf, result, resultlen ); + } + if ( *result != NULL ) + reverse_buffer (*result, *resultlen ); + } + else + { + sw = apdu_send (slot, 0x00, CMD_PSO, 0x9E, 0x9A, datalen, + (const char*)data, result, resultlen); + } if (sw != SW_SUCCESS) { /* Make sure that pending buffers are released. */ @@ -506,13 +618,14 @@ unsigned char **result, size_t *resultlen) { int sw; + int class = is_cryptoflex(slot)? 0xC0: 0x00; if (!data || !datalen || !result || !resultlen) return gpg_error (GPG_ERR_INV_VALUE); *result = NULL; *resultlen = 0; - sw = apdu_send (slot, 0x00, CMD_INTERNAL_AUTHENTICATE, 0, 0, + sw = apdu_send (slot, class, CMD_INTERNAL_AUTHENTICATE, 0, 0, datalen, (const char*)data, result, resultlen); if (sw != SW_SUCCESS) { @@ -579,6 +692,7 @@ int sw; unsigned char *result; size_t resultlen, n; + int class = is_cryptoflex(slot)? 0xC0: 0x00; if (!buffer || length < 1) return gpg_error (GPG_ERR_INV_VALUE); @@ -587,7 +701,7 @@ { result = NULL; n = length > 254? 254 : length; - sw = apdu_send_le (slot, 0x00, CMD_GET_CHALLENGE, 0, 0, -1, NULL, + sw = apdu_send_le (slot, class, CMD_GET_CHALLENGE, 0, 0, -1, NULL, n, &result, &resultlen); if (sw != SW_SUCCESS) @@ -621,6 +735,7 @@ size_t bufferlen; int read_all = !nmax; size_t n; + int class = is_cryptoflex(slot)? 0xC0: 0x00; if (!result || !resultlen) return gpg_error (GPG_ERR_INV_VALUE); @@ -632,6 +747,15 @@ if (offset > 32767) return gpg_error (GPG_ERR_INV_VALUE); + /* Cryptoflex 32K cards don't like the attempts to read past the EOF caused + by setting N to 254 if the filesize is unknown below. Substitute the size + we learnt from the last file select */ + if (is_cryptoflex(slot) && !nmax) + { + nmax = cryptoflex_info[slot].cf32k_efsize; + read_all = !nmax; + } + do { buffer = NULL; @@ -644,13 +768,13 @@ n = 254; else n = nmax; - sw = apdu_send_le (slot, 0x00, CMD_READ_BINARY, + sw = apdu_send_le (slot, class, CMD_READ_BINARY, ((offset>>8) & 0xff), (offset & 0xff) , -1, NULL, n, &buffer, &bufferlen); if ( SW_EXACT_LENGTH_P(sw) ) { n = (sw & 0x00ff); - sw = apdu_send_le (slot, 0x00, CMD_READ_BINARY, + sw = apdu_send_le (slot, class, CMD_READ_BINARY, ((offset>>8) & 0xff), (offset & 0xff) , -1, NULL, n, &buffer, &bufferlen); } @@ -723,6 +847,7 @@ int sw; unsigned char *buffer; size_t bufferlen; + int class = is_cryptoflex(slot)? 0xC0: 0x00; if (!result || !resultlen) return gpg_error (GPG_ERR_INV_VALUE); @@ -739,7 +864,7 @@ bufferlen = 0; /* Fixme: Either the ccid driver or the TCOS cards have problems with an Le of 0. */ - sw = apdu_send_le (slot, 0x00, CMD_READ_RECORD, + sw = apdu_send_le (slot, class, CMD_READ_RECORD, recno, short_ef? short_ef : 0x04, -1, NULL, -- Bob Dunlop From alf at bordel-ambiant.org Tue Sep 5 11:42:57 2006 From: alf at bordel-ambiant.org (Francois Gaudin) Date: Tue Sep 5 13:25:45 2006 Subject: gpgme_op_verify behaves weird Message-ID: <200609051143.01344.alf@bordel-ambiant.org> Hello, I'm new to this list, nice to meet you =) so, my problem is that I can sign text, but the verification failed with a segfault and I can't find why. here is my code : gpgme_signers_clear(context) ; // retrieving key gpgme_key_t gpgkey ; gpgme_error_t result = gpgme_get_key(context, key.toLocal8Bit(),&gpgkey,true) ; Q_ASSERT(result == GPG_ERR_NO_ERROR) ; Q_ASSERT(gpgkey != NULL) ; // signing result = gpgme_signers_add(context,gpgkey) ; Q_ASSERT(result == GPG_ERR_NO_ERROR) ; gpgme_data_t signature ; result = gpgme_data_new(&signature); Q_ASSERT(result == GPG_ERR_NO_ERROR) ; gpgme_data_t msg ; result = gpgme_data_new_from_mem(&msg,message.toLocal8Bit(),message.size(),0) ; result = gpgme_op_sign(context, msg,signature, GPGME_SIG_MODE_DETACH) ; Q_ASSERT(result == GPG_ERR_NO_ERROR || result == GPG_ERR_BAD_PASSPHRASE || result == GPG_ERR_CANCELED) ; QString signatureStr ; char * buffer = (char *) calloc(1024,sizeof(char)) ; gpgme_data_rewind(signature) ; // should be the following, but for a fucking mysterious reason, it doesn't want to work // gpgme_data_seek(signature,0,SEEK_SET) ; gpgme_data_read(signature,buffer,1024) ; signatureStr += buffer ; qDebug() << "signature" << signatureStr ; // test part result = gpgme_op_verify (context, signature, msg , NULL) ; qDebug() << "verify result" << result ; Q_ASSERT(result != GPG_ERR_INV_VALUE) ; Q_ASSERT(result != GPG_ERR_NO_DATA) ; // Q_ASSERT(result == GPG_ERR_NO_ERROR) ; qDebug() << "verify" ; gpgme_verify_result_t verification = gpgme_op_verify_result(context) ; Q_ASSERT(verification != NULL) ; qDebug() << "result" ; gpgme_signature_t signatures = verification->signatures ; qDebug() << signatures->summary ; qDebug() << "GPGME_SIGSUM_VALID" << GPGME_SIGSUM_VALID ; qDebug() << "GPGME_SIGSUM_GREEN" << GPGME_SIGSUM_GREEN ; qDebug() << "GPGME_SIGSUM_RED" << GPGME_SIGSUM_RED ; gpgme_error_t status = signatures->status ; qDebug() << "status" << status ; gpgme_error_t validity_reason = signatures->validity_reason ; qDebug() << "validity reason" << validity_reason ; if(signatures->summary == GPGME_SIGSUM_VALID || signatures->summary == GPGME_SIGSUM_GREEN) { qDebug() << "verified" ; } else { qDebug() << "not verified" ; } And here is the output : signature "-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFE/UXk3r3TxDvLjIQRAst5AJ44V0/f8w9gTtlWw79rkmzq5RDdfwCeK5fR 1QBGb0cEEUBkWQg0rc3HG7g= =OKaA -----END PGP SIGNATURE----- " verify result 117440570 verify result Erreur de segmentation so it seems to well sign but the value returned by gpgme_op_verify is weird ... Is there a known bug or I do something wrong ? gnupg version is : 1.4.2.2-1ubuntu2.2 gpgme version is : 1.1.0-1 thx -- Francois Gaudin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 829 bytes Desc: not available Url : /pipermail/attachments/20060905/856a5eea/attachment.pgp From marcus.brinkmann at ruhr-uni-bochum.de Tue Sep 5 14:06:13 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue Sep 5 14:05:45 2006 Subject: gpgme_op_verify behaves weird In-Reply-To: <200609051143.01344.alf@bordel-ambiant.org> References: <200609051143.01344.alf@bordel-ambiant.org> Message-ID: <87slj6zfey.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 5 Sep 2006 11:42:57 +0200, Francois Gaudin wrote: > so, my problem is that I can sign text, but the verification failed with a > segfault and I can't find why. Should be easy, let's walk through the various issues. First of all, return values are not error codes, they are error codes plus encoded error source information. So the right way to access the error code is gpgme_err_code (result) for comparison, assertions etc. > gpgme_data_rewind(signature) ; > // should be the following, but for a fucking mysterious reason, it doesn't > want to work > // gpgme_data_seek(signature,0,SEEK_SET) ; See the FAQ at http://www.gnupg.org/(en)/faq/gpgme-faq.html: Why does the function gpgme_data_seek not work? You probably did not compile the program with largefile support. GPGME is compiled with largefile support by default, so off_t is a 64-bit data type. Because gpgme_data_seek uses off_t as a parameter type, you have to compile your program with largefile support as well, so that the data types used by GPGME and by your program match. Note that you have to compile your program with largefile support even if you do not use gpgme_data_seek, because file descriptors are exchanged between the program and GPGME. The GPGME documentation contains much more information on the subject. See section 2.3 Largefile support of the GPGME Reference Manual. > gpgme_data_read(signature,buffer,1024) ; > > signatureStr += buffer ; > > qDebug() << "signature" << signatureStr ; Here you have to rewind a second time if you want to verify the signature. > // test part > result = gpgme_op_verify (context, signature, msg , NULL) ; > qDebug() << "verify result" << result ; > Q_ASSERT(result != GPG_ERR_INV_VALUE) ; > Q_ASSERT(result != GPG_ERR_NO_DATA) ; > // Q_ASSERT(result == GPG_ERR_NO_ERROR) ; > qDebug() << "verify" ; Always catch all errors. From the output below: > verify result 117440570 And this means: $ gpg-error 117440570 117440570 = (7, 58) = (GPG_ERR_SOURCE_GPGME, GPG_ERR_NO_DATA) = (GPGME, No data) So, no data was found. > gpgme_verify_result_t verification = gpgme_op_verify_result(context) ; > Q_ASSERT(verification != NULL) ; > qDebug() << "result" ; The result structure is not always well-formed after a failed operation. GPGME tries to make as much information available as possible, of course. In particular, if no data was found, no signatures were found either, so: > gpgme_signature_t signatures = verification->signatures ; This is likely NULL. > qDebug() << signatures->summary ; And this will then segfault. > so it seems to well sign but the value returned by gpgme_op_verify is > weird ... The higher bits encode the error source (GPGME in this case), and the lower bits the error value. We use this to be able to report errors from deeper layers with as little loss of information as possible. I suggest that you browse through the manual if you didn't already, especially the first sections, and then the sections for the crypto operations you are using. The manual is not complete, because it does not document how the crypto backends behave in all possible cases, but the issues specific to GPGME should all be answered. Happy hacking, Marcus From alf at bordel-ambiant.org Tue Sep 5 14:55:55 2006 From: alf at bordel-ambiant.org (Francois Gaudin) Date: Tue Sep 5 14:54:15 2006 Subject: gpgme_op_verify behaves weird In-Reply-To: <87slj6zfey.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200609051143.01344.alf@bordel-ambiant.org> <87slj6zfey.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200609051455.59617.alf@bordel-ambiant.org> Really thank you for all these explainations. I've corrected my code and now error codes are more meaningfull for me. But I can't understand why this failed to verify. I sign and verify and nothing more. result = gpgme_op_sign(context, msg,signature, GPGME_SIG_MODE_DETACH) ; Q_ASSERT(gpgme_err_code(result) == GPG_ERR_NO_ERROR || gpgme_err_code(result) == GPG_ERR_BAD_PASSPHRASE || gpgme_err_code(result) == GPG_ERR_CANCELED) ; // test gpgme_data_rewind(signature) ; gpgme_data_rewind(msg) ; result = gpgme_op_verify (context, signature, msg , 0) ; qDebug() << "verify result" << gpgme_err_code(result) ; Q_ASSERT(gpgme_err_code(result) != GPG_ERR_INV_VALUE) ; Q_ASSERT(gpgme_err_code(result) != GPG_ERR_NO_DATA) ; Q_ASSERT(result == GPG_ERR_NO_ERROR) ; qDebug() << "verify" ; gpgme_verify_result_t verification = gpgme_op_verify_result(context) ; Q_ASSERT(verification != NULL) ; qDebug() << "result" ; gpgme_signature_t signatures = verification->signatures ; Q_ASSERT(verification->signatures != NULL) ; gpgme_error_t status = signatures->status ; qDebug() << "status" << gpgme_err_code(status) ; // test output : verify result 0 verify result status 8 signature "-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFE/XKv3r3TxDvLjIQRAi5SAKCODnDtKwtCCbfRnkXI8hd4E8VX1ACcDGyd kkScz6pUEiCABCYzQOI/4Yw= =Vf9z -----END PGP SIGNATURE----- " and : alf@gros:~/gpl_projects/torrentlibre/tlclient$ gpg-error 8 8 = (0, 8) = (GPG_ERR_SOURCE_UNKNOWN, GPG_ERR_BAD_SIGNATURE) = (Source non-sp?cifi?e, Mauvaise signature) -- Francois Gaudin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 829 bytes Desc: not available Url : /pipermail/attachments/20060905/d47e47ff/attachment.pgp From yanagisawa at csg.is.titech.ac.jp Tue Sep 5 13:20:29 2006 From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA) Date: Tue Sep 5 14:55:29 2006 Subject: I ported Camellia (RFC3713) to the GnuPG 1.4.5. Message-ID: <20060905202029.195f3ba1.yanagisawa@csg.is.titech.ac.jp> Hello, I have ported the Camellia (RFC3713) block cipher to the GnuPG version 1.4.5. Camellia is a block cipher algorithm which was selected as a recommended cryptographic primitive by the EU NESSIE project and also included in the list of cryptographic techniques for Japanese e-Government systems. It is also a standard algorithm for IPsec (RFC4312) and SSL/TLS (RFC4132). To port Camellia, I made a patch which includes a program distributed at NTT (Nippon Telephone and Telecomunication) open-source website (https://info.isl.ntt.co.jp/crypt/camellia/source_s.html). If you are interested in the patch, please download and use it from: http://www.is.titech.ac.jp/~yanagis0/text/camellia-e.html Regards, Yoshisato YANAGISAWA. -- ------------------------------------------------------- Yoshisato YANAGISAWA Dept. of Mathematical and Computing Sciences, Graduate School of Information Science and Engineering, Tokyo Institute of Technology. /* If you are an *BSD user, let's join http://bsdstats.org/ */ From marcus.brinkmann at ruhr-uni-bochum.de Tue Sep 5 15:36:47 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue Sep 5 15:35:46 2006 Subject: gpgme_op_verify behaves weird In-Reply-To: <200609051455.59617.alf@bordel-ambiant.org> References: <200609051143.01344.alf@bordel-ambiant.org> <87slj6zfey.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200609051455.59617.alf@bordel-ambiant.org> Message-ID: <87r6yqzb80.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 5 Sep 2006 14:55:55 +0200, Francois Gaudin wrote: > > Really thank you for all these explainations. > > I've corrected my code and now error codes are more meaningfull for me. But I > can't understand why this failed to verify. I sign and verify and nothing > more. I am not sure. You may want to try to write out MSG and SIGNATURE and see if they verify on the command line. You may also want to try running with environment variable GPGME_DEBUG=3, to see the communication between GPGME and GPG. If you still have trouble, please provide a small example which is self-contained, ie can be compiled and run, so I can try to reproduce the problem. Thanks, Marcus From wk at gnupg.org Wed Sep 6 10:59:42 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Sep 6 11:01:38 2006 Subject: gpgme_op_verify behaves weird In-Reply-To: <87r6yqzb80.wl%marcus.brinkmann@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "Tue, 05 Sep 2006 15:36:47 +0200") References: <200609051143.01344.alf@bordel-ambiant.org> <87slj6zfey.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200609051455.59617.alf@bordel-ambiant.org> <87r6yqzb80.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <87ac5djrpd.fsf@wheatstone.g10code.de> On Tue, 5 Sep 2006 15:36, Marcus Brinkmann said: > see if they verify on the command line. You may also want to try > running with environment variable GPGME_DEBUG=3, to see the > communication between GPGME and GPG. Another option is to put "debug 512" into gpg.conf. This will create files with the actual hashed content. Compare what you signed and what you verified. Salam-Shalom, Werner From wk at gnupg.org Wed Sep 6 11:02:25 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Sep 6 11:06:23 2006 Subject: I ported Camellia (RFC3713) to the GnuPG 1.4.5. In-Reply-To: <20060905202029.195f3ba1.yanagisawa@csg.is.titech.ac.jp> (Yoshisato YANAGISAWA's message of "Tue, 5 Sep 2006 20:20:29 +0900") References: <20060905202029.195f3ba1.yanagisawa@csg.is.titech.ac.jp> Message-ID: <8764g1jrku.fsf@wheatstone.g10code.de> On Tue, 5 Sep 2006 13:20, Yoshisato YANAGISAWA said: > I have ported the Camellia (RFC3713) block cipher to the GnuPG version > 1.4.5. Camellia is a block cipher algorithm which was selected as a GnuPG won't support algorithms not defined by OpenPGP. Camellia is not defined by OpenPGP. However, it might be useful to put it into Libgcrypt. The code is similar it mereley needs a few tewaks for cipher registration. Shalom-Salam, Werner From alf at bordel-ambiant.org Wed Sep 6 11:13:58 2006 From: alf at bordel-ambiant.org (Francois Gaudin) Date: Wed Sep 6 11:12:09 2006 Subject: gpgme_op_verify behaves weird In-Reply-To: <87ac5djrpd.fsf@wheatstone.g10code.de> References: <200609051143.01344.alf@bordel-ambiant.org> <87r6yqzb80.wl%marcus.brinkmann@ruhr-uni-bochum.de> <87ac5djrpd.fsf@wheatstone.g10code.de> Message-ID: <200609061113.59008.alf@bordel-ambiant.org> I'v solved my problem and it was because of Qt ... really weird... (message is a QString) int message_length = message.toAscii().size() ; char * message_char = (char *) calloc(message_length+1,sizeof(char)) ; memcpy(message_char,message.toAscii().data(),message_length) ; result = gpgme_data_new_from_mem(&msg,message_char,message_length,0) ; Seems to have a lack of \0 or too many, I don't known, when I put directly a hard coded string it works and from a QString I need to really care with initializing all bytes with \0 (with the calloc). A memcpy(qstring_str.toAscii(),hardcoded_string,length+1) returns 0. Good luck for those who use Qt (C++) and C api ... Thanks to all Le Mercredi 6 Septembre 2006 10:59, Werner Koch a ?crit?: > On Tue, 5 Sep 2006 15:36, Marcus Brinkmann said: > > see if they verify on the command line. You may also want to try > > running with environment variable GPGME_DEBUG=3, to see the > > communication between GPGME and GPG. > > Another option is to put "debug 512" into gpg.conf. This will create > files with the actual hashed content. Compare what you signed and > what you verified. > > > Salam-Shalom, > > Werner -- Francois Gaudin From bob at xyzzy.org.uk Wed Sep 6 15:21:34 2006 From: bob at xyzzy.org.uk (Bob Dunlop) Date: Wed Sep 6 15:20:02 2006 Subject: Declaration correction in pcsc-wrapper.c Message-ID: <20060906132134.GA7640@xyzzy.org.uk> Hi, Just spotted an incorrect declaration of pcsc_end_transaction() in scd/pcsc-wrapper.c. The same error occurs in acd/apdu.c The function is currently unused in the standard code so the fix is only good house keeping. I of course found this when I tried to use the function in some additional code I'm working on. --- pcsc-wrapper.c-orig 2006-09-06 11:43:18.000000000 +0000 +++ pcsc-wrapper.c 2006-09-06 13:02:34.000000000 +0000 @@ -162,7 +169,8 @@ unsigned long *r_protocol, unsigned char *atr, unsigned long *atrlen); long (* pcsc_begin_transaction) (unsigned long card); -long (* pcsc_end_transaction) (unsigned long card); +long (* pcsc_end_transaction) (unsigned long card, + unsigned long disposition); long (* pcsc_transmit) (unsigned long card, const pcsc_io_request_t send_pci, const unsigned char *send_buffer, -- Bob Dunlop From wk at gnupg.org Wed Sep 6 17:38:58 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Sep 6 17:41:33 2006 Subject: Declaration correction in pcsc-wrapper.c In-Reply-To: <20060906132134.GA7640@xyzzy.org.uk> (Bob Dunlop's message of "Wed, 6 Sep 2006 14:21:34 +0100") References: <20060906132134.GA7640@xyzzy.org.uk> Message-ID: <87hczlhunh.fsf@wheatstone.g10code.de> On Wed, 6 Sep 2006 15:21, Bob Dunlop said: > -long (* pcsc_end_transaction) (unsigned long card); > +long (* pcsc_end_transaction) (unsigned long card, > + unsigned long disposition); Applied to both files. Thanks. Shalom-Salam, Werner From rw at rlworkman.net Sat Sep 9 07:35:54 2006 From: rw at rlworkman.net (Robby Workman) Date: Sat Sep 9 08:55:52 2006 Subject: Compile error with gpgme-1.1.2 Message-ID: <450252BA.40401@rlworkman.net> While attempting to compile gpgme 1.1.2, I encountered this error: http://rlworkman.net/linux/gpgme_error_1 For those who don't want to click links, the first part of the actual error is: In file included from ath-pthread.c:36: /usr/include/pthread.h:285: error: conflicting types for 'pthread_t' /usr/include/bits/pthreadtypes.h:150: error: previous declaration of 'pthread_t' was here In searching the archives, I found something similar to this from back in 2005: http://lists.gnupg.org/pipermail/gpa-dev/2005-September/002322.html However, a fix was committed in 1.1.0 (iirc) according to the ChangeLog. Other likely relevant information: pth was compiled with --prefix=/usr --sysconfdir=/etc --enable-shared=yes --enable-static=no --enable-pthread originally; however, I have rebuilt it with --disable-pthread and then attempted gpgme afterward, but the same error occurs. The installed kernel headers are 2.4.33.3, and glibc is version 2.3.6. OS is Slackware -current (11.0rc4+). TIA, RW (robw810) -- http://rlworkman.net From yanagisawa at csg.is.titech.ac.jp Sun Sep 10 09:55:33 2006 From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA) Date: Sun Sep 10 09:54:08 2006 Subject: I ported Camellia (RFC3713) to the GnuPG 1.4.5. In-Reply-To: <8764g1jrku.fsf@wheatstone.g10code.de> References: <20060905202029.195f3ba1.yanagisawa@csg.is.titech.ac.jp> <8764g1jrku.fsf@wheatstone.g10code.de> Message-ID: <20060910165533.71539dff.yanagisawa@csg.is.titech.ac.jp> On Wed, 06 Sep 2006 11:02:25 +0200 Werner Koch wrote: > However, it might be useful to put it into Libgcrypt. The code is > similar it mereley needs a few tewaks for cipher registration. According to your suggestion, I also ported it to libgcrypt 1.2.3. I put a patch to: http://www.is.titech.ac.jp/~yanagis0/text/camellia-e.html Thanks -- ------------------------------------------------------- Yoshisato YANAGISAWA Dept. of Mathematical and Computing Sciences, Graduate School of Information Science and Engineering, Tokyo Institute of Technology. /* If you are an *BSD user, let's join http://bsdstats.org/ */ From blibbet at gmail.com Mon Sep 11 00:01:17 2006 From: blibbet at gmail.com (Lee Fisher) Date: Mon Sep 11 01:25:20 2006 Subject: gpg winsock versions Message-ID: <45048B2D.5070700@gmail.com> Hi, Gpg's WinSock version requirements are unclear. I assume they should be 2.x, since winsock2.h is included. In the last one below, the status is ignored. dirmngr-0.9.6/src/http.c if (WSAStartup(0x0101, &wsdata)) gnupg-1.4.5/keyserver/gpgkeys_finger.c if (WSAStartup(0x0101, &wsdata)) gnupg-1.4.5/util/http.c if (WSAStartup(0x0101, &wsdata)) gnupg-1.9.22/jnlib/w32-pth.c if (WSAStartup(0x202, &wsadat)) gnupg-1.9.22/agent/preset-passphrase.c WSAStartup(0x202, &wsadat); From rw at rlworkman.net Wed Sep 13 02:16:00 2006 From: rw at rlworkman.net (Robby Workman) Date: Wed Sep 13 02:14:37 2006 Subject: Compile error with gpgme-1.1.2 In-Reply-To: <450252BA.40401@rlworkman.net> References: <450252BA.40401@rlworkman.net> Message-ID: <45074DC0.6000008@rlworkman.net> Robby Workman wrote: > While attempting to compile gpgme 1.1.2, I encountered this error: > http://rlworkman.net/linux/gpgme_error_1 > > For those who don't want to click links, the first part of the actual > error is: > > In file included from ath-pthread.c:36: > /usr/include/pthread.h:285: error: conflicting types for 'pthread_t' > /usr/include/bits/pthreadtypes.h:150: error: previous declaration of > 'pthread_t' was here > > In searching the archives, I found something similar to this from back > in 2005: > http://lists.gnupg.org/pipermail/gpa-dev/2005-September/002322.html > However, a fix was committed in 1.1.0 (iirc) according to the ChangeLog. > > Other likely relevant information: > pth was compiled with --prefix=/usr --sysconfdir=/etc > --enable-shared=yes --enable-static=no --enable-pthread originally; > however, I have rebuilt it with --disable-pthread and then attempted > gpgme afterward, but the same error occurs. > The installed kernel headers are 2.4.33.3, and glibc is version 2.3.6. > OS is Slackware -current (11.0rc4+). I'm replying to my own post, as I've done a few more things to try and get better information. I've built (in this order) libgpg-error 1.3, libksba 1.0.0, libassuan 0.6.10, libgcrypt 1.2.3, pth 2.0.7, pinentry 0.7.2, dirmngr 0.9.6, and gnupg 1.9.22. Unless I've missed something, those are the most recent versions of each one. Now, when trying to build gpgme 1.1.2, I get the following error. gcc -shared .libs/ath.o .libs/funopen.o -Wl,--whole-archive ./.libs/libgpgme-real.a ../assuan/.libs/libassuan.a -Wl,--no-whole-archive /usr/lib/libgpg-error.so -march=i486 -mtune=i686 -Wl,--version-script=./libgpgme.vers -Wl,-soname -Wl,libgpgme.so.11 -o .libs/libgpgme.so.11.6.1 (cd .libs && rm -f libgpgme.so.11 && ln -s libgpgme.so.11.6.1 libgpgme.so.11) (cd .libs && rm -f libgpgme.so && ln -s libgpgme.so.11.6.1 libgpgme.so) creating libgpgme.la (cd .libs && rm -f libgpgme.la && ln -s ../libgpgme.la libgpgme.la) if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../assuan -O2 -march=i486 -mtune=i686 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF ".deps/ath-pthread.Tpo" -c -o ath-pthread.lo ath-pthread.c; \ then mv -f ".deps/ath-pthread.Tpo" ".deps/ath-pthread.Plo"; else rm -f ".deps/ath-pthread.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../assuan -O2 -march=i486 -mtune=i686 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF .deps/ath-pthread.Tpo -c ath-pthread.c -fPIC -DPIC -o .libs/ath-pthread.o In file included from ath-pthread.c:36: /usr/include/pthread.h:285: error: conflicting types for 'pthread_t' /usr/include/bits/pthreadtypes.h:150: error: previous declaration of 'pthread_t' was here /usr/include/pthread.h:286: error: conflicting types for 'pthread_attr_t' /usr/include/bits/pthreadtypes.h:52: error: previous declaration of 'pthread_attr_t' was here /usr/include/pthread.h:287: error: conflicting types for 'pthread_key_t' /usr/include/bits/pthreadtypes.h:80: error: previous declaration of 'pthread_key_t' was here /usr/include/pthread.h:289: error: conflicting types for 'pthread_mutexattr_t' /usr/include/bits/pthreadtypes.h:100: error: previous declaration of 'pthread_mutexattr_t' was here /usr/include/pthread.h:290: error: conflicting types for 'pthread_mutex_t' /usr/include/bits/pthreadtypes.h:93: error: previous declaration of 'pthread_mutex_t' was here /usr/include/pthread.h:291: error: conflicting types for 'pthread_condattr_t' /usr/include/bits/pthreadtypes.h:77: error: previous declaration of 'pthread_condattr_t' was here /usr/include/pthread.h:292: error: conflicting types for 'pthread_cond_t' /usr/include/bits/pthreadtypes.h:70: error: previous declaration of 'pthread_cond_t' was here /usr/include/pthread.h:293: error: conflicting types for 'pthread_rwlockattr_t' /usr/include/bits/pthreadtypes.h:126: error: previous declaration of 'pthread_rwlockattr_t' was here /usr/include/pthread.h:294: error: conflicting types for 'pthread_rwlock_t' /usr/include/bits/pthreadtypes.h:118: error: previous declaration of 'pthread_rwlock_t' was here /usr/include/pthread.h:357: error: conflicting types for 'pthread_kill' /usr/include/bits/sigthread.h:36: error: previous declaration of 'pthread_kill' was here /usr/include/pthread.h:357: error: conflicting types for 'pthread_kill' /usr/include/bits/sigthread.h:36: error: previous declaration of 'pthread_kill' was here ath-pthread.c: In function `_gpgme_ath_connect': ath-pthread.c:161: warning: passing arg 2 of `__pthread_connect' discards qualifiers from pointer target type make[3]: *** [ath-pthread.lo] Error 1 make[3]: Leaving directory `/tmp/build/gpgme-1.1.2/gpgme' make[2]: *** [all] Error 2 make[2]: Leaving directory `/tmp/build/gpgme-1.1.2/gpgme' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/build/gpgme-1.1.2' make: *** [all] Error 2 I've tried this after building pth both with and without pthreads enabled (and rebuilding everything that depends on it afterward), and it makes no difference either way. Am I missing something obvious (both in looking at the sources and/or otherwise), and if so, can someone please pop me with a cluestick? :) RW -- http://rlworkman.net From rw at rlworkman.net Wed Sep 13 06:52:52 2006 From: rw at rlworkman.net (Robby Workman) Date: Wed Sep 13 06:51:30 2006 Subject: SOLVED - Compile error with gpgme-1.1.2 In-Reply-To: <45074DC0.6000008@rlworkman.net> References: <450252BA.40401@rlworkman.net> <45074DC0.6000008@rlworkman.net> Message-ID: <45078EA4.5090305@rlworkman.net> Robby Workman wrote: >> The installed kernel headers are 2.4.33.3, and glibc is version >> 2.3.6. OS is Slackware -current (11.0rc4+). > > I'm replying to my own post, as I've done a few more things to try and > get better information. I've built (in this order) libgpg-error 1.3, > libksba 1.0.0, libassuan 0.6.10, libgcrypt 1.2.3, pth 2.0.7, pinentry > 0.7.2, dirmngr 0.9.6, and gnupg 1.9.22. Unless I've missed something, > those are the most recent versions of each one. Now, when trying to > build gpgme 1.1.2, I get the following error. > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../assuan -O2 -march=i486 > -mtune=i686 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT > ath-pthread.lo -MD -MP -MF .deps/ath-pthread.Tpo -c ath-pthread.c -fPIC > -DPIC -o .libs/ath-pthread.o > In file included from ath-pthread.c:36: > /usr/include/pthread.h:285: error: conflicting types for 'pthread_t' > /usr/include/bits/pthreadtypes.h:150: error: previous declaration of > 'pthread_t' was here > I've tried this after building pth both with and without pthreads > enabled (and rebuilding everything that depends on it afterward), and it > makes no difference either way. Well, it seems that building pth with --enable-pthread=yes installs /usr/include/pthread.h, which overwrites the one that was already there. Rebuilding it with pthread=no didn't make a difference due to the fact that the changed header was not removed when I removed the first package (since it's part of the glibc package initially). Copying over the original header from the glibc package and rebuilding pth with --enable-pthread=no solved the problem; gpgme built just fine. RW -- http://rlworkman.net From wk at gnupg.org Wed Sep 13 10:10:23 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Sep 13 10:16:32 2006 Subject: --output for In-Reply-To: (Greg Troxel's message of "Wed, 30 Aug 2006 07:59:09 -0400") References: <87irka4t0b.fsf@wheatstone.g10code.de> Message-ID: <871wqg191s.fsf@wheatstone.g10code.de> On Wed, 30 Aug 2006 13:59, Greg Troxel said: > e.g. can verify a signature and put the sig validation output > separately from the text. From this viewpoint, --list-keys outputs > data, so it should respect --output. Okay, will do so. Shalom-Salam, Werner From wk at gnupg.org Wed Sep 13 10:39:37 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Sep 13 10:41:29 2006 Subject: gpg winsock versions In-Reply-To: <45048B2D.5070700@gmail.com> (Lee Fisher's message of "Sun, 10 Sep 2006 15:01:17 -0700") References: <45048B2D.5070700@gmail.com> Message-ID: <87sliwyxbq.fsf@wheatstone.g10code.de> On Mon, 11 Sep 2006 00:01, Lee Fisher said: > Gpg's WinSock version requirements are unclear. > I assume they should be 2.x, since winsock2.h is included. I can't see that we include winsock2.h. We only include windows.h. > gnupg-1.9.22/jnlib/w32-pth.c > if (WSAStartup(0x202, &wsadat)) I am not sure why 2.2 is required. Timo, might now. For the other code 1.1 has always worked. > gnupg-1.9.22/agent/preset-passphrase.c > WSAStartup(0x202, &wsadat); This was a quick hack to make it work. There is a comment indicating that we need to do some other things. The w32 port of gnupg2 is not very matured yet. I have added error detection. Shalom-Salam, Werner From wk at gnupg.org Wed Sep 13 10:55:48 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Sep 13 11:01:31 2006 Subject: cross-certification In-Reply-To: <44F18B1A.12879.441D75BF@dirk.traulsen.lypso.de> (Dirk Traulsen's message of "Sun, 27 Aug 2006 12:07:54 +0200") References: <44F18B1A.12879.441D75BF@dirk.traulsen.lypso.de> Message-ID: <87odtkywkr.fsf@wheatstone.g10code.de> On Sun, 27 Aug 2006 12:07, Dirk Traulsen said: > @item --require-cross-certification > -@itemx --no-require-certification > +@itemx --no-require-cross-certification Fixed. Also made --require-cross-certification the defualt for gpg2. > 2. > When one issues the help command In the edit-key menu, there comes a list of commands. "cross-certify" is missing. I had a look at keyedit.c and the > non-listed commands are the short cuts and the aliases. So it doesn't seem to be a deliberate ommision. Here is a proposal for a text. (The only There are not that many signing subkeys out in the wild and the "backsign" command is a helper to fix existing keys. For new subkeys it is not required. The error message issued for a missing backsig points to a web page explaining how to rectify this. Thus there is no advertise this command. > other missing commands are delphoto and revphoto. Are they intentionally ommitted?) Not sure. David? > gpg: Signature made 08/22/06 10:02:04 using DSA key ID 0A77A149 > gpg: WARNING: signing subkey 0A77A149 is not cross-certified > gpg: please see http://www.gnupg.org/faq/subkey-cross-certify.html for more information > gpg: Can't check signature: general error > > This seems a bit too harsh for me, especially when it will be default. The signature could We want people to update their key. Experience shows that a warning is not sufficiebnt. If people don't like to update their key they may still use --no-require-cross-certification. > Then I wanted to export and import it on another computer. > gpg did not import (merge) the new key, because: > gpg: key 12345678: already in secret keyring. > gpg did not recognize the new cross-certification. I had to delete the old key before You only need to import the public key. Updating the secret key is a long-standing problem. Thanks, Werner From dshaw at jabberwocky.com Wed Sep 13 17:20:53 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Sep 13 17:19:33 2006 Subject: cross-certification In-Reply-To: <87odtkywkr.fsf@wheatstone.g10code.de> References: <44F18B1A.12879.441D75BF@dirk.traulsen.lypso.de> <87odtkywkr.fsf@wheatstone.g10code.de> Message-ID: <20060913152053.GA19824@jabberwocky.com> On Wed, Sep 13, 2006 at 10:55:48AM +0200, Werner Koch wrote: > On Sun, 27 Aug 2006 12:07, Dirk Traulsen said: > > > @item --require-cross-certification > > -@itemx --no-require-certification > > +@itemx --no-require-cross-certification > > Fixed. Also made --require-cross-certification the defualt for gpg2. I think this is not a good idea - at least, not yet. At the moment, there are very few keys that have cross certification, and GPG is the only program that generates keys with it. If --require-cross-certification is set by default, it will pretty much break signing subkeys for most people. We should give it more time with just the warning being printed before this default is changed. > > 2. > > When one issues the help command In the edit-key menu, there comes a list of commands. "cross-certify" is missing. I had a look at keyedit.c and the > > non-listed commands are the short cuts and the aliases. So it doesn't seem to be a deliberate ommision. Here is a proposal for a text. (The only > > There are not that many signing subkeys out in the wild and the > "backsign" command is a helper to fix existing keys. For new subkeys > it is not required. The error message issued for a missing backsig > points to a web page explaining how to rectify this. Thus there is no > advertise this command. > > > other missing commands are delphoto and revphoto. Are they intentionally ommitted?) > > Not sure. David? Yes, it was intentional. The reason is that delphoto is just another name for deluid and revphoto is just another name for revuid. Photos are just user IDs, and the XXXphoto commands are there in case people misunderstand that. The help command in --edit-key is like the --help command line option. It can't list everything or it will be useless. It should only list common options. David From wk at gnupg.org Wed Sep 13 18:21:43 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Sep 13 18:26:26 2006 Subject: cross-certification In-Reply-To: <20060913152053.GA19824@jabberwocky.com> (David Shaw's message of "Wed, 13 Sep 2006 11:20:53 -0400") References: <44F18B1A.12879.441D75BF@dirk.traulsen.lypso.de> <87odtkywkr.fsf@wheatstone.g10code.de> <20060913152053.GA19824@jabberwocky.com> Message-ID: <87odtjybxk.fsf@wheatstone.g10code.de> On Wed, 13 Sep 2006 17:20, David Shaw said: > I think this is not a good idea - at least, not yet. At the moment, > there are very few keys that have cross certification, and GPG is the > only program that generates keys with it. If > --require-cross-certification is set by default, it will pretty much > break signing subkeys for most people. My reasonsing is that people who are going to use gpg2 need to be a bit adventurous anyway and thus they should be able do create the backsigs. Lets see how this works out. It will be easy to change it back for the 2.0 release. Shalom-Salam, Werner From dshaw at jabberwocky.com Wed Sep 13 18:40:59 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Sep 13 18:39:30 2006 Subject: cross-certification In-Reply-To: <87odtjybxk.fsf@wheatstone.g10code.de> References: <44F18B1A.12879.441D75BF@dirk.traulsen.lypso.de> <87odtkywkr.fsf@wheatstone.g10code.de> <20060913152053.GA19824@jabberwocky.com> <87odtjybxk.fsf@wheatstone.g10code.de> Message-ID: <20060913164059.GB20120@jabberwocky.com> On Wed, Sep 13, 2006 at 06:21:43PM +0200, Werner Koch wrote: > On Wed, 13 Sep 2006 17:20, David Shaw said: > > > I think this is not a good idea - at least, not yet. At the moment, > > there are very few keys that have cross certification, and GPG is the > > only program that generates keys with it. If > > --require-cross-certification is set by default, it will pretty much > > break signing subkeys for most people. > > My reasonsing is that people who are going to use gpg2 need to be a > bit adventurous anyway and thus they should be able do create the > backsigs. Absolutely, but the problem with backsigs is that it requires the *other* person to create them. It is true that someone using gpg2 should be savvy enough to be able to turn the backsig check off, though. > Lets see how this works out. It will be easy to change it back for > the 2.0 release. Ok. David From wk at gnupg.org Thu Sep 14 08:45:08 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Sep 14 08:51:39 2006 Subject: cross-certification In-Reply-To: <20060913164059.GB20120@jabberwocky.com> (David Shaw's message of "Wed, 13 Sep 2006 12:40:59 -0400") References: <44F18B1A.12879.441D75BF@dirk.traulsen.lypso.de> <87odtkywkr.fsf@wheatstone.g10code.de> <20060913152053.GA19824@jabberwocky.com> <87odtjybxk.fsf@wheatstone.g10code.de> <20060913164059.GB20120@jabberwocky.com> Message-ID: <87k647x7yj.fsf@wheatstone.g10code.de> On Wed, 13 Sep 2006 18:40, David Shaw said: > Absolutely, but the problem with backsigs is that it requires the > *other* person to create them. It is true that someone using gpg2 Well, I have once been nagged for weeks by several others persons to to add a backsig on my key. Eventually I did it for this reasons ;-) Salam-Shalom, Werner From twoaday at gmx.net Thu Sep 14 09:44:07 2006 From: twoaday at gmx.net (Timo Schulz) Date: Thu Sep 14 11:25:31 2006 Subject: gpg winsock versions In-Reply-To: <87sliwyxbq.fsf@wheatstone.g10code.de> References: <45048B2D.5070700@gmail.com> <87sliwyxbq.fsf@wheatstone.g10code.de> Message-ID: <45090847.6000302@gmx.net> Werner Koch wrote: > I am not sure why 2.2 is required. Timo, might now. It's more a default that an required. Because 2.2 is the most widespread versions among the different Window types (XP, 2K, 9X). > For the other code 1.1 has always worked. I guess backward compatibility is provided by MS as long as possible. But IMHO it can't heart to use 2.2 as default because only Win95 had problems with it. Timo From wk at gnupg.org Thu Sep 14 16:50:39 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Sep 14 17:43:24 2006 Subject: [Announce] libgpg-error 1.4 released Message-ID: <87y7smec3k.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From ahasenack at terra.com.br Sun Sep 17 00:31:55 2006 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Sun Sep 17 01:51:34 2006 Subject: [Announce] libgpg-error 1.4 released In-Reply-To: <87y7smec3k.fsf@wheatstone.g10code.de> References: <87y7smec3k.fsf@wheatstone.g10code.de> Message-ID: <200609161931.57066.ahasenack@terra.com.br> On Thursday 14 September 2006 11:50, Werner Koch wrote: > Hi, > > We are pleased to announce version 1.4 of libgpg-error, > a library for common error values and messages in GnuPG components. The www.gnupg.org download page still links to version 1.3. From ariga at os.rim.or.jp Sun Sep 17 04:44:38 2006 From: ariga at os.rim.or.jp (ARIGA Seiji) Date: Sun Sep 17 06:21:51 2006 Subject: x509 v1 certificate Message-ID: <20060917.114438.71082783.say@khaotic.net> hi, all. i'm using gpgsm 1.9.20, libgpg-error 1.3, libksba 1.0.0, libgcrypt 1.2.2_1. does gpgsm (or libksba) support x509 v1 certificate ? if not, i want it to be supported very much because there are many certs having VeriSign's v1 cert as their root cert. // ARIGA Seiji [background] when i tried to verify email, gpgsm says, ---- >gpgsm --verify email.sig email gpgsm: Signature made 2006-08-28 22:00:38 using certificate ID 30BFD581 gpgsm: invalid certification chain: No value ---- so, i tried debug option as follows, ---- >gpgsm --verify email.sig email --debug-no-chain-validation gpgsm: Signature made 2006-08-28 22:00:38 using certificate ID 30BFD581 gpgsm: WARNING: bypassing certificate chain validation gpgsm: Good signature from "/CN=SUMITOMO MITSUI BANKING CORPORATION/OU=Class 3 Organizational E-Mail Certificate/OU=Terms of use at https:\x2f\x2fwww.verisign.com\x2frpa (c)05/OU=Mass Retail Dept.,Consumer Banking Unit/O=SUMITOMO MITSUI BANKING CORPORATION/L=Chiyoda-ku/ST=Tokyo/C=JP/EMail=SMBC_service@dn.smbc.co.jp" gpgsm: aka "SMBC_service@dn.smbc.co.jp" ---- then, i though the signature itself is correct but there are something wrong in the chained certificates. after looking through the code for a while, i came to think gpgsm/libksba doesn't support x509 v1 cert which doesn't have x509 extensions (and that's what "No value" says). here is excerpt from "openssl pkcs7 -inform der -in email.sig -text -print_certs". ---- Version: 3 (0x2) Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)04, CN=VeriSign Class 3 Organizational CA Subject: C=JP, ST=Tokyo, L=Chiyoda-ku, O=SUMITOMO MITSUI BANKING CORPORATION, OU=Mass Retail Dept.,Consumer Banking Unit, OU=Terms of use at https://www.verisign.com/rpa (c)05, OU=Class 3 Organizational E-Mail Certificate, CN=SUMITOMO MITSUI BANKING CORPORATION/emailAddress=SMBC_service@dn.smbc.co.jp X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Key Encipherment ---- Version: 3 (0x2) Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)04, CN=VeriSign Class 3 Organizational CA X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Key Usage: Certificate Sign, CRL Sign ---- Version: 1 (0x0) Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network ---- From alguibert+gpd at free.fr Sun Sep 10 08:31:54 2006 From: alguibert+gpd at free.fr (Alain Guibert) Date: Mon Sep 18 13:05:17 2006 Subject: libassuan 0.6.10 build fails on old Linux Message-ID: <20060910063154.GB9023@free.fr> Hello, On my old Linux box (Intel Pentium 200 MMX, Debian bo, kernel 2.0.40, gcc 2.7.2.1, libc 5.4.33, GNU ld cygnus-2.7.1) during libassuan 0.6.10 build, make fails: | gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -c assuan-domain-connect.c | assuan-domain-connect.c: In function `domain_reader': | assuan-domain-connect.c:139: `MSG_TRUNC' undeclared (first use this function) | assuan-domain-connect.c:139: (Each undeclared identifier is reported only once | assuan-domain-connect.c:139: for each function it appears in.) | assuan-domain-connect.c:210: warning: implicit declaration of function `CMSG_DATA' | make[3]: *** [assuan-domain-connect.o] Error 1 | make[3]: Leaving directory `/tmp/libassuan-0.6.10/src' | make[2]: *** [all] Error 2 | make[2]: Leaving directory `/tmp/libassuan-0.6.10/src' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/tmp/libassuan-0.6.10' | make: *** [all] Error 2 Alain. From wk at gnupg.org Mon Sep 18 14:50:36 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 18 14:56:38 2006 Subject: x509 v1 certificate In-Reply-To: <20060917.114438.71082783.say@khaotic.net> (ARIGA Seiji's message of "Sun, 17 Sep 2006 11:44:38 +0900 (JST)") References: <20060917.114438.71082783.say@khaotic.net> Message-ID: <87lkohcp9f.fsf@wheatstone.g10code.de> On Sun, 17 Sep 2006 04:44, ARIGA Seiji said: > does gpgsm (or libksba) support x509 v1 certificate ? Yes. > if not, i want it to be supported very much because there are many > certs having VeriSign's v1 cert as their root cert. We don't support the MD2 hash algorithm as used by some Verisign certificates. Shalom-Salam, Werner From wk at gnupg.org Mon Sep 18 15:20:02 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 18 15:26:39 2006 Subject: GnuPG 1.9.23 released Message-ID: <877j01cnwd.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of GnuPG 1.9.23 - the branch of GnuPG heading towards a GnuPG 2.0 and featuring the OpenPGP as well as the S/MIME protocol. This is a BETA release and not suitable for production use! Noteworthy changes in version 1.9.23 (2006-09-18) ------------------------------------------------- * Regular man pages for most tools are now build directly from the Texinfo source. * The gpg code from 1.4.5 has been fully merged into this release. For production use of OpenPGP the gpg version 1.4.5 is still recommended. Note, that gpg will be installed under the name gpg2 to allow coexisting with an 1.4.x gpg. * API change in gpg-agent's pkdecrypt command. Thus an older gpgsm may not be used with the current gpg-agent. * The scdaemon will now call a script on reader status changes. * gpgsm now allows file descriptor passing for "INPUT", "OUTPUT" and "MESSAGE". * The gpgsm server may now output a key listing to the output file handle. This needs to be enabled using "OPTION list-to-output=1". * The --output option of gpgsm has now an effect on list-keys. * New gpgsm commands --dump-chain and list-chain. * gpg-connect-agent has new options to utilize descriptor passing. * A global trustlist may now be used. See doc/examples/trustlist.txt. * When creating a new pubring.kbx keybox common certificates are imported. Note, that gpg2 is now build by default and may actually be used. There are some minor things missing but most people should not be affected by this. Please test this release and report bugs. If you are a translator, please do not yet start with translations but wait for the first release candidate which is planned for early October. You may download it from one of the mirrors as listed at http://www.gnupg.org/download/mirrors.html or direct from the master server ftp://ftp.gnupg.org: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.23.tar.bz2 (2227k) ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.23.tar.bz2.sig or as a patch against the previous release: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.22-1.9.23.diff.bz2 (495k) For help on installing or running GnuPG 1.9 you should send mail to the gnupg-users mailing list or to one of the country specific lists. See http://www.gnupg.org/documentation/mailing-lists.html . 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 gpg's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. Happy hacking, Werner -- Werner Koch The GnuPG Experts http://g10code.com Join the Fellowship and protect your Freedom! http://www.fsfe.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20060918/e185bcef/attachment.pgp From beebe at math.utah.edu Mon Sep 18 19:49:20 2006 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Mon Sep 18 22:51:48 2006 Subject: libassuan-0.9.0 build problems Message-ID: In order to build gnupg-1.9.23, it is necessary to first install four dependent packages: libassuan, libgpg-error libksba, and pth. I've had reasonable success with three of them, but libassuan-0.9.0 has build failures, and test failures on several platforms. The validation tests failed on several systems because /etc/motd does not exist: here is what happens: fdpassing[25781.4] DBG: -> OK Pleased to meet you fdpassing[25780]: failed to open `/etc/motd': No such file or directory fdpassing[25781.4] DBG: <- BYE fdpassing[25781.4] DBG: -> OK closing connection FAIL: fdpassing ====================================== 1 of 1 tests failed Please report to gnupg-devel@gnupg.org ====================================== There are complete failures on these systems: Apple Mac OS X PowerPC DEC OSF/1 Alpha SGI IRIX 6.5 MIPS Sun Solaris 7, 8, 9, 10 SPARC Sun Solaris 10 IA-32 Below is a summary of the build failures. I include only one instance of each problem type. ============================================================ Machinetype: SGI Origin/200-4 (180 MHz) (4 R10000 CPUs); IRIX 6.5 Remote c89 version: MIPSpro Compilers: Version 7.3.1.3m Configure environment: CC=c89 CXX=CC CFLAGS=-I/usr/local/include CXXFLAGS=-I/usr/local/include LDFLAGS=-Wl,-rpath,/usr/local/libn32 c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I/usr/local/include -c assuan-client.c cc-1185 c89: WARNING File = assuan-client.c, Line = 47 An enumerated type is mixed with another type. rc = _assuan_read_line (ctx); ^ cc-1185 c89: WARNING File = assuan-client.c, Line = 107 An enumerated type is mixed with another type. rc = _assuan_error (ASSUAN_Invalid_Response); ^ cc-1185 c89: WARNING File = assuan-client.c, Line = 148 An enumerated type is mixed with another type. return rc; ^ cc-1185 c89: WARNING File = assuan-client.c, Line = 151 An enumerated type is mixed with another type. return 0; /* Don't expect a response for a comment line. */ ^ cc-1185 c89: WARNING File = assuan-client.c, Line = 156 An enumerated type is mixed with another type. return rc; /* error reading from server */ ^ cc-1185 c89: WARNING File = assuan-client.c, Line = 229 An enumerated type is mixed with another type. return rc; ^ source='assuan-pipe-server.c' object='assuan-pipe-server.o' libtool=no \ c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I/usr/local/include -c assuan-socket-server.c cc-1164 c89: WARNING File = assuan-socket-server.c, Line = 90 Argument of type "size_t *" is incompatible with parameter of type "int *". fd = accept (ctx->listen_fd, (struct sockaddr*)&clnt_addr, &len ); ^ source='assuan-pipe-connect.c' object='assuan-pipe-connect.o' libtool=no \ DEPDIR=.deps depmode=sgi /bin/sh ../depcomp \ c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I/usr/local/include -c assuan-pipe-connect.c cc-1185 c89: WARNING File = assuan-pipe-connect.c, Line = 159 An enumerated type is mixed with another type. err = _assuan_error (ASSUAN_Connect_Failed); ^ cc-1185 c89: WARNING File = assuan-pipe-connect.c, Line = 188 An enumerated type is mixed with another type. return _assuan_error (ASSUAN_Invalid_Value); ^ cc-1185 c89: WARNING File = assuan-pipe-connect.c, Line = 195 An enumerated type is mixed with another type. return _assuan_error (ASSUAN_General_Error); ^ cc-1185 c89: WARNING File = assuan-pipe-connect.c, Line = 201 An enumerated type is mixed with another type. return _assuan_error (ASSUAN_General_Error); ^ cc-1185 c89: WARNING File = assuan-pipe-connect.c, Line = 204 An enumerated type is mixed with another type. err = _assuan_new_context (ctx); ^ cc-1185 c89: WARNING File = assuan-pipe-connect.c, Line = 229 An enumerated type is mixed with another type. return _assuan_error (ASSUAN_General_Error); ^ cc-1162 c89: ERROR File = assuan-pipe-connect.c, Line = 324 Too few arguments in function call. unsetenv ("_assuan_connection_fd"); ^ cc-1185 c89: WARNING File = assuan-pipe-connect.c, Line = 374 An enumerated type is mixed with another type. return _assuan_error (ASSUAN_Invalid_Value); ^ cc-1185 c89: WARNING File = assuan-pipe-connect.c, Line = 383 An enumerated type is mixed with another type. return _assuan_error (ASSUAN_General_Error); ^ cc-1185 c89: WARNING File = assuan-pipe-connect.c, Line = 386 An enumerated type is mixed with another type. err = _assuan_new_context (ctx); ^ cc-1185 c89: WARNING File = assuan-pipe-connect.c, Line = 407 An enumerated type is mixed with another type. return _assuan_error (ASSUAN_General_Error); ^ cc-1185 c89: WARNING File = assuan-pipe-connect.c, Line = 505 An enumerated type is mixed with another type. return 0; ^ 1 error detected in the compilation of "assuan-pipe-connect.c". ============================================================ Machinetype: SGI Origin/200-4 (180 MHz) (4 R10000 CPUs); IRIX 6.5 Remote gcc version: gcc (GCC) 3.4.3 Configure environment: CC=gcc CFLAGS=-I/usr/local/include CXX=g++ CXXFLAGS=-I/usr/local/include LDFLAGS=-Wl,-rpath,/usr/local/libn32 if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT assuan-pipe-connect.o -MD -MP -MF ".deps/assuan-pipe-connect.Tpo" -c -o assuan-pipe-connect.o assuan-pipe-connect.c; \ then mv -f ".deps/assuan-pipe-connect.Tpo" ".deps/assuan-pipe-connect.Po"; else rm -f ".deps/assuan-pipe-connect.Tpo"; exit 1; fi assuan-pipe-connect.c: In function `pipe_connect_unix': assuan-pipe-connect.c:324: error: too few arguments to function `_assuan_setenv' make[3]: *** [assuan-pipe-connect.o] Error 1 ============================================================ Machinetype: Sun W40z (4 CPUs, 2400 MHz AMD64 Opteron, 8GB RAM); FreeBSD 5.0-RELEASE #0 Remote gcc version: gcc (GCC) 3.4.3 Configure environment: CC=gcc CFLAGS=-I/usr/local/include CXX=g++ LDFLAGS=-Wl,-rpath,/usr/local/lib if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT putc_unlocked.o -MD -MP -MF ".deps/putc_unlocked.Tpo" -c -o putc_unlocked.o putc_unlocked.c; \ then mv -f ".deps/putc_unlocked.Tpo" ".deps/putc_unlocked.Po"; else rm -f ".deps/putc_unlocked.Tpo"; exit 1; fi putc_unlocked.c:30: error: redefinition of '__sputc' /usr/local/lib/gcc/i386-unknown-freebsd5.0/3.4.3/include/stdio.h:405: error: previous definition of '__sputc' was here make[3]: *** [putc_unlocked.o] Error 1 ============================================================ Machinetype: Apple Power Mac G4 (2 1420 MHz PowerPC G4 (3.3) CPUs, 2GB RAM); Darwin 7.9.0 (Mac OS X Server 10.3.9 (7W98)) Remote gcc version: gcc (GCC) 3.4.3 Configure environment: CC=gcc CXX=g++ LIBS=-lcc_dynamic gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o fdpassing fdpassing.o ../src/libassuan.a -lcc_dynamic /usr/bin/ld: Undefined symbols: _pth_fdmode _pth_read _pth_select _pth_waitpid _pth_write collect2: ld returned 1 exit status This failure happened on all build attempts on Apple Mac OS X. The -lpth library is not being specified, although the library is certainly installed: % ls -ltr /usr/local/lib/libpth* -rwxr-xr-x 1 beebe 10 107272 Sep 23 2004 /usr/local/lib/libpth.20.0.22.dylib -rwxr-xr-x 1 beebe 10 803 Sep 18 08:42 /usr/local/lib/libpth.la lrwxr-xr-x 1 root 10 20 Sep 18 08:42 /usr/local/lib/libpth.dylib -> libpth.20.0.27.dylib lrwxr-xr-x 1 root 10 20 Sep 18 08:42 /usr/local/lib/libpth.20.dylib -> libpth.20.0.27.dylib -rwxr-xr-x 1 beebe 10 109560 Sep 18 08:42 /usr/local/lib/libpth.20.0.27.dylib -rw-r--r-- 1 beebe 10 115920 Sep 18 08:42 /usr/local/lib/libpth.a ============================================================ Machinetype: DEC Alpha 4100-5/466 (4 21164 EV5 CPUs, 466 MHz, 2GB RAM); OSF/1 4.0F Remote cc version: DEC C V5.9-005 on Digital UNIX V4.0 (Rev. 1229) Configure environment: CC=cc CFLAGS="-ieee -I/usr/local/include" CXX=cxx CXXFLAGS="-ieee -I/usr/local/include" LDFLAGS="-Wl,-rpath,/usr/local/lib -Wl,-oldstyle_liblookup -L/usr/local/lib" LIBS="-lsnprintf" FC=f77 F77=f77 cc -std1 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -ieee -I/usr/local/include -c assuan-socket-server.c cc: Info: assuan.h, line 283: Trailing comma found in enumerator list. (trailcomma) } assuan_error_t; ^ cc: Warning: assuan-socket-server.c, line 90: In this statement, the referenced type of the pointer value "&len" is "unsigned long", which is not compatible with "int". (ptrmismatch) fd = accept (ctx->listen_fd, (struct sockaddr*)&clnt_addr, &len ); -------------------------------------------------------------^ source='assuan-pipe-connect.c' object='assuan-pipe-connect.o' libtool=no \ DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp \ cc -std1 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -ieee -I/usr/local/include -c assuan-pipe-connect.c cc: Info: assuan.h, line 283: Trailing comma found in enumerator list. (trailcomma) } assuan_error_t; ^ cc: Error: assuan-pipe-connect.c, line 380: In this statement, "AF_LOCAL" is not declared. (undeclared) if ( socketpair (AF_LOCAL, SOCK_STREAM, 0, fds) ) -------------------^ ============================================================ Machinetype: Sun Ultra Enterprise 2900 (4 CPUs, 1050 MHz UltraSPARC-IV, 16GB); Solaris 10 Remote gcc4 version: gcc4 (GCC) 4.0.2 Configure environment: CC=/usr/local/test/bin/gcc CFLAGS=-I/usr/local/include CXX=/usr/local/test/bin/g++ CXXFLAGS=-I/usr/local/include LDFLAGS="-R/usr/local/lib -L/usr/local/lib" if /usr/local/test/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT assuan-socket-server.o -MD -MP -MF ".deps/assuan-socket-server.Tpo" -c -o assuan-socket-server.o assuan-socket-server.c; \ then mv -f ".deps/assuan-socket-server.Tpo" ".deps/assuan-socket-server.Po"; else rm -f ".deps/assuan-socket-server.Tpo"; exit 1; fi if /usr/local/test/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT assuan-pipe-connect.o -MD -MP -MF ".deps/assuan-pipe-connect.Tpo" -c -o assuan-pipe-connect.o assuan-pipe-connect.c; \ then mv -f ".deps/assuan-pipe-connect.Tpo" ".deps/assuan-pipe-connect.Po"; else rm -f ".deps/assuan-pipe-connect.Tpo"; exit 1; fi assuan-pipe-connect.c: In function 'socketpair_connect': assuan-pipe-connect.c:380: error: 'AF_LOCAL' undeclared (first use in this function) assuan-pipe-connect.c:380: error: (Each undeclared identifier is reported only once assuan-pipe-connect.c:380: error: for each function it appears in.) make[3]: *** [assuan-pipe-connect.o] Error 1 make[3]: Leaving directory `/local/build/gcc4/libassuan-0.9.0/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/local/build/gcc4/libassuan-0.9.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/local/build/gcc4/libassuan-0.9.0' This same error happens for all tested compilers on Solaris 7, 8, 9, and 10 (SPARC), and 10 (IA-32), completing preventing builds of libassuan on those systems. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From ariga at os.rim.or.jp Tue Sep 19 01:32:56 2006 From: ariga at os.rim.or.jp (ARIGA Seiji) Date: Tue Sep 19 01:31:15 2006 Subject: x509 v1 certificate In-Reply-To: <87lkohcp9f.fsf@wheatstone.g10code.de> References: <20060917.114438.71082783.say@khaotic.net> <87lkohcp9f.fsf@wheatstone.g10code.de> Message-ID: <20060919.083256.39153403.say@khaotic.net> hi. thank you for your response. On Mon, 18 Sep 2006 14:50:36 +0200, Werner Koch wrote, > > does gpgsm (or libksba) support x509 v1 certificate ? > Yes. hmm. let me ask one more. output below is from "gpgsm -kv". you can see "[error: No value]" at "key usage:" and "chain length:" field (which, i think, is in x509 extension field that x509 version 1 cert doesn't have). isn't this the same error i got when i run "gpgsm --verify" ? ---- Serial number: 7DD9FE07CFA81EB7107967FBA78934C6 Issuer: /OU=VeriSign Trust Network/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=Class 3 Public Primary Certification Authority - G2/O=VeriSign, Inc./C=US Subject: /OU=VeriSign Trust Network/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=Class 3 Public Primary Certification Authority - G2/O=VeriSign, Inc./C=US validity: 1998-05-18 00:00:00 through 2028-08-01 23:59:59 key type: 1024 bit RSA key usage: [error: No value] chain length: [error: No value] fingerprint: 85:37:1C:A6:E5:50:14:3D:CE:28:03:47:1B:DE:3A:09:E8:F8:77:0F ---- also, i think following is my guess on how i got an error, "gpgsm: invalid certification chain: No value" (gnupg) verify.c rc = gpgsm_validate_chain (ctrl, cert, keyexptime, 0, NULL, 0); certchain.c:gpgsm_validate_chain() rc = allowed_ca (subject_cert, NULL, listmode, fp); certchain.c:allowed_ca() err = ksba_cert_is_ca (cert, &flag, chainlen); (libksba) cert.c:ksba_cert_is_ca() err=ksba_cert_get_extension (cert, idx, &oid, &crit,&off, &derlen) cert.c:ksba_cert_get_extension() err = read_extensions (cert); cert.c:read_extensions() return gpg_error (GPG_ERR_NO_VALUE); > > if not, i want it to be supported very much because there are many > > certs having VeriSign's v1 cert as their root cert. > We don't support the MD2 hash algorithm as used by some Verisign > certificates. it seems that is not the cause in this case. could you see attachment which is full a output from "openssl pkcs7 -text -print_certs" ? hash algorithm looks like SHA1. // ARIGA Seiji -------------- next part -------------- Certificate: Data: Version: 3 (0x2) Serial Number: 51:29:bd:a9:38:a6:b9:c9:5d:d5:59:e5:ae:54:87:30 Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)04, CN=VeriSign Class 3 Organizational CA Validity Not Before: Apr 12 00:00:00 2006 GMT Not After : Apr 11 23:59:59 2007 GMT Subject: C=JP, ST=Tokyo, L=Chiyoda-ku, O=SUMITOMO MITSUI BANKING CORPORATION, OU=Mass Retail Dept.,Consumer Banking Unit, OU=Terms of use at https://www.verisign.com/rpa (c)05, OU=Class 3 Organizational E-Mail Certificate, CN=SUMITOMO MITSUI BANKING CORPORATION/emailAddress=SMBC_service@dn.smbc.co.jp Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:d9:01:b6:30:36:40:96:f9:6b:5d:74:3d:bc:b2: 55:8b:b0:28:e6:bc:ac:db:a8:8a:20:97:c7:57:97: 05:1e:d8:1a:b8:50:82:d4:25:37:45:da:36:2e:ac: 2e:d5:bc:9e:a1:66:6f:ac:ad:a1:e7:4d:86:fd:21: e6:ca:d8:0d:14:3f:50:58:81:9b:76:37:77:7f:80: 03:02:ef:69:9e:93:7f:e4:fb:39:c7:b0:f1:74:0d: 53:c2:d6:4a:e8:58:df:20:4e:1e:1d:78:66:1c:91: e9:19:60:73:70:66:df:c1:5f:ad:47:d5:6d:2c:01: db:cc:49:e7:0e:67:77:fd:1f Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Certificate Policies: Policy: 2.16.840.1.113733.1.7.23.3 CPS: https://www.verisign.com/rpa X509v3 Key Usage: Digital Signature, Key Encipherment X509v3 CRL Distribution Points: URI:http://orgc3-crl.verisign.com/orgc3.crl X509v3 Subject Alternative Name: email:SMBC_service@dn.smbc.co.jp Signature Algorithm: sha1WithRSAEncryption 3e:b7:c3:95:a9:48:88:12:78:fb:33:29:1b:25:0f:3f:de:9c: 1b:c2:03:a4:a6:f4:02:cd:dc:26:9c:f1:42:80:6f:26:8e:e8: c7:3b:69:b3:e1:df:ab:1d:68:87:ad:d8:9d:9c:75:31:45:fb: 39:c2:29:48:49:01:9e:c9:12:7c:f0:09:f7:39:e8:5a:a0:ad: 1c:9b:54:e9:ab:e2:f2:0e:65:44:b2:b9:0f:84:cb:99:68:54: 0e:f9:6b:f8:ec:c6:10:b7:26:cb:60:e2:eb:18:41:82:13:f7: 88:f1:c4:3a:f4:62:fe:95:5d:c1:5f:31:a3:f2:9f:d1:f6:89: 0f:05:79:0a:60:b6:a0:fa:58:0b:34:8a:c0:80:20:3c:b4:0e: c8:04:67:34:86:74:11:94:8c:c5:51:ec:b3:08:51:03:5d:25: 2c:25:88:66:da:12:8f:94:09:e9:eb:04:55:d6:9d:af:ae:b9: 5a:ec:74:ad:a1:ce:75:22:89:39:27:51:85:d4:2f:7a:54:c6: 9d:4e:09:3c:bd:f1:20:f9:1e:8f:13:09:ad:ac:ef:90:dd:59: 56:ef:ce:0e:33:2c:7c:c1:b4:d5:e0:d6:99:b2:2b:b6:40:a4: c1:89:bd:ba:de:98:56:e5:28:ed:86:18:1b:f4:a6:4e:2f:7b: 10:f6:f3:1c -----BEGIN CERTIFICATE----- MIIE2TCCA8GgAwIBAgIQUSm9qTimucld1VnlrlSHMDANBgkqhkiG9w0BAQUFADCB sTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNDErMCkGA1UEAxMi VmVyaVNpZ24gQ2xhc3MgMyBPcmdhbml6YXRpb25hbCBDQTAeFw0wNjA0MTIwMDAw MDBaFw0wNzA0MTEyMzU5NTlaMIIBXDELMAkGA1UEBhMCSlAxDjAMBgNVBAgTBVRv a3lvMRMwEQYDVQQHEwpDaGl5b2RhLWt1MSwwKgYDVQQKEyNTVU1JVE9NTyBNSVRT VUkgQkFOS0lORyBDT1JQT1JBVElPTjEwMC4GA1UECxMnTWFzcyBSZXRhaWwgRGVw dC4sQ29uc3VtZXIgQmFua2luZyBVbml0MTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEyMDAGA1UECxMp Q2xhc3MgMyBPcmdhbml6YXRpb25hbCBFLU1haWwgQ2VydGlmaWNhdGUxLDAqBgNV BAMTI1NVTUlUT01PIE1JVFNVSSBCQU5LSU5HIENPUlBPUkFUSU9OMSkwJwYJKoZI hvcNAQkBFhpTTUJDX3NlcnZpY2VAZG4uc21iYy5jby5qcDCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA2QG2MDZAlvlrXXQ9vLJVi7Ao5rys26iKIJfHV5cFHtga uFCC1CU3Rdo2Lqwu1byeoWZvrK2h502G/SHmytgNFD9QWIGbdjd3f4ADAu9pnpN/ 5Ps5x7DxdA1TwtZK6FjfIE4eHXhmHJHpGWBzcGbfwV+tR9VtLAHbzEnnDmd3/R8C AwEAAaOBwjCBvzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwMw KjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNV HQ8EBAMCBaAwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL29yZ2MzLWNybC52ZXJp c2lnbi5jb20vb3JnYzMuY3JsMCUGA1UdEQQeMByBGlNNQkNfc2VydmljZUBkbi5z bWJjLmNvLmpwMA0GCSqGSIb3DQEBBQUAA4IBAQA+t8OVqUiIEnj7MykbJQ8/3pwb wgOkpvQCzdwmnPFCgG8mjujHO2mz4d+rHWiHrdidnHUxRfs5wilISQGeyRJ88An3 OehaoK0cm1Tpq+LyDmVEsrkPhMuZaFQO+Wv47MYQtybLYOLrGEGCE/eI8cQ69GL+ lV3BXzGj8p/R9okPBXkKYLag+lgLNIrAgCA8tA7IBGc0hnQRlIzFUeyzCFEDXSUs JYhm2hKPlAnp6wRV1p2vrrla7HStoc51Iok5J1GF1C96VMadTgk8vfEg+R6PEwmt rO+Q3VlW784OMyx8wbTV4NaZsiu2QKTBib263phW5Sjthhgb9KZOL3sQ9vMc -----END CERTIFICATE----- Certificate: Data: Version: 1 (0x0) Serial Number: 7d:d9:fe:07:cf:a8:1e:b7:10:79:67:fb:a7:89:34:c6 Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network Validity Not Before: May 18 00:00:00 1998 GMT Not After : Aug 1 23:59:59 2028 GMT Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:cc:5e:d1:11:5d:5c:69:d0:ab:d3:b9:6a:4c:99: 1f:59:98:30:8e:16:85:20:46:6d:47:3f:d4:85:20: 84:e1:6d:b3:f8:a4:ed:0c:f1:17:0f:3b:f9:a7:f9: 25:d7:c1:cf:84:63:f2:7c:63:cf:a2:47:f2:c6:5b: 33:8e:64:40:04:68:c1:80:b9:64:1c:45:77:c7:d8: 6e:f5:95:29:3c:50:e8:34:d7:78:1f:a8:ba:6d:43: 91:95:8f:45:57:5e:7e:c5:fb:ca:a4:04:eb:ea:97: 37:54:30:6f:bb:01:47:32:33:cd:dc:57:9b:64:69: 61:f8:9b:1d:1c:89:4f:5c:67 Exponent: 65537 (0x10001) Signature Algorithm: sha1WithRSAEncryption 51:4d:cd:be:5c:cb:98:19:9c:15:b2:01:39:78:2e:4d:0f:67: 70:70:99:c6:10:5a:94:a4:53:4d:54:6d:2b:af:0d:5d:40:8b: 64:d3:d7:ee:de:56:61:92:5f:a6:c4:1d:10:61:36:d3:2c:27: 3c:e8:29:09:b9:11:64:74:cc:b5:73:9f:1c:48:a9:bc:61:01: ee:e2:17:a6:0c:e3:40:08:3b:0e:e7:eb:44:73:2a:9a:f1:69: 92:ef:71:14:c3:39:ac:71:a7:91:09:6f:e4:71:06:b3:ba:59: 57:26:79:00:f6:f8:0d:a2:33:30:28:d4:aa:58:a0:9d:9d:69: 91:fd -----BEGIN CERTIFICATE----- MIIDAjCCAmsCEH3Z/gfPqB63EHln+6eJNMYwDQYJKoZIhvcNAQEFBQAwgcExCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xh c3MgMyBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcy MTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3Jp emVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMB4X DTk4MDUxODAwMDAwMFoXDTI4MDgwMTIzNTk1OVowgcExCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMyBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEo YykgMTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDMXtERXVxp0KvTuWpMmR9ZmDCOFoUgRm1HP9SFIIThbbP4 pO0M8RcPO/mn+SXXwc+EY/J8Y8+iR/LGWzOOZEAEaMGAuWQcRXfH2G71lSk8UOg0 13gfqLptQ5GVj0VXXn7F+8qkBOvqlzdUMG+7AUcyM83cV5tkaWH4mx0ciU9cZwID AQABMA0GCSqGSIb3DQEBBQUAA4GBAFFNzb5cy5gZnBWyATl4Lk0PZ3BwmcYQWpSk U01UbSuvDV1Ai2TT1+7eVmGSX6bEHRBhNtMsJzzoKQm5EWR0zLVznxxIqbxhAe7i F6YM40AIOw7n60RzKprxaZLvcRTDOaxxp5EJb+RxBrO6WVcmeQD2+A2iMzAo1KpY oJ2daZH9 -----END CERTIFICATE----- Certificate: Data: Version: 3 (0x2) Serial Number: 7a:83:35:8f:7f:e2:a9:0b:56:f6:a6:2d:82:5a:64:fe Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network Validity Not Before: Dec 14 00:00:00 2004 GMT Not After : Dec 13 23:59:59 2009 GMT Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)04, CN=VeriSign Class 3 Organizational CA Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:c3:e6:d4:7e:53:c9:82:8a:98:2c:f7:5b:48:8c: 83:ae:a0:e5:57:fe:41:34:9f:00:7e:80:92:40:61: 09:2e:11:3f:25:83:69:e1:a3:98:d7:08:24:84:8e: c8:7a:ef:37:fd:7b:7f:37:66:1d:46:1e:c1:80:54: 5d:b2:0f:5e:b1:cc:19:e9:b8:4e:21:70:7d:f0:5a: 0f:37:16:af:1f:bc:90:fb:57:73:ac:39:37:79:6d: 36:bb:96:e3:87:d6:1f:43:d0:30:8e:79:47:bd:8c: 70:41:a9:62:08:bd:29:b0:81:7f:18:e7:12:50:91: 30:98:9b:02:f3:46:6d:35:b4:23:18:6e:5b:8a:a0: da:43:61:8e:60:c6:8e:58:33:ac:15:88:c7:d4:87: 54:1e:b4:57:7c:9d:ec:26:10:3d:a0:22:7e:e4:ee: 17:34:bb:8d:90:92:40:f2:a2:6d:c2:82:16:8d:fc: 70:0c:da:4c:a1:26:c1:cb:08:77:d7:c7:3f:b8:b7: 0e:5e:8d:e9:5b:3e:37:af:3f:57:6e:27:97:91:49: b5:41:98:34:f5:25:bb:fd:01:88:d3:d3:6f:9c:a7: 1f:24:df:c7:9a:6e:9b:4a:1f:34:c4:50:cb:ca:06: 64:7b:0d:4a:74:09:3c:4b:f5:40:8d:3b:1c:80:92: 3e:ed Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Certificate Policies: Policy: 2.16.840.1.113733.1.7.23.3 CPS: https://www.verisign.com/rpa X509v3 CRL Distribution Points: URI:http://crl.verisign.com/pca3-g2.crl X509v3 Key Usage: Certificate Sign, CRL Sign Netscape Cert Type: SSL CA, S/MIME CA X509v3 Subject Alternative Name: DirName:/CN=Class3CA2048-1-44 X509v3 Subject Key Identifier: D6:A0:4C:D8:69:05:D0:A4:49:0E:A2:42:59:E4:4C:B2:76:82:6F:48 X509v3 Authority Key Identifier: DirName:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network serial:7D:D9:FE:07:CF:A8:1E:B7:10:79:67:FB:A7:89:34:C6 Signature Algorithm: sha1WithRSAEncryption 93:c9:76:b9:7e:d5:42:e3:f9:57:88:54:4c:e7:79:13:67:c5: 93:08:64:88:ce:76:c5:71:f7:f6:04:b6:04:5f:2b:49:58:cc: 74:4e:89:e2:2d:41:2f:c7:d6:be:44:52:88:9f:e0:9e:39:76: 08:fa:fe:0e:da:82:a9:e8:ce:26:6f:ca:84:12:fa:4b:58:9a: 27:7d:b4:9b:ad:41:d5:21:08:d3:b0:d6:ec:9c:e7:8d:b5:21: a0:f7:50:11:a6:d7:11:92:99:2d:1f:fe:fc:98:f8:4e:6e:c9: b8:3c:2c:89:39:3d:30:ff:81:11:3d:f2:8c:31:6e:36:63:2d: 7a:9c -----BEGIN CERTIFICATE----- MIIFZzCCBNCgAwIBAgIQeoM1j3/iqQtW9qYtglpk/jANBgkqhkiG9w0BAQUFADCB wTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQL EzNDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1 dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmswHhcNMDQxMjE0MDAwMDAwWhcNMDkxMjEzMjM1OTU5WjCBsTELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNDErMCkGA1UEAxMiVmVyaVNpZ24gQ2xh c3MgMyBPcmdhbml6YXRpb25hbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAMPm1H5TyYKKmCz3W0iMg66g5Vf+QTSfAH6AkkBhCS4RPyWDaeGjmNcI JISOyHrvN/17fzdmHUYewYBUXbIPXrHMGem4TiFwffBaDzcWrx+8kPtXc6w5N3lt NruW44fWH0PQMI55R72McEGpYgi9KbCBfxjnElCRMJibAvNGbTW0IxhuW4qg2kNh jmDGjlgzrBWIx9SHVB60V3yd7CYQPaAifuTuFzS7jZCSQPKibcKCFo38cAzaTKEm wcsId9fHP7i3Dl6N6Vs+N68/V24nl5FJtUGYNPUlu/0BiNPTb5ynHyTfx5pum0of NMRQy8oGZHsNSnQJPEv1QI07HICSPu0CAwEAAaOCAegwggHkMBIGA1UdEwEB/wQI MAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQtMCswKaAnoCWG I2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMtZzIuY3JsMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEUNs YXNzM0NBMjA0OC0xLTQ0MB0GA1UdDgQWBBTWoEzYaQXQpEkOokJZ5EyydoJvSDCB 5wYDVR0jBIHfMIHcoYHHpIHEMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xPDA6BgNVBAsTM0NsYXNzIDMgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVy aVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29ya4IQfdn+B8+oHrcQeWf7p4k0xjANBgkqhkiG 9w0BAQUFAAOBgQCTyXa5ftVC4/lXiFRM53kTZ8WTCGSIznbFcff2BLYEXytJWMx0 ToniLUEvx9a+RFKIn+CeOXYI+v4O2oKp6M4mb8qEEvpLWJonfbSbrUHVIQjTsNbs nOeNtSGg91ARptcRkpktH/78mPhObsm4PCyJOT0w/4ERPfKMMW42Yy16nA== -----END CERTIFICATE----- From rw at rlworkman.net Tue Sep 19 06:46:56 2006 From: rw at rlworkman.net (Robby Workman) Date: Tue Sep 19 06:46:01 2006 Subject: Error building gnupg-1.9.23 (undefined references) Message-ID: <450F7640.4040409@rlworkman.net> First of all, thanks for looking at the earlier thread about my problems with gpgme, even if it did turn out to be a PEBKAC - that needed to be in the archives anyway... Just when I get everything up and running, you guys go and release new versions of stuff :) In this order, I've built: libgpg-error-1.4 libksba-1.0.0 libassuan-0.9.0 libgcrypt-1.2.3 pth-2.0.7 pinentry-0.7.2 dirmngr-0.9.6 I'm now attempting to build gnupg-1.9.23, but this happens: make[2]: Leaving directory `/tmp/gnupg-1.9.23/g10' Making all in keyserver make[2]: Entering directory `/tmp/gnupg-1.9.23/keyserver' if i486-slackware-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I../common -I../intl -DLOCALEDIR=\"/usr/share/locale\" -DGNUPG_BINDIR="\"/usr/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/libexec\"" -DGNUPG_LIBDIR="\"/usr/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/etc/gnupg\"" -O2 -march=i486 -mtune=i686 -Wall -MT gpg2keys_ldap-gpgkeys_ldap.o -MD -MP -MF ".deps/gpg2keys_ldap-gpgkeys_ldap.Tpo" -c -o gpg2keys_ldap-gpgkeys_ldap.o `test -f 'gpgkeys_ldap.c' || echo './'`gpgkeys_ldap.c; \ then mv -f ".deps/gpg2keys_ldap-gpgkeys_ldap.Tpo" ".deps/gpg2keys_ldap-gpgkeys_ldap.Po"; else rm -f ".deps/gpg2keys_ldap-gpgkeys_ldap.Tpo"; exit 1; fi if i486-slackware-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I../common -I../intl -DLOCALEDIR=\"/usr/share/locale\" -DGNUPG_BINDIR="\"/usr/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/libexec\"" -DGNUPG_LIBDIR="\"/usr/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/etc/gnupg\"" -O2 -march=i486 -mtune=i686 -Wall -MT gpg2keys_ldap-ksutil.o -MD -MP -MF ".deps/gpg2keys_ldap-ksutil.Tpo" -c -o gpg2keys_ldap-ksutil.o `test -f 'ksutil.c' || echo './'`ksutil.c; \ then mv -f ".deps/gpg2keys_ldap-ksutil.Tpo" ".deps/gpg2keys_ldap-ksutil.Po"; else rm -f ".deps/gpg2keys_ldap-ksutil.Tpo"; exit 1; fi i486-slackware-linux-gcc -O2 -march=i486 -mtune=i686 -Wall -o gpg2keys_ldap gpg2keys_ldap-gpgkeys_ldap.o gpg2keys_ldap-ksutil.o ../gl/libgnu.a ../common/libcommon.a ../jnlib/libjnlib.a -lldap -ldl ../jnlib/libjnlib.a(stringhelp.o)(.text+0x1d0): In function `mem2str': : undefined reference to `gcry_xmalloc' ../jnlib/libjnlib.a(stringhelp.o)(.text+0x4c2): In function `make_dirname': : undefined reference to `gcry_xmalloc' ../jnlib/libjnlib.a(stringhelp.o)(.text+0x552): In function `make_filename': : undefined reference to `gcry_xmalloc' ../jnlib/libjnlib.a(stringhelp.o)(.text+0x898): In function `print_sanitized_utf8_buffer': : undefined reference to `gcry_free' ../jnlib/libjnlib.a(stringhelp.o)(.text+0x9cc): In function `sanitize_buffer': : undefined reference to `gcry_xmalloc' ../jnlib/libjnlib.a(stringhelp.o)(.text+0x489): In function `make_basename': : undefined reference to `gcry_xstrdup' ../jnlib/libjnlib.a(stringhelp.o)(.text+0x504): In function `make_dirname': : undefined reference to `gcry_xstrdup' ../jnlib/libjnlib.a(utf8conv.o)(.text+0x1e6): In function `native_to_utf8': : undefined reference to `gcry_xmalloc' ../jnlib/libjnlib.a(utf8conv.o)(.text+0x278): In function `native_to_utf8': : undefined reference to `gcry_xmalloc' ../jnlib/libjnlib.a(utf8conv.o)(.text+0x2c4): In function `native_to_utf8': : undefined reference to `gcry_xstrdup' ../jnlib/libjnlib.a(utf8conv.o)(.text+0x39f): In function `utf8_to_native': : undefined reference to `gcry_xmalloc' ../jnlib/libjnlib.a(logging.o)(.text+0x382): In function `fun_closer': : undefined reference to `gcry_free' ../jnlib/libjnlib.a(logging.o)(.text+0x408): In function `set_file_fd': : undefined reference to `gcry_xmalloc' collect2: ld returned 1 exit status make[2]: *** [gpg2keys_ldap] Error 1 make[2]: Leaving directory `/tmp/gnupg-1.9.23/keyserver' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/gnupg-1.9.23' make: *** [all] Error 2 This is using make -j1 (well, just 'make' really), as attempting to build with -j(>1) occasionally fails to create libcommon.a before it's needed, and the build errors out. I know that's not relevant to the error above, but it's something you probably want to know about, as many people tend to build with more than one make thread. Anyway, any ideas about how to fix the undefined references above? I don't think this is a problem on my end (though I've been wrong before) :) as this is in a clean chroot build environment (Slackware 11.0 RC5). Also, I thought you might want to know about these compiler warnings issued while building pinentry-0.7.2: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include/ncurses -I../secmem -I../pinentry -Wall -O2 -march=i486 -mtune=i686 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT gtksecentry.o -MD -MP -MF ".deps/gtksecentry.Tpo" -c -o gtksecentry.o gtksecentry.c; \ then mv -f ".deps/gtksecentry.Tpo" ".deps/gtksecentry.Po"; else rm -f ".deps/gtksecentry.Tpo"; exit 1; fi In file included from /usr/include/gtk-1.2/gdk/gdki18n.h:32, from gtksecentry.c:42: /usr/include/glib-1.2/glib.h:1697: warning: declaration of 'index' shadows a global declaration /usr/include/string.h:304: warning: shadowed declaration is here /usr/include/glib-1.2/glib.h:1703: warning: declaration of 'index' shadows a global declaration /usr/include/string.h:304: warning: shadowed declaration is here /usr/include/glib-1.2/glib.h:1705: warning: declaration of 'index' shadows a global declaration /usr/include/string.h:304: warning: shadowed declaration is here /usr/include/glib-1.2/glib.h:1719: warning: declaration of 'index' shadows a global declaration /usr/include/string.h:304: warning: shadowed declaration is here /usr/include/glib-1.2/glib.h:1721: warning: declaration of 'index' shadows a global declaration /usr/include/string.h:304: warning: shadowed declaration is here /usr/include/glib-1.2/glib.h:1745: warning: declaration of 'index' shadows a global declaration /usr/include/string.h:304: warning: shadowed declaration is here /usr/include/glib-1.2/glib.h:1747: warning: declaration of 'index' shadows a global declaration /usr/include/string.h:304: warning: shadowed declaration is here /usr/include/glib-1.2/glib.h:2319: warning: declaration of 'index' shadows a global declaration /usr/include/string.h:304: warning: shadowed declaration is here In file included from /usr/include/gtk-1.2/gtk/gtkmain.h:31, from gtksecentry.c:43: /usr/include/gtk-1.2/gdk/gdk.h:821: warning: declaration of 'index' shadows a global declaration /usr/include/string.h:304: warning: shadowed declaration is here In file included from /usr/include/gtk-1.2/gtk/gtkarg.h:31, from /usr/include/gtk-1.2/gtk/gtkobject.h:31, from /usr/include/gtk-1.2/gtk/gtkaccelgroup.h:35, from /usr/include/gtk-1.2/gtk/gtkwidget.h:31, from /usr/include/gtk-1.2/gtk/gtkmain.h:32, from gtksecentry.c:43: /usr/include/gtk-1.2/gtk/gtktypeutils.h:163: warning: function declaration isn't a prototype -- http://rlworkman.net From wk at gnupg.org Tue Sep 19 11:54:36 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Sep 19 11:56:45 2006 Subject: libassuan-0.9.0 build problems In-Reply-To: (Nelson H. F. Beebe's message of "Mon, 18 Sep 2006 11:49:20 -0600 (MDT)") References: Message-ID: <87u0349o6b.fsf@wheatstone.g10code.de> On Mon, 18 Sep 2006 19:49, Nelson H. F. Beebe said: > The validation tests failed on several systems because /etc/motd does > not exist: here is what happens: Okay, replaced by fdpassing.c > There are complete failures on these systems: > > Apple Mac OS X PowerPC Folks succeeded building gpgms for MAC OS X. I need to check how they did it. > DEC OSF/1 Alpha > SGI IRIX 6.5 MIPS > Sun Solaris 7, 8, 9, 10 SPARC > Sun Solaris 10 IA-32 Hopefully solved now. May I send you another tarball for testing? > An enumerated type is mixed with another type. > > rc = _assuan_read_line (ctx); > ^ I fixed this by defining the assuan error codes and not using an enum. Also typedefed assuan_error_t to int. >> cc-1164 c89: WARNING File = assuan-socket-server.c, Line = 90 > Argument of type "size_t *" is incompatible with parameter of type "int *". > > fd = accept (ctx->listen_fd, (struct sockaddr*)&clnt_addr, &len ); Well, that should be socklen_t. > cc-1162 c89: ERROR File = assuan-pipe-connect.c, Line = 324 > Too few arguments in function call. > > unsetenv ("_assuan_connection_fd"); Silly wrong repaclement macro which defiend it to setenv. > assuan-pipe-connect.c: In function `pipe_connect_unix': > assuan-pipe-connect.c:324: error: too few arguments to function `_assuan_setenv' Not sure about this. > putc_unlocked.c:30: error: redefinition of '__sputc' > /usr/local/lib/gcc/i386-unknown-freebsd5.0/3.4.3/include/stdio.h:405: error: previous definition of '__sputc' was here > make[3]: *** [putc_unlocked.o] Error 1 Add a function definition. However the real cause might be a wrong detection of putc_unlocked. > Machinetype: Apple Power Mac G4 (2 1420 MHz PowerPC G4 (3.3) CPUs, 2GB RAM); Darwin 7.9.0 (Mac OS X Server 10.3.9 (7W98)) > /usr/bin/ld: Undefined symbols: > _pth_fdmode > _pth_read > _pth_select > _pth_waitpid > _pth_write Well, we use a the ELF weak pragma to use the pth functions if they are available (i.e. the binary is linked with pth). This is not really portable but the best we can do for now. When switching to a shared library we will do one library for each threading model. > assuan-pipe-connect.c:380: error: 'AF_LOCAL' undeclared (first use in this function) defed to AF_UNIX Many thanks, Werner From marcus.brinkmann at ruhr-uni-bochum.de Tue Sep 19 12:17:06 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue Sep 19 12:15:25 2006 Subject: libassuan-0.9.0 build problems In-Reply-To: References: Message-ID: <87d59s2mal.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 18 Sep 2006 11:49:20 -0600 (MDT), Nelson H F Beebe wrote: > > In order to build gnupg-1.9.23, it is necessary to first install four > dependent packages: libassuan, libgpg-error libksba, and pth. > > I've had reasonable success with three of them, but libassuan-0.9.0 > has build failures, and test failures on several platforms. Thanks for testing this. Libassuan has some dark corners of known incompatibility which we will eventually have to get around fixing. There were a couple of surprises as well, though, which I did my best to fix. > The validation tests failed on several systems because /etc/motd does > not exist: here is what happens: I included a motd in the source and the corresponding tuning to enable it: 2006-09-19 Marcus Brinkmann * tests/fdpassing.c (MOTD): New macro. * tests/Makefile.am (AM_CPPFLAGS): New variable. * tests/motd: New file. > ============================================================ > Machinetype: SGI Origin/200-4 (180 MHz) (4 R10000 CPUs); IRIX 6.5 > Remote c89 version: MIPSpro Compilers: Version 7.3.1.3m > Configure environment: CC=c89 CXX=CC CFLAGS=-I/usr/local/include CXXFLAGS=-I/usr/local/include LDFLAGS=-Wl,-rpath,/usr/local/libn32 > > c89 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I/usr/local/include -c assuan-client.c > cc-1185 c89: WARNING File = assuan-client.c, Line = 47 > An enumerated type is mixed with another type. > > rc = _assuan_read_line (ctx); > ^ Oh well, there are a bunch of those. I did some changes to massage everything into the assuan_error_t type of use, but its quite a mess, and more problems like this remain, also because of mixed support for old-style errors and new gpg-error values (which are not correctly typed to suppress a dependency). Eventually we may make libassuan dependent on gpg-error and clean it all up. > cc-1162 c89: ERROR File = assuan-pipe-connect.c, Line = 324 > Too few arguments in function call. > > unsetenv ("_assuan_connection_fd"); Simple typo with a straightforward fix: 2006-09-19 Marcus Brinkmann * assuan-defs.h (unsetenv): Define correctly. > ============================================================ > Machinetype: SGI Origin/200-4 (180 MHz) (4 R10000 CPUs); IRIX 6.5 > Remote gcc version: gcc (GCC) 3.4.3 > Configure environment: CC=gcc CFLAGS=-I/usr/local/include CXX=g++ CXXFLAGS=-I/usr/local/include LDFLAGS=-Wl,-rpath,/usr/local/libn32 > > if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT assuan-pipe-connect.o -MD -MP -MF ".deps/assuan-pipe-connect.Tpo" -c -o assuan-pipe-connect.o assuan-pipe-connect.c; \ > then mv -f ".deps/assuan-pipe-connect.Tpo" ".deps/assuan-pipe-connect.Po"; else rm -f ".deps/assuan-pipe-connect.Tpo"; exit 1; fi > assuan-pipe-connect.c: In function `pipe_connect_unix': > assuan-pipe-connect.c:324: error: too few arguments to function `_assuan_setenv' > make[3]: *** [assuan-pipe-connect.o] Error 1 Same as above, just different diagnostic. > ============================================================ > Machinetype: Sun W40z (4 CPUs, 2400 MHz AMD64 Opteron, 8GB RAM); FreeBSD 5.0-RELEASE #0 > Remote gcc version: gcc (GCC) 3.4.3 > Configure environment: CC=gcc CFLAGS=-I/usr/local/include CXX=g++ LDFLAGS=-Wl,-rpath,/usr/local/lib > > if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT putc_unlocked.o -MD -MP -MF ".deps/putc_unlocked.Tpo" -c -o putc_unlocked.o putc_unlocked.c; \ > then mv -f ".deps/putc_unlocked.Tpo" ".deps/putc_unlocked.Po"; else rm -f ".deps/putc_unlocked.Tpo"; exit 1; fi > putc_unlocked.c:30: error: redefinition of '__sputc' > /usr/local/lib/gcc/i386-unknown-freebsd5.0/3.4.3/include/stdio.h:405: error: previous definition of '__sputc' was here > make[3]: *** [putc_unlocked.o] Error 1 This is curious. I am not sure what's going on. If freebsd defines putc_unlocked, the file shouldn't get included at all. If it doesn't, it should not redefine it to __sputc, which it seems to do. Maybe AC_REPLACE_FUNCS(putc_unlocked) does not do its job properly. Things that could help me to find out what's going on: The stdio.h file from above and the config.log file generated by configure. > ============================================================ > Machinetype: Apple Power Mac G4 (2 1420 MHz PowerPC G4 (3.3) CPUs, 2GB RAM); Darwin 7.9.0 (Mac OS X Server 10.3.9 (7W98)) > Remote gcc version: gcc (GCC) 3.4.3 > Configure environment: CC=gcc CXX=g++ LIBS=-lcc_dynamic > > gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o fdpassing fdpassing.o ../src/libassuan.a -lcc_dynamic > /usr/bin/ld: Undefined symbols: > _pth_fdmode > _pth_read > _pth_select > _pth_waitpid > _pth_write > collect2: ld returned 1 exit status > > This failure happened on all build attempts on Apple Mac OS X. The > -lpth library is not being specified, although the library is > certainly installed: The -lpth library should not be specified. The pth functions are referenced with #pragma weak, which should make their omission non-critical (and detectable by libassuan). However, that's not very portable (as you found out), and eventually we will probably do the same as for GPGME, where we generate different library versions, one without pth support and one with. It's a TODO list item for the shared library version, but apparently it's also a problem for the static version on this platform. > ============================================================ > Machinetype: DEC Alpha 4100-5/466 (4 21164 EV5 CPUs, 466 MHz, 2GB RAM); OSF/1 4.0F > Remote cc version: DEC C V5.9-005 on Digital UNIX V4.0 (Rev. 1229) > Configure environment: CC=cc CFLAGS="-ieee -I/usr/local/include" CXX=cxx CXXFLAGS="-ieee -I/usr/local/include" LDFLAGS="-Wl,-rpath,/usr/local/lib -Wl,-oldstyle_liblookup -L/usr/local/lib" LIBS="-lsnprintf" FC=f77 F77=f77 > > cc -std1 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -ieee -I/usr/local/include -c assuan-socket-server.c > cc: Info: assuan.h, line 283: Trailing comma found in enumerator list. (trailcomma) > } assuan_error_t; > ^ Oh well. I moved the comma into the #ifdef, and it should work now. 2006-09-19 Marcus Brinkmann * assuan.h (enum): Avoid trailing comma in enumerator list. Ugh. > cc: Warning: assuan-socket-server.c, line 90: In this statement, the referenced type of the pointer value "&len" is "unsigned long", which is not compatible with "int". (ptrmismatch) > fd = accept (ctx->listen_fd, (struct sockaddr*)&clnt_addr, &len ); > -------------------------------------------------------------^ > source='assuan-pipe-connect.c' object='assuan-pipe-connect.o' libtool=no \ > DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp \ > cc -std1 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -ieee -I/usr/local/include -c assuan-pipe-connect.c > cc: Info: assuan.h, line 283: Trailing comma found in enumerator list. (trailcomma) > } assuan_error_t; > ^ > cc: Error: assuan-pipe-connect.c, line 380: In this statement, "AF_LOCAL" is not declared. (undeclared) > if ( socketpair (AF_LOCAL, SOCK_STREAM, 0, fds) ) > -------------------^ I added the same hacks as in assuan-server-connect.c: 2006-09-19 Marcus Brinkmann * assuan-pipe-connect.c: Add hacks for Slowaris. * assuan-socket.c: Likewise here. > ============================================================ > Machinetype: Sun Ultra Enterprise 2900 (4 CPUs, 1050 MHz UltraSPARC-IV, 16GB); Solaris 10 > Remote gcc4 version: gcc4 (GCC) 4.0.2 > Configure environment: CC=/usr/local/test/bin/gcc CFLAGS=-I/usr/local/include CXX=/usr/local/test/bin/g++ CXXFLAGS=-I/usr/local/include LDFLAGS="-R/usr/local/lib -L/usr/local/lib" > > if /usr/local/test/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT assuan-socket-server.o -MD -MP -MF ".deps/assuan-socket-server.Tpo" -c -o assuan-socket-server.o assuan-socket-server.c; \ > then mv -f ".deps/assuan-socket-server.Tpo" ".deps/assuan-socket-server.Po"; else rm -f ".deps/assuan-socket-server.Tpo"; exit 1; fi > if /usr/local/test/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT assuan-pipe-connect.o -MD -MP -MF ".deps/assuan-pipe-connect.Tpo" -c -o assuan-pipe-connect.o assuan-pipe-connect.c; \ > then mv -f ".deps/assuan-pipe-connect.Tpo" ".deps/assuan-pipe-connect.Po"; else rm -f ".deps/assuan-pipe-connect.Tpo"; exit 1; fi > assuan-pipe-connect.c: In function 'socketpair_connect': > assuan-pipe-connect.c:380: error: 'AF_LOCAL' undeclared (first use in this function) > assuan-pipe-connect.c:380: error: (Each undeclared identifier is reported only once > assuan-pipe-connect.c:380: error: for each function it appears in.) Same as above. I am not sure what your chances are with these fixes. Somewhat better, I guess, but the pth symbol hickup may still prevent it from working completely. Thanks a lot, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Tue Sep 19 12:38:12 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue Sep 19 12:35:35 2006 Subject: SOLVED - Compile error with gpgme-1.1.2 In-Reply-To: <45078EA4.5090305@rlworkman.net> References: <450252BA.40401@rlworkman.net> <45074DC0.6000008@rlworkman.net> <45078EA4.5090305@rlworkman.net> Message-ID: <87bqpc2lbf.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 12 Sep 2006 23:52:52 -0500, Robby Workman wrote: > Well, it seems that building pth with --enable-pthread=yes > installs /usr/include/pthread.h, which overwrites the one that > was already there. Rebuilding it with pthread=no didn't make a > difference due to the fact that the changed header was not > removed when I removed the first package (since it's part of the > glibc package initially). Copying over the original header from > the glibc package and rebuilding pth with --enable-pthread=no > solved the problem; gpgme built just fine. Thanks for figuring this out and posting about it, this will help us identify the cause of this problem in future bug reports and enables people to find the solution via the mailing list archives and web searches. Marcus From wk at gnupg.org Tue Sep 19 15:01:05 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Sep 19 15:25:11 2006 Subject: [Announce] GnuPG Logo Contest Message-ID: <87ac4w9fji.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Tue Sep 19 16:15:07 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Sep 19 16:16:36 2006 Subject: Error building gnupg-1.9.23 (undefined references) In-Reply-To: <450F7640.4040409@rlworkman.net> (Robby Workman's message of "Mon, 18 Sep 2006 23:46:56 -0500") References: <450F7640.4040409@rlworkman.net> Message-ID: <87odtc7xjo.fsf@wheatstone.g10code.de> On Tue, 19 Sep 2006 06:46, Robby Workman said: > Just when I get everything up and running, you guys go and release new > versions of stuff :) More are to follow :-) > : undefined reference to `gcry_xmalloc' > ../jnlib/libjnlib.a(stringhelp.o)(.text+0x4c2): In function Ah well. We newd to add stubs to get rid of the libgcrypt requirements. Either you link all these modules also to libgcrypt (-lgcrypt should be sufficient) or you copy tools/no-libgcrypt.c to keyserver/ and add it to the foo_SOURCES lines. I just did that in the SVN. > This is using make -j1 (well, just 'make' really), as attempting to > build with -j(>1) occasionally fails to create libcommon.a before it's Thankls. That is a missing dependency. I'll put it on my TODO list. > Also, I thought you might want to know about these compiler warnings > issued while building pinentry-0.7.2: > In file included from /usr/include/gtk-1.2/gdk/gdki18n.h:32, > from gtksecentry.c:42: > /usr/include/glib-1.2/glib.h:1697: warning: declaration of 'index' > shadows a global declaration glib uses "index" as a parameter name but "index" is also a old-style standard C function. Very common problem. Swapping include lines often helps. Shalom-Salam, Werner From bernhard at intevation.de Tue Sep 19 16:07:13 2006 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue Sep 19 17:51:31 2006 Subject: GnuPG 1.9.23 released In-Reply-To: <877j01cnwd.fsf@wheatstone.g10code.de> References: <877j01cnwd.fsf@wheatstone.g10code.de> Message-ID: <200609191607.16551.bernhard@intevation.de> On Monday 18 September 2006 15:20, Werner Koch wrote: > We are pleased to announce the availability of GnuPG 1.9.23 - the > branch of GnuPG heading towards a GnuPG 2.0 and featuring the OpenPGP > as well as the S/MIME protocol. > > This is a BETA release and not suitable for production use! I have added a wish for a Debian experimental package http://bugs.debian.org/388257 > Note, that gpg2 is now build by default and may actually be used. > There are some minor things missing but most people should not be > affected by this. > > Please test this release and report bugs. If you are a translator, > please do not yet start with translations but wait for the first > release candidate which is planned for early October. > 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 gpg's principal author, is currently > funding GnuPG development. We are always looking for interesting > development projects. -- Managing Director - Owner, www.intevation.net (Free Software Company) Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software) www.kolab-konsortium.com (Email/Groupware Solution, Professional Service) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1310 bytes Desc: not available Url : /pipermail/attachments/20060919/839cec31/smime.bin From wk at gnupg.org Tue Sep 19 18:28:07 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Sep 19 18:32:09 2006 Subject: GnuPG 1.9.23 released In-Reply-To: <200609191607.16551.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 19 Sep 2006 16:07:13 +0200") References: <877j01cnwd.fsf@wheatstone.g10code.de> <200609191607.16551.bernhard@intevation.de> Message-ID: <878xkf95yg.fsf@wheatstone.g10code.de> On Tue, 19 Sep 2006 16:07, Bernhard Reiter said: > I have added a wish for a Debian experimental package > http://bugs.debian.org/388257 I fear that your whish to completly supercede the gnupg package by gnupg2 is not possible. gnupg2 has a *lot of dependencies* and relies on the gpg-agent. gpg however is a core package of Debian. I see no way to go without gpg 1.4. In fact, I plan to keep the name gpg2 to allow installing along with gpg1. I am currently discussing with Marcus on how we can make the gpgme library use gpg2. Shalom-Salam, Werner From bernhard at intevation.de Tue Sep 19 20:06:23 2006 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue Sep 19 20:04:39 2006 Subject: GnuPG 1.9.23 released In-Reply-To: <878xkf95yg.fsf@wheatstone.g10code.de> References: <877j01cnwd.fsf@wheatstone.g10code.de> <200609191607.16551.bernhard@intevation.de> <878xkf95yg.fsf@wheatstone.g10code.de> Message-ID: <200609192006.26690.bernhard@intevation.de> On Tuesday 19 September 2006 18:28, Werner Koch wrote: > On Tue, 19 Sep 2006 16:07, Bernhard Reiter said: > > I have added a wish for a Debian experimental package > > http://bugs.debian.org/388257 > > I fear that your whish to completly supercede the gnupg package by > gnupg2 is not possible. gnupg2 has a *lot of dependencies* and relies > on the gpg-agent. gpg however is a core package of Debian. This is not necessarily a hard conflict as far as I can see, but I of course appreciate your input on the issue. > I see no way to go without gpg 1.4. This is for now, but I guess the plan is to have gpg 2 to supercede gpg 1.4 in the mid run. Packaging for this in experimental seems to be the right place to start and see if this already works. Debian could try to sort the dependencies in a way that there is a binary target for a udeb gpg 2 that covers the basic needs or something similiar. > In fact, I plan to keep the name gpg2 to > allow installing along with gpg1. I am currently discussing with > Marcus on how we can make the gpgme library use gpg2. Thanks for the clarification I understood the announcement that gpg2 could already replace gpg1 fully and just needs testing. From you comment I guess that at least gpgme does not work with it yet. Bernhard -- Managing Director - Owner, www.intevation.net (Free Software Company) Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software) www.kolab-konsortium.com (Email/Groupware Solution, Professional Service) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1310 bytes Desc: not available Url : /pipermail/attachments/20060919/3b9464f7/smime.bin From wk at gnupg.org Tue Sep 19 20:49:06 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Sep 19 20:51:50 2006 Subject: GnuPG 1.9.23 released In-Reply-To: <200609192006.26690.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 19 Sep 2006 20:06:23 +0200") References: <877j01cnwd.fsf@wheatstone.g10code.de> <200609191607.16551.bernhard@intevation.de> <878xkf95yg.fsf@wheatstone.g10code.de> <200609192006.26690.bernhard@intevation.de> Message-ID: <873ban8zfh.fsf@wheatstone.g10code.de> On Tue, 19 Sep 2006 20:06, Bernhard Reiter said: > This is for now, but I guess the plan is to have gpg 2 to supercede > gpg 1.4 in the mid run. Packaging for this in experimental seems Not really. There are many applications of gpg which don't need the new features of gpg2 and thus we will keep the 1.x branch alive and maintain it as long as there is interest in it. We might not backport all new features from gpg2. gpg2 is more targeted to the desktop than to a server. Of course it might as well be used in server applications (cf. gpg-preset-passphrase). OTOH, a simple tools with minimal dependecies is often better suited for certain tasks. > Thanks for the clarification I understood the announcement that > gpg2 could already replace gpg1 fully and just needs testing. Yes, it may fully replace gpg1. > From you comment I guess that at least gpgme does not work with it > yet. It may be used with gpgme. We are thinking of a smooth way to have ggme application migrate to gpg2. In the long run gpg2 will have advantages for gpgme based applications. For example we will add a --server mode to avoid the sometimes costly fork and exec. Salam-Shalom, Werner From wk at gnupg.org Wed Sep 20 14:21:04 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Sep 20 14:26:47 2006 Subject: x509 v1 certificate In-Reply-To: <20060919.083256.39153403.say@khaotic.net> (ARIGA Seiji's message of "Tue, 19 Sep 2006 08:32:56 +0900 (JST)") References: <20060917.114438.71082783.say@khaotic.net> <87lkohcp9f.fsf@wheatstone.g10code.de> <20060919.083256.39153403.say@khaotic.net> Message-ID: <87d59q4tlb.fsf@wheatstone.g10code.de> On Tue, 19 Sep 2006 01:32, ARIGA Seiji said: > hmm. let me ask one more. output below is from "gpgsm -kv". you can see > "[error: No value]" at "key usage:" and "chain length:" field (which, > i think, is in x509 extension field that x509 version 1 cert doesn't > have). isn't this the same error i got when i run "gpgsm --verify" ? Yes. I have now looked at the certificate. The problematic part in the chain is the root certificate: $ gpgsm --dump-cert --with-validation --disable-crl-checks 85:37 [...] Serial number: 7DD9FE07CFA81EB7107967FBA78934C6 Issuer: OU=VeriSign Trust Network,OU=(c) 1998 VeriSign[...] Subject: OU=VeriSign Trust Network,OU=(c) 1998 VeriSign[...] sha1_fpr: 85:37:1C:A6:E5:50:14:3D:CE:28:03:47:1B:DE:3A:09:E8:F8:77:0F md5_fpr: A2:33:9B:4C:74:78:73:D4:6C:E7:C1:F3:8D:CB:5C:E9 certid: 92BE1570CFF4130C3B6EDB06C113047112E2F2C4.7DD9F[...] keygrip: 2870B97CA003D18304669D8A8229E5B126911B1B notBefore: 1998-05-18 00:00:00 notAfter: 2028-08-01 23:59:59 hashAlgo: 1.2.840.113549.1.1.5 (sha1WithRSAEncryption) keyType: 1024 bit RSA subjKeyId: [?] authKeyId: [?] keyUsage: [error: No value] extKeyUsage: [none] policies: [none] chainLength: [error: No value] crlDP: [error] authInfo: [error] subjInfo: [error] [certificate is bad: No value] As you rightfully noticed, the keyUsage is missing and gpgsm flags this as an error. However, PKIX (rfc3280) says: This extension MUST appear in certificates that contain public keys that are used to validate digital signatures on other public key certificates or CRLs. When this extension appears, it SHOULD be marked critical. Other profiles (e.g. ISIS-MTT) state it even more clear. The missing basicContraints ("chainLength" above) is another reason why this certificate is not valid (rfc3280, 4.2.1.10): This extension MUST appear as a critical extension in all CA certificates that contain public keys used to validate digital signatures on certificates. [...] The question whether version 1 is supported is thus non-relevant because we are validating certificates. In this case PKIX requires extensions and following from that version should be 3 as per 4.1.2.1. The question now is how we can support these root certificates. An option to bypass the failing checks would be an appropriate way. However I am reluctant to add a general option to do this. I am currently investigating how we can completely support qualified signatures according to the German law. This might require a mechanism to allow certain exceptions. Salam-Shalom, Werner From alguibert+gpd at free.fr Wed Sep 20 17:18:49 2006 From: alguibert+gpd at free.fr (Alain Guibert) Date: Wed Sep 20 17:23:04 2006 Subject: libassuan 0.6.10 build fails on old Linux In-Reply-To: <20060910063154.GB9023@free.fr> References: <20060910063154.GB9023@free.fr> Message-ID: <20060920151849.GB12647@free.fr> Hello again, On Sunday, September 10, 2006 at 8:31:54 +0200, Alain Guibert wrote: > On my old Linux box (Intel Pentium 200 MMX, Debian bo, kernel 2.0.40, > gcc 2.7.2.1, libc 5.4.33, GNU ld cygnus-2.7.1) during libassuan 0.6.10 > build, make fails: Also tried libassuan 0.9.0, it fails a little earlier: | gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -c assuan-pipe-connect.c | assuan-pipe-connect.c: In function `socketpair_connect': | assuan-pipe-connect.c:380: `AF_LOCAL' undeclared (first use this function) | assuan-pipe-connect.c:380: (Each undeclared identifier is reported only once | assuan-pipe-connect.c:380: for each function it appears in.) | make[3]: *** [assuan-pipe-connect.o] Error 1 | make[3]: Leaving directory `/tmp/libassuan-0.9.0/src' | make[2]: *** [all] Error 2 | make[2]: Leaving directory `/tmp/libassuan-0.9.0/src' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/tmp/libassuan-0.9.0' | make: *** [all] Error 2 And later: | gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o fdpassing fdpassing.o ../src/libassuan.a | ../src/libassuan.a(assuan-handler.o): In function `process_request': | /tmp/libassuan-0.9.0/src/assuan-handler.c:525: undefined reference to `gpg_strerror_r' | /tmp/libassuan-0.9.0/src/assuan-handler.c:526: undefined reference to `gpg_strsource' | ../src/libassuan.a(assuan-uds.o): In function `uds_reader': | /tmp/libassuan-0.9.0/src/assuan-uds.c:69: undefined reference to `CMSG_SPACE' | /tmp/libassuan-0.9.0/src/assuan-uds.c:95: undefined reference to `CMSG_FIRSTHDR' | /tmp/libassuan-0.9.0/src/assuan-uds.c:96: undefined reference to `CMSG_LEN' | /tmp/libassuan-0.9.0/src/assuan-uds.c:103: undefined reference to `CMSG_DATA' | ../src/libassuan.a(assuan-uds.o): In function `uds_sendfd': | /tmp/libassuan-0.9.0/src/assuan-uds.c:171: undefined reference to `CMSG_SPACE' | /tmp/libassuan-0.9.0/src/assuan-uds.c:197: undefined reference to `CMSG_FIRSTHDR' | /tmp/libassuan-0.9.0/src/assuan-uds.c:198: undefined reference to `CMSG_LEN' | /tmp/libassuan-0.9.0/src/assuan-uds.c:201: undefined reference to `CMSG_DATA' | ../src/libassuan.a(assuan-io.o): In function `_assuan_simple_sendmsg': | /tmp/libassuan-0.9.0/src/assuan-io.c:162: undefined reference to `FD_ZERO' | /tmp/libassuan-0.9.0/src/assuan-io.c:163: undefined reference to `FD_SET' | ../src/libassuan.a(assuan-io.o): In function `_assuan_simple_recvmsg': | /tmp/libassuan-0.9.0/src/assuan-io.c:204: undefined reference to `FD_ZERO' | /tmp/libassuan-0.9.0/src/assuan-io.c:205: undefined reference to `FD_SET' | make[3]: *** [fdpassing] Error 1 | make[3]: Leaving directory `/tmp/libassuan-0.9.0/tests' | make[2]: *** [all] Error 2 | make[2]: Leaving directory `/tmp/libassuan-0.9.0/tests' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/tmp/libassuan-0.9.0' | make: *** [all] Error 2 Alain. From greve at fsfeurope.org Wed Sep 20 15:15:19 2006 From: greve at fsfeurope.org (Georg C. F. Greve) Date: Wed Sep 20 19:51:57 2006 Subject: GnuPG 1.9.23 released In-Reply-To: <873ban8zfh.fsf@wheatstone.g10code.de> (Werner Koch's message of "Tue\, 19 Sep 2006 20\:49\:06 +0200") References: <877j01cnwd.fsf@wheatstone.g10code.de> <200609191607.16551.bernhard@intevation.de> <878xkf95yg.fsf@wheatstone.g10code.de> <200609192006.26690.bernhard@intevation.de> <873ban8zfh.fsf@wheatstone.g10code.de> Message-ID: || On Tue, 19 Sep 2006 20:49:06 +0200 || Werner Koch wrote: wk> OTOH, a simple tools with minimal dependecies is often better wk> suited for certain tasks. [...] Yes, it may fully replace gpg1. Good to hear. I fully agree with the sentiment of "the right tool for the right job", but I think Bernhard has a point in so far as it seems that the time has come to make gnupg2 the "main" release now. I wonder: could it ever become possible to build a "downsized" version for specific purposes and limited dependencies from the gnupg2 branch? That might make maintenance of 1.4 unnecessary in the long run. Regards, Georg -- Georg C. F. Greve Free Software Foundation Europe (http://fsfeurope.org) Join the Fellowship and protect your freedom! (http://www.fsfe.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : /pipermail/attachments/20060920/1dbb053d/attachment.pgp From anosek at suse.cz Wed Sep 20 17:53:02 2006 From: anosek at suse.cz (Ales Nosek) Date: Wed Sep 20 19:52:03 2006 Subject: gpgme-1.0.3: local variable used before set Message-ID: <451163DE.1020806@suse.cz> David Binderman wrote: I just tried to compile package gpgme-1.0.3-9 with the Intel C compiler. It said keylist.c(370): warning #592: variable "key" is used before its value is set The source code is DEBUG3 ("keylist_colon_handler ctx = %p, key = %p, line = %s\n", ctx, key, line ? line : "(null)"); I agree with the compiler. Suggest initialise local variable "key" before first use. -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme-1.1.2-warning.patch Type: text/x-patch Size: 231 bytes Desc: not available Url : /pipermail/attachments/20060920/e007fa33/gpgme-1.1.2-warning.bin From ariga at os.rim.or.jp Thu Sep 21 08:00:50 2006 From: ariga at os.rim.or.jp (ARIGA Seiji) Date: Thu Sep 21 07:59:26 2006 Subject: x509 v1 certificate In-Reply-To: <87d59q4tlb.fsf@wheatstone.g10code.de> References: <20060917.114438.71082783.say@khaotic.net> <87lkohcp9f.fsf@wheatstone.g10code.de> <20060919.083256.39153403.say@khaotic.net> <87d59q4tlb.fsf@wheatstone.g10code.de> Message-ID: <20060921.150050.58462644.say@khaotic.net> On Wed, 20 Sep 2006 14:21:04 +0200, Werner Koch wrote, > > hmm. let me ask one more. output below is from "gpgsm -kv". you can see > > "[error: No value]" at "key usage:" and "chain length:" field (which, > > i think, is in x509 extension field that x509 version 1 cert doesn't > > have). isn't this the same error i got when i run "gpgsm --verify" ? > > Yes. I have now looked at the certificate. The problematic part in > the chain is the root certificate: [...] > As you rightfully noticed, the keyUsage is missing and gpgsm flags > this as an error. However, PKIX (rfc3280) says: [...] > The missing basicContraints ("chainLength" above) is another reason > why this certificate is not valid (rfc3280, 4.2.1.10): [...] > The question whether version 1 is supported is thus non-relevant > because we are validating certificates. In this case PKIX requires > extensions and following from that version should be 3 as per 4.1.2.1. [...] > The question now is how we can support these root certificates. An > option to bypass the failing checks would be an appropriate way. yeah, i totally agree with you. > I am currently investigating how we can completely support qualified > signatures according to the German law. This might require a mechanism > to allow certain exceptions. i'll be appreciated if you can find a way to support it. FYI, "Internet Explorer 6.0 SP2" has 115 root certificates (though this includes some of my private root certs), and 44 certs are v1 cert. the problem, i think, is that VeriSign's, one of the most popular CA, certs are all version 1 ... // ARIGA Seiji From npcole at yahoo.co.uk Thu Sep 21 14:38:03 2006 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Thu Sep 21 14:37:07 2006 Subject: DSA2 Message-ID: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> Dear David and others, Thank you for the information you have already posted about DSA2 on the list. Could I ask a few other questions: I am right that this is not a new algorithm as such, it is just the old one with longer key sizes? And that the only reason it has been restricted to 1024 in the past is a US standard? Or was there any fear that a larger key size with that algorithm would not provide security? Is moving to the larger key size something that the OpenPGP community is doing by itself, or has it been sactioned by any other group? Is the new upper limit of 3072 bits picked for any particular reason? Best wishes, N. ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" ? The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html From dshaw at jabberwocky.com Thu Sep 21 15:06:05 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Sep 21 15:04:51 2006 Subject: DSA2 In-Reply-To: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> Message-ID: <20060921130605.GB3928@jabberwocky.com> On Thu, Sep 21, 2006 at 01:38:03PM +0100, Nicholas Cole wrote: > Dear David and others, > > Thank you for the information you have already posted > about DSA2 on the list. Could I ask a few other > questions: > > I am right that this is not a new algorithm as such, > it is just the old one with longer key sizes? Correct. DSA2 (it's not really called that, by the way. It's just what the OpenPGP WG was calling it to differentiate it from the original DSA) is the same algorithm as original DSA with the ability to have a larger key size and use hashes other than SHA-1 or RIPEMD-160. > And that > the only reason it has been restricted to 1024 in the > past is a US standard? Or was there any fear that a > larger key size with that algorithm would not provide > security? Not exactly. The argument was that a larger key size was not really useful without a larger hash to go with it. The "1024 bit key and 160-bit hash" was considered roughly balanced. Changing one without changing the other didn't really increase the overall security of the scheme. > Is moving to the larger key size something that the > OpenPGP community is doing by itself, or has it been > sactioned by any other group? DSA2 (again, not really called that) is the new US standard. > Is the new upper limit of 3072 bits picked for any > particular reason? Sanity, mostly. The rough balances between key size and hash size are: 1024 bits, 160 bit q size (i.e. regular old DSA) 2048 bits, 224 bit q size 3072 bits, 256 bit q size 7680 bits, 384 bit q size 15360 bits, 512 bit q size A 7680-bit key is enormous and takes a long time to generate or make signatures. A 15360-bit key is all but unusable. David From npcole at yahoo.co.uk Thu Sep 21 16:38:14 2006 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Thu Sep 21 17:37:00 2006 Subject: DSA2 In-Reply-To: <20060921130605.GB3928@jabberwocky.com> Message-ID: <20060921143814.91172.qmail@web26713.mail.ukl.yahoo.com> Dear David, Thank you, as ever, for a very helpful and complete reply! Best wishes, N ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From jas at extundo.com Thu Sep 21 17:00:22 2006 From: jas at extundo.com (Simon Josefsson) Date: Thu Sep 21 18:21:55 2006 Subject: x509 v1 certificate In-Reply-To: <87d59q4tlb.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed\, 20 Sep 2006 14\:21\:04 +0200") References: <20060917.114438.71082783.say@khaotic.net> <87lkohcp9f.fsf@wheatstone.g10code.de> <20060919.083256.39153403.say@khaotic.net> <87d59q4tlb.fsf@wheatstone.g10code.de> Message-ID: <87slil4649.fsf@latte.josefsson.org> Werner Koch writes: > As you rightfully noticed, the keyUsage is missing and gpgsm flags > this as an error. However, PKIX (rfc3280) says: > > This extension MUST appear in certificates that contain public keys > that are used to validate digital signatures on other public key > certificates or CRLs. When this extension appears, it SHOULD be > marked critical. > > Other profiles (e.g. ISIS-MTT) state it even more clear. Although RFC 3280 goes on to say in section 6 that: (n) If a key usage extension is present, verify that the keyCertSign bit is set. The interpretation I've made is that while the CA certificate does not conform to RFC 3280, a certificate chain verifier that conform to RFC 3280 can accept certificates that lack a key usage extension. It would be nice if the specifications were a bit clearer on this matter... (GnuTLS do accept CA certificates that lack the key usage extension.) /Simon From qed at tiscali.it Thu Sep 21 17:55:26 2006 From: qed at tiscali.it (Qed) Date: Thu Sep 21 19:51:56 2006 Subject: DSA2 In-Reply-To: <45128C9A.8040906@sixdemonbag.org> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <45128C9A.8040906@sixdemonbag.org> Message-ID: <4512B5EE.3030501@tiscali.it> Maybe this should have gone to gnupg-devel, where the thread was started :-) On 09/21/2006 02:59 PM, Robert J. Hansen wrote: >> I am right that this is not a new algorithm as such, > > The problem with describing anything as a 'new algorithm' is, where do > you draw the line for new? Changing just one line in a specification > could be enough to categorize something as 'new', if you wanted to > define it that way. > > It's more apt to say that DSA2 is very closely related to the original > DSA. DSA2 is a logical outgrowth of the older DSA specification. > >> it is just the old one with longer key sizes? > > And better hash algorithms. > >> And that the only reason it has been restricted to 1024 in the past >> is a US standard? > > DSA is part of a United States FIPS (Federal Information Processing > Standard). In this FIPS a scheme called DSS, the Digital Signature > Standard, is defined. DSS specifies that DSA with SHA-1 will be used > for all signatures. > >> Or was there any fear that a larger key size with that algorithm >> would not provide security? > > At the time DSA was designed, 1024 bits of the Discrete Logarithm > Problem was widely considered to be enough for all practical purposes. > It isn't considered to be so any longer and various attacks are being > discovered against SHA-1 (which DSS requires to be used with DSA), so a > revised FIPS was put out addressing these two concerns. > >> Is the new upper limit of 3072 bits picked for any particular reason? > > Because this is the new upper limit in the FIPS. > > If you're asking why the FIPS chose 3072-bit keys as the upper limit, I > suspect their reasoning is that attacking 3072-bit DLP is a pipe dream > now and for the foreseeable future. > > For whatever it's worth, some critics of OpenPGP point to the lack of a > hash function firewall in DSA and DSA2 keys as a big unresolved security > issue. These critics are of the opinion the RSA signature specification > is better-defined. While I haven't looked at the spec enough to see if > DSA2 still lacks a hash function firewall, the criticism should probably > be brought up and considered, especially if you're thinking of migrating > your key to a different signature algorithm. > -- Q.E.D. War is Peace Freedom is Slavery Ignorance is Strength ICQ UIN: 301825501 OpenPGP key ID: 0x58D14EB3 Key fingerprint: 00B9 3E17 630F F2A7 FF96 DA6B AEE0 EC27 58D1 4EB3 Check fingerprints before trusting a key! From marcus.brinkmann at ruhr-uni-bochum.de Fri Sep 22 13:49:00 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri Sep 22 13:45:17 2006 Subject: gpgme-1.0.3: local variable used before set In-Reply-To: <451163DE.1020806@suse.cz> References: <451163DE.1020806@suse.cz> Message-ID: <87psdojf4j.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Wed, 20 Sep 2006 17:53:02 +0200, Ales Nosek wrote: > > David Binderman wrote: > > I just tried to compile package gpgme-1.0.3-9 with the Intel C compiler. > > It said > > keylist.c(370): warning #592: variable "key" is used before its value is set > > The source code is > > DEBUG3 ("keylist_colon_handler ctx = %p, key = %p, line = %s\n", > ctx, key, line ? line : "(null)"); > > I agree with the compiler. Suggest initialise local variable "key" > before first use. I checked in a slightly different change. 2006-09-22 Marcus Brinkmann * keylist.c (keylist_colon_handler): Move debug output after initialising KEY. Thanks, Marcus From clbianco at tiscalinet.it Sat Sep 23 15:15:07 2006 From: clbianco at tiscalinet.it (Carlo Luciano Bianco) Date: Sat Sep 23 16:51:37 2006 Subject: DSA2 References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> Message-ID: Il /21 set 2006/, *David Shaw* ha scritto: > On Thu, Sep 21, 2006 at 01:38:03PM +0100, Nicholas Cole wrote: >> Dear David and others, >> >> Thank you for the information you have already posted >> about DSA2 on the list. Could I ask a few other >> questions: Thanks to everybody for this very interesting thread. Some weeks ago I tried to start a similar one on the Italian crypto usenet group, but without much luck... ;-) I just try to summarize what I understood from this thread about OpenPGP implementation of DSA and RSA signatures, so you can correct me if I am wrong: ;-) - DSA is limited to 256-bit hashes (greater hashes are truncated). - DSA is limited to 3072-bit keys (largers are useless, see above). - DSA does not support "firewalled hashes" On the other hand: - RSA supports hashes up to 512-bit full lenght. - RSA supports keys up to 4096 bit. - RSA does support "firewalled hashes". So my point is: what is the real advantage of "DSA2" over RSA (if any, beside being the US standard)? > Sanity, mostly. The rough balances between key size and hash size > are: > > 1024 bits, 160 bit q size (i.e. regular old DSA) > 2048 bits, 224 bit q size > 3072 bits, 256 bit q size > 7680 bits, 384 bit q size > 15360 bits, 512 bit q size Therefore, now that GnuPG uses 256-bit symmetric algos and 512-bit hashes (i.e. AES-256 and SHA-512), shouldn't we use also DSA/ElG and RSA keys greater than 4096-bits, to achieve a "balanced" security? > A 7680-bit key is enormous and takes a long time to generate or > make signatures. A 15360-bit key is all but unusable. And therefore, even better, what is the present status of adding to GnuPG an "official" ECC keys support? Thank you in advance for the replies! :-) Carlo Luciano -- | ICQ UIN: 109517158 Carlo Luciano Bianco | Home page: ______________________|________________________________________________ GnuPG RSAv4 4096 - Fingerprint:FA68CF697EA63865AAFA805F68703AD40609D743 From kazu at iij.ad.jp Mon Sep 25 02:35:26 2006 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Mon Sep 25 04:21:28 2006 Subject: x509 v1 certificate In-Reply-To: <87d59q4tlb.fsf@wheatstone.g10code.de> References: <87lkohcp9f.fsf@wheatstone.g10code.de> <20060919.083256.39153403.say@khaotic.net> <87d59q4tlb.fsf@wheatstone.g10code.de> Message-ID: <20060925.093526.27266308.kazu@iij.ad.jp> Hello, > The missing basicContraints ("chainLength" above) is another reason > why this certificate is not valid (rfc3280, 4.2.1.10): > > This extension MUST appear as a critical extension in all CA > certificates that contain public keys used to validate digital > signatures on certificates. [...] > > The question whether version 1 is supported is thus non-relevant > because we are validating certificates. In this case PKIX requires > extensions and following from that version should be 3 as per 4.1.2.1. I have asked this to a specialist of X.509 and he said that Werner's interpretation is not correct. Yes, RFC3280 is not readable but the "certificates" in Section 4 refers "intermediate" CA's ones only, dos not refer to root CA's ones. Please read Section 6 carefully. First, trusted anchor is to be set. Practically speaking, the trusted anchor is taken from a root CA's certificate. But it is trusted anchor, not certificate in the varification algorithm. Thus the root CA's certificate is NOT treated as a certificate, thus it need not include the extensions above. It's OK even if the root CA's certificate is v1. Intermediated CA's certificates are treated as certificates. Since they MUST include the extensions above, it MUST be v3. --Kazu Yamamoto From jas at extundo.com Mon Sep 25 10:58:04 2006 From: jas at extundo.com (Simon Josefsson) Date: Mon Sep 25 10:56:43 2006 Subject: x509 v1 certificate In-Reply-To: <20060925.093526.27266308.kazu@iij.ad.jp> (Kazu Yamamoto =?utf-8?B?KOWxseacrOWSjAnlvaYpJ3M=?= message of "Mon\, 25 Sep 2006 09\:35\:26 +0900 \(JST\)") References: <87lkohcp9f.fsf@wheatstone.g10code.de> <20060919.083256.39153403.say@khaotic.net> <87d59q4tlb.fsf@wheatstone.g10code.de> <20060925.093526.27266308.kazu@iij.ad.jp> Message-ID: <87irjcwcf7.fsf@latte.josefsson.org> Kazu Yamamoto (????) writes: > Hello, > >> The missing basicContraints ("chainLength" above) is another reason >> why this certificate is not valid (rfc3280, 4.2.1.10): >> >> This extension MUST appear as a critical extension in all CA >> certificates that contain public keys used to validate digital >> signatures on certificates. [...] >> >> The question whether version 1 is supported is thus non-relevant >> because we are validating certificates. In this case PKIX requires >> extensions and following from that version should be 3 as per 4.1.2.1. > > I have asked this to a specialist of X.509 and he said that Werner's > interpretation is not correct. > > Yes, RFC3280 is not readable but the "certificates" in Section 4 > refers "intermediate" CA's ones only, dos not refer to root CA's ones. I wouldn't agree to that. Section 4.2 says: Conforming CAs MUST support key identifiers (sections 4.2.1.1 and 4.2.1.2), basic constraints (section 4.2.1.10), key usage (section 4.2.1.3), and certificate policies (section 4.2.1.5) extensions. If The document doesn't generally distinguish between "root CA" and "intermediate CA". However, I do agree with you, and a perfectly reasonable interpretation is that CA certificates (including root CAs) MUST have key usage extensions, but a conforming verifier of certificates chains should permit certificates without key usage extensions. This is also consistent with section 6. > Please read Section 6 carefully. First, trusted anchor is to be set. > Practically speaking, the trusted anchor is taken from a root CA's > certificate. But it is trusted anchor, not certificate in the > varification algorithm. > > Thus the root CA's certificate is NOT treated as a certificate, thus > it need not include the extensions above. It's OK even if the root > CA's certificate is v1. > > Intermediated CA's certificates are treated as certificates. Since > they MUST include the extensions above, it MUST be v3. I agree with you here. It is confusing, but certificate 1 in Section 6 doesn't refer to a Root CA aka trusted anchor, but to a certificate issued by a Root CA aka trusted anchor. /Simon From wk at gnupg.org Mon Sep 25 12:22:09 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 25 12:26:48 2006 Subject: x509 v1 certificate In-Reply-To: <20060925.093526.27266308.kazu@iij.ad.jp> (Kazu Yamamoto's message of "Mon, 25 Sep 2006 09:35:26 +0900 (JST)") References: <87lkohcp9f.fsf@wheatstone.g10code.de> <20060919.083256.39153403.say@khaotic.net> <87d59q4tlb.fsf@wheatstone.g10code.de> <20060925.093526.27266308.kazu@iij.ad.jp> Message-ID: <87ac4oz1ny.fsf@wheatstone.g10code.de> On Mon, 25 Sep 2006 02:35, Kazu Yamamoto (????) said: > Yes, RFC3280 is not readable but the "certificates" in Section 4 > refers "intermediate" CA's ones only, dos not refer to root CA's ones. The nice thing with X.509 is that there are so many possible interpratations and that even profiles even add more possible translations. Well, we know all that :-( Gpgsm has been build and certified for a German profile which is based on PKIX but has some more restrictions. That is the spo called Sphinx profile. We now tend to adhere to the newer ISIS-MTT profile which should be fully compatible with PKIX but isn't at some places. > Yes, RFC3280 is not readable but the "certificates" in Section 4 > refers "intermediate" CA's ones only, dos not refer to root CA's ones. Sorry, I am not able to read this from rfc3280. To quote it again: This extension MUST appear as a critical extension in all CA certificates that contain public keys used to validate digital signatures on certificates. This extension MAY appear as a critical The root certificates has the public key to verify the intermediate certificate. The ISIS-MTT profile says: This extension MAY appear in end entity certificates and MUST appear in CA certificates. It MUST be marked critical. Thus stating only that an EE certificate is allowed to carry a BasicContraints extension. It does not say anoything about the root certificate. Your interpretation is that a root certificate is not a CA certificate. My interpretation is that a root certificate has the public key and thus is a CA certificate used to verify a signature. I an see now other way to verify a signature without having a public key. Section 6 may or may not contradict this but the specification of the certificates in section 4 states that a root certificates requires a BasicConstraint. BTW, using root certificates based on MD5 is highly questionable and alone good reasons to not support those v1 root certificates. Shalom-Salam, Werner From wk at gnupg.org Mon Sep 25 12:31:00 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 25 12:36:50 2006 Subject: x509 v1 certificate In-Reply-To: <87irjcwcf7.fsf@latte.josefsson.org> (Simon Josefsson's message of "Mon, 25 Sep 2006 10:58:04 +0200") References: <87lkohcp9f.fsf@wheatstone.g10code.de> <20060919.083256.39153403.say@khaotic.net> <87d59q4tlb.fsf@wheatstone.g10code.de> <20060925.093526.27266308.kazu@iij.ad.jp> <87irjcwcf7.fsf@latte.josefsson.org> Message-ID: <8764fcz197.fsf@wheatstone.g10code.de> On Mon, 25 Sep 2006 10:58, Simon Josefsson said: > However, I do agree with you, and a perfectly reasonable > interpretation is that CA certificates (including root CAs) MUST have > key usage extensions, but a conforming verifier of certificates chains > should permit certificates without key usage extensions. This is also But not without BasicConstraints. I just looked at the test specification we had to pass and they clearly state that all CA certificates (including the root CA certificate) are required to carry a BasicConstraints. Whey saying "all certificates issued by a CA" this obviously includes the root certitificate because that one has been issued by the CA too. Whether it is self-signed or not does not matter. Salam-Shalom, Werner From wk at gnupg.org Mon Sep 25 12:36:09 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 25 12:42:04 2006 Subject: GnuPG 1.9.23 released In-Reply-To: (Georg C. F. Greve's message of "Wed, 20 Sep 2006 15:15:19 +0200") References: <877j01cnwd.fsf@wheatstone.g10code.de> <200609191607.16551.bernhard@intevation.de> <878xkf95yg.fsf@wheatstone.g10code.de> <200609192006.26690.bernhard@intevation.de> <873ban8zfh.fsf@wheatstone.g10code.de> Message-ID: <871wq0z10m.fsf@wheatstone.g10code.de> On Wed, 20 Sep 2006 15:15, Georg C. F. Greve said: > I wonder: could it ever become possible to build a "downsized" version > for specific purposes and limited dependencies from the gnupg2 branch? No. > That might make maintenance of 1.4 unnecessary in the long run. We will keep 1.4 and maybe even come up with 1.6 at some point. The reasons: * It is designed with no external build dependecies. Just configure and make and you end up with a usable OpenPGP implementation. This is not the case for 2.0. * GnuPG 1.4 is more portable that 2.0. It runs on may different OSes many of them predating the POSIX specs. We simply can't make GnuPG 2 run on them. * It is smaller and thus suitable for embedded or old platforms. Shalom-Salam, Werner From kazu at iij.ad.jp Mon Sep 25 12:52:28 2006 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Mon Sep 25 12:54:00 2006 Subject: x509 v1 certificate In-Reply-To: <8764fcz197.fsf@wheatstone.g10code.de> References: <20060925.093526.27266308.kazu@iij.ad.jp> <87irjcwcf7.fsf@latte.josefsson.org> <8764fcz197.fsf@wheatstone.g10code.de> Message-ID: <20060925.195228.135531168.kazu@iij.ad.jp> From: Werner Koch Subject: Re: x509 v1 certificate > Whey saying "all certificates issued by a CA" this obviously includes > the root certitificate because that one has been issued by the CA too. > Whether it is self-signed or not does not matter. During verification, a root certificate is NOT a certificate, but trusted anchor. This is a point. We can obtain trusted anchor from *anything*, even from something which is not a root certificate. Again, practically speaking, this information is extracted from the root certificate. But the root certificate is not treated as a certificate. How to verify root certificate is outside scope of the Section 6. --Kazu From kazu at iij.ad.jp Mon Sep 25 12:57:39 2006 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Mon Sep 25 12:59:14 2006 Subject: x509 v1 certificate In-Reply-To: <87ac4oz1ny.fsf@wheatstone.g10code.de> References: <87d59q4tlb.fsf@wheatstone.g10code.de> <20060925.093526.27266308.kazu@iij.ad.jp> <87ac4oz1ny.fsf@wheatstone.g10code.de> Message-ID: <20060925.195739.104567255.kazu@iij.ad.jp> > Section 6 may or may not contradict this but the specification > of the certificates in section 4 states that a root certificates > requires a BasicConstraint. Why do you trust section 4? Why don't you trust section 6, instead? Aagain, section 4 is not readable (i.e. hard to understand or mis-leading). --Kazu From jas at extundo.com Mon Sep 25 13:19:23 2006 From: jas at extundo.com (Simon Josefsson) Date: Mon Sep 25 13:17:42 2006 Subject: x509 v1 certificate In-Reply-To: <87ac4oz1ny.fsf@wheatstone.g10code.de> (Werner Koch's message of "Mon\, 25 Sep 2006 12\:22\:09 +0200") References: <87lkohcp9f.fsf@wheatstone.g10code.de> <20060919.083256.39153403.say@khaotic.net> <87d59q4tlb.fsf@wheatstone.g10code.de> <20060925.093526.27266308.kazu@iij.ad.jp> <87ac4oz1ny.fsf@wheatstone.g10code.de> Message-ID: <878xk8urb8.fsf@latte.josefsson.org> Werner Koch writes: > BTW, using root certificates based on MD5 is highly questionable and > alone good reasons to not support those v1 root certificates. I think only intermediate and end-entity certificates is a problem in practice. The signature in a root CA aka trusted anchor is typically never verified, so whether it is possible to fake that signature doesn't matter. For trusted anchors, it is the public key (and other information like key usage and basic constraints) in the certificate you need. Thus, a RSA-MD5 trust anchor verified using its SHA-1 fingerprint out of band should be secure. (I came to this conclusion when we made GnuTLS permit trusted anchors that used weak signature algorithms.) /Simon From fweimer at bfk.de Mon Sep 25 11:58:21 2006 From: fweimer at bfk.de (Florian Weimer) Date: Mon Sep 25 13:21:19 2006 Subject: [PATCH 3/3] Fix the "gpg: [don't know]: invalid packet (ctb=14)" bug In-Reply-To: References: Message-ID: <78ed7e9ce186d65118f066ebfae0b9887021df66.1159179048.git.fweimer@bfk.de> In some cases, zlib does not consume all bytes from the supplied buffer. The code did not handle this situation at all, essentially dropping these bytes. The fix uses the new iobuf_unread function to stuff the unread bytes back into the IOBUF where they came from. --- g10/compress.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/g10/compress.c b/g10/compress.c index 0cee5ae..9c0a4a4 100644 --- a/g10/compress.c +++ b/g10/compress.c @@ -210,6 +210,15 @@ #endif log_fatal("zlib inflate problem: rc=%d\n", zrc ); } } while( zs->avail_out && zrc != Z_STREAM_END && zrc != Z_BUF_ERROR ); + + if( zrc == Z_STREAM_END && zs->avail_in ) { + iobuf_unread(a, zs->next_in, zs->avail_in); + if( DBG_FILTER ) + log_debug("inflate: left %u bytes, unget buffer now has %u\n", + (unsigned)zs->avail_in, a->unget.len - a->unget.start); + zs->avail_in = 0; + } + *ret_len = zfx->outbufsize - zs->avail_out; if( DBG_FILTER ) log_debug("do_uncompress: returning %u bytes\n", (unsigned)*ret_len ); -- 1.4.2.1 From fweimer at bfk.de Mon Sep 25 12:10:00 2006 From: fweimer at bfk.de (Florian Weimer) Date: Mon Sep 25 13:21:47 2006 Subject: [PATCH 0/3] Fix the "gpg: [don't know]: invalid packet (ctb=14)" bug Message-ID: <82mz8ol0jr.fsf@mid.bfk.de> This series of patches fixes a long-standing bug in the interaction between GnuPG's packet parsing and zlib. (It's been mentioned several times in the mailing list archive.) Please review the changes; I hope I'll be able to fast-track it into Debian sid. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Durlacher Allee 47 tel: +49-721-96201-1 D-76131 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Mon Sep 25 11:54:22 2006 From: fweimer at bfk.de (Florian Weimer) Date: Mon Sep 25 13:21:58 2006 Subject: [PATCH 1/3] IOBUF: Document meaning of bits in the nofast field In-Reply-To: <82mz8ol0jr.fsf@mid.bfk.de> References: <82mz8ol0jr.fsf@mid.bfk.de> Message-ID: --- include/iobuf.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/iobuf.h b/include/iobuf.h index 0e3584c..4df9ab7 100644 --- a/include/iobuf.h +++ b/include/iobuf.h @@ -44,6 +44,8 @@ struct iobuf_struct { off_t nbytes; /* used together with nlimit */ off_t ntotal; /* total bytes read (position of stream) */ int nofast; /* used by the iobuf_get() */ + /* bit 0 (LSB): slow path because of limit */ + /* bit 1: slow path because of unread */ void *directfp; struct { size_t size; /* allocated size */ -- 1.4.2.1 From fweimer at bfk.de Mon Sep 25 11:56:17 2006 From: fweimer at bfk.de (Florian Weimer) Date: Mon Sep 25 13:22:13 2006 Subject: [PATCH 2/3] Implement iobuf_unread In-Reply-To: References: Message-ID: --- include/iobuf.h | 1 + util/iobuf.c | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 0 deletions(-) diff --git a/include/iobuf.h b/include/iobuf.h index 4df9ab7..f810fa7 100644 --- a/include/iobuf.h +++ b/include/iobuf.h @@ -115,6 +115,7 @@ int iobuf_seek( IOBUF a, off_t newpos int iobuf_readbyte(IOBUF a); int iobuf_read(IOBUF a, byte *buf, unsigned buflen ); +void iobuf_unread(IOBUF a, const byte *buf, unsigned buflen ); unsigned iobuf_read_line( IOBUF a, byte **addr_of_buffer, unsigned *length_of_buffer, unsigned *max_length ); int iobuf_peek(IOBUF a, byte *buf, unsigned buflen ); diff --git a/util/iobuf.c b/util/iobuf.c index f6e817c..c7c1fa4 100644 --- a/util/iobuf.c +++ b/util/iobuf.c @@ -1714,6 +1714,25 @@ iobuf_read(IOBUF a, byte *buf, unsigned return n; } +void +iobuf_unread(IOBUF a, const byte *buf, unsigned buflen ) +{ + unsigned new_len; + + /* We always relocate the buffer, which is not optimal. However, + the code is easier to read this way, and it is not on the fast + path. */ + + if( !a->unget.buf ) + a->unget.size = a->unget.start = a->unget.len = 0; + + new_len = a->unget.len + buflen; + a->unget.buf = xrealloc(a->unget.buf, new_len); + memcpy(a->unget.buf + a->unget.len, buf, buflen); + a->unget.len = new_len; + a->nofast |= 2; +} + /**************** * Have a look at the iobuf. -- 1.4.2.1 From jas at extundo.com Mon Sep 25 13:24:30 2006 From: jas at extundo.com (Simon Josefsson) Date: Mon Sep 25 13:22:51 2006 Subject: x509 v1 certificate In-Reply-To: <8764fcz197.fsf@wheatstone.g10code.de> (Werner Koch's message of "Mon\, 25 Sep 2006 12\:31\:00 +0200") References: <87lkohcp9f.fsf@wheatstone.g10code.de> <20060919.083256.39153403.say@khaotic.net> <87d59q4tlb.fsf@wheatstone.g10code.de> <20060925.093526.27266308.kazu@iij.ad.jp> <87irjcwcf7.fsf@latte.josefsson.org> <8764fcz197.fsf@wheatstone.g10code.de> Message-ID: <874puwur2p.fsf@latte.josefsson.org> Werner Koch writes: > On Mon, 25 Sep 2006 10:58, Simon Josefsson said: > >> However, I do agree with you, and a perfectly reasonable >> interpretation is that CA certificates (including root CAs) MUST have >> key usage extensions, but a conforming verifier of certificates chains >> should permit certificates without key usage extensions. This is also > > But not without BasicConstraints. I just looked at the test > specification we had to pass and they clearly state that all CA > certificates (including the root CA certificate) are required to carry > a BasicConstraints. > > Whey saying "all certificates issued by a CA" this obviously includes > the root certitificate because that one has been issued by the CA too. > Whether it is self-signed or not does not matter. If we talk about RFC 3280, the algorithm in section 6 doesn't verify root CAs aka trust anchors, only intermediate CAs, see: To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions: (a) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1; (b) certificate 1 is issued by the trust anchor; (c) certificate n is the certificate to be validated; and (d) for all x in {1, ..., n}, the certificate was valid at the time in question. When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path. Information about trust anchors are provided as inputs to the certification path validation algorithm (section 6.1.1). And further: 6.1.1 Inputs This algorithm assumes the following seven inputs are provided to the path processing logic: ... (d) trust anchor information, describing a CA that serves as a trust anchor for the certification path. The trust anchor information includes: (1) the trusted issuer name, (2) the trusted public key algorithm, (3) the trusted public key, and (4) optionally, the trusted public key parameters associated with the public key. The trust anchor information may be provided to the path processing procedure in the form of a self-signed certificate. The trusted anchor information is trusted because it was delivered to the path processing procedure by some trustworthy out-of-band procedure. If the trusted public key algorithm requires parameters, then the parameters are provided along with the trusted public key. Although in general, I'd love to see more implementations reject CAs that doesn't conform to RFC 3280 section 4. It is difficult to motivate that decision by pointing to any standard, though, as far as I know. /Simon From bob.dunlop at xyzzy.org.uk Thu Sep 21 09:05:52 2006 From: bob.dunlop at xyzzy.org.uk (Bob Dunlop) Date: Mon Sep 25 13:57:15 2006 Subject: gpgme-1.0.3: local variable used before set In-Reply-To: <451163DE.1020806@suse.cz> References: <451163DE.1020806@suse.cz> Message-ID: <20060921070552.GA8366@xyzzy.org.uk> Hi, On Wed, Sep 20 at 05:53, Ales Nosek wrote: > David Binderman wrote: > > I just tried to compile package gpgme-1.0.3-9 with the Intel C compiler. > > It said > > keylist.c(370): warning #592: variable "key" is used before its value is set > > The source code is > > DEBUG3 ("keylist_colon_handler ctx = %p, key = %p, line = %s\n", > ctx, key, line ? line : "(null)"); > > I agree with the compiler. Suggest initialise local variable "key" > before first use. I agree with the comiler and the error also, but I don't think I agree with your fix. Key is uninitialised at this point and isi in fact initialised 8 lines further on: key = opd->tmp_key; Your nulling of the variable is spurious in the non-debug case and the displaying of the value by the DEBUG statement is misleading. It implies that the value has a use at this point. Better in my opinion to remove the display of the spurious key value from the DEBUG statement. --- keylist.c-orig 2004-12-07 20:42:12.000000000 +0000 +++ keylist.c 2006-09-21 07:55:59.000000000 +0100 @@ -367,8 +367,8 @@ gpgme_subkey_t subkey = NULL; gpgme_key_sig_t keysig = NULL; - DEBUG3 ("keylist_colon_handler ctx = %p, key = %p, line = %s\n", - ctx, key, line ? line : "(null)"); + DEBUG2 ("keylist_colon_handler ctx = %p, line = %s\n", + ctx, line ? line : "(null)"); err = _gpgme_op_data_lookup (ctx, OPDATA_KEYLIST, &hook, -1, NULL); opd = hook; -- Bob Dunlop From wk at gnupg.org Mon Sep 25 14:43:23 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 25 14:47:06 2006 Subject: x509 v1 certificate In-Reply-To: <878xk8urb8.fsf@latte.josefsson.org> (Simon Josefsson's message of "Mon, 25 Sep 2006 13:19:23 +0200") References: <87lkohcp9f.fsf@wheatstone.g10code.de> <20060919.083256.39153403.say@khaotic.net> <87d59q4tlb.fsf@wheatstone.g10code.de> <20060925.093526.27266308.kazu@iij.ad.jp> <87ac4oz1ny.fsf@wheatstone.g10code.de> <878xk8urb8.fsf@latte.josefsson.org> Message-ID: <87k63sxgk4.fsf@wheatstone.g10code.de> On Mon, 25 Sep 2006 13:19, Simon Josefsson said: > practice. The signature in a root CA aka trusted anchor is typically > never verified, so whether it is possible to fake that signature I agree that it does not make much sense to verify it as you can only detect root certificates which are buggy. However this happens quite easily as verified by the recent tries to replicate the Bleichenbacher attack :-) Am not a 100% sure but believe that at the time gpgsm was tested at a certifcation lab they explicity tested the correctness of the root certificates. Will need to look up all the papers to verify this. > Thus, a RSA-MD5 trust anchor verified using its SHA-1 fingerprint out > of band should be secure. Agreed. However we need to pass the certification. I'll check in the next days. Salam-Shalom, Werner From wk at gnupg.org Mon Sep 25 14:45:45 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 25 14:51:40 2006 Subject: x509 v1 certificate In-Reply-To: <20060925.195739.104567255.kazu@iij.ad.jp> (Kazu Yamamoto's message of "Mon, 25 Sep 2006 19:57:39 +0900 (JST)") References: <87d59q4tlb.fsf@wheatstone.g10code.de> <20060925.093526.27266308.kazu@iij.ad.jp> <87ac4oz1ny.fsf@wheatstone.g10code.de> <20060925.195739.104567255.kazu@iij.ad.jp> Message-ID: <87fyegxgg6.fsf@wheatstone.g10code.de> On Mon, 25 Sep 2006 12:57, Kazu Yamamoto (????) said: > Why do you trust section 4? > Why don't you trust section 6, instead? Why don't you trust section 4? Why do you trust section 6, instead? SCNR. In afct I did not implemented it according to PKIX but to the said German profile which is supposed to be compatible with PKIX. Shalom-Salam, Werner From kazu at iij.ad.jp Mon Sep 25 15:08:49 2006 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Mon Sep 25 15:10:23 2006 Subject: x509 v1 certificate In-Reply-To: <87fyegxgg6.fsf@wheatstone.g10code.de> References: <87ac4oz1ny.fsf@wheatstone.g10code.de> <20060925.195739.104567255.kazu@iij.ad.jp> <87fyegxgg6.fsf@wheatstone.g10code.de> Message-ID: <20060925.220849.167661107.kazu@iij.ad.jp> > Why don't you trust section 4? > Why do you trust section 6, instead? Because verisign's root certificates are v1 which are widely accepted. --Kazu From wk at gnupg.org Mon Sep 25 16:07:56 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 25 16:11:46 2006 Subject: x509 v1 certificate In-Reply-To: <874puwur2p.fsf@latte.josefsson.org> (Simon Josefsson's message of "Mon, 25 Sep 2006 13:24:30 +0200") References: <87lkohcp9f.fsf@wheatstone.g10code.de> <20060919.083256.39153403.say@khaotic.net> <87d59q4tlb.fsf@wheatstone.g10code.de> <20060925.093526.27266308.kazu@iij.ad.jp> <87irjcwcf7.fsf@latte.josefsson.org> <8764fcz197.fsf@wheatstone.g10code.de> <874puwur2p.fsf@latte.josefsson.org> Message-ID: <877izsxcn7.fsf@wheatstone.g10code.de> Hi, I found this reference (ISIS_MTT, Part 5, Table 2, Column 3 - Pseudo code for ValidateCertificate): if( tbvCert.certType != EndEntityAC ) { if( tbvCert.KeyUsagePresent()==false ) return false; if( CheckKeyUsage( tbvCert, intendedKeyUsage )==false ) return false; } It is practical to check at this early stage whether the certificate is authorized for the intended key usage indicated in parameter intendedKeyUsage. Permitted key uses are indicated in the KeyUsage and the ExtendedKeyUsage extensions of tbvCert. CA certificates (i.e. CA-, root-CA- and cross-certificates) MUST furthermore contain ! ^^^^^^^^ the BasicConstraints extension and MUST have the cA-flag set. If the intended usage is not permitted, ValidatCertificate() returns false. ISIS-MTT PROFILE: Note that the KeyUsage extension MUST be present in all PKCs and is always critical (P1.T12.[1]). Where BasicContraints are explictly required for root certificates. Well, this is what we had to implement in gpgsm. As said, there are so many profiles and all want to be compatible to each other. Shalom-Salam, Werner From wk at gnupg.org Mon Sep 25 16:20:32 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 25 16:26:43 2006 Subject: x509 v1 certificate In-Reply-To: <20060925.220849.167661107.kazu@iij.ad.jp> (Kazu Yamamoto's message of "Mon, 25 Sep 2006 22:08:49 +0900 (JST)") References: <87ac4oz1ny.fsf@wheatstone.g10code.de> <20060925.195739.104567255.kazu@iij.ad.jp> <87fyegxgg6.fsf@wheatstone.g10code.de> <20060925.220849.167661107.kazu@iij.ad.jp> Message-ID: <87zmcovxhr.fsf@wheatstone.g10code.de> On Mon, 25 Sep 2006 15:08, Kazu Yamamoto (????) said: > Because verisign's root certificates are v1 which are widely accepted. Isn't that the company who once issue a certificate for MICROS0FT.COM :-) To be fair it doesn't matter which CA issues bogus certificates as in general all 100 and more root certificates are implicitly cross-certified. I consider a per root CA flag to allow relaxing some checks. Salam-Shalom, Werner From kazu at iij.ad.jp Mon Sep 25 16:44:43 2006 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Mon Sep 25 16:46:10 2006 Subject: x509 v1 certificate In-Reply-To: <87zmcovxhr.fsf@wheatstone.g10code.de> References: <87fyegxgg6.fsf@wheatstone.g10code.de> <20060925.220849.167661107.kazu@iij.ad.jp> <87zmcovxhr.fsf@wheatstone.g10code.de> Message-ID: <20060925.234443.179203163.kazu@iij.ad.jp> > Isn't that the company who once issue a certificate for MICROS0FT.COM :-) I don't understand what's point here. Some authors of RFC 3280 belongs to versign. Why did they have to write RFC3280 which make their certificates invalid? It seems to me that it is not the case. They wrote RFC3280 so as their certificates are all valid and unfortunately Section 4 is mis-leading somewhat. --Kazu From kazu at iij.ad.jp Mon Sep 25 16:50:19 2006 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Mon Sep 25 16:51:49 2006 Subject: x509 v1 certificate In-Reply-To: <87zmcovxhr.fsf@wheatstone.g10code.de> References: <87fyegxgg6.fsf@wheatstone.g10code.de> <20060925.220849.167661107.kazu@iij.ad.jp> <87zmcovxhr.fsf@wheatstone.g10code.de> Message-ID: <20060925.235019.110722867.kazu@iij.ad.jp> Hello, One more thing.: I think the best way to see which interpretation is correct is ask the authors of RFC 3280... --Kazu From wk at gnupg.org Mon Sep 25 17:19:01 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 25 17:22:25 2006 Subject: x509 v1 certificate In-Reply-To: <20060925.234443.179203163.kazu@iij.ad.jp> (Kazu Yamamoto's message of "Mon, 25 Sep 2006 23:44:43 +0900 (JST)") References: <87fyegxgg6.fsf@wheatstone.g10code.de> <20060925.220849.167661107.kazu@iij.ad.jp> <87zmcovxhr.fsf@wheatstone.g10code.de> <20060925.234443.179203163.kazu@iij.ad.jp> Message-ID: <8764fcvusa.fsf@wheatstone.g10code.de> On Mon, 25 Sep 2006 16:44, Kazu Yamamoto (????) said: >> Isn't that the company who once issue a certificate for MICROS0FT.COM :-) > > I don't understand what's point here. The point is that the whole CA business is about collecting money and not about security. A security aware CA would have checked names not just by scripts but by proper manual checks. And then a name as simliar to MICROSOFT.COM (watch out for the "0/O") would not be eligable for such a certificate. > Some authors of RFC 3280 belongs to versign. Why did they have to [The advantage for them to work in the WG was to help them educate a little bit on how to CA the right way.] > It seems to me that it is not the case. They wrote RFC3280 so as their > certificates are all valid and unfortunately Section 4 is mis-leading > somewhat. Yep. The usual specification mangling process to turn all bugs in a software into a feature. Shalom-Salam, Werner From dshaw at jabberwocky.com Tue Sep 26 05:33:38 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Sep 26 05:32:39 2006 Subject: DSA2 In-Reply-To: References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> Message-ID: <20060926033338.GA4375@jabberwocky.com> On Sat, Sep 23, 2006 at 03:15:07PM +0200, Carlo Luciano Bianco wrote: > I just try to summarize what I understood from this thread about > OpenPGP implementation of DSA and RSA signatures, so you can correct > me if I am wrong: ;-) > > - DSA is limited to 256-bit hashes (greater hashes are truncated). > - DSA is limited to 3072-bit keys (largers are useless, see above). Correct, but not completely correct. The DSA algorithm can handle larger hashes and larger keys, but there is little point in a larger hash when you don't have a larger key to go along with it (the whole "balance" argument). GnuPG will properly handle a 7680 bit DSA key (384 bit hash) and 15360 bit DSA key (512 bit hash), but it's not recommended because of the speed. > On the other hand: > > - RSA supports hashes up to 512-bit full lenght. > - RSA supports keys up to 4096 bit. Again correct, but not the whole story. RSA can certainly handle a 512-bit hash, but the whole balance question comes in again. A 4096-bit RSA key roughly balances a hash somewhere between 256 and 384 bits. A 512-bit hash will work with a 4096-bit key, yes, but that doesn't really change the overall strength of the signature. The hash is stronger than the key, so the key is the weak point. GnuPG will accept larger RSA keys than 4096, by the way. Again, it just makes things slow. > So my point is: what is the real advantage of "DSA2" over RSA > (if any, beside being the US standard)? Smaller signatures, for one. Try making a 3072-bit key/256-bit hash with DSA and RSA. The RSA signature is much larger. > Therefore, now that GnuPG uses 256-bit symmetric algos and 512-bit > hashes (i.e. AES-256 and SHA-512), shouldn't we use also DSA/ElG and > RSA keys greater than 4096-bits, to achieve a "balanced" security? Only if you have a lot of time to wait for signatures to be issued ;) David From wk at gnupg.org Tue Sep 26 11:13:41 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Sep 26 11:16:54 2006 Subject: x509 v1 certificate In-Reply-To: <20060925.220849.167661107.kazu@iij.ad.jp> (Kazu Yamamoto's message of "Mon, 25 Sep 2006 22:08:49 +0900 (JST)") References: <87ac4oz1ny.fsf@wheatstone.g10code.de> <20060925.195739.104567255.kazu@iij.ad.jp> <87fyegxgg6.fsf@wheatstone.g10code.de> <20060925.220849.167661107.kazu@iij.ad.jp> Message-ID: <87fyeft2gq.fsf@wheatstone.g10code.de> On Mon, 25 Sep 2006 15:08, Kazu Yamamoto (????) said: > Because verisign's root certificates are v1 which are widely accepted. Okay, with the current SVN version of gnupg, you may now have a line 85371CA6E550143DCE2803471BDE3A09E8F8770F S relax in the trustlist.txt to allow using the old Verisign certificates. Note the "relax" flag. You need to restart gpg-agent. Shalom-Salam, Werner From wk at gnupg.org Tue Sep 26 12:23:41 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Sep 26 12:26:44 2006 Subject: DSA2 In-Reply-To: <20060926033338.GA4375@jabberwocky.com> (David Shaw's message of "Mon, 25 Sep 2006 23:33:38 -0400") References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060926033338.GA4375@jabberwocky.com> Message-ID: <871wpzsz82.fsf@wheatstone.g10code.de> On Tue, 26 Sep 2006 05:33, David Shaw said: > 4096-bit RSA key roughly balances a hash somewhere between 256 and 384 > bits. A 512-bit hash will work with a 4096-bit key, yes, but that But it doesn't balance with the probability of implementation, system, or user bugs. This is needs to be taken into acount and then even a 2048 bit key is too strong to balance out these other risks. One should always ask the question: How would I attack a system? Then it will soon be clear that breaking RSA or finding a second pre-image for SHA-1 is not the way any sane attacker would go. Shalom-Salam, Werner From dshaw at jabberwocky.com Tue Sep 26 14:34:47 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Sep 26 14:33:09 2006 Subject: DSA2 In-Reply-To: <871wpzsz82.fsf@wheatstone.g10code.de> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060926033338.GA4375@jabberwocky.com> <871wpzsz82.fsf@wheatstone.g10code.de> Message-ID: <20060926123447.GB4375@jabberwocky.com> On Tue, Sep 26, 2006 at 12:23:41PM +0200, Werner Koch wrote: > One should always ask the question: How would I attack a system? Then > it will soon be clear that breaking RSA or finding a second pre-image > for SHA-1 is not the way any sane attacker would go. Yes. Most discussion of algorithms and key sizes and hashes these days are not particularly meaningful in the real world. There is an odd assumption that the other factors in the system are axiomatically secure. It's the castle that has a million-mile-high wall with spikes... and a cardboard door. David From ladislav.hagara at unob.cz Tue Sep 26 15:50:03 2006 From: ladislav.hagara at unob.cz (Ladislav Hagara) Date: Tue Sep 26 17:21:26 2006 Subject: gnupg-1.9.90 build problem Message-ID: <4519300B.3020700@unob.cz> Hi, trying to compile gnupg-1.9.90 and seems I have some problem with readline (from gnupg's NEWS: Made readline work for gpg). I have installed last 5.1 readline with last patches. Please, is it a problem of my box (readline) or gnupg? Thanks. -- Ladislav Hagara ranlib libsimple-pwquery.a if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I/usr/include -O -march=pentium4 -mmmx -mfpmath=sse -msse -msse2 -pipe -O3 -Wall -Wno-pointer-sign -MT gpgrlhelp.o -MD -MP -MF ".deps/gpgrlhelp.Tpo" -c -o gpgrlhelp.o gpgrlhelp.c; \ then mv -f ".deps/gpgrlhelp.Tpo" ".deps/gpgrlhelp.Po"; else rm -f ".deps/gpgrlhelp.Tpo"; exit 1; fi In file included from /usr/include/readline/readline.h:37, from gpgrlhelp.c:34: /usr/include/readline/rltypedefs.h:65: error: syntax error before '*' token In file included from gpgrlhelp.c:34: /usr/include/readline/readline.h:416: error: syntax error before '*' token /usr/include/readline/readline.h:532: error: syntax error before '*' token /usr/include/readline/readline.h:533: error: syntax error before '*' token /usr/include/readline/readline.h:823: error: syntax error before 'FILE' /usr/include/readline/readline.h:840: error: syntax error before '}' token gpgrlhelp.c: In function 'init_stream': gpgrlhelp.c:66: warning: assignment from incompatible pointer type make[2]: make[2]: Leaving directory `/usr/src/gnupg-1.9.90/common' *** [gpgrlhelp.o] Error 1 make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/gnupg-1.9.90' make: *** [all] Error 2 From rdieter at math.unl.edu Tue Sep 26 18:23:01 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue Sep 26 18:29:30 2006 Subject: gnupg-1.9.90 build problem References: <4519300B.3020700@unob.cz> Message-ID: Ladislav Hagara wrote: > trying to compile gnupg-1.9.90 and seems I have some problem with > readline (from gnupg's NEWS: Made readline work for gpg). ditto, same error, using fedora core 6, readline-5.1. Also, trying to build *without* readline support (ie, when readline is not installed) fails too (but differently): ... gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I/usr/include -O2 -g -pipe -Wall -Wno-pointer-sign -c gpgrlhelp.c gpgrlhelp.c: In function 'set_completer': gpgrlhelp.c:45: error: 'rl_attempted_completion_function' undeclared (first use in this function) gpgrlhelp.c:45: error: (Each undeclared identifier is reported only once gpgrlhelp.c:45: error: for each function it appears in.) gpgrlhelp.c:46: error: 'rl_inhibit_completion' undeclared (first use in this function) gpgrlhelp.c: In function 'inhibit_completion': gpgrlhelp.c:52: error: 'rl_inhibit_completion' undeclared (first use in this function) gpgrlhelp.c: In function 'cleanup_after_signal': gpgrlhelp.c:58: warning: implicit declaration of function 'rl_free_line_state' gpgrlhelp.c:59: warning: implicit declaration of function 'rl_cleanup_after_signal' gpgrlhelp.c: In function 'init_stream': gpgrlhelp.c:65: error: 'rl_catch_signals' undeclared (first use in this function) gpgrlhelp.c:66: error: 'rl_instream' undeclared (first use in this function) gpgrlhelp.c:66: error: 'rl_outstream' undeclared (first use in this function) gpgrlhelp.c:67: error: 'rl_inhibit_completion' undeclared (first use in this function) gpgrlhelp.c: In function 'gnupg_rl_initialize': gpgrlhelp.c:80: error: 'readline' undeclared (first use in this function) gpgrlhelp.c:81: error: 'add_history' undeclared (first use in this function) gpgrlhelp.c:82: error: 'rl_readline_name' undeclared (first use in this function) make[2]: *** [gpgrlhelp.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/builddir/build/BUILD/gnupg-1.9.90/common' From johnmoore3rd at joimail.com Tue Sep 26 17:54:08 2006 From: johnmoore3rd at joimail.com (John W. Moore III) Date: Tue Sep 26 19:21:22 2006 Subject: ~4269 won't Compile Message-ID: <45194D20.7080908@joimail.com> I have stumbled when compiling the 1.4svn4269 release. Can anyone diagnose my problem from below? make[1]: Entering directory `/home/Compaq_Owner/4269/keyserver' gcc -g -O2 -march=i386 -mfpmath=387 -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno- 3dnow -Wall -s -static -o gpgkeys_ldap.exe gpgkeys_ldap-gpgkeys_ldap.o gpgkeys _ldap-ksutil.o -lwldap32 -lwsock32 gpgkeys_ldap-gpgkeys_ldap.o: In function `ldap2epochtime': F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_ldap.c:199: undefined reference to `timegm' gpgkeys_ldap-gpgkeys_ldap.o: In function `main': F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_ldap.c:367: undefined reference to `strsep' F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_ldap.c:376: undefined reference to `strsep' F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_ldap.c:388: undefined reference to `strsep' F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_ldap.c:403: undefined reference to `strsep' F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_ldap.c:421: undefined reference to `strsep' gpgkeys_ldap-gpgkeys_ldap.o:F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_lda p.c:435: more undefined references to `strsep' follow make[1]: *** [gpgkeys_ldap.exe] Error 1 make[1]: Leaving directory `/home/Compaq_Owner/4269/keyserver' make: *** [install-recursive] Error 1 Making check in m4 make[1]: Entering directory `/home/Compaq_Owner/4269/m4' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/Compaq_Owner/4269/m4' Making check in intl make[1]: Entering directory `/home/Compaq_Owner/4269/intl' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/Compaq_Owner/4269/intl' Making check in zlib make[1]: Entering directory `/home/Compaq_Owner/4269/zlib' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/Compaq_Owner/4269/zlib' Making check in util make[1]: Entering directory `/home/Compaq_Owner/4269/util' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/Compaq_Owner/4269/util' Making check in mpi make[1]: Entering directory `/home/Compaq_Owner/4269/mpi' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/Compaq_Owner/4269/mpi' Making check in cipher make[1]: Entering directory `/home/Compaq_Owner/4269/cipher' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/Compaq_Owner/4269/cipher' Making check in tools make[1]: Entering directory `/home/Compaq_Owner/4269/tools' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/Compaq_Owner/4269/tools' Making check in g10 make[1]: Entering directory `/home/Compaq_Owner/4269/g10' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/Compaq_Owner/4269/g10' Making check in keyserver make[1]: Entering directory `/home/Compaq_Owner/4269/keyserver' gcc -g -O2 -march=i386 -mfpmath=387 -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno- 3dnow -Wall -s -static -o gpgkeys_ldap.exe gpgkeys_ldap-gpgkeys_ldap.o gpgkeys _ldap-ksutil.o -lwldap32 -lwsock32 gpgkeys_ldap-gpgkeys_ldap.o: In function `ldap2epochtime': F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_ldap.c:199: undefined reference to `timegm' gpgkeys_ldap-gpgkeys_ldap.o: In function `main': F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_ldap.c:367: undefined reference to `strsep' F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_ldap.c:376: undefined reference to `strsep' F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_ldap.c:388: undefined reference to `strsep' F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_ldap.c:403: undefined reference to `strsep' F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_ldap.c:421: undefined reference to `strsep' gpgkeys_ldap-gpgkeys_ldap.o:F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_lda p.c:435: more undefined references to `strsep' follow make[1]: *** [gpgkeys_ldap.exe] Error 1 make[1]: Leaving directory `/home/Compaq_Owner/4269/keyserver' make: *** [check-recursive] Error 1 Compaq_Owner@YOUR-F78BF48CE2 ~/4269 $ TIA! JOHN :-\ Timestamp: Tuesday 26 Sep 2006, 11:54 --400 (Eastern Daylight Time) From wk at gnupg.org Tue Sep 26 20:45:14 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Sep 26 20:51:40 2006 Subject: ~4269 won't Compile In-Reply-To: <45194D20.7080908@joimail.com> (John W. Moore, III's message of "Tue, 26 Sep 2006 11:54:08 -0400") References: <45194D20.7080908@joimail.com> Message-ID: <87bqp2sc05.fsf@wheatstone.g10code.de> On Tue, 26 Sep 2006 17:54, John W. Moore III said: > F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_ldap.c:199: undefined > reference to `timegm' > gpgkeys_ldap-gpgkeys_ldap.o: In function `main': > F:/msys/home/Compaq_Owner/4269/keyserver/gpgkeys_ldap.c:367: undefined > reference to `strsep' I made that program a standalone one so that it does not depend on libcommon or libutil. This is for license reasons. We take strsep from gnulib (../gl) - obviously we need to add it. I need to check why timegm fails. Salam-Shalom, Werner From wk at gnupg.org Tue Sep 26 20:52:20 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Sep 26 20:56:45 2006 Subject: Revision numbers and branches In-Reply-To: <45194D20.7080908@joimail.com> (John W. Moore, III's message of "Tue, 26 Sep 2006 11:54:08 -0400") References: <45194D20.7080908@joimail.com> Message-ID: <873baesbob.fsf@wheatstone.g10code.de> Hi! If you report problems and give the SVN revision number, please also state which version your are building (i.e. 1.4 or trunk). Without it we need to guess it from the context. Shalom-Salam, Werner From clbianco at tiscalinet.it Wed Sep 27 00:33:38 2006 From: clbianco at tiscalinet.it (Carlo Luciano Bianco) Date: Wed Sep 27 01:33:27 2006 Subject: DSA2 References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060926033338.GA4375@jabberwocky.com> Message-ID: Il /26 set 2006/, *David Shaw* ha scritto: > On Sat, Sep 23, 2006 at 03:15:07PM +0200, Carlo Luciano Bianco > wrote: > >> I just try to summarize what I understood from this thread about >> OpenPGP implementation of DSA and RSA signatures, so you can >> correct me if I am wrong: ;-) >> >> - DSA is limited to 256-bit hashes (greater hashes are >> truncated). >> - DSA is limited to 3072-bit keys (largers are >> useless, see above). > > Correct, but not completely correct. Well... Better than what I was afraid of... ;-)) > The DSA algorithm can handle > larger hashes and larger keys, but there is little point in a > larger hash when you don't have a larger key to go along with it > (the whole "balance" argument). I see, and I fully share this argument. The strength of a chain is the strength of the weakest ring, not the one of the strongest. That's why I asked about using also larger (15Kbit) public keys, but... [...] > but it's not recommended because of the speed. OK. I got the point. >> On the other hand: >> >> - RSA supports hashes up to 512-bit full lenght. >> - RSA supports keys up to 4096 bit. > > Again correct, but not the whole story. RSA can certainly handle > a 512-bit hash, but the whole balance question comes in again. Of course, I see. > A > 4096-bit RSA key roughly balances a hash somewhere between 256 and > 384 bits. A 512-bit hash will work with a 4096-bit key, yes, but > that doesn't really change the overall strength of the signature. > The hash is stronger than the key, so the key is the weak point. > GnuPG will accept larger RSA keys than 4096, by the way. But it will not generate them, I suppose... > Again, it just makes things slow. > >> So my point is: what is the real advantage of "DSA2" over RSA >> (if any, beside being the US standard)? > > Smaller signatures, for one. Try making a 3072-bit key/256-bit > hash with DSA and RSA. The RSA signature is much larger. Yes, as I replied to Qed, this is a good point which I did not consider. Actually, I noticed this "enlargement" when I switched from my old DSA-1024/ElG-4096 key to my new RSA-4096/RSA-4096 one. But, at that time, I thought it was mainly due to the different key and hash sizes, not to the algorithm itself... >> Therefore, now that GnuPG uses 256-bit symmetric algos and >> 512-bit hashes (i.e. AES-256 and SHA-512), shouldn't we use also >> DSA/ElG and RSA keys greater than 4096-bits, to achieve a >> "balanced" security? > > Only if you have a lot of time to wait for signatures to be issued > ;) Well... I am usually very patient... ;-)) Trying to be a little less fool [;-)], this means that a "balanced" security with AES-256 and SHA-512 (which are balanced between themselves) can be actually achieved only with ECC public keys... -- | ICQ UIN: 109517158 Carlo Luciano Bianco | Home page: ______________________|________________________________________________ GnuPG RSAv4 4096 - Fingerprint:FA68CF697EA63865AAFA805F68703AD40609D743 From clbianco at tiscalinet.it Wed Sep 27 01:28:56 2006 From: clbianco at tiscalinet.it (Carlo Luciano Bianco) Date: Wed Sep 27 01:43:29 2006 Subject: DSA2 References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060926033338.GA4375@jabberwocky.com> <871wpzsz82.fsf@wheatstone.g10code.de> <20060926123447.GB4375@jabberwocky.com> Message-ID: Il /26 set 2006/, *David Shaw* ha scritto: > On Tue, Sep 26, 2006 at 12:23:41PM +0200, Werner Koch wrote: > >> One should always ask the question: How would I attack a system? >> Then it will soon be clear that breaking RSA or finding a second >> pre-image for SHA-1 is not the way any sane attacker would go. > > Yes. Most discussion of algorithms and key sizes and hashes these > days are not particularly meaningful in the real world. There is > an odd assumption that the other factors in the system are > axiomatically secure. Needless to say, I completely agree with both you and Werner on this. This discussion about "balancing" security is very interesting [at least for me... ;-)] from a theoretical point of view. I know very well that using this extra-large keys does not add any security in real life. An attacker who is really motivated in reading someone's e-mails and has enough money/time/resources, would never be so stupid to loose his/her time trying to "force" even a 1024-bit RSA key! It would be much more simple to install a keylogger and/or a backdoor on the victim's machine, for example. Before having a real security enhancement from an extra-large key, one must use a machine with only fully trusted and verified softwares and operating system [having inspected the source codes by himself - and I am writing this on my WinXP laptop... ;-)], he must not insert passphrases near windows [I mean *real* ones, made by glasses... ;-)], and he must take an incredible amount of other cautions... > It's the castle that has a million-mile-high wall with spikes... > and a cardboard door. We had a very long thread about OpenPGP security at the end of the last year on Italian usenet group it.comp.sicurezza.crittografia, where we made a small list of "possible ways to crack OpenPGP without even knowing what it is" (more or less). Just to quote one of them, did you ever check that there is not a hidden camera in the lamp on your desk? ;-) -- | ICQ UIN: 109517158 Carlo Luciano Bianco | Home page: ______________________|________________________________________________ GnuPG RSAv4 4096 - Fingerprint:FA68CF697EA63865AAFA805F68703AD40609D743 From rjh at sixdemonbag.org Wed Sep 27 02:01:30 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed Sep 27 01:59:51 2006 Subject: DSA2 In-Reply-To: References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060926033338.GA4375@jabberwocky.com> <871wpzsz82.fsf@wheatstone.g10code.de> <20060926123447.GB4375@jabberwocky.com> Message-ID: <4519BF5A.6050104@sixdemonbag.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Carlo Luciano Bianco wrote: > Needless to say, I completely agree with both you and Werner on this. > This discussion about "balancing" security is very interesting [at > least for me... ;-)] from a theoretical point of view. I know very > well that using this extra-large keys does not add any security in > real life. There's a contrary view, which says that balancing cryptosystem components is an unnecessary distraction. This contrary view says that each component of a system should be built to meet or exceed security requirements while meeting or exceeding performance and usability requirements. As long as each component is in that sweet spot, then you're great. For instance, I use SHA512 for my signatures. I do so for two reasons: (a) when I was entering my digest preferences I accidentally set SHA512 first, and (b) I haven't bothered to correct it yet. The reason why such an 'unbalanced' system is of no concern to me is simple: (a) none of my correspondents have complained about the size of my signatures and (b) using SHA512 is just as convenient and quick as using SHA256. Anyway, please don't think I'm saying balanced systems are problematic or silly or anything else. All I'm saying is there's more than one way to interpret security best practices. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBCgAGBQJFGb9aAAoJELcA9IL+r4EJ+0YIAKN1RHpEtumxAMg75E+T7Q5I X2ofYUcmoFbyqNJLw5FXk7P35hhibY0ienY3+kMQLe1kTzY0+Sq64gU0BgWhUv6m xuPI8VABSXfPI5XKfiDhTZR+7w6Ige/oibyUdHWRrjas7XOY5qa5M6QbSAfKUIkN OfJGH6Wc7+fepm91/IEGakrmlMqfb1B9Qx0odoQSQq3Ur9nEAFlIA8JByhivfPIf 4rg50R6nmyptGKyf87gx3hWBQedXlmZQ+rNrzGjv7D4XUTV4EQ9BvSeoRPOXzjDP /Ku7P5RXzbmOMQlwZEXUo75Emef2qkINmMMchjylsI36MrL7V5xmPoIDY5KlY78= =vp6Q -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Wed Sep 27 06:45:15 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Sep 27 06:43:43 2006 Subject: DSA2 In-Reply-To: References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060926033338.GA4375@jabberwocky.com> Message-ID: <20060927044515.GC28262@jabberwocky.com> On Wed, Sep 27, 2006 at 12:33:38AM +0200, Carlo Luciano Bianco wrote: > >> So my point is: what is the real advantage of "DSA2" over RSA > >> (if any, beside being the US standard)? > > > > Smaller signatures, for one. Try making a 3072-bit key/256-bit > > hash with DSA and RSA. The RSA signature is much larger. > > Yes, as I replied to Qed, this is a good point which I did not > consider. Actually, I noticed this "enlargement" when I switched > from my old DSA-1024/ElG-4096 key to my new RSA-4096/RSA-4096 one. > But, at that time, I thought it was mainly due to the different key > and hash sizes, not to the algorithm itself... It's due to both, actually. The RSA signature size is tied to the size of the key. The DSA signature size is tied to the size of the hash used (and remember that DSA can accept truncated hashes). David From dshaw at jabberwocky.com Wed Sep 27 06:57:39 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Sep 27 06:56:09 2006 Subject: DSA2 In-Reply-To: <4519BF5A.6050104@sixdemonbag.org> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060926033338.GA4375@jabberwocky.com> <871wpzsz82.fsf@wheatstone.g10code.de> <20060926123447.GB4375@jabberwocky.com> <4519BF5A.6050104@sixdemonbag.org> Message-ID: <20060927045739.GD28262@jabberwocky.com> On Tue, Sep 26, 2006 at 07:01:30PM -0500, Robert J. Hansen wrote: > Carlo Luciano Bianco wrote: > > Needless to say, I completely agree with both you and Werner on this. > > This discussion about "balancing" security is very interesting [at > > least for me... ;-)] from a theoretical point of view. I know very > > well that using this extra-large keys does not add any security in > > real life. > > There's a contrary view, which says that balancing cryptosystem > components is an unnecessary distraction. This contrary view says that > each component of a system should be built to meet or exceed security > requirements while meeting or exceeding performance and usability > requirements. As long as each component is in that sweet spot, then > you're great. Indeed. I'm not even sure this is a "contrary" view, as it is very compatible with the idea of balance. There is nothing invalid about a 8192-bit RSA key making SHA-1 signatures. It just means that the signature has at most 80 bits of strength. The signer could have used a 1024-bit RSA key and gotten the same 80 bits of strength, but that doesn't make the 8192-bit signature wrong (just large). David From wk at gnupg.org Wed Sep 27 10:15:20 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Sep 27 10:21:48 2006 Subject: DSA2 In-Reply-To: <4519BF5A.6050104@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 26 Sep 2006 19:01:30 -0500") References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060926033338.GA4375@jabberwocky.com> <871wpzsz82.fsf@wheatstone.g10code.de> <20060926123447.GB4375@jabberwocky.com> <4519BF5A.6050104@sixdemonbag.org> Message-ID: <87lko5rahz.fsf@wheatstone.g10code.de> On Wed, 27 Sep 2006 02:01, Robert J. Hansen said: > my signatures and (b) using SHA512 is just as convenient and quick as > using SHA256. Jyust for the records here are benchmarks from libgcrypt for 10^6 bytes, calculated in chunks of 1000, 100 and 1 bytes: SHA1 30ms 50ms 180ms SHA224 30ms 50ms 110ms SHA256 90ms 50ms 110ms SHA384 70ms 100ms 140ms SHA512 70ms 90ms 150ms So there is a noticable performance gain for SHA256 (except for the first one which might be a caching issue) Shalom-Salam, Werner From rjh at sixdemonbag.org Wed Sep 27 10:40:35 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed Sep 27 10:39:10 2006 Subject: DSA2 In-Reply-To: <87lko5rahz.fsf@wheatstone.g10code.de> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060926033338.GA4375@jabberwocky.com> <871wpzsz82.fsf@wheatstone.g10code.de> <20060926123447.GB4375@jabberwocky.com> <4519BF5A.6050104@sixdemonbag.org> <87lko5rahz.fsf@wheatstone.g10code.de> Message-ID: <451A3903.6020100@sixdemonbag.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Werner Koch wrote: > So there is a noticable performance gain for SHA256 (except for the > first one which might be a caching issue) Given the difference is just a handful of milliseconds for a 1mb file, and most of the data I send is at most a few k, I feel safe in repeating my assertion that for my usage profile SHA512 meets my usability and performance goals. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBCgAGBQJFGjkDAAoJELcA9IL+r4EJ/dcIAJg9iVmDFgoy/mvOu+AcJTSZ cA52WBGDYABdk3EOEygYRLlssAVWeYrxHOSiuYYvpaxUHwzpdDCY21adZJVDIFAd jAGM04mUblHsdLv12SI64fFuZtI0i/Arin5gIb6rsCRk81splfwwD7CKJic4cuQp r5XC0ZV7y5CDwBziDAqV1iAkRk8/xSFSj5XnxLjZIcy1z0V4pg+axau3c/g0dZuA gQcE0Kw5n/DnMbuod0fbDxiIGo1nbtd08TfKBvDWUwzmCbK0ggEFdAwpssOpHrWV xIqA2U8aOR7lkWFl6sxWEqZ6J2nq/2wu/Q669eWtSlN0ObENPjl+yktQxv4hmEI= =27Tv -----END PGP SIGNATURE----- From wk at gnupg.org Wed Sep 27 14:03:43 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Sep 27 14:06:41 2006 Subject: [PATCH 0/3] Fix the "gpg: [don't know]: invalid packet (ctb=14)" bug In-Reply-To: <82mz8ol0jr.fsf@mid.bfk.de> (Florian Weimer's message of "Mon, 25 Sep 2006 12:10:00 +0200") References: <82mz8ol0jr.fsf@mid.bfk.de> Message-ID: <87fyedqzxc.fsf@wheatstone.g10code.de> On Mon, 25 Sep 2006 12:10, Florian Weimer said: > Please review the changes; I hope I'll be able to fast-track it into > Debian sid. Applied to trunk (gpg2). However I have not yet found any test cases. Frankly I believe this should be fixed in zlib. Salam-Shalom, Werner From clbianco at tiscalinet.it Thu Sep 28 00:46:00 2006 From: clbianco at tiscalinet.it (Carlo Luciano Bianco) Date: Thu Sep 28 00:55:53 2006 Subject: DSA2 References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060926033338.GA4375@jabberwocky.com> <871wpzsz82.fsf@wheatstone.g10code.de> <20060926123447.GB4375@jabberwocky.com> <4519BF5A.6050104@sixdemonbag.org> Message-ID: Il /27 set 2006/, *Robert J. Hansen* ha scritto: > Carlo Luciano Bianco wrote: >> Needless to say, I completely agree with both you and Werner on >> this. This discussion about "balancing" security is very >> interesting [at least for me... ;-)] from a theoretical point of >> view. I know very well that using this extra-large keys does not >> add any security in real life. > > There's a contrary view, which says that balancing cryptosystem > components is an unnecessary distraction. This contrary view says > that each component of a system should be built to meet or exceed > security requirements while meeting or exceeding performance and > usability requirements. As long as each component is in that > sweet spot, then you're great. I agree with David in saying that this two points of view are not necessarily "contrary" to each other. You can chose a "minimum" security level and then make sure that all cryptosystem components are "balanced" in the sense that they all meet at least such level. This is also because the "equivalence" between the security of a DSA/RSA 15-kbit key, SHA-512 and AES-256 comes just from a more or less rough estimate and not from a mathematical theorem (AFAIK). Therefore, if you "overshoot" the security of a component of your cryptosystem, this is not bad. At worst, it is not even good (i.e. it is useless), but for sure it is not bad. Just to make an example: I am currently using a 4096-bit RSA key, with AES-256 and SHA-512 as "preferred" algorithms. I am not going to switch back to AES-128 and SHA-256 to have a "balanced" system. I will stay with AES-256 and SHA-512, even if they are estimated to be much more secure than 4096-bit RSA keys (and therefore maybe "useless"). In this way, I can be reasonably sure that the weakest component of my cryptosystem is the 4096-bit RSA key. But such a key meets my minimum security requirements, so I am safe. The "balance" requirement for my cryptosystem means that I will bother GnuPG developers about adding full support for longer public keys before bothering them about longer symmetric keys and longer hashes, instead of viceversa... ;-) -- | ICQ UIN: 109517158 Carlo Luciano Bianco | Home page: ______________________|________________________________________________ GnuPG RSAv4 4096 - Fingerprint:FA68CF697EA63865AAFA805F68703AD40609D743 From johnmoore3rd at joimail.com Thu Sep 28 05:44:03 2006 From: johnmoore3rd at joimail.com (John W. Moore III) Date: Thu Sep 28 05:42:28 2006 Subject: DSA2 In-Reply-To: <20060928033058.GB13728@jabberwocky.com> References: <45169A4E.40702@tiscali.it> <45169F70.1000600@gmail.com> <4516A43D.3060808@tiscali.it> <5d7f07420609241402r44ef21em2bf80df62a04aa7f@mail.gmail.com> <4517605C.8040303__40604.7906996266$1159160554$gmane$org@comcast.net> <20060927002617.GA28262__2510.2142397829$1159316883$gmane$org@jabberwocky.com> <20060928030545.GA13728@jabberwocky.com> <451B40CB.8@joimail.com> <20060928033058.GB13728@jabberwocky.com> Message-ID: <451B4503.7010101@joimail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 David Shaw wrote: > Probably not. It's literally a change in the comments. No actual > code change involved. > > David > Ahhhh...But the New Branch Release does *not* Compile. Surely you and Others are interested in that??? There has been much speculation about the \Trunk superseding the \Branch development. You are so associated with clean Branch Code...ya gotta have an Interest. JOHN :-\ Timestamp: Wednesday 27 Sep 2006, 23:42 --400 (Eastern Daylight Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6-svn4250: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Homepage: http://tinyurl.com/9ubue Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBCgAGBQJFG0UBAAoJEBCGy9eAtCsPgNUH/iFrOVmQKv0XHsh38aalAE6d c57lrjjFHSrzCbVAVdq3+RUTWtk6g159Hu37IsQ92dMW0a7pzNsYIg3w9PwKcL+X g3z3QOSowZkzb0eNZRus9V3iWPshPYOemqFn2p7PDb43P9pXgnAvS72OKNwcWtzn uR3jmyMPRv/iRrk2sJ/+PYGYF6WIxaghmVUqFKRbt3Parx8mt8QvKBXE0BRjJ2Rd 1gtYcY9FtYph1CKvBk9P/JmQ98cbyNBe1DrXXCm3fyfoq/JfcQtQKbv2mJMNumP+ fU+6RnwZj8QfEnS/Tu5ni3TP+nc6txXDJRasuUKQ0WCcb+821y4XAz1tvFn8mDk= =7P34 -----END PGP SIGNATURE----- From kristian.fiskerstrand at kfwebs.net Thu Sep 28 06:46:17 2006 From: kristian.fiskerstrand at kfwebs.net (Kristian Fiskerstrand) Date: Thu Sep 28 08:21:46 2006 Subject: DSA2 In-Reply-To: References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060926033338.GA4375@jabberwocky.com> <871wpzsz82.fsf@wheatstone.g10code.de> <20060926123447.GB4375@jabberwocky.com> <4519BF5A.6050104@sixdemonbag.org> Message-ID: <451B5399.4020600@kfwebs.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carlo Luciano Bianco wrote, On 09/28/2006 12:46 AM: > Il /27 set 2006/, *Robert J. Hansen* ha scritto: > >> Carlo Luciano Bianco wrote: >>> Needless to say, I completely agree with both you and Werner on >>> this. This discussion about "balancing" security is very >>> interesting [at least for me... ;-)] from a theoretical point of >>> view. I know very well that using this extra-large keys does not >>> add any security in real life. >> There's a contrary view, which says that balancing cryptosystem >> components is an unnecessary distraction. This contrary view says >> that each component of a system should be built to meet or exceed >> security requirements while meeting or exceeding performance and >> usability requirements. As long as each component is in that >> sweet spot, then you're great. > > I agree with David in saying that this two points of view are not > necessarily "contrary" to each other. You can chose a "minimum" > security level and then make sure that all cryptosystem components > are "balanced" in the sense that they all meet at least such level. > > This is also because the "equivalence" between the security of a > DSA/RSA 15-kbit key, SHA-512 and AES-256 comes just from a more or > less rough estimate and not from a mathematical theorem (AFAIK). > Therefore, if you "overshoot" the security of a component of your > cryptosystem, this is not bad. At worst, it is not even good (i.e. > it is useless), but for sure it is not bad. > > Just to make an example: > > I am currently using a 4096-bit RSA key, with AES-256 and SHA-512 as > "preferred" algorithms. I am not going to switch back to AES-128 and > SHA-256 to have a "balanced" system. I will stay with AES-256 and > SHA-512, even if they are estimated to be much more secure than > 4096-bit RSA keys (and therefore maybe "useless"). In this way, I > can be reasonably sure that the weakest component of my cryptosystem > is the 4096-bit RSA key. But such a key meets my minimum security > requirements, so I am safe. > > The "balance" requirement for my cryptosystem means that I will > bother GnuPG developers about adding full support for longer public > keys before bothering them about longer symmetric keys and longer > hashes, instead of viceversa... ;-) > Last time I checked GnuPG supported to read larger keys, to generate them only requires altering the max variable in the sourecode. I used this to test the performance on a system with some different keysizes, one of them being 15,360 bits. The 15,360bit ElGamal encryption key took me about 20 hours to generate on an Intel Centrino 1400MHz. Which is more that what would be considered practical for ordinary uses, on the same computer encrypting a file took about 33 seconds using the key. It was slower ( 44 seconds ) on my Dual PIII 1000MHz, as it wasn't shared across the CPUs ( http://www.kfwebs.net/news/62/Experimenting-with-GnuPG ) I CCed the sender as some posts of mine in the past have never reached the list, probably due to using a different sender address and moderation. Yours sincerely - -- - ---------------------------- Kristian Fiskerstrand http://www.kfwebs.net - ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this, visit: http://www.secure-my-email.com - ---------------------------- http://www.secure-my-internet.com http://www.yourblog.in - ---------------------------- Public PGP key 0x6B0B9508 at http://www.kfwebs.net/pgp/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5-svn4189 (GNU/Linux) iQIVAwUBRRtTmRbgz41rC5UIAQLxrxAAo0gDyVbGeDp7MLrcgOq4IrpuigsxbhO4 GVFRyxH8fNpBznbtIVrBXtaFkY8jg/VU20Q4GAaX4iyshwomOlQB+87XYqHQpwlV /oXUbXKFTswSChNtcmAkoYDI4lLlj22ZAnu0CU6pINe6uYLf6cxRGCti84cIZgCA 4xa2QnHDJbPraEV9ciiAxM7n0p+shD0ovDw5O5rnvA8v2X1oZusxGAFyR6Aw6HDN R2I8e4822s6Or/NEaeYot9Ef7tNLnmpzgAdDVSNkHC4NEwp/Xqs4NQ6q2tfQVVZH k6tofDyoGq/c0QOEMFoHgmReIpTu2ku48h9yqekRKdYnURDc8//ANwAMdKp9tq98 t+emQms6VHwimcYwzVz2rRofemP+WqPxEuj9FOytiNLvgsLlVXgA1ItK5la9Mfuq v05qSOXn431yrSu5Wwq3K4y5cTbiNuJG9VbVxbrkJfshHtFD/GoGSoF3rUcTNLwv CqLz9n4F6wJENmxBHVTwvuyBnXwy7JnyN+fw+Z6hvpq5wNm5x1ktD56qrK8ygFxn vmW9V3x85EOdXjHbZOczaa+yLB5UDBeZDtsI5ilYT4B5N5OZB7oHm3Pzl2kAwbBz F9UmlFBATzhNtugSzdjYHm0YPIPDuzV/ChBdqIiE4AHAgQioReiLKtpK+gSvqSQj 2CCMWJ/6pJE= =Tx1B -----END PGP SIGNATURE----- From wk at gnupg.org Thu Sep 28 10:00:22 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Sep 28 10:06:49 2006 Subject: DSA2 In-Reply-To: <451B4503.7010101@joimail.com> (John W. Moore, III's message of "Wed, 27 Sep 2006 23:44:03 -0400") References: <45169A4E.40702@tiscali.it> <45169F70.1000600@gmail.com> <4516A43D.3060808@tiscali.it> <5d7f07420609241402r44ef21em2bf80df62a04aa7f@mail.gmail.com> <4517605C.8040303__40604.7906996266$1159160554$gmane$org@comcast.net> <20060927002617.GA28262__2510.2142397829$1159316883$gmane$org@jabberwocky.com> <20060928030545.GA13728@jabberwocky.com> <451B40CB.8@joimail.com> <20060928033058.GB13728@jabberwocky.com> <451B4503.7010101@joimail.com> Message-ID: <87psdgju95.fsf@wheatstone.g10code.de> On Thu, 28 Sep 2006 05:44, John W. Moore III said: > Ahhhh...But the New Branch Release does *not* Compile. Surely you and SVN version in general do compile on the development box. They are not expected to build cleanly on other platforms. > Others are interested in that??? There has been much speculation about > the \Trunk superseding the \Branch development. You are so The thing is that we do development now on gnupg 1.9.90 (aka GnuPG 2) and port changes back to 1.4. Shalom-Salam, Werner From dshaw at jabberwocky.com Thu Sep 28 21:18:31 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Sep 28 21:16:53 2006 Subject: SVN and branches (was Re: DSA2) In-Reply-To: <451B4503.7010101@joimail.com> References: <4516A43D.3060808@tiscali.it> <5d7f07420609241402r44ef21em2bf80df62a04aa7f@mail.gmail.com> <4517605C.8040303__40604.7906996266$1159160554$gmane$org@comcast.net> <20060927002617.GA28262__2510.2142397829$1159316883$gmane$org@jabberwocky.com> <20060928030545.GA13728@jabberwocky.com> <451B40CB.8@joimail.com> <20060928033058.GB13728@jabberwocky.com> <451B4503.7010101@joimail.com> Message-ID: <20060928191831.GB15938@jabberwocky.com> On Wed, Sep 27, 2006 at 11:44:03PM -0400, John W. Moore III wrote: > David Shaw wrote: > > > Probably not. It's literally a change in the comments. No actual > > code change involved. > > > > David > > > > Ahhhh...But the New Branch Release does *not* Compile. Surely you and > Others are interested in that??? This is not good. First, you forwarded private mail to a mailing list. Second, your question was "Will a new branch release follow soon?". My answer, as seen above, was no. There is no reason to make a new GPG 1.4.x release for a license change with no change in actual functionality. How you got from there to a complaint that it doesn't currently compile, I don't see. The SVN code may not compile on some platforms. It may even stay in that state for a while while problems are worked out. That the difference between the SVN and a release. In this particular case, Werner and I were discussing how we wanted to fix the problem. Now that there are two GPG branches, it's important to not do something in one branch that will make life miserable in the other. > There has been much speculation about > the \Trunk superseding the \Branch development. The 1.4.x branch is not going away. David From 0xlukej at gmail.com Fri Sep 29 06:32:35 2006 From: 0xlukej at gmail.com (Luke J) Date: Fri Sep 29 07:25:52 2006 Subject: Problem with email addresses beginning with 0x Message-ID: <451CA1E3.8020804@gmail.com> Hi, I have recently started using GnuPG. My personal email address begins with 0x and this seems to cause problems for gpg when using the -u option. I think it tries to interpret the email address as a key ID instead. Naturally, when using this from the command line it isn't a big issue but when trying to gpg automatically from within Evolution or Thunderbird, it tries to sign or encrypt messages by specifying the email address as the argument to the -u option which causes the problem. At the moment this means I can't use GnuPG with this email address without annoying all the people I send emails to and myself! lol :) The error message I get is as follows: gpg: skipped "0xlukej@gmail.com": malformed user id gpg: signing failed: malformed user id Is this a known issue? Is there anyway around it? Thanks for your help, Luke From lionel at mamane.lu Fri Sep 29 07:11:12 2006 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Fri Sep 29 08:51:19 2006 Subject: DSA2 In-Reply-To: References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> Message-ID: <20060929051112.GA1551@capsaicin.mamane.lu> On Sat, Sep 23, 2006 at 03:15:07PM +0200, Carlo Luciano Bianco wrote: > I just try to summarize what I understood from this thread about > OpenPGP implementation of DSA and RSA signatures, so you can correct > me if I am wrong: ;-) > - DSA does not support "firewalled hashes" Not exactly. Version 3 DSA signatures lack a hash firewall. But version 4 DSA signatures do have a hash firewall. The version refers not to a version of DSA itself, but the version of the OpenPGP packet format being used. > On the other hand: > - RSA does support "firewalled hashes". All RSA signatures (V3 or V4) do have a hash firewall, yes. -- Lionel From JPClizbe at comcast.net Fri Sep 29 09:20:18 2006 From: JPClizbe at comcast.net (John Clizbe) Date: Fri Sep 29 09:19:44 2006 Subject: Problem with email addresses beginning with 0x In-Reply-To: <451CA1E3.8020804@gmail.com> References: <451CA1E3.8020804@gmail.com> Message-ID: <451CC932.5020302@comcast.net> Luke J wrote: > Hi, > > I have recently started using GnuPG. My personal email address begins > with 0x and this seems to cause problems for gpg when using the -u > option. I think it tries to interpret the email address as a key ID instead. > > Naturally, when using this from the command line it isn't a big issue > but when trying to gpg automatically from within Evolution or > Thunderbird, it tries to sign or encrypt messages by specifying the > email address as the argument to the -u option which causes the problem. > At the moment this means I can't use GnuPG with this email address > without annoying all the people I send emails to and myself! lol :) > > The error message I get is as follows: > > gpg: skipped "0xlukej@gmail.com": malformed user id > gpg: signing failed: malformed user id > > Is this a known issue? Is there anyway around it? Thunderbird --> Enigmail. In the mail account's 'OpenPGP Security' tab, check the radio button for 'Use specific OpenPGP key ID' and then enter the key ID in the box below. -- John P. Clizbe Inet: John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10/0x18BB373A "what's the key to success?" / "two words: good decisions." "what's the key to good decisions?" / "one word: experience." "how do i get experience?" / "two words: bad decisions." "Just how do the residents of Haiku, Hawai'i hold conversations?" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 663 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060929/d686b29b/signature.pgp From clbianco at tiscalinet.it Fri Sep 29 10:21:49 2006 From: clbianco at tiscalinet.it (Carlo Luciano Bianco) Date: Fri Sep 29 10:21:08 2006 Subject: DSA2 References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060929051112.GA1551@capsaicin.mamane.lu> Message-ID: Il /29 set 2006/, *Lionel Elie Mamane* ha scritto: > Not exactly. Version 3 DSA signatures lack a hash firewall. But > version 4 DSA signatures do have a hash firewall. Thanks, this is very good to know! > The version refers > not to a version of DSA itself, but the version of the OpenPGP packet > format being used. OK, and I think that now v4 packets are the default ones in GnuPG, unless force-v3-sigs is specified. So, this meas that GnuPG implementation of DSA (and of the so-called "DSA2") does have a hash firewall by default, am I correct? > All RSA signatures (V3 or V4) do have a hash firewall, yes. OK, thanks! -- | ICQ UIN: 109517158 Carlo Luciano Bianco | Home page: ______________________|________________________________________________ GnuPG RSAv4 4096 - Fingerprint:FA68CF697EA63865AAFA805F68703AD40609D743 From clbianco at tiscalinet.it Fri Sep 29 10:15:44 2006 From: clbianco at tiscalinet.it (Carlo Luciano Bianco) Date: Fri Sep 29 10:23:28 2006 Subject: DSA2 References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060926033338.GA4375@jabberwocky.com> <871wpzsz82.fsf@wheatstone.g10code.de> <20060926123447.GB4375@jabberwocky.com> <4519BF5A.6050104@sixdemonbag.org> <451B5399.4020600@kfwebs.net> Message-ID: Il /28 set 2006/, *Kristian Fiskerstrand* ha scritto: > The 15,360bit ElGamal encryption key took me about 20 hours to > generate on an Intel Centrino 1400MHz. Which is more that what > would be considered practical for ordinary uses, ... and also for extraordinary ones, maybe. I agree, 15kbit keys are far too slower... :-/ > I CCed the sender as some posts of mine in the past have never > reached the list, probably due to using a different sender address > and moderation. Well.. Just to confirm that this one reached the list correctly (at least, I am reading it on gmane)... ;-) -- | ICQ UIN: 109517158 Carlo Luciano Bianco | Home page: ______________________|________________________________________________ GnuPG RSAv4 4096 - Fingerprint:FA68CF697EA63865AAFA805F68703AD40609D743 From ariga at os.rim.or.jp Fri Sep 29 10:26:00 2006 From: ariga at os.rim.or.jp (ARIGA Seiji) Date: Fri Sep 29 10:24:18 2006 Subject: x509 v1 certificate In-Reply-To: <87fyeft2gq.fsf@wheatstone.g10code.de> References: <87ac4oz1ny.fsf@wheatstone.g10code.de> <20060925.195739.104567255.kazu@iij.ad.jp> <87fyegxgg6.fsf@wheatstone.g10code.de> <20060925.220849.167661107.kazu@iij.ad.jp> <87fyeft2gq.fsf@wheatstone.g10code.de> Message-ID: <20060929.172600.88529589.say@khaotic.net> sorry for belated response. On Tue, 26 Sep 2006 11:13:41 +0200, Werner Koch wrote, > > Because verisign's root certificates are v1 which are widely accepted. > > Okay, with the current SVN version of gnupg, you may now have a line > > 85371CA6E550143DCE2803471BDE3A09E8F8770F S relax > > in the trustlist.txt to allow using the old Verisign certificates. > Note the "relax" flag. You need to restart gpg-agent. i built gpgsm/gpg-agent from the source "svn update"-ed at 2006/09/29 02:00 UTC. # certchain.c r4267 | wk | 2006-09-26 19:00:12 +0900 (Tue, 26 Sep 2006) and still got following error: ---- gpgsm: error getting key usage information: No value gpgsm: invalid certification chain: No value ---- i believe "rc = gpgsm_cert_use_cert_p (issuer_cert);" is the issue. // ARIGA Seiji From rjh at sixdemonbag.org Fri Sep 29 10:35:20 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri Sep 29 10:33:38 2006 Subject: DSA2 In-Reply-To: <20060929051112.GA1551@capsaicin.mamane.lu> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060929051112.GA1551@capsaicin.mamane.lu> Message-ID: <451CDAC8.7070700@sixdemonbag.org> Lionel Elie Mamane wrote: >> - DSA does not support "firewalled hashes" > > Not exactly. Version 3 DSA signatures lack a hash firewall. But > version 4 DSA signatures do have a hash firewall. The version refers > not to a version of DSA itself, but the version of the OpenPGP packet > format being used. This is one of those times when the language in the RFC appears designed to obscure meaning, as opposed to illuminate it. E.g., if memory serves we can talk about one set of versions for keys, and another set of versions for signatures, etc., etc. It is my understanding--and I would welcome being pointed to language in the RFC showing that I am wrong--that v4 DSA keys lack a satisfactory hash function firewall. If I'm correct and the problem is associated with keys and not certificates, then that to me would be sufficient reason to recommend RSA. From alphasigmax at gmail.com Fri Sep 29 11:20:07 2006 From: alphasigmax at gmail.com (Alphax) Date: Fri Sep 29 11:19:00 2006 Subject: DSA2 In-Reply-To: <451CDAC8.7070700@sixdemonbag.org> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060929051112.GA1551@capsaicin.mamane.lu> <451CDAC8.7070700@sixdemonbag.org> Message-ID: <451CE547.8050009@gmail.com> Robert J. Hansen wrote: > Lionel Elie Mamane wrote: >>> - DSA does not support "firewalled hashes" >> Not exactly. Version 3 DSA signatures lack a hash firewall. But >> version 4 DSA signatures do have a hash firewall. The version refers >> not to a version of DSA itself, but the version of the OpenPGP packet >> format being used. > > This is one of those times when the language in the RFC appears designed > to obscure meaning, as opposed to illuminate it. E.g., if memory serves > we can talk about one set of versions for keys, and another set of > versions for signatures, etc., etc. > > It is my understanding--and I would welcome being pointed to language in > the RFC showing that I am wrong--that v4 DSA keys lack a satisfactory > hash function firewall. If I'm correct and the problem is associated > with keys and not certificates, then that to me would be sufficient > reason to recommend RSA. > Back to RFC 2440 we go. Section 5.2.2. "Version 3 Signature Packet Format" says: > The body of a version 3 Signature Packet contains: > - One-octet version number (3). > - One-octet length of following hashed material. MUST be 5. > - One-octet signature type. > - Four-octet creation time. > - Eight-octet key ID of signer. > - One-octet public key algorithm. > - One-octet hash algorithm. > - Two-octet field holding left 16 bits of signed hash value. > - One or more multi-precision integers comprising the signature. > This portion is algorithm specific, as described below. It then talks about how DSA differs from RSA: > With RSA signatures, the hash value is encoded as described in PKCS-1 > section 10.1.2, "Data encoding", producing an ASN.1 value of type > DigestInfo, and then padded using PKCS-1 block type 01 [RFC2313]. > This requires inserting the hash value as an octet string into an > ASN.1 structure. The object identifier for the type of hash being > used is included in the structure. > DSA signatures MUST use hashes with a size of 160 bits, to match q, > the size of the group generated by the DSA key's generator value. > The hash function result is treated as a 160 bit number and used > directly in the DSA signature algorithm. Section 5.2.3. "Version 4 Signature Packet Format" says: > The body of a version 4 Signature Packet contains: > - One-octet version number (4). > - One-octet signature type. > - One-octet public key algorithm. > - One-octet hash algorithm. > - Two-octet scalar octet count for following hashed subpacket > data. Note that this is the length in octets of all of the hashed > subpackets; a pointer incremented by this number will skip over > the hashed subpackets. > - Hashed subpacket data. (zero or more subpackets) > - Two-octet scalar octet count for following unhashed subpacket > data. Note that this is the length in octets of all of the > unhashed subpackets; a pointer incremented by this number will > skip over the unhashed subpackets. > - Unhashed subpacket data. (zero or more subpackets) > - Two-octet field holding left 16 bits of signed hash value. > - One or more multi-precision integers comprising the signature. > This portion is algorithm specific, as described above. The question is: does the "one-octect hash algorithm" field provide a sufficient hash function firewall? My thought is that it doesn't, because it doesn't appear to be signed. -- Alphax Death to all fanatics! Down with categorical imperative! OpenPGP key: http://tinyurl.com/lvq4g -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 569 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060929/38c4749e/signature.pgp From alex at bofh.net.pl Fri Sep 29 13:01:08 2006 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Fri Sep 29 12:59:37 2006 Subject: DSA2 In-Reply-To: <20060929051112.GA1551@capsaicin.mamane.lu> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060929051112.GA1551@capsaicin.mamane.lu> Message-ID: <20060929110107.GA25034@hell.pl> > All RSA signatures (V3 or V4) do have a hash firewall, yes. Is there anywhere a good description of the idea except Kaliski's presentation? Alex From dshaw at jabberwocky.com Fri Sep 29 14:23:35 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Sep 29 14:21:47 2006 Subject: Problem with email addresses beginning with 0x In-Reply-To: <451CA1E3.8020804@gmail.com> References: <451CA1E3.8020804@gmail.com> Message-ID: <20060929122335.GA25664@jabberwocky.com> On Fri, Sep 29, 2006 at 05:32:35AM +0100, Luke J wrote: > Hi, > > I have recently started using GnuPG. My personal email address begins > with 0x and this seems to cause problems for gpg when using the -u > option. I think it tries to interpret the email address as a key ID instead. > > Naturally, when using this from the command line it isn't a big issue > but when trying to gpg automatically from within Evolution or > Thunderbird, it tries to sign or encrypt messages by specifying the > email address as the argument to the -u option which causes the problem. > At the moment this means I can't use GnuPG with this email address > without annoying all the people I send emails to and myself! lol :) > > The error message I get is as follows: > > gpg: skipped "0xlukej@gmail.com": malformed user id > gpg: signing failed: malformed user id As you've seen, GPG uses "0x" to indicate a hex key ID. Try sticking a "<" before the address: <0xlukej@gmail.com The "<" is a hint to the parser that the characters that follow are an email address. David From dshaw at jabberwocky.com Fri Sep 29 14:41:46 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Sep 29 14:40:04 2006 Subject: DSA2 In-Reply-To: <20060929051112.GA1551@capsaicin.mamane.lu> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060929051112.GA1551@capsaicin.mamane.lu> Message-ID: <20060929124146.GB25664@jabberwocky.com> On Fri, Sep 29, 2006 at 07:11:12AM +0200, Lionel Elie Mamane wrote: > On Sat, Sep 23, 2006 at 03:15:07PM +0200, Carlo Luciano Bianco wrote: > > > I just try to summarize what I understood from this thread about > > OpenPGP implementation of DSA and RSA signatures, so you can correct > > me if I am wrong: ;-) > > > - DSA does not support "firewalled hashes" > > Not exactly. Version 3 DSA signatures lack a hash firewall. But > version 4 DSA signatures do have a hash firewall. The version refers > not to a version of DSA itself, but the version of the OpenPGP packet > format being used. This is not correct. No DSA signatures in OpenPGP, whether v3 or v4, have a hash firewall. > > - RSA does support "firewalled hashes". > > All RSA signatures (V3 or V4) do have a hash firewall, yes. Yes. It's important to not focus unduly on one thing. This gives hash firewalls too much import. Today it's hash firewalls. Yesterday it was hash length. Before that it was key size, etc, etc. Make sure you're not armoring your front door to an absurd degree and leaving a window open. :) David From rjh at sixdemonbag.org Fri Sep 29 14:50:21 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri Sep 29 14:48:38 2006 Subject: DSA2 In-Reply-To: <20060929124146.GB25664@jabberwocky.com> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060929051112.GA1551@capsaicin.mamane.lu> <20060929124146.GB25664@jabberwocky.com> Message-ID: <451D168D.90308@sixdemonbag.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 David Shaw wrote: > It's important to not focus unduly on one thing. This gives hash > firewalls too much import. Today it's hash firewalls. Yesterday it > was hash length. Before that it was key size, etc, etc. Make sure > you're not armoring your front door to an absurd degree and leaving a > window open. :) While true, if this was all there was to it most of us would still be using PGP 2.6. :) The idea of low-hanging fruit comes to mind here. Obsessing over the front door is a bad idea, but if there's a deadbolt you can throw without any difficulty and you're going to walk by the door anyway on the way to the stairs, why not? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBCAAGBQJFHRaNAAoJELcA9IL+r4EJLtEIAM+wcxGfv2tCUvvHXzOZBy38 K8uWJ2EXMHD528UfEkdC01MZuVooTWf+vyEyfrAPgjyrXI+kyjWVsT33Q6Zjgd1I ZSFFqqqJLkpOs6S9GoEIns5frKYH4WhY+Nxe/n4NmQgl9AIX1CkvsA8eIBNl9Bkq iKAZAuuhBD0ZAVCC5PeWnaZ3MLkYWpZ/YQLpUbbg9C/tVVzTeVEy5fevu8nvC88/ Xc9OOykyqXg+l5DfTh9tQcobb/ZmiyjkrIAZryjpG4n9P5LTGexnCfG9GEiI8WYI 15A/LAOD0boe1a65aneJ3jRksX9OJY7TLIXf+QABN4Iof0BkvvcX/fLjqEJCTk8= =ZFBU -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Fri Sep 29 15:01:41 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Sep 29 14:59:52 2006 Subject: DSA2 In-Reply-To: <451D168D.90308@sixdemonbag.org> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060929051112.GA1551@capsaicin.mamane.lu> <20060929124146.GB25664@jabberwocky.com> <451D168D.90308@sixdemonbag.org> Message-ID: <20060929130141.GC25664@jabberwocky.com> On Fri, Sep 29, 2006 at 07:50:21AM -0500, Robert J. Hansen wrote: > David Shaw wrote: > > It's important to not focus unduly on one thing. This gives hash > > firewalls too much import. Today it's hash firewalls. Yesterday it > > was hash length. Before that it was key size, etc, etc. Make sure > > you're not armoring your front door to an absurd degree and leaving a > > window open. :) > > While true, if this was all there was to it most of us would still be > using PGP 2.6. :) It's interesting you mention PGP 2.6. The main "problem", such as it is, with 2.6 is that there wasn't a problem with it. It's a familiar (though somewhat tongue in cheek) refrain in the OpenPGP WG and among OpenPGP developers that it's too bad PGP 2.6 was never broken so people would just stop using it and upgrade already. > The idea of low-hanging fruit comes to mind here. Obsessing over the > front door is a bad idea, but if there's a deadbolt you can throw > without any difficulty and you're going to walk by the door anyway on > the way to the stairs, why not? My concern is that the front door is already 1000 pounds of reinforced carbon steel and has protruding spikes and built-in lasers or some such. No harm in throwing the deadbolt, but spending a lot of time worrying about the deadbolt takes time away from worrying that the window next to the front door is still open... David From rjh at sixdemonbag.org Fri Sep 29 15:26:55 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri Sep 29 15:25:25 2006 Subject: DSA2 In-Reply-To: <20060929130141.GC25664@jabberwocky.com> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060929051112.GA1551@capsaicin.mamane.lu> <20060929124146.GB25664@jabberwocky.com> <451D168D.90308@sixdemonbag.org> <20060929130141.GC25664@jabberwocky.com> Message-ID: <451D1F1F.5050302@sixdemonbag.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 David Shaw wrote: > It's interesting you mention PGP 2.6. The main "problem", such as it > is, with 2.6 is that there wasn't a problem with it. It's a familiar > (though somewhat tongue in cheek) refrain in the OpenPGP WG and among > OpenPGP developers that it's too bad PGP 2.6 was never broken so > people would just stop using it and upgrade already. That's exactly what I was referring to. :) To the extent people have migrated from 2.6, they've mostly migrated for reasons other than need. That doesn't mean the effort put into making GnuPG is for naught, or that there's no point in migrating from ClassicPGP to OpenPGP. It just means we're doing so for reasons other than need. People have emotional attachments to software. Look at how much flamage goes on over the One True Editor[*] and the hellfire and perdition awaiting the infidel unbelievers. Best we can hope for is that to the extent we're going to be unreasonable, we'll at least _know_ we're being unreasonable. The lack of a hash function firewall in DSA keys gives me the heebie-jeebies. This is why I use an RSA key, and recommend new keys use RSA. Sure, the long-term risk to DSA keys from the lack of a hash function firewall is probably minimal, but it still gives me the heebie-jeebies. It's easy for me to get rid of the heebie-jeebies: just don't use DSA. So I don't. Anyway, I get the idea I'm (a) waxing philosophical and (b) far off-topic for GnuPG-devel. So unless there's mad interest in what I've said here, I'll just step out now. :) [*] TextMate, of course! http://www.macromates.com. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBCAAGBQJFHR8fAAoJELcA9IL+r4EJIGcH/2fbjYEPQTWBuc0shZ/vVyjc N30NSUHnw1tOogkepA4coMJvAofzFufojxeoNG4ukVuJRjsLcWwYXaLqr2mz6v9f hgxBMPYvcBgxeJME59l78S6mYBBcRchH5N6rLzAsayz6JOsy0bCDwEVfuNIml3O2 M2rOh7Neq8i2xsR+Dy0Fbg/DmLtqqKp9KrULqmlf+wdhGAtrRqS/nH95rhOgj3j3 8z2dqtTpdl1GY7ukMgpYnfQ7twXKu2PgFe+RB6PszS9ovweC0c3LMQYkw3XGejcz 45+Bs1ZmZYLGmafpzT8jepOeJyQgHZGw8qFCUH1cTEJ2fo4HTkfCUoc8x8a2neM= =G9s6 -----END PGP SIGNATURE----- From wk at gnupg.org Fri Sep 29 18:18:30 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Sep 29 18:59:21 2006 Subject: x509 v1 certificate In-Reply-To: <20060929.172600.88529589.say@khaotic.net> (ARIGA Seiji's message of "Fri, 29 Sep 2006 17:26:00 +0900 (JST)") References: <87ac4oz1ny.fsf@wheatstone.g10code.de> <20060925.195739.104567255.kazu@iij.ad.jp> <87fyegxgg6.fsf@wheatstone.g10code.de> <20060925.220849.167661107.kazu@iij.ad.jp> <87fyeft2gq.fsf@wheatstone.g10code.de> <20060929.172600.88529589.say@khaotic.net> Message-ID: <87mz8iodd5.fsf@wheatstone.g10code.de> On Fri, 29 Sep 2006 10:26, ARIGA Seiji said: > ---- > gpgsm: error getting key usage information: No value > gpgsm: invalid certification chain: No value > ---- Sure, that you added the "relax" flag to the appropriate line of the trustlist.txt and also updated the gpg-agent.? Shalom-Salam, Werner From ariga at os.rim.or.jp Sat Sep 30 04:11:36 2006 From: ariga at os.rim.or.jp (ARIGA Seiji) Date: Sat Sep 30 04:09:52 2006 Subject: x509 v1 certificate In-Reply-To: <87mz8iodd5.fsf@wheatstone.g10code.de> References: <87fyegxgg6.fsf@wheatstone.g10code.de> <20060925.220849.167661107.kazu@iij.ad.jp> <87fyeft2gq.fsf@wheatstone.g10code.de> <20060929.172600.88529589.say@khaotic.net> <87mz8iodd5.fsf@wheatstone.g10code.de> Message-ID: <20060930.111136.35717327.say@khaotic.net> On Fri, 29 Sep 2006 18:18:30 +0200, Werner Koch wrote, > > ---- > > gpgsm: error getting key usage information: No value > > gpgsm: invalid certification chain: No value > > ---- > > Sure, that you added the "relax" flag to the appropriate line of the > trustlist.txt and also updated the gpg-agent.? do you mean that is expected ? i thought you've changed gpgsm to allow us to use/validate old VeriSign cert (v1 certs). # but as i showed, "--verify" still failed. without "relax", i only got this. ---- gpgsm: invalid certification chain: No value ---- i think certlist.c:cert_usage_p() returns message above ("... key usage ..."). # this is called by certchain.c:gpgsm_cert_use_cert_p() # (which looks irrelevant to "relax" flag). // ARIGA Seiji From 0xlukej at gmail.com Fri Sep 29 05:51:31 2006 From: 0xlukej at gmail.com (Luke J) Date: Wed Oct 18 14:56:51 2006 Subject: Problem with email addresses beginning with 0x Message-ID: <451C8019.9090302@gmail.com> Hi, I have recently started using GnuPG. My personal email address begins with 0x and this seems to cause problems for gpg when using the -u option. I think it tries to interpret the email address as a key ID instead. Naturally, when using this from the command line it isn't a big issue but when trying to gpg automatically from within Evolution or Thunderbird, it tries to sign or encrypt messages by specifying the email address as the argument to the -u option which causes the problem. At the moment this means I can't use GnuPG with this email address without annoying all the people I send emails to and myself! lol :) The error message I get is as follows: gpg: skipped "0xlukej@gmail.com": malformed user id gpg: signing failed: malformed user id Is this a known issue? Is there anyway around it? Thanks for your help, Luke