From wk at gnupg.org Tue Apr 3 19:25:17 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Apr 2007 19:25:17 +0200 Subject: GnuPG 2.0.3: gpgconf.conf and allow-mark-trusted In-Reply-To: <200703301354.29159.jan-oliver.wagner@intevation.de> (Jan-Oliver Wagner's message of "Fri\, 30 Mar 2007 12\:54\:28 +0100") References: <200703301354.29159.jan-oliver.wagner@intevation.de> Message-ID: <87wt0t74le.fsf@wheatstone.g10code.de> On Fri, 30 Mar 2007 13:54, jan-oliver.wagner at intevation.de said: > I realized that "allow-mark-trusted" is set to "no-change" hardwired > in the source code. I am aware it is set to "change" through gpgconf.conf > (if installed correctly). I reverted that. The gpgconf.conf now has a no-change example. > Next, the default gpgconf.conf should not set anything but only > keep some examples (like the one for "allow-mark-trusted") commented > out. There is no default ggconf.conf - it is just an example on what can be done. > Then we would have a liberal default and it is subject to packagers or > sysadmins to define policies. I don't agree that liberal defaults are a Good Thing. However in this case I reverted it because we should not be more restrictive than in the past. Shalom-Salam, Werner From buanzo at buanzo.com.ar Wed Apr 11 13:14:29 2007 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Wed, 11 Apr 2007 08:14:29 -0300 Subject: GPGME-verify: GPG_ERR_SOURCE_UNKNOWN Message-ID: <461CC315.5080303@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi group! Thanks for the suggestion of using gpgme. Although I couldn't use it on the Enigform Firefox extension, I'm using it for an Apache module (mod_auth_openpgp). As I was having some issues with gpgme sig verification, I took t-verify.c, removed all that didn't seemed necessary for a bare-bones test, and I'm getting the GPG_ERR_SOURCE_UNKNOWN error. I'm linking against gpgme 1.1.4 and libgpg-error 1.5. The error I'm getting is: 55536 This is the code: #ifdef HAVE_CONFIG_H #include #endif #include #include #include #include #include "t-support.h" char test_text1[] = "variable=dsa"; /* I tried with and without \n at the end */ char test_sig1[] = "-----BEGIN PGP SIGNATURE-----\n" "Version: GnuPG v1.4.6 (GNU/Linux)\n" "\n" "iD8DBQFGHLqoAlpOsGhXcE0RAs8yAJ4vfspPFR1KHaD0woc+bSuTX9J2NwCeKtZOVNJTNs0Nj6LMzRs5blgxKWg==k+5M\n" "-----END PGP SIGNATURE------\n"; int main (int argc, char *argv[]) { gpgme_ctx_t ctx; gpgme_error_t err; gpgme_data_t sig, text; gpgme_verify_result_t result; init_gpgme (GPGME_PROTOCOL_OpenPGP); err = gpgme_new (&ctx); fail_if_err (err); err = gpgme_data_new_from_mem (&text, test_text1, strlen (test_text1), 0); fail_if_err (err); err = gpgme_data_new_from_mem (&sig, test_sig1, strlen (test_sig1), 0); fail_if_err (err); err = gpgme_op_verify (ctx, sig, text, NULL); fail_if_err (err); result = gpgme_op_verify_result (ctx); printf("GPGME error: %u\n",gpgme_err_code((int)result)); gpgme_data_release (sig); gpgme_data_release (text); gpgme_release (ctx); return 0; } Do you notice anything wrong? I'm even compiling with: gcc -o v v.c -I/usr/include/gpgme -lgpgme -lgpg-error -Wall -ansi -pedantic (nothing shows there). - -- Arturo "Buanzo" Busleiman - Consultor Independiente en Seguridad Informatica Foros GNU/Buanzo: Respeto, Soluciones y Buena Onda: http://foros.buanzo.com.ar Consulting and Secure Mail Hosting: http://www.buanzo.com.ar/pro/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHMMVAlpOsGhXcE0RCgKEAKCAKe+7coQVduxs6TQp9klaK92+NgCdH2QQ Q+Dn38oVQLUNE7uOstR9pTA= =y01X -----END PGP SIGNATURE----- From buanzo at buanzo.com.ar Wed Apr 11 13:27:55 2007 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Wed, 11 Apr 2007 08:27:55 -0300 Subject: GPGME-verify: GPG_ERR_SOURCE_UNKNOWN Message-ID: <461CC63B.10105@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Please disregard my previous message. I found my mistake. As usual, I find my bugs jsut after posting my question to the list. The mozilla people already hate me for that :P Big sorry. PS: Yes, I can verify correctly :D - -- Arturo "Buanzo" Busleiman - Consultor Independiente en Seguridad Informatica Foros GNU/Buanzo: Respeto, Soluciones y Buena Onda: http://foros.buanzo.com.ar Consulting and Secure Mail Hosting: http://www.buanzo.com.ar/pro/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHMY7AlpOsGhXcE0RCq3QAJ9/FLBM+diUA2Spz6KInwZlWj2zagCfRD0f Kg4UOl7KLArrrNVMkNvWrfs= =ICp7 -----END PGP SIGNATURE----- From marcus.brinkmann at ruhr-uni-bochum.de Fri Apr 13 00:53:52 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri, 13 Apr 2007 00:53:52 +0200 Subject: [Announce] GPGME 1.1.3 released In-Reply-To: <200702032109.12618.alon.barlev@gmail.com> References: <878xff5jtb.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200702032109.12618.alon.barlev@gmail.com> Message-ID: <873b35b3wf.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sat, 3 Feb 2007 21:09:12 +0200, Alon Bar-Lev wrote: > > On Saturday 03 February 2007, Marcus Brinkmann wrote: > > Hi, > > > > We are pleased to announce version 1.1.3 of GnuPG Made Easy, > > Hello, > > Please consider the following patch for freebsd. GPGME follows libassuan, which we maintain separately. According to http://g10code.com/autobuild/libassuan-1.0.1.tar.gz-x86-freebsd1-output.html libassuan builds just fine on freebsd. So, if GPGME doesn't, there is something we need to fix, but it is not clear that the below patch is the right approach. Can you please send me more info about the build problems? Thanks, Marcus > Best Regards, > Alon Bar-Lev > > diff -urNp gpgme-1.1.3.org/assuan/assuan.h gpgme-1.1.3/assuan/assuan.h > --- gpgme-1.1.3.org/assuan/assuan.h 2007-01-29 22:16:18.000000000 +0200 > +++ gpgme-1.1.3/assuan/assuan.h 2007-02-03 20:57:23.000000000 +0200 > @@ -24,6 +24,7 @@ > > #include > #include > +#include > #include > > > diff -urNp gpgme-1.1.3.org/assuan/funopen.c gpgme-1.1.3/assuan/funopen.c > --- gpgme-1.1.3.org/assuan/funopen.c 2007-01-29 22:16:19.000000000 +0200 > +++ gpgme-1.1.3/assuan/funopen.c 2007-02-03 20:57:23.000000000 +0200 > @@ -39,7 +39,7 @@ > cookie instead of the fiel descripor. > */ > > - > +#ifndef HAVE_FUNOPEN > #ifdef HAVE_FOPENCOOKIE > FILE * > _assuan_funopen(void *cookie, > @@ -62,3 +62,4 @@ _assuan_funopen(void *cookie, > #else > #error No known way to implement funopen. > #endif > +#endif > From marcus.brinkmann at ruhr-uni-bochum.de Fri Apr 13 00:58:46 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri, 13 Apr 2007 00:58:46 +0200 Subject: GpgME BUG: list expired secret keys? In-Reply-To: <1172411401l.4301l.1l@antares.localdomain> References: <1172411401l.4301l.1l@antares.localdomain> Message-ID: <871wipb3o9.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sun, 25 Feb 2007 14:50:01 +0100, Albrecht Dre? wrote: > > Hi all, > > I noticed a confusing behaviour of gpgme 1.1.2 when I try to list keys and > check their expiry status. Running the trivial attached code (which takes > the second and third parameter of gpgme_op_keylist_start() as arguments), > I try to list an expired secret key: > > > [albrecht at antares ~]$ ./gpgme-key-expire [key_id_removed] 1 > now is 1172581963 > key: can_sign=1 can_encrypt=0 expired=0 > subkey id=9FFF6E9CD027FFD1 can_sign=1 can_encrypt=0 expired=0 > expires=1172493215 [1] > subkey id=9AA774B7653B2476 can_sign=0 can_encrypt=1 expired=0 expires=0 > [0] > > > Although the current date is behind the expiry date of the secret sub-key > (can_sign=1), gpgme returns expired=0! If you run with GPGME_DEBUG=3 or just run gpg --status-fd 2 manually, you will probably find that this is because gpg does return incomplete data. As far as I understand, gnupg's key listing output of secret keys is currently not fully complete in the manner you noticed before. Can you confirm that this is the problem in your case? > Running the app on the same public > key, the returned data looks fine, though: > > > [albrecht at antares ~]$ ./gpgme-key-expire [key_id_removed] 0 > now is 1172581965 > key: can_sign=1 can_encrypt=0 expired=1 > subkey id=9FFF6E9CD027FFD1 can_sign=1 can_encrypt=0 expired=1 > expires=1172493215 [1] > subkey id=9AA774B7653B2476 can_sign=0 can_encrypt=1 expired=1 expires=0 > [0] > > > Did I completely misunderstand the concept of listing keys or miss some > "vital" initialisation here? > > When I now use the "non expired" (as reported by the key list operation) > secret key in gpgme_op_sign() with mode GPGME_SIG_MODE_CLEAR, this > function returns GPG_ERR_NO_ERROR, as does gpgme_signers_add(). > gpgme_op_sign_result() returns a valid structure, but both the > "signatures" and "invalid_signers" elements are NULL, so there is no way > to catch the real reason why the operation failed which is obviously a bad > situation. Always "manually" checking the expiry date seems to be the > obvious workaround here, but this should be done in the library IMHO... Thanks, Marcus From seanb at qnx.com Fri Apr 13 18:02:57 2007 From: seanb at qnx.com (Sean Boudreau) Date: Fri, 13 Apr 2007 12:02:57 -0400 Subject: qnx6 patches Message-ID: <20070413160257.GA692266@qnx.com> Hello: Please find attached the QNX6 diffs I've been using for gnupg-1.4.6. I think most of these may be applicable to other POSIX strict environments. Regards, Sean Boudreau -------------- next part -------------- --- acinclude.m4.orig 2006-10-02 11:15:43.000000000 -0400 +++ acinclude.m4 2007-03-28 09:13:07.000000000 -0400 @@ -416,6 +416,42 @@ #include #include + /* This mess was copied from the GNU getpagesize.h. */ + #ifndef HAVE_GETPAGESIZE + /* Assume that all systems that can run configure have sys/param.h. */ + # ifndef HAVE_SYS_PARAM_H + # define HAVE_SYS_PARAM_H 1 + # endif + + # ifdef _SC_PAGESIZE + # define getpagesize() sysconf(_SC_PAGESIZE) + # else /* no _SC_PAGESIZE */ + # ifdef HAVE_SYS_PARAM_H + # include + # ifdef EXEC_PAGESIZE + # define getpagesize() EXEC_PAGESIZE + # else /* no EXEC_PAGESIZE */ + # ifdef NBPG + # define getpagesize() NBPG * CLSIZE + # ifndef CLSIZE + # define CLSIZE 1 + # endif /* no CLSIZE */ + # else /* no NBPG */ + # ifdef NBPC + # define getpagesize() NBPC + # else /* no NBPC */ + # ifdef PAGESIZE + # define getpagesize() PAGESIZE + # endif /* PAGESIZE */ + # endif /* no NBPC */ + # endif /* no NBPG */ + # endif /* no EXEC_PAGESIZE */ + # else /* no HAVE_SYS_PARAM_H */ + # define getpagesize() 8192 /* punt totally */ + # endif /* no HAVE_SYS_PARAM_H */ + # endif /* no _SC_PAGESIZE */ + + #endif /* no HAVE_GETPAGESIZE */ int main() { char *pool; --- configure.ac.orig 2006-12-05 07:17:02.000000000 -0500 +++ configure.ac 2007-03-28 09:13:07.000000000 -0400 @@ -619,12 +619,12 @@ _dns_save_libs=$LIBS LIBS="" # the double underscore thing is a glibc-ism? - AC_SEARCH_LIBS(res_query,resolv bind,, - AC_SEARCH_LIBS(__res_query,resolv bind,,have_resolver=no)) - AC_SEARCH_LIBS(dn_expand,resolv bind,, - AC_SEARCH_LIBS(__dn_expand,resolv bind,,have_resolver=no)) - AC_SEARCH_LIBS(dn_skipname,resolv bind,, - AC_SEARCH_LIBS(__dn_skipname,resolv bind,,have_resolver=no)) + AC_SEARCH_LIBS(res_query,resolv bind socket,, + AC_SEARCH_LIBS(__res_query,resolv bind socket,,have_resolver=no)) + AC_SEARCH_LIBS(dn_expand,resolv bind socket,, + AC_SEARCH_LIBS(__dn_expand,resolv bind socket,,have_resolver=no)) + AC_SEARCH_LIBS(dn_skipname,resolv bind socket,, + AC_SEARCH_LIBS(__dn_skipname,resolv bind socket,,have_resolver=no)) if test x"$have_resolver" != xno ; then --- g10/gpg.c.orig 2006-12-03 10:37:45.000000000 -0500 +++ g10/gpg.c 2007-03-28 09:13:07.000000000 -0400 @@ -25,6 +25,7 @@ #include #include #include +#include #include #include #include --- g10/pkclist.c.orig 2006-07-26 06:31:15.000000000 -0400 +++ g10/pkclist.c 2007-03-28 09:13:07.000000000 -0400 @@ -24,6 +24,7 @@ #include #include #include +#include #include #include --- keyserver/gpgkeys_curl.c.orig 2006-09-26 09:07:53.000000000 -0400 +++ keyserver/gpgkeys_curl.c 2007-03-28 09:13:07.000000000 -0400 @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include --- keyserver/gpgkeys_hkp.c.orig 2006-12-03 10:37:44.000000000 -0500 +++ keyserver/gpgkeys_hkp.c 2007-03-28 09:13:07.000000000 -0400 @@ -34,6 +34,7 @@ #include #include #include +#include #include #include #include --- keyserver/ksutil.c.orig 2006-12-04 03:36:46.000000000 -0500 +++ keyserver/ksutil.c 2007-03-28 09:13:07.000000000 -0400 @@ -35,6 +35,7 @@ #include #include #include +#include #include #ifdef HAVE_LIBCURL --- util/miscutil.c.orig 2006-10-02 08:07:23.000000000 -0400 +++ util/miscutil.c 2007-03-28 09:13:07.000000000 -0400 @@ -24,6 +24,7 @@ #include #include #include +#include #include #include #ifdef HAVE_LANGINFO_H --- tools/shmtest.c.orig 2005-07-27 13:02:56.000000000 -0400 +++ tools/shmtest.c 2007-03-28 09:13:09.000000000 -0400 @@ -39,12 +39,14 @@ static int serverpid = -1; +#ifdef USE_SHM_COPROCESSING static void my_usage(void) { fprintf(stderr, "usage: shmtest gpg-command-line\n"); exit(1); } +#endif const char * strusage( int level ) @@ -63,6 +65,7 @@ } +#ifdef USE_SHM_COPROCESSING static void do_get_string( int mode, const char *keyword, byte *area, size_t areasize ) { @@ -93,12 +96,14 @@ area[3] = 1; /* we should better use a semaphore */ kill( serverpid, SIGUSR1 ); } +#endif int main(int argc, char **argv) { +#ifdef USE_SHM_COPROCESSING void *area = NULL; size_t areasize = 4096; int shm_id = -1; @@ -107,6 +112,7 @@ char *p, *p2; size_t n; int i; +#endif log_set_name("shmtest"); i18n_init(); @@ -193,9 +199,9 @@ if( pclose(fp) ) log_error("pclose failed\n"); +#endif return 0; -#endif } #endif --- util/cert.c.orig 2006-04-03 04:13:21.000000000 -0400 +++ util/cert.c 2007-03-28 09:13:09.000000000 -0400 @@ -27,6 +27,7 @@ #else #include #include +#include #include #endif #include --- util/pka.c.orig 2005-07-28 14:50:09.000000000 -0400 +++ util/pka.c 2007-03-28 09:13:09.000000000 -0400 @@ -32,6 +32,7 @@ #else #include #include +#include #include #endif #endif /* USE_DNS_PKA */ --- util/srv.c.orig 2006-02-12 04:07:05.000000000 -0500 +++ util/srv.c 2007-03-28 09:13:09.000000000 -0400 @@ -26,6 +26,7 @@ #else #include #include +#include #include #endif #include From dshaw at jabberwocky.com Sun Apr 15 20:58:33 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 15 Apr 2007 14:58:33 -0400 Subject: qnx6 patches In-Reply-To: <20070413160257.GA692266@qnx.com> References: <20070413160257.GA692266@qnx.com> Message-ID: <20070415185833.GD1983@jabberwocky.com> On Fri, Apr 13, 2007 at 12:02:57PM -0400, Sean Boudreau wrote: > > Hello: > > Please find attached the QNX6 diffs I've been using > for gnupg-1.4.6. I think most of these may be > applicable to other POSIX strict environments. Thank you for the diffs. The reason for some of the changes are clear, and I've started to apply them. Some of the others I have questions about: > --- acinclude.m4.orig 2006-10-02 11:15:43.000000000 -0400 > +++ acinclude.m4 2007-03-28 09:13:07.000000000 -0400 > @@ -416,6 +416,42 @@ > #include > #include > > + /* This mess was copied from the GNU getpagesize.h. */ > + #ifndef HAVE_GETPAGESIZE (etc). Can you clarify what this change is intended to address? Presumably getpagesize, but can you show me what did not work in the current code? > --- g10/gpg.c.orig 2006-12-03 10:37:45.000000000 -0500 > +++ g10/gpg.c 2007-03-28 09:13:07.000000000 -0400 > @@ -25,6 +25,7 @@ > #include > #include > #include > +#include I assume the various changes are for strcasecmp(). > --- tools/shmtest.c.orig 2005-07-27 13:02:56.000000000 -0400 > +++ tools/shmtest.c 2007-03-28 09:13:09.000000000 -0400 > @@ -39,12 +39,14 @@ > > static int serverpid = -1; > > +#ifdef USE_SHM_COPROCESSING > static void > my_usage(void) > { > fprintf(stderr, "usage: shmtest gpg-command-line\n"); > exit(1); > } > +#endif The various additions of USE_SHM_COPROCESSING is to avoid unreferenced static function warnings? David From wk at gnupg.org Sun Apr 15 21:24:58 2007 From: wk at gnupg.org (Werner Koch) Date: Sun, 15 Apr 2007 21:24:58 +0200 Subject: qnx6 patches In-Reply-To: <20070415185833.GD1983@jabberwocky.com> (David Shaw's message of "Sun\, 15 Apr 2007 14\:58\:33 -0400") References: <20070413160257.GA692266@qnx.com> <20070415185833.GD1983@jabberwocky.com> Message-ID: <87tzvha19x.fsf@wheatstone.g10code.de> On Sun, 15 Apr 2007 20:58, dshaw at jabberwocky.com said: >> #include >> +#include > > I assume the various changes are for strcasecmp(). I consider the use of strings.h as a bad choice. It defines legacy functions like bcmp and index and especially the latter one will lead to a lot of warnings in some code. Anyway strcasecmp is locale dependend and should thus be avoided. In general we use the ascii_* replacements. Shalom-Salam, Werner From dshaw at jabberwocky.com Sun Apr 15 22:00:59 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 15 Apr 2007 16:00:59 -0400 Subject: qnx6 patches In-Reply-To: <87tzvha19x.fsf@wheatstone.g10code.de> References: <20070413160257.GA692266@qnx.com> <20070415185833.GD1983@jabberwocky.com> <87tzvha19x.fsf@wheatstone.g10code.de> Message-ID: <20070415200059.GE1983@jabberwocky.com> On Sun, Apr 15, 2007 at 09:24:58PM +0200, Werner Koch wrote: > On Sun, 15 Apr 2007 20:58, dshaw at jabberwocky.com said: > > >> #include > >> +#include > > > > I assume the various changes are for strcasecmp(). > > I consider the use of strings.h as a bad choice. It defines legacy > functions like bcmp and index and especially the latter one will lead to > a lot of warnings in some code. This is true, but nevertheless, POSIX does place strcasecmp in strings.h. It works on glibc and most other systems anyway, as there is a second copy of strcasecmp in string.h, but that's not POSIX. glibc systems actually define bcmp and index and the like in string.h (unless strict POSIX is requested), so we aren't really avoiding those functions by avoiding strings.h. > Anyway strcasecmp is locale dependend and should thus be avoided. In > general we use the ascii_* replacements. Unless the goal is to be locale dependent (for the group name stuff, for example). David From seanb at qnx.com Sun Apr 15 23:00:26 2007 From: seanb at qnx.com (Sean Boudreau) Date: Sun, 15 Apr 2007 17:00:26 -0400 Subject: qnx6 patches In-Reply-To: <20070415185833.GD1983@jabberwocky.com> References: <20070413160257.GA692266@qnx.com> <20070415185833.GD1983@jabberwocky.com> Message-ID: <20070415210026.GA536592@qnx.com> On Sun, Apr 15, 2007 at 02:58:33PM -0400, David Shaw wrote: > On Fri, Apr 13, 2007 at 12:02:57PM -0400, Sean Boudreau wrote: > > > > Hello: > > > > Please find attached the QNX6 diffs I've been using > > for gnupg-1.4.6. I think most of these may be > > applicable to other POSIX strict environments. > > Thank you for the diffs. The reason for some of the changes are > clear, and I've started to apply them. Some of the others I have > questions about: > > > --- acinclude.m4.orig 2006-10-02 11:15:43.000000000 -0400 > > +++ acinclude.m4 2007-03-28 09:13:07.000000000 -0400 > > @@ -416,6 +416,42 @@ > > #include > > #include > > > > + /* This mess was copied from the GNU getpagesize.h. */ > > + #ifndef HAVE_GETPAGESIZE > > (etc). Can you clarify what this change is intended to address? > Presumably getpagesize, but can you show me what did not work in the > current code? Yes, getpagesize() which qnx6 doesn't have; however we do have sysconf(_SC_PAGESIZE). I was getting the HAVE_BROKEN_MLOCK define due to its undefined reference. The above is similar to what autoconf does for mmap(). > > > --- g10/gpg.c.orig 2006-12-03 10:37:45.000000000 -0500 > > +++ g10/gpg.c 2007-03-28 09:13:07.000000000 -0400 > > @@ -25,6 +25,7 @@ > > #include > > #include > > #include > > +#include > > I assume the various changes are for strcasecmp(). Yes. > > > --- tools/shmtest.c.orig 2005-07-27 13:02:56.000000000 -0400 > > +++ tools/shmtest.c 2007-03-28 09:13:09.000000000 -0400 > > @@ -39,12 +39,14 @@ > > > > static int serverpid = -1; > > > > +#ifdef USE_SHM_COPROCESSING > > static void > > my_usage(void) > > { > > fprintf(stderr, "usage: shmtest gpg-command-line\n"); > > exit(1); > > } > > +#endif > > The various additions of USE_SHM_COPROCESSING is to avoid unreferenced > static function warnings? Yes. Regards, -seanb From M_Hoeller at nurfuerspam.de Sun Apr 15 22:50:08 2007 From: M_Hoeller at nurfuerspam.de (M Hoeller) Date: Sun, 15 Apr 2007 22:50:08 +0200 Subject: gpgsm 1.9.22 supports no RC2 Algorithm ? Message-ID: <200704152250.08124.M_Hoeller@nurfuerspam.de> Hello experts, I just received an S/MIME encrypted mail which I can not decrypt with gpgsm 1.9.22 this seems to be due to the fact that the used algorithm was a RC2. It seems that the sender userd Thinderbird as Mailclient. Here is a part of the log: 4 - 2007-04-14 22:52:42 gpgsm[5444]: unsupported algorithm `1.2.840.113549.3.2' 4 - 2007-04-14 22:52:42 gpgsm[5444]: (Dies ist der RC-2 Algorithmus) 4 - 2007-04-14 22:52:42 gpgsm[5444.0x8084a98] DBG: -> S ERROR decrypt.algorithm 50331732 1.2.840.113549.3.2 4 - 2007-04-14 22:52:42 gpgsm[5444.0x8084a98] DBG: -> S DECRYPTION_FAILED 4 - 2007-04-14 22:52:42 gpgsm[5444]: message decryption failed: Nicht unterst?tztes Verfahren 4 - 2007-04-14 22:52:42 gpgsm[5444.0x8084a98] DBG: -> ERR 50331732 Nicht unterst?tztes Verfahren Is this a bug, a feature, and is there a way how I can decrypt these mails? I use openSUSE 10.2 and KDE 3.5.6 with gpgsm 1.9.22 Thanks a lot for any hint Michael From wk at gnupg.org Mon Apr 16 10:40:05 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Apr 2007 10:40:05 +0200 Subject: gpgsm 1.9.22 supports no RC2 Algorithm ? In-Reply-To: <200704152250.08124.M_Hoeller@nurfuerspam.de> (M. Hoeller's message of "Sun\, 15 Apr 2007 22\:50\:08 +0200") References: <200704152250.08124.M_Hoeller@nurfuerspam.de> Message-ID: <87d524af16.fsf@wheatstone.g10code.de> On Sun, 15 Apr 2007 22:50, M_Hoeller at nurfuerspam.de said: > I just received an S/MIME encrypted mail which I can not decrypt with > gpgsm 1.9.22 this seems to be due to the fact that the used algorithm > was a RC2. It seems that the sender userd Thinderbird as Mailclient. For patent reasons we don't support RC2 Salam-Shalom, Werner From M_Hoeller at nurfuerspam.de Mon Apr 16 10:47:17 2007 From: M_Hoeller at nurfuerspam.de (=?iso-8859-1?Q?=22Michael_H=F6ller=22?=) Date: Mon, 16 Apr 2007 10:47:17 +0200 Subject: gpgsm 1.9.22 supports no RC2 Algorithm ? In-Reply-To: <87d524af16.fsf@wheatstone.g10code.de> References: <200704152250.08124.M_Hoeller@nurfuerspam.de> <87d524af16.fsf@wheatstone.g10code.de> Message-ID: <20070416084717.44210@gmx.net> Hello Werner, I receive RC2 encrypted mails from Thunderbird / Ubuntu does this mean there is an alternative which I may can use? Or why is it possible that this works with Ubuntu. Or is it just the decryption which does not work? So I would be able to send mails encrypted with RC2 but I can not decrypt any RC2 enrcypted mail? Is there an Alternative ? Thanks a lot Michael -------- Original-Nachricht -------- Datum: Mon, 16 Apr 2007 10:40:05 +0200 Von: Werner Koch An: M Hoeller CC: gnupg-devel at gnupg.org Betreff: Re: gpgsm 1.9.22 supports no RC2 Algorithm ? > On Sun, 15 Apr 2007 22:50, M_Hoeller at nurfuerspam.de said: > > > I just received an S/MIME encrypted mail which I can not decrypt with > > gpgsm 1.9.22 this seems to be due to the fact that the used algorithm > > was a RC2. It seems that the sender userd Thinderbird as Mailclient. > > For patent reasons we don't support RC2 > > > Salam-Shalom, > > Werner -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail From wk at gnupg.org Mon Apr 16 11:19:09 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Apr 2007 11:19:09 +0200 Subject: gpgsm 1.9.22 supports no RC2 Algorithm ? In-Reply-To: <20070416084717.44210@gmx.net> ("Michael =?utf-8?Q?H=C3=B6lle?= =?utf-8?Q?r=22's?= message of "Mon\, 16 Apr 2007 10\:47\:17 +0200") References: <200704152250.08124.M_Hoeller@nurfuerspam.de> <87d524af16.fsf@wheatstone.g10code.de> <20070416084717.44210@gmx.net> Message-ID: <87tzvg8ynm.fsf@wheatstone.g10code.de> On Mon, 16 Apr 2007 10:47, M_Hoeller at nurfuerspam.de said: > I receive RC2 encrypted mails from Thunderbird / Ubuntu does this mean there is an alternative which I may can use? Or why is it possible that this works with Ubuntu. Or is it just the decryption which does not work? So I would be able to send mails encrypted with RC2 but I can not decrypt any RC2 enrcypted mail? I don't know why Mozilla uses RC2 at all. This algorithm is not only patented but also obsolete for many years. Tell the senders to switch to AES or Triple-DES. Shalom-Salam, Werner From alon.barlev at gmail.com Mon Apr 16 13:00:19 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 16 Apr 2007 14:00:19 +0300 Subject: [Announce] GPGME 1.1.3 released In-Reply-To: <873b35b3wf.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <878xff5jtb.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200702032109.12618.alon.barlev@gmail.com> <873b35b3wf.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <9e0cf0bf0704160400n5cb7a58crbb330f07e7b6e086@mail.gmail.com> On 4/13/07, Marcus Brinkmann wrote: > GPGME follows libassuan, which we maintain separately. According to > > http://g10code.com/autobuild/libassuan-1.0.1.tar.gz-x86-freebsd1-output.html > > libassuan builds just fine on freebsd. So, if GPGME doesn't, there is > something we need to fix, but it is not clear that the below patch is > the right approach. Can you please send me more info about the build > problems? > > Thanks, > Marcus Failure without the patch. i686-gentoo-freebsd6.2-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -D_ASSUAN_IN_GPGME_BUILD_ASSUAN -O2 -march=pentium-m -pipe -I../assuan/ -MT assuan-errors.lo -MD -MP -MF .deps/assuan-errors.Tpo -c assuan-errors.c -fPIC -DPIC -o .libs/assuan-errors.o In file included from assuan-errors.c:13: assuan.h:74: error: expected declaration specifiers or '...' before 'socklen_t' assuan.h:75: error: expected declaration specifiers or '...' before 'socklen_t' gmake[3]: *** [assuan-errors.lo] Error 1 Best Regards, Alon Bar-Lev. From M_Hoeller at nurfuerspam.de Mon Apr 16 21:42:14 2007 From: M_Hoeller at nurfuerspam.de (M Hoeller) Date: Mon, 16 Apr 2007 21:42:14 +0200 Subject: gpgsm 1.9.22 supports no RC2 Algorithm ? In-Reply-To: <87tzvg8ynm.fsf@wheatstone.g10code.de> References: <200704152250.08124.M_Hoeller@nurfuerspam.de> <20070416084717.44210@gmx.net> <87tzvg8ynm.fsf@wheatstone.g10code.de> (sfid-20070416_210003_806785_1C62BFDF) Message-ID: <200704162142.14708.M_Hoeller@nurfuerspam.de> Hallo Werner, On Montag, 16. April 2007, Werner Koch wrote: > On Mon, 16 Apr 2007 10:47, M_Hoeller at nurfuerspam.de said: > > I receive RC2 encrypted mails from Thunderbird / Ubuntu does this > > mean there is an alternative which I may can use? Or why is it > > possible that this works with Ubuntu. Or is it just the > > decryption which does not work? So I would be able to send mails > > encrypted with RC2 but I can not decrypt any RC2 enrcypted mail? > > I don't know why Mozilla uses RC2 at all. This algorithm is not > only patented but also obsolete for many years. Tell the senders > to switch to AES or Triple-DES. hier sind noch ein paar Details, laut der thunderbird entwicker liste wird RC2 gar nicht mehr verwendet,,, aber das gpgsm log sagt was anderes. Vielleicht f?llt euch was auf, ich steck gerade in Deadlock.. verwendete gpgsm Version ist 1.9.22 mit kmail 1.9.2, KDE 3.5.6, openSUSE 10.2 Hier sind die Headerdaten der Mail die ich erhalten habe: User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 X-Enigmail-Version: 0.94.0.0 OpenPGP: id=BDD13B90; url=http://tinyurl.com/5d8mm Content-Type: application/x-pkcs7-mime; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Description: S/MIME Encrypted Message und hier ist das log von gpgsm: 4 - 2007-04-16 21:32:46 gpgsm[7623.0x8084a98] DBG: <- DECRYPT 4 - 2007-04-16 21:32:46 gpgsm[7623]: unsupported algorithm `1.2.840.113549.3.2' 4 - 2007-04-16 21:32:46 gpgsm[7623]: (Dies ist der RC-2 Algorithmus) 4 - 2007-04-16 21:32:46 gpgsm[7623.0x8084a98] DBG: -> S ERROR decrypt.algorithm 50331732 1.2.840.113549.3.2 4 - 2007-04-16 21:32:46 gpgsm[7623.0x8084a98] DBG: -> S DECRYPTION_FAILED 4 - 2007-04-16 21:32:46 gpgsm[7623]: message decryption failed: Nicht unterst?tztes Verfahren 4 - 2007-04-16 21:32:46 gpgsm[7623.0x8084a98] DBG: -> ERR 50331732 Nicht unterst?tztes Verfahren 4 - 2007-04-16 21:32:47 gpgsm[7623.0x8084a98] DBG: <- BYE demnach muss Thunderbird eine RC2 Verschl?sselung geschickt haben. Wie kann das sein wenn diese von TB gar nicht unterst?tzt wird? Oder kommt gpgsm durch was anderes aus dem Tritt? Hoffe es weis jemand Rat. Viele Gr??e Michael From dshaw at jabberwocky.com Tue Apr 17 01:36:42 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 16 Apr 2007 19:36:42 -0400 Subject: qnx6 patches In-Reply-To: <20070415210026.GA536592@qnx.com> References: <20070413160257.GA692266@qnx.com> <20070415185833.GD1983@jabberwocky.com> <20070415210026.GA536592@qnx.com> Message-ID: <20070416233642.GA16986@jabberwocky.com> On Sun, Apr 15, 2007 at 05:00:26PM -0400, Sean Boudreau wrote: > On Sun, Apr 15, 2007 at 02:58:33PM -0400, David Shaw wrote: > > On Fri, Apr 13, 2007 at 12:02:57PM -0400, Sean Boudreau wrote: > > > > > > Hello: > > > > > > Please find attached the QNX6 diffs I've been using > > > for gnupg-1.4.6. I think most of these may be > > > applicable to other POSIX strict environments. > > > > Thank you for the diffs. The reason for some of the changes are > > clear, and I've started to apply them. Some of the others I have > > questions about: > > > > > --- acinclude.m4.orig 2006-10-02 11:15:43.000000000 -0400 > > > +++ acinclude.m4 2007-03-28 09:13:07.000000000 -0400 > > > @@ -416,6 +416,42 @@ > > > #include > > > #include > > > > > > + /* This mess was copied from the GNU getpagesize.h. */ > > > + #ifndef HAVE_GETPAGESIZE > > > > (etc). Can you clarify what this change is intended to address? > > Presumably getpagesize, but can you show me what did not work in the > > current code? > > Yes, getpagesize() which qnx6 doesn't have; however we do > have sysconf(_SC_PAGESIZE). I was getting the > HAVE_BROKEN_MLOCK define due to its undefined reference. > The above is similar to what autoconf does for mmap(). Ok, I put a fix in for this (and then Werner fixed my fix!) Anyway, it's not the same as the patch, but the end result should be the same. It was more than qnx: the code wouldn't work on any platform that didn't have getpagesize(). > > I assume the various changes are for strcasecmp(). > > Yes. Fixed as well. The keyserver/*.c files were actually better as ascii_strcasecmp(), so that doesn't even need strings.h. Things should be okay for qnx6 without any special patches now. David From wk at gnupg.org Tue Apr 17 10:03:06 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Apr 2007 10:03:06 +0200 Subject: gpgsm 1.9.22 supports no RC2 Algorithm ? In-Reply-To: <200704162142.14708.M_Hoeller@nurfuerspam.de> (M. Hoeller's message of "Mon\, 16 Apr 2007 21\:42\:14 +0200") References: <200704152250.08124.M_Hoeller@nurfuerspam.de> <20070416084717.44210@gmx.net> <87tzvg8ynm.fsf@wheatstone.g10code.de> <200704162142.14708.M_Hoeller@nurfuerspam.de> Message-ID: <87bqhn1l8l.fsf@wheatstone.g10code.de> On Mon, 16 Apr 2007 21:42, M_Hoeller at nurfuerspam.de said: > hier sind noch ein paar Details, laut der thunderbird entwicker liste > wird RC2 gar nicht mehr verwendet,,, aber das gpgsm log sagt was > anderes. [ According to the TB dev ML, RC2 is not used...but the gpgsm log tells something different] > OpenPGP: id=BDD13B90; url=http://tinyurl.com/5d8mm Cool feature: let TinyURL.com know whenever someone wants to verify that message for the first time. > 4 - 2007-04-16 21:32:46 gpgsm[7623.0x8084a98] DBG: <- DECRYPT > 4 - 2007-04-16 21:32:46 gpgsm[7623]: unsupported algorithm > `1.2.840.113549.3.2' > 4 - 2007-04-16 21:32:46 gpgsm[7623]: (Dies ist der RC-2 Algorithmus) > demnach muss Thunderbird eine RC2 Verschl?sselung geschickt haben. Wie > kann das sein wenn diese von TB gar nicht unterst?tzt wird? Oder > kommt gpgsm durch was anderes aus dem Tritt? [ so TB must have send a message using RC2. How can that happen if TB does not support RC2. Or is it a gpgsm problem? ] Look at the error handling code: rc = gpg_error (GPG_ERR_UNSUPPORTED_ALGORITHM); log_error ("unsupported algorithm `%s'\n", algoid? algoid:"?"); if (algoid && !strcmp (algoid, "1.2.840.113549.3.2")) log_info (_("(this is the RC2 algorithm)\n")); RC2 has clearly been identified. To get a second opinion, you might want to run dumpasn1 over the message (remove the base64 first) and see that dumpasn1 will tell you the same. Shalom-Salam, Werner From M_Hoeller at nurfuerspam.de Tue Apr 17 21:44:53 2007 From: M_Hoeller at nurfuerspam.de (M Hoeller) Date: Tue, 17 Apr 2007 21:44:53 +0200 Subject: gpgsm 1.9.22 supports no RC2 Algorithm ? In-Reply-To: <87bqhn1l8l.fsf@wheatstone.g10code.de> References: <200704152250.08124.M_Hoeller@nurfuerspam.de> <200704162142.14708.M_Hoeller@nurfuerspam.de> <87bqhn1l8l.fsf@wheatstone.g10code.de> (sfid-20070417_193110_993119_7806BE01) Message-ID: <200704172144.54351.M_Hoeller@nurfuerspam.de> Hello, I am sorry I am not an expert.., but how can I remove the base64 first? On Dienstag, 17. April 2007, Werner Koch wrote: > RC2 has clearly been identified. ?To get a second opinion, you > might want to run dumpasn1 over the message (remove the base64 > first) and see that dumpasn1 will tell you the same. I hope someone can help me: The mail I have at hand, which is not encrypted, b/c the mail is detected as RC2 looks like this: Thanks a lot Michael Return-Path: X-Flags: 1001 Delivered-To: GMX delivery to zzzzz at gmx.de Received: (qmail invoked by alias); 16 Apr 2007 22:02:20 -0000 Received: from smtprelay03.ispgateway.de (EHLO smtprelay03.ispgateway.de) [80.67.18.15] by mx0.gmx.net (mx009) with SMTP; 17 Apr 2007 00:02:20 +0200 Received: (qmail 12481 invoked from network); 16 Apr 2007 22:02:20 -0000 Received: from unknown (HELO [192.168.1.115]) (817251@[85.176.97.251]) (envelope-sender ) by smtprelay03.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 16 Apr 2007 22:02:20 -0000 Message-ID: <4623F24A.4060004 at web.de> (sfid-20070417_063847_591224_FAD1344B) Date: Tue, 17 Apr 2007 00:01:46 +0200 From: =?ISO-8859-15?Q?yyyyyy at web.de> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Michael Hoeller Subject: Re: crypto-test04 nur sig References: <200704162347.35838.zzzz at gmx.de> In-Reply-To: <200704162347.35838.zzzzz at gmx.de> X-Enigmail-Version: 0.94.3.0 OpenPGP: id=3B56E5C4; url=http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xB397AEB03B56E5C4 Content-Type: application/x-pkcs7-mime; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Description: S/MIME Encrypted Message X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 4 (From mass domain over foreign mail server) X-GMX-UID: W8QQcpReTXs9HN8LSGY5HrBKRzdyMkOh X-CRM114-Version: 20070301-BlameBaltar ( TRE 0.7.5 (LGPL) ) MR-BD9991E2 X-CRM114-CacheID: sfid-20070417_063847_591224_FAD1344B X-CRM114-Status: GOOD ( 19.98 ) X-UID: Status: R X-Status: NC X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: MIAGCSqGSIb3DQEHA6CAMIACAQAxggMTMIIBcgIBADBaMFQxFDASBgNVBAoTC0NBY2VydCBJ bmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD [...] AMWCgKRGqlIzgjMIh6XbgCI6xLJ5p107aXb4ylA81oY1neZmdGU6pyQ7hh9BAbmwOUnsDHNj l0shKsDccPtpMnExtNhIUitHHXjpHAztvnetmZ1Lc2okMwZrkPZk9BCcmrjb5PDBFUljKePG OpyV01GGBLPUMLMHQLxn8CNn3iROhogWaW9KWd7GqMeZzuB/boIJgMbu0Mzp4gg2Lc7oJ+jr WCWtu1uubfnYv30XiA282P4IyA4Hc/Kb4ey+W800GJodCoQ0ErgQF21Qh9V0tIlAJDK775dW NxIygebEqlSPTxDwWs8zp807iimnFVpnW0cPH6avBYWnkCDbt2OHKGlLXQeszo8cVXqpeLNE zh7WndeOhNRpFO5mtVzFtMnpezgbW4rPZuD5t3Wnhb0ESJxh6uH4chl7kIB0DnfQd80pB97s J1umFJsHQ1nW/lMMTxJvEHvJ6T3YoZamV3QY5xKd1R4fqeY3QEQWrsmePD84meG2tU3C9wQI 3nOxqQ+B/6sAAAAAAAAAAAAA From wk at gnupg.org Wed Apr 18 14:28:25 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Apr 2007 14:28:25 +0200 Subject: First ECC certificate imported by gpgsm Message-ID: <87lkgpvpcm.fsf@wheatstone.g10code.de> Hi, this is just to let you know that I have made some progress with ECDSA support for GPGSM. With the SVN versions of libgcrypt, libksba and gnupg it is now possible to import at least one certificate: http://dev.experimentalstuff.com:8082/certs/secp256r1ca.cert.pem Serial number: 3A Issuer: /CN=dev.experimentalstuff.com/OU=Test CA (secp256r1)/O=Sun Microsystems Laboratories/L=Mountain View/ST=CA/C=US Subject: /CN=dev.experimentalstuff.com/OU=Test CA (secp256r1)/O=Sun Microsystems Laboratories/L=Mountain View/ST=CA/C=US validity: 2005-12-06 21:29:53 through 2010-01-14 21:29:53 key type: 256 bit ECDSA chain length: unlimited fingerprint: 43:3A:10:57:83:6D:87:E7:BC:C2:B5:64:8A:75:0F:17:BF:73:E2:4A importing also means that the signature has been checked. Stay tuned. Salam-Shalom, Werner From wk at gnupg.org Wed Apr 18 14:30:44 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Apr 2007 14:30:44 +0200 Subject: gpgsm 1.9.22 supports no RC2 Algorithm ? In-Reply-To: <200704172144.54351.M_Hoeller@nurfuerspam.de> (M. Hoeller's message of "Tue\, 17 Apr 2007 21\:44\:53 +0200") References: <200704152250.08124.M_Hoeller@nurfuerspam.de> <200704162142.14708.M_Hoeller@nurfuerspam.de> <87bqhn1l8l.fsf@wheatstone.g10code.de> <200704172144.54351.M_Hoeller@nurfuerspam.de> Message-ID: <87hcrdvp8r.fsf@wheatstone.g10code.de> On Tue, 17 Apr 2007 21:44, M_Hoeller at nurfuerspam.de said: > I am sorry I am not an expert.., but how can I remove the base64 > first? Something like cat foo.pem | grev -v '^--' | mimencode -u >foo.cms should work. > I hope someone can help me: The mail I have at hand, which is not > encrypted, b/c the mail is detected as RC2 looks like this: That does not much because you cut off the part with the algorithm specification. Shalom-Salam, Werner From buanzo at buanzo.com.ar Thu Apr 19 03:25:23 2007 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Wed, 18 Apr 2007 22:25:23 -0300 Subject: pka_address Message-ID: <4626C503.8050703@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi group! For my module mod_auth_openpgp I'm currently adding X-Auth-OpenPGP headers such as Fingerprint, Trust, etc, but I definitely need to be able to provide the email-address (which I guess would be pka_address). My operation is a simple verify_op against a message+signature. So, at the end of this message you'll find the function I've written, but although I've tried different approaches (deprecated and current ones), I've not had luck. If I verify the same message|signature with gpgv, I get no mail address: apache at bbs ~ $ gpgv < request.limpio.txt.asc gpgv: keyblock resource `/var/www/.gnupg/trustedkeys.gpg': general error gpgv: Signature made Fri Oct 20 08:46:27 2006 ART using DSA key ID 6857704D gpgv: Can't check signature: public key not found So I tried this: apache at bbs ~/.gnupg $ cp pubring.gpg trustedkeys.gpg apache at bbs ~ $ gpgv < request.limpio.txt.asc gpgv: Signature made Fri Oct 20 08:46:27 2006 ART using DSA key ID 6857704D gpgv: Good signature from "Arturo Alberto Busleiman (aka Buanzo) " So I thought: "ok, this was my problem, let's try again". But no, my module still does not get a pka_address that's different from NULL. So, I although I've spent this week trying to figure this out (even reading the gpgme source) I couldn't get a hold on the correct way of getting pka_address filled, or even find my mistake, or whatever. The fingerprint is correctly obtained, and matches what gpg --list-keys --fingerprint shows me. Any ideas? Even one word might probably help me. :) This is the code: == cut here == int gpg_verification (char *message, char *signature, int msgSize, char **fpr, char **key_address,request_rec * r) { gpgme_ctx_t ctx; gpgme_error_t err; gpgme_data_t sign, text; gpgme_verify_result_t result; int retval = 1; if (msgSize < 0) return 1; err = gpgme_new (&ctx); if (msgSize == 0) err = gpgme_data_new_from_mem (&text, message, strlen(message), 0); else err = gpgme_data_new_from_mem (&text, message, msgSize, 0); err = gpgme_data_new_from_mem (&sign, signature, strlen (signature), 0); err = gpgme_op_verify (ctx, sign, text, NULL); result = gpgme_op_verify_result (ctx); switch (gpg_err_code (result->signatures->status)) { case GPG_ERR_NO_ERROR: { /* copy fingerprint */ *fpr = apr_pcalloc (r->pool, strlen(result->signatures->fpr) + 1); memcpy ((char *) *fpr, result->signatures->fpr, strlen(result->signatures->fpr)); /* pka_address can be null when address is unknown.. but WHY is it unknown?! */ if (result->signatures->pka_address != NULL) { *key_address = apr_pcalloc (r->pool, strlen(result->signatures->pka_address) + 1); memcpy ((char *) *key_address, result->signatures->pka_address, strlen(result->signatures->pka_address)); } retval = 0; break; } default: { retval = 1; break; } } gpgme_data_release (sign); gpgme_data_release (text); gpgme_release (ctx); return (retval); } == cut here == PS: I even tried upgrading gnupg, libgpg-error, gpgme and everything to the latest available version in Gentoo, which seemed fairly bleeding-edge / near cvs level. I can try CVS if needed. Sincerely, - -- Arturo "Buanzo" Busleiman - Consultor Independiente en Seguridad Informatica Foros GNU/Buanzo: Respeto, Soluciones y Buena Onda: http://foros.buanzo.com.ar Consulting and Secure Mail Hosting: http://www.buanzo.com.ar/pro/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJsUDAlpOsGhXcE0RCnhGAJ9tHN01t948gNuDKrpX8cR34f/UPACggOGH nucIIDK9gUSGxFUx/dBeoMc= =Hr0X -----END PGP SIGNATURE----- From M_Hoeller at nurfuerspam.de Thu Apr 19 22:32:53 2007 From: M_Hoeller at nurfuerspam.de (M Hoeller) Date: Thu, 19 Apr 2007 22:32:53 +0200 Subject: gpgsm 1.9.22 supports no RC2 Algorithm ? In-Reply-To: <87d524af16.fsf@wheatstone.g10code.de> References: <200704152250.08124.M_Hoeller@nurfuerspam.de> <87d524af16.fsf@wheatstone.g10code.de> (sfid-20070416_210002_755596_F0D522C4) Message-ID: <200704192232.53272.M_Hoeller@nurfuerspam.de> Hello all, it seems that there are recently problems wenn KMail/gpgsm should decrypt mails form Thunderbird. gpgsm complains that a RC2 Algorithm is used from TB which is not supported in gpgsm (what is corrcet, thanks Werner). Well the TB folks swear that TB sends not RC2 by default. There is some guessing out that KMail/gpgsm does not request 3DES and that for this reason TB sends RC2. Well my knowledg is to poor at this point to go ahead, I have to asked the experts. I have check 3 Mails from different persons the TB on Mac and Debain where my KMail 1.9.6 with gpgsm 1.9.22 openSUSE 10.2 complains that a RC2 algorithm is used. dumpasn1 reports all of them as RC2. At this point I do not know who is rigth or wrong. What would be a procedure to check if it is TB, gpgsm or both ?? Thanks a lot Michael From buanzo at buanzo.com.ar Thu Apr 19 23:32:34 2007 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Thu, 19 Apr 2007 18:32:34 -0300 Subject: pka_address [SOLVED] In-Reply-To: <4626C503.8050703@buanzo.com.ar> References: <4626C503.8050703@buanzo.com.ar> Message-ID: <4627DFF2.1030100@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Arturo 'Buanzo' Busleiman wrote: > /* pka_address can be null when address is unknown.. but WHY is it unknown?! */ > if (result->signatures->pka_address != NULL) { > *key_address = apr_pcalloc (r->pool, strlen(result->signatures->pka_address) + 1); > memcpy ((char *) *key_address, result->signatures->pka_address, > strlen(result->signatures->pka_address)); > } Well, I've solved the issue with this very simple code. I was sure this was deprecated, but seems I was mistaken: [the code block above] } else { err = gpgme_get_key (ctx, result->signatures->fpr, &key, 0); if (key->uids->email != NULL) { *key_address = apr_pcalloc (r->pool, strlen(key->uids->email) + 1); memcpy ((char *) *key_address, key->uids->email, strlen(key->uids->email)); } } - -- Arturo "Buanzo" Busleiman - Consultor Independiente en Seguridad Informatica Foros GNU/Buanzo: Respeto, Soluciones y Buena Onda: http://foros.buanzo.com.ar Consulting and Secure Mail Hosting: http://www.buanzo.com.ar/pro/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJ9/yAlpOsGhXcE0RChozAJsHTY8Ywmq0vn91G2ZTvD9FGJouUwCfbCJ/ bXngLLq4PghzcqWJ0wnjlB0= =Td5n -----END PGP SIGNATURE----- From wk at gnupg.org Fri Apr 20 08:56:11 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Apr 2007 08:56:11 +0200 Subject: pka_address [SOLVED] In-Reply-To: <4627DFF2.1030100@buanzo.com.ar> (Arturo Busleiman's message of "Thu\, 19 Apr 2007 18\:32\:34 -0300") References: <4626C503.8050703@buanzo.com.ar> <4627DFF2.1030100@buanzo.com.ar> Message-ID: <87d51zo7p0.fsf@wheatstone.g10code.de> On Thu, 19 Apr 2007 23:32, buanzo at buanzo.com.ar said: > if (key->uids->email != NULL) { > *key_address = apr_pcalloc (r->pool, strlen(key->uids->email) + 1); > memcpy ((char *) *key_address, key->uids->email, strlen(key->uids->email)); > } > } I wonder why you are calling this a PKA address. The PKA address is an attribute of a signature not yet widley used. PKA is a system similar to domain keys but built on top of existsing protocols. You won't see the PKA_ADRESS filled unless the sender has setup an appropriate DNS record and enabled PKA in his MUA. Shalom-Salam, Werner From wk at gnupg.org Fri Apr 20 09:14:04 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Apr 2007 09:14:04 +0200 Subject: gpgsm 1.9.22 supports no RC2 Algorithm ? In-Reply-To: <200704192232.53272.M_Hoeller@nurfuerspam.de> (M. Hoeller's message of "Thu\, 19 Apr 2007 22\:32\:53 +0200") References: <200704152250.08124.M_Hoeller@nurfuerspam.de> <87d524af16.fsf@wheatstone.g10code.de> <200704192232.53272.M_Hoeller@nurfuerspam.de> Message-ID: <87647ro6v7.fsf@wheatstone.g10code.de> On Thu, 19 Apr 2007 22:32, M_Hoeller at nurfuerspam.de said: > Well the TB folks swear that TB sends not RC2 by default. There is > some guessing out that KMail/gpgsm does not request 3DES and that for > this reason TB sends RC2. Those who make a MUA deliberately falling back to 40 bit RC2 are at best ignorant to privacy issues or in the worst case hoping for a job at a 3 letter agency. Note, that the US crypto export regulations have basically been dropped more than 6 years ago and thus there is no reason at all to cripple the key even for software distributed from the US. Salam-Shalom, Werner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20070420/e5b4086c/attachment.pgp From M_Hoeller at nurfuerspam.de Fri Apr 20 22:07:01 2007 From: M_Hoeller at nurfuerspam.de (M Hoeller) Date: Fri, 20 Apr 2007 22:07:01 +0200 Subject: gpgsm 1.9.22 supports no RC2 Algorithm ? In-Reply-To: <87647ro6v7.fsf@wheatstone.g10code.de> References: <200704152250.08124.M_Hoeller@nurfuerspam.de> <200704192232.53272.M_Hoeller@nurfuerspam.de> <87647ro6v7.fsf@wheatstone.g10code.de> (sfid-20070420_175047_045544_C4DEF6C2) Message-ID: <200704202207.01477.M_Hoeller@nurfuerspam.de> Hello experts, is there a chance that the certificate it selve is the problem? I only found these kind of error reports with CAcert and thawte. Best regards Michael On Freitag, 20. April 2007, Werner Koch wrote: > On Thu, 19 Apr 2007 22:32, M_Hoeller at nurfuerspam.de said: > > Well the TB folks swear that TB sends not RC2 by default. There > > is some guessing out that KMail/gpgsm does not request 3DES and > > that for this reason TB sends RC2. > > Those who make a MUA deliberately falling back to 40 bit RC2 are at > best ignorant to privacy issues or in the worst case hoping for a > job at a 3 letter agency. Note, that the US crypto export > regulations have basically been dropped more than 6 years ago and > thus there is no reason at all to cripple the key even for software > distributed from the US. > > Salam-Shalom, > Werner From albrecht.dress at arcor.de Sat Apr 21 16:22:09 2007 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Sat, 21 Apr 2007 16:22:09 +0200 Subject: GpgME BUG: list expired secret keys? In-Reply-To: <871wipb3o9.wl%marcus.brinkmann@ruhr-uni-bochum.de> (from marcus.brinkmann@ruhr-uni-bochum.de on Fri Apr 13 00:58:46 2007) Message-ID: <1177165340l.3231l.0l@antares.localdomain> Am 13.04.07 00:58 schrieb(en) Marcus Brinkmann: > If you run with GPGME_DEBUG=3 or just run gpg --status-fd 2 manually, you will probably find that this is because gpg does return incomplete data. As far as I understand, gnupg's key listing output of secret keys is currently not fully complete in the manner you noticed before. Can you confirm that this is the problem in your case? I tried again with my test application, and the GPGME debug output is attached. I tested with a dummy key, so no confidential data has been removed from the logs. Please note that I meanwhile upgraded to gpg 1.4.7 and gpgme 1.1.4: ---snip----------------------------- [albrecht at antares ~]$ GPGME_DEBUG=3:expire-sec.log ./gpgme-key-expire test.key at some.org 1 now is 1177164586 key: can_sign=1 can_encrypt=0 expired=0 subkey id=5AF280F9940BBECD can_sign=1 can_encrypt=0 expired=0 expires=1177073638 [1] subkey id=4450EFC17F688538 can_sign=0 can_encrypt=1 expired=0 expires=1177073658 [1] [albrecht at antares ~]$ GPGME_DEBUG=3:expire-pub.log ./gpgme-key-expire test.key at some.org 0 now is 1177164730 key: can_sign=1 can_encrypt=0 expired=1 subkey id=5AF280F9940BBECD can_sign=1 can_encrypt=0 expired=1 expires=1177073638 [1] subkey id=4450EFC17F688538 can_sign=0 can_encrypt=1 expired=1 expires=1177073658 [1] ---snip----------------------------- GnuPG spits out several "expired" messages in both cases, as you can see in the logs. For the time being, I will supply a patch for Balsa checking if the secret key has expired or not, but IMO gpgme *must* return a correct value here! Cheers, Albrecht. -- Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress at arcor.de GnuPG public key: http://www.mynetcologne.de/~nc-dreszal/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: expire-pub.log Type: text/x-log Size: 3406 bytes Desc: not available Url : /pipermail/attachments/20070421/26ff4474/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: expire-sec.log Type: text/x-log Size: 4413 bytes Desc: not available Url : /pipermail/attachments/20070421/26ff4474/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070421/26ff4474/attachment.pgp From buanzo at buanzo.com.ar Sat Apr 21 17:36:34 2007 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Sat, 21 Apr 2007 12:36:34 -0300 Subject: pka_address [SOLVED] In-Reply-To: <87d51zo7p0.fsf@wheatstone.g10code.de> References: <4626C503.8050703@buanzo.com.ar> <4627DFF2.1030100@buanzo.com.ar> <87d51zo7p0.fsf@wheatstone.g10code.de> Message-ID: <462A2F82.9080104@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Werner Koch wrote: > I wonder why you are calling this a PKA address. I got confused when reading an old thread in the archives. Thanks for the heads up. - -- Arturo "Buanzo" Busleiman - Consultor Independiente en Seguridad Informatica OpenPGP for HTTP: New Web-Auth Scheme: http://freshmeat.net/articles/view/2599 Consulting and Secure Mail Hosting: http://www.buanzo.com.ar/pro/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGKi+CAlpOsGhXcE0RCp88AJ0ds2OjQSJ8Rufp0TF5k8WIbQ3wlgCfZ8qo 3dp7COIXKN8eYQh4OM1ltaY= =72ey -----END PGP SIGNATURE----- From M_Hoeller at nurfuerspam.de Sun Apr 22 08:42:57 2007 From: M_Hoeller at nurfuerspam.de (M Hoeller) Date: Sun, 22 Apr 2007 08:42:57 +0200 Subject: Is this possible ?? Message-ID: <200704220842.57504.M_Hoeller@nurfuerspam.de> Hello experts, here I hava a real live problem which I hope someone of the experts on this list can explain.. The probelm is that I recieve from various people encrypted mails which useed RC2 as algorithm... Here the szenario; Person A uses Thunderbird Person B uses KMail The Problem is that Person B (KMail) can not read encrypted S/MIME Messages from person A (Thunderbird). The assumption is that KMail from person B sends with every mail to person A some kind of informtaion which maks Thunderbird think that it should encrypt with the RC2 algo. Therefore person A deletes the public cert from B and imports this manualy again. Person B did send the cert as PEM to person A, And... voila Thunderbird from person A uses 3DES. Person B writes back. Person A answers and :-(( it does not work the used Algo is RC2. ==> Is it possible that KMAIL/gpgsm sends or stores some information in the mail which leads to the fact that Thunderbird sends RC2 ???? Thanks a lot for any hint Michael From wk at gnupg.org Sun Apr 22 13:25:13 2007 From: wk at gnupg.org (Werner Koch) Date: Sun, 22 Apr 2007 13:25:13 +0200 Subject: Is this possible ?? In-Reply-To: <200704220842.57504.M_Hoeller@nurfuerspam.de> (M. Hoeller's message of "Sun\, 22 Apr 2007 08\:42\:57 +0200") References: <200704220842.57504.M_Hoeller@nurfuerspam.de> Message-ID: <878xckhcrq.fsf@wheatstone.g10code.de> On Sun, 22 Apr 2007 08:42, M_Hoeller at nurfuerspam.de said: > ==> Is it possible that KMAIL/gpgsm sends or stores some information in the > mail which leads to the fact that Thunderbird sends RC2 ???? Definitely not. Salam-Shalom, Werner From simon at josefsson.org Sun Apr 22 13:45:36 2007 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 22 Apr 2007 13:45:36 +0200 Subject: Scute: feature request: Support CKA_TRUSTED attribute on X.509 certs Message-ID: <87r6qc63a7.fsf@mocca.josefsson.org> Hi! I'm making GnuTLS support PKCS#11, and use Scute to test it. I've noticed that while Scute do have the users' CA cert, it is not marked as trusted via the PKCS#11 interface. A small PKCS#11 app that does: pValueTemplate[0].type = CKA_ID; pValueTemplate[0].pValue = buf; pValueTemplate[0].ulValueLen = sizeof(buf); ... pValueTemplate[2].type = CKA_CERTIFICATE_CATEGORY; pValueTemplate[2].pValue = &cat; pValueTemplate[2].ulValueLen = sizeof(cat); pValueTemplate[3].type = CKA_TRUSTED; pValueTemplate[3].pValue = &trusted; pValueTemplate[3].ulValueLen = sizeof(trusted); ... rv = C_GetAttributeValue(shSession, ohObject, pValueTemplate, 4); ... printf ("buf: %s\n", buf); printf ("trust: %d\n", trusted); printf ("cat: %d\n", cat); Will print: buf: 1532B4BA5A8A7988CA264283591BA3A21C0BCC24 trust: 0 cat: 0 .. buf: BD5F80DE63034EC9E2841E6309552E345C5F226F trust: 0 cat: 0 The trustlist.txt is set up: jas at mocca:~$ cat .gnupg/trustlist.txt # CN=GnuTLS test CA 1532B4BA5A8A7988CA264283591BA3A21C0BCC24 S jas at mocca:~$ My intention is to use the CKA_TRUSTED, or possibly the CKA_CERTIFICATE_CATEGORY, attributes to decide whether to treat a certificate as a trusted certificate by GnuTLS. Is that a bad idea, or would implementing those attributes in Scute be a good idea? Thanks, Simon jas at mocca:~$ gpgsm -k /home/jas/.gnupg/pubring.kbx ---------------------------- Serial number: 4628A165 Issuer: /CN=GnuTLS test CA Subject: /CN=Test Key/O=Simon Josefsson aka: (dns-name josefsson.org) validity: 2007-04-20 11:17:59 through 2007-10-17 11:18:02 key type: 1024 bit RSA key usage: digitalSignature keyEncipherment ext key usage: clientAuth (suggested), serverAuth (suggested) fingerprint: BD:5F:80:DE:63:03:4E:C9:E2:84:1E:63:09:55:2E:34:5C:5F:22:6F Serial number: 46261D27 Issuer: /CN=GnuTLS test CA Subject: /CN=GnuTLS test CA validity: 2007-04-18 13:29:11 through 2008-04-17 13:29:11 key type: 1024 bit RSA key usage: certSign chain length: unlimited fingerprint: 15:32:B4:BA:5A:8A:79:88:CA:26:42:83:59:1B:A3:A2:1C:0B:CC:24 random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 secmem usage: 0/16384 bytes in 0 blocks jas at mocca:~$ From M_Hoeller at nurfuerspam.de Sun Apr 22 15:09:16 2007 From: M_Hoeller at nurfuerspam.de (M Hoeller) Date: Sun, 22 Apr 2007 15:09:16 +0200 Subject: Is this possible ?? In-Reply-To: <878xckhcrq.fsf@wheatstone.g10code.de> References: <200704220842.57504.M_Hoeller@nurfuerspam.de> <878xckhcrq.fsf@wheatstone.g10code.de> (sfid-20070422_150213_305098_295F3FAE) Message-ID: <200704221509.16914.M_Hoeller@nurfuerspam.de> Hello Werner, On Sonntag, 22. April 2007, Werner Koch wrote: > On Sun, 22 Apr 2007 08:42, M_Hoeller at nurfuerspam.de said: > > ==> Is it possible that KMAIL/gpgsm sends or stores some information > > in the mail which leads to the fact that Thunderbird sends RC2 ???? > > Definitely not. I am, in some kind, happy to here this. But what could be the reason that the manual imported certificate works fine, as longs as no other signed mail was recieved? Can you, or the other experts (sorry don't want to be rude when I address this to Werner) difintely exclude that KMail/gpgsm is the source of the problem that Thunderbird sends RC2 encrypted mails back? Michael > > Here the szenario; > > > > Person A uses Thunderbird > > Person B uses KMail > > > > The Problem is that Person B (KMail) can not read encrypted S/MIME > > Messages > > > > >from person A (Thunderbird). > > > > The assumption is that KMail from person B sends with every mail to > > person A some kind of informtaion which maks Thunderbird think that it > > should encrypt with the RC2 algo. > > > > Therefore person A deletes the public cert from B and imports this > > manualy again. Person B did send the cert as PEM to person A, > > > > And... voila Thunderbird from person A uses 3DES. > > > > Person B writes back. > > > > Person A answers and :-(( it does not work the used Algo is RC2. From wk at gnupg.org Sun Apr 22 23:30:08 2007 From: wk at gnupg.org (Werner Koch) Date: Sun, 22 Apr 2007 23:30:08 +0200 Subject: Scute: feature request: Support CKA_TRUSTED attribute on X.509 certs In-Reply-To: <87r6qc63a7.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Sun\, 22 Apr 2007 13\:45\:36 +0200") References: <87r6qc63a7.fsf@mocca.josefsson.org> Message-ID: <87wt04f673.fsf@wheatstone.g10code.de> On Sun, 22 Apr 2007 13:45, simon at josefsson.org said: > My intention is to use the CKA_TRUSTED, or possibly the > CKA_CERTIFICATE_CATEGORY, attributes to decide whether to treat a > certificate as a trusted certificate by GnuTLS. Is that a bad idea, > or would implementing those attributes in Scute be a good idea? A good one. Marcus, can you please look after it? Shalom-Salam, Werner From thanga at midascomm.com Mon Apr 23 08:02:29 2007 From: thanga at midascomm.com (S.Thanga Prakash) Date: Mon, 23 Apr 2007 11:32:29 +0530 (IST) Subject: help on gpgme Message-ID: hi all, I am using gpgme.0.3.14 and gpg.1.2.0. when i use gpgme_op_verify(), status was set to GPGME_SIG_STAT_NONE. When i retry once again, it is succeeds. Please, direct me to solve this issue. regards, stp. From simon at josefsson.org Mon Apr 23 11:35:08 2007 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 23 Apr 2007 11:35:08 +0200 Subject: Scute: feature request: Support CKA_TRUSTED attribute on X.509 certs In-Reply-To: <87wt04f673.fsf@wheatstone.g10code.de> (Werner Koch's message of "Sun\, 22 Apr 2007 23\:30\:08 +0200") References: <87r6qc63a7.fsf@mocca.josefsson.org> <87wt04f673.fsf@wheatstone.g10code.de> Message-ID: <87ps5v1lir.fsf@mocca.josefsson.org> Werner Koch writes: > On Sun, 22 Apr 2007 13:45, simon at josefsson.org said: > >> My intention is to use the CKA_TRUSTED, or possibly the >> CKA_CERTIFICATE_CATEGORY, attributes to decide whether to treat a >> certificate as a trusted certificate by GnuTLS. Is that a bad idea, >> or would implementing those attributes in Scute be a good idea? > > A good one. Marcus, can you please look after it? Thanks. Btw, do you know what the best way to find out which certificate correspond to a private key? Using the key id seems somewhat fragile, but it is what I'll use unless I learn of a better way. /Simon From M_Hoeller at gmx.de Sun Apr 15 22:10:06 2007 From: M_Hoeller at gmx.de (Michael Hoeller) Date: Sun, 15 Apr 2007 22:10:06 +0200 Subject: gpgsm 1.9.22 supports no RC2 Algorithm ? Message-ID: <200704152210.06821.M_Hoeller@gmx.de> Hello experts, I just received an S/MIME encrypted mail which I can not decrypt with gpgsm 1.9.22 this seems to be due to the fact that the used algorithm was a RC2. It seems that the sender userd Thinderbird as Mailclient. Here is a part of the log: 4 - 2007-04-14 22:52:42 gpgsm[5444]: unsupported algorithm `1.2.840.113549.3.2' 4 - 2007-04-14 22:52:42 gpgsm[5444]: (Dies ist der RC-2 Algorithmus) 4 - 2007-04-14 22:52:42 gpgsm[5444.0x8084a98] DBG: -> S ERROR decrypt.algorithm 50331732 1.2.840.113549.3.2 4 - 2007-04-14 22:52:42 gpgsm[5444.0x8084a98] DBG: -> S DECRYPTION_FAILED 4 - 2007-04-14 22:52:42 gpgsm[5444]: message decryption failed: Nicht unterst?tztes Verfahren 4 - 2007-04-14 22:52:42 gpgsm[5444.0x8084a98] DBG: -> ERR 50331732 Nicht unterst?tztes Verfahren Is this a bug, a feature, and is there a way how I can decrypt these mails? I use openSUSE 10.2 and KDE 3.5.6 with gpgsm 1.9.22 Thanks a lot for any hint Michael From grajababu at novell.com Wed Apr 18 07:18:03 2007 From: grajababu at novell.com (Gorjala Rajababu) Date: Tue, 17 Apr 2007 23:18:03 -0600 Subject: HKP fetch error: Connection refused Help needed. Message-ID: <4625F763.72A7.00F0.0@novell.com> ** High Priority ** Dear Sir, On SUSE 10 My name is Rajababu working for Novell-Bangalore .I used SP1 SLED10,Evolution worked out of box and very fast,Very impressive....:) They want to enable PGP for the same I used help topics and got the steps as follows from Evolution help. Getting and Using GPG Public Keys To send an encrypted message, you need to use the recipient's public key in combination with your private key. Evolution handles the encryption, but you need to get the public key and add it to your keyring. To get public keys from a public key server, enter the command gpg --recv-keys --keyserver wwwkeys.pgp.net keyid, substituting keyid for your recipient's ID. You need to enter your password, and the ID is automatically added to your keyring. If someone sends you a public key directly, save it as a plain text file and enter the command gpg --filename to add it to your keyring. But got the error when I did that............Please help Evolution use PGP (output we got) annamalaiv at migrate:~> gpg --keyserver itnt2.il.nds.com --recv-keys 0xBA928817 gpg: requesting key BA928817 from hkp server itnt2.il.nds.com ?: itnt2.il.nds.com: Connection refused gpgkeys: HKP fetch error: Connection refused gpg: no valid OpenPGP data found. gpg: Total number processed: 0 annamalaiv at migrate:~> Please advice. Thanking you Regards Rajababu.G.R From james.juran at baesystems.com Fri Apr 20 21:46:24 2007 From: james.juran at baesystems.com (Juran, James (US SSA)) Date: Fri, 20 Apr 2007 15:46:24 -0400 Subject: got_fatal_signal() fix for no sys_siglist Message-ID: <1177098384.22535.34.camel@juran.digitalnet.com> On systems without sys_siglist, got_fatal_signal() will try to convert the signal number to a printable string. This works, but it leaves the variable sig modified, so that when the signal is re-raised it ends up raising signal 0, which doesn't have the intended effect of ending the process. Using a different variable to do the conversion fixes this problem. I don't have an svn account, so if this is OK could someone please commit it? Please let me know if there's anything else I need to do. Index: signal.c =================================================================== --- signal.c (revision 1942) +++ signal.c (working copy) @@ -114,16 +114,16 @@ got_fatal_signal (int sig) write (2, "?", 1); else { - int i, any=0; + int i, any=0, tsig=sig; for (i=10000; i; i /= 10) { - if (sig >= i || ((any || i==1) && !(sig/i))) + if (tsig >= i || ((any || i==1) && !(tsig/i))) { - write (2, "0123456789"+(sig/i), 1); - if ((sig/i)) + write (2, "0123456789"+(tsig/i), 1); + if ((tsig/i)) any = 1; - sig %= i; + tsig %= i; } } } -- James Juran Senior Secure Systems Analyst BAE Systems Information Technology Information Assurance Group XTS Operating Systems james.juran at baesystems.com +1 703-563-8081 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/attachments/20070420/9639acd9/attachment.pgp From M_Hoeller at gmx.de Sat Apr 21 23:51:49 2007 From: M_Hoeller at gmx.de (Michael Hoeller) Date: Sat, 21 Apr 2007 23:51:49 +0200 Subject: Is this possible ?? Message-ID: <200704212351.57258.M_Hoeller@gmx.de> Hello experts, here I hava a real live problem which I hope someone of the experts on this list can explain.. The probelm is that I recieve from various people encrypted mails which useed RC2 as algorithm... Here the szenario; Person A uses Thunderbird Person B uses KMail The Problem is that Person B (KMail) can not read encrypted S/MIME Messages from person A (Thunderbird). The assumption is that KMail from person B sends with every mail to person A some kind of informtaion which maks Thunderbird think that it should encrypt with the RC2 algo. Therefore person A deletes the public cert from B and imports this manualy again. Person B did send the cert as PEM to person A, And... voila Thunderbird from person A uses 3DES. Person B writes back. Person A answers and :-(( it does not work the used Algo is RC2. ==> Is it possible that KMAIL/gpgsm sends or stores some information in the mail which leads to the fact that Thunderbird sends RC2 ???? Thanks a lot for any hint Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1954 bytes Desc: not available Url : /pipermail/attachments/20070421/a7c91ef3/attachment.bin From marcus.brinkmann at ruhr-uni-bochum.de Mon Apr 23 15:36:48 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 23 Apr 2007 15:36:48 +0200 Subject: help on gpgme In-Reply-To: References: Message-ID: <87bqhfxle7.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 23 Apr 2007 11:32:29 +0530 (IST), "S.Thanga Prakash" wrote: > > hi all, > > I am using gpgme.0.3.14 and gpg.1.2.0. > > when i use gpgme_op_verify(), status was set to GPGME_SIG_STAT_NONE. > > When i retry once again, it is succeeds. > > Please, direct me to solve this issue. Is it possible for you to use newer versions of these tools? The software you are using is over 4 years old, and many bugs have been fixed in the meanwhile. For security reasons alone you should update. Thanks, Marcus From gdt at ir.bbn.com Mon Apr 23 14:01:19 2007 From: gdt at ir.bbn.com (Greg Troxel) Date: Mon, 23 Apr 2007 08:01:19 -0400 Subject: Is this possible ?? In-Reply-To: <200704221509.16914.M_Hoeller@nurfuerspam.de> (M. Hoeller's message of "Sun\, 22 Apr 2007 15\:09\:16 +0200") References: <200704220842.57504.M_Hoeller@nurfuerspam.de> <878xckhcrq.fsf@wheatstone.g10code.de> <200704221509.16914.M_Hoeller@nurfuerspam.de> Message-ID: M Hoeller writes: > Hello Werner, > > I am, in some kind, happy to here this. But what could be the reason that > the manual imported certificate works fine, as longs as no other signed > mail was recieved? > Can you, or the other experts (sorry don't want to be rude when I address > this to Werner) difintely exclude that KMail/gpgsm is the source of the > problem that Thunderbird sends RC2 encrypted mails back? This is really a problem which needs to be debugged in Thunderbird. First, thunderbird probably should not even have RC2 support, and second it should only use it as a last resort. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : /pipermail/attachments/20070423/96340994/attachment.pgp From thanga at midascomm.com Mon Apr 23 16:09:49 2007 From: thanga at midascomm.com (S.Thanga Prakash) Date: Mon, 23 Apr 2007 19:39:49 +0530 (IST) Subject: help on gpgme In-Reply-To: <87bqhfxle7.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: dear sir, how to get stable versions of gpg and gpgme? I will update it for new system. For existing systems, i need to fix it. whether updating latest gpgme, solve the issue? Please, guide me for the same. regards, stp. On Mon, 23 Apr 2007, Marcus Brinkmann wrote: > At Mon, 23 Apr 2007 11:32:29 +0530 (IST), > "S.Thanga Prakash" wrote: > > > > hi all, > > > > I am using gpgme.0.3.14 and gpg.1.2.0. > > > > when i use gpgme_op_verify(), status was set to GPGME_SIG_STAT_NONE. > > > > When i retry once again, it is succeeds. > > > > Please, direct me to solve this issue. > > Is it possible for you to use newer versions of these tools? The > software you are using is over 4 years old, and many bugs have been > fixed in the meanwhile. For security reasons alone you should update. > > Thanks, > Marcus > From marcus.brinkmann at ruhr-uni-bochum.de Mon Apr 23 16:21:23 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 23 Apr 2007 16:21:23 +0200 Subject: help on gpgme In-Reply-To: References: <87bqhfxle7.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <87abwzxjbw.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 23 Apr 2007 19:39:49 +0530 (IST), "S.Thanga Prakash" wrote: > > dear sir, > > how to get stable versions of gpg and gpgme? > I will update it for new system. http://www.gnupg.org/(en)/download/index.html > For existing systems, i need to fix it. > whether updating latest gpgme, solve the issue? > > Please, guide me for the same. We don't even know what the problem is, so I can't tell. It could be anything from a bug in GPG to GPGME or your application. Thanks, Marcus From patrick at mozilla-enigmail.org Tue Apr 24 11:46:01 2007 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Tue, 24 Apr 2007 11:46:01 +0200 Subject: Is this possible ?? In-Reply-To: References: <200704220842.57504.M_Hoeller@nurfuerspam.de> <878xckhcrq.fsf@wheatstone.g10code.de> <200704221509.16914.M_Hoeller@nurfuerspam.de> Message-ID: <462DD1D9.1050201@mozilla-enigmail.org> Greg Troxel wrote: > M Hoeller writes: > >> Hello Werner, >> >> I am, in some kind, happy to here this. But what could be the reason that >> the manual imported certificate works fine, as longs as no other signed >> mail was recieved? >> Can you, or the other experts (sorry don't want to be rude when I address >> this to Werner) difintely exclude that KMail/gpgsm is the source of the >> problem that Thunderbird sends RC2 encrypted mails back? > > This is really a problem which needs to be debugged in Thunderbird. > First, thunderbird probably should not even have RC2 support, and second > it should only use it as a last resort. Any RC2 algorithms, as well as any support for SSL2 are disabled by default in Thunderbird, since they are no longer considered secure. To enable RC2, you have to set the following preferences to true (I don't know which one would actually be used for S/MIME): security.ssl2.rc2_128 security.ssl2.rc2_40 security.ssl3.rsa_rc2_40_md5 You might also set the following parameter to true: security.enable_ssl2 -Patrick From wk at gnupg.org Tue Apr 24 11:32:41 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Apr 2007 11:32:41 +0200 Subject: Scute: feature request: Support CKA_TRUSTED attribute on X.509 certs In-Reply-To: <87ps5v1lir.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon\, 23 Apr 2007 11\:35\:08 +0200") References: <87r6qc63a7.fsf@mocca.josefsson.org> <87wt04f673.fsf@wheatstone.g10code.de> <87ps5v1lir.fsf@mocca.josefsson.org> Message-ID: <87hcr6azie.fsf@wheatstone.g10code.de> On Mon, 23 Apr 2007 11:35, simon at josefsson.org said: > Thanks. Btw, do you know what the best way to find out which > certificate correspond to a private key? Using the key id seems > somewhat fragile, but it is what I'll use unless I learn of a better > way. GnuPG uses a thing called keygrip unsigned char *gcry_pk_get_keygrip (gcry_sexp_t key, unsigned char *array) Return the so called "keygrip" which is the SHA-1 hash of the public key parameters expressed in a way depended on the algorithm. @var{array} must either provide space for 20 bytes or be @code{NULL}. In the latter case a newly allocated array of that size is returned. On success a pointer to the newly allocated space or to @var{array} is returned. @code{NULL} is returned to indicate an error which is most likely an unknown algorithm or one where a "keygrip" has not yet been defined. The function accepts public or secret keys in @var{key}. This might return more than one certificate in case a CA has reissued a one. With gpgsm you can select keys based on there keygrip using gpgsm -k '&1122334455667788990011223344556677889900' The ampersand indicates a keygrip. Needs to be implemented for gpg2, though. Shalom-Salam, Werner From christoph.wintersteiger at inf.ethz.ch Thu Apr 26 11:34:13 2007 From: christoph.wintersteiger at inf.ethz.ch (Christoph M. Wintersteiger) Date: Thu, 26 Apr 2007 11:34:13 +0200 Subject: Bug Report: Client DOS in g10 keyserver search Message-ID: <1177580053.18186.12.camel@localhost.localdomain> At least versions 1.4.4, 1.4.7 and 2.0.3 of GnuPG allow malicious keyservers to crash a client when searching for keys. The bug is due to an incorrect implementation of trailing whitespace removal from a keyservers response. The bug can be found in g10/keyserver.c at line 1410 (version 1.4.4) line 1415 (version 1.4.7) line 1424 (version 2.0.3), which reads plen[ptr]='\0'; Obviously the two variables have been reversed and the line should be corrected to ptr[plen]='\0'; At least versions 2.95, 3.2.3 and 4.1.2 of GCC do not warn when casting the unsigned to a pointer and the pointer to an index. Regards, CM Wintersteiger From simon at josefsson.org Thu Apr 26 13:15:08 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 26 Apr 2007 13:15:08 +0200 Subject: Bug Report: Client DOS in g10 keyserver search In-Reply-To: <1177580053.18186.12.camel@localhost.localdomain> (Christoph M. Wintersteiger's message of "Thu\, 26 Apr 2007 11\:34\:13 +0200") References: <1177580053.18186.12.camel@localhost.localdomain> Message-ID: <87lkgf4car.fsf@mocca.josefsson.org> "Christoph M. Wintersteiger" writes: > At least versions 1.4.4, 1.4.7 and 2.0.3 of GnuPG allow malicious > keyservers to crash a client when searching for keys. The bug is due to > an incorrect implementation of trailing whitespace removal from a > keyservers response. > > The bug can be found in g10/keyserver.c at > line 1410 (version 1.4.4) > line 1415 (version 1.4.7) > line 1424 (version 2.0.3), > which reads > plen[ptr]='\0'; > > Obviously the two variables have been reversed and the line should be > corrected to > ptr[plen]='\0'; I thought those two statements were equivalent in C. Can you trigger the bug in practice? /Simon From wk at gnupg.org Thu Apr 26 13:34:06 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Apr 2007 13:34:06 +0200 Subject: Bug Report: Client DOS in g10 keyserver search In-Reply-To: <87lkgf4car.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Thu\, 26 Apr 2007 13\:15\:08 +0200") References: <1177580053.18186.12.camel@localhost.localdomain> <87lkgf4car.fsf@mocca.josefsson.org> Message-ID: <87tzv31ia9.fsf@wheatstone.g10code.de> On Thu, 26 Apr 2007 13:15, simon at josefsson.org said: >> Obviously the two variables have been reversed and the line should be >> corrected to >> ptr[plen]='\0'; > > I thought those two statements were equivalent in C. Exactly, all the following expressions are equivalent. plen[ptr] *(plen + ptr) *(ptr + plen) ptr[plen] Maybe David did this as a test to see how long it would take that someone stumbled on it and wondered about this geeky code: Close to 5 years. ;-) Shalom-Salam, Werner From dshaw at jabberwocky.com Thu Apr 26 13:40:42 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 26 Apr 2007 07:40:42 -0400 Subject: Bug Report: Client DOS in g10 keyserver search In-Reply-To: <1177580053.18186.12.camel@localhost.localdomain> References: <1177580053.18186.12.camel@localhost.localdomain> Message-ID: <20070426114042.GA3357@jabberwocky.com> On Thu, Apr 26, 2007 at 11:34:13AM +0200, Christoph M. Wintersteiger wrote: > > At least versions 1.4.4, 1.4.7 and 2.0.3 of GnuPG allow malicious > keyservers to crash a client when searching for keys. The bug is due to > an incorrect implementation of trailing whitespace removal from a > keyservers response. > > The bug can be found in g10/keyserver.c at > line 1410 (version 1.4.4) > line 1415 (version 1.4.7) > line 1424 (version 2.0.3), > which reads > plen[ptr]='\0'; > > Obviously the two variables have been reversed and the line should be > corrected to > ptr[plen]='\0'; Yes, this is incorrect, and I'll fix it. It's a readability bug, though, and not a code bug. Were you able to actually get the client to crash? If so, I suspect it was for other reasons. As Simon points out, 'plen[ptr]' is identical to 'ptr[plen]' in C. http://c-faq.com/aryptr/joke.html David From marcus.brinkmann at ruhr-uni-bochum.de Mon Apr 30 01:09:05 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 30 Apr 2007 01:09:05 +0200 Subject: eccGnuPG In-Reply-To: <87fy7ptv8u.fsf@mocca.josefsson.org> References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> <87tzweqxlm.fsf@wheatstone.g10code.de> <87mz25mef5.fsf@wheatstone.g10code.de> <87d52t7km5.fsf@wheatstone.g10code.de> <87fy7ptv8u.fsf@mocca.josefsson.org> Message-ID: <874pmy3him.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Wed, 28 Mar 2007 14:20:33 +0200, Simon Josefsson wrote: > > I get failures for the 512 bit ECDSA signatures sometimes: > > jas at mocca:~/src/libgcrypt$ tests/benchmark ecc > Algorithm generate 100*sign 100*verify > ---------------------------------------------- > ECDSA 192 bit 20ms 450ms 830ms > ECDSA 224 bit 20ms 580ms 1040ms > ECDSA 256 bit 30ms 720ms 1300ms > ECDSA 384 bit 60ms 1620ms 3180ms > ECDSA 521 bit 170ms 4030ms > benchmark: verify failed: Bad signature > jas at mocca:~/src/libgcrypt$ > > It seems to fail about 25 % of the time or so. Can you reproduce > this? And Werner Koch writes: > Yes. I realized that too late. It happens with all key sizes. Not > sure whetehr I will be abale to debug it today. I spend a bit too > much time on ecc recently ;-) And sbt at megacceso.com said: > Every times that this appears when I am testing with gdb, the verification > broke the normal flow because (x!=r) in the ecc.c:658 comparison. I checking > out if the problem was in the signature process, and I thing not. IMHO I > think the problem could be in the coordinates conversion from projective to > affine. I fixed this now. The problem was indeed related to conversion from projective to affine, but very superficial: If the affine y coordinate used less bytes in their bit representation than the prime number, then the memmove in ec2os would overwrite the y coordinate by some shifted version of the x coordinate. Fixed in revision 1237: 2007-04-30 Marcus Brinkmann * ecc.c (ec2os): Fix relocation of short numbers. I also fixed a bunch of memory leaks. Thanks, Marcus _______________________________________________ Gnupg-devel mailing list Gnupg-devel at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-devel From gnupg-devel at mlists.thewrittenword.com Mon Apr 30 23:47:30 2007 From: gnupg-devel at mlists.thewrittenword.com (Peter O'Gorman) Date: Mon, 30 Apr 2007 16:47:30 -0500 Subject: small patches for libksba-1.0.1 and libassuan-1.0.1 Message-ID: <20070430214730.GO8893@localhost.localdomain> Hi, We had to patch libksba to get it to build on hpux and aix4.3 with the native compilers. ksba On AIX-4.3, xlc complains if enums end in a comma. HPUX does not like doing pointer math with void* pointers. assuan We need to define _XOPEN_SOURCE etc for irix and Tru64. There was another pointer math issue, and Tru64 4.0D does not have snprintf, rather than using trio or another replacement, I just used sprintf and made sure that the result would be small enough. Thanks, Peter -------------- next part -------------- Index: src/crl.c =================================================================== --- src/crl.c.orig 2006-08-31 07:57:24.000000000 +0000 +++ src/crl.c 2007-04-30 16:12:29.791318000 +0000 @@ -59,7 +59,7 @@ crl->hashbuf.buffer, crl->hashbuf.used); crl->hashbuf.used = 0; } - buffer += n; + buffer = (char*)buffer + n; length -= n; } } Index: src/ksba.h =================================================================== --- src/ksba.h.orig 2006-08-31 14:57:54.000000000 +0000 +++ src/ksba.h 2007-04-30 16:17:32.723334000 +0000 @@ -78,7 +78,7 @@ KSBA_SR_DETACHED_DATA = 8, KSBA_SR_BEGIN_ITEMS = 9, KSBA_SR_GOT_ITEM = 10, - KSBA_SR_END_ITEMS = 11, + KSBA_SR_END_ITEMS = 11 } ksba_stop_reason_t; typedef ksba_stop_reason_t KsbaStopReason _KSBA_DEPRECATED; Index: src/asn1-parse.y =================================================================== --- src/asn1-parse.y.orig 2006-06-20 06:40:10.000000000 +0000 +++ src/asn1-parse.y 2007-04-30 16:23:35.351631000 +0000 @@ -54,7 +54,7 @@ /* constants used in the grammar */ enum { CONST_EXPLICIT = 1, - CONST_IMPLICIT, + CONST_IMPLICIT }; struct parser_control_s { -------------- next part -------------- Index: configure.ac =================================================================== --- configure.ac.orig 2007-04-30 21:07:54.924432000 +0000 +++ configure.ac 2007-04-30 21:07:58.936707000 +0000 @@ -98,7 +95,7 @@ have_dosish_system=yes have_w32_system=yes ;; - *-solaris*) + *-solaris*|*-irix*|*-osf*) AC_DEFINE(_XOPEN_SOURCE, 500, Activate extensions on Solaris) AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, Activate extensions on Solaris) AC_DEFINE(__EXTENSIONS__, 1, Activate extensions on Solaris) @@ -192,7 +189,7 @@ # Checks for library functions. -AC_CHECK_FUNCS(flockfile funlockfile) +AC_CHECK_FUNCS(flockfile funlockfile snprintf) # Check for funopen AC_CHECK_FUNCS(funopen) Index: src/assuan-uds.c =================================================================== --- src/assuan-uds.c.orig 2007-04-30 21:07:54.972677000 +0000 +++ src/assuan-uds.c 2007-04-30 21:11:25.044447000 +0000 @@ -150,7 +150,7 @@ if (len > buflen) /* We have more than the user requested. */ len = buflen; - memcpy (buf, ctx->uds.buffer + ctx->uds.bufferoffset, len); + memcpy (buf, (char*)ctx->uds.buffer + ctx->uds.bufferoffset, len); ctx->uds.buffersize -= len; assert (ctx->uds.buffersize >= 0); ctx->uds.bufferoffset += len; @@ -206,7 +206,12 @@ /* We need to send some real data so that a read won't return 0 which will be taken as an EOF. It also helps with debugging. */ +#if HAVE_SNPRINTF snprintf (buffer, sizeof(buffer)-1, "# descriptor %d is in flight\n", fd); +#else + /* The following can not exceed 79 chars, even if fd is ULLONG_MAX */ + sprintf(buffer,"# descriptor %d is in flight\n", fd); +#endif buffer[sizeof(buffer)-1] = 0; memset (&msg, 0, sizeof (msg)); Index: src/assuan-pipe-connect.c =================================================================== --- src/assuan-pipe-connect.c.orig 2007-04-30 21:07:54.996791000 +0000 +++ src/assuan-pipe-connect.c 2007-04-30 21:26:09.018369000 +0000 @@ -338,10 +338,20 @@ execv (name, (char *const *) argv); /* oops - use the pipe to tell the parent about it */ +#if HAVE_SNPRINTF snprintf (errbuf, sizeof(errbuf)-1, "ERR %d can't exec `%s': %.50s\n", _assuan_error (ASSUAN_Problem_Starting_Server), name, strerror (errno)); +#else + /* errbuf is 512 bytes, the maximum length of the following + * string must be < 511, in reality, it will always be + * less than 128 bytes */ + sprintf (errbuf, + "ERR %d can't exec `%.50s': %.50s\n", + _assuan_error (ASSUAN_Problem_Starting_Server), + name, strerror (errno)); +#endif errbuf[sizeof(errbuf)-1] = 0; writen (1, errbuf, strlen (errbuf)); _exit (4); @@ -520,10 +530,20 @@ execv (name, (char *const *) argv); /* oops - use the pipe to tell the parent about it */ +#if HAVE_SNPRINTF snprintf (errbuf, sizeof(errbuf)-1, "ERR %d can't exec `%s': %.50s\n", _assuan_error (ASSUAN_Problem_Starting_Server), name, strerror (errno)); +#else + /* errbuf is 512 bytes, the maximum length of the following + * string must be < 511, in reality, it will always be + * less than 128 bytes */ + sprintf (errbuf, + "ERR %d can't exec `%.50s': %.50s\n", + _assuan_error (ASSUAN_Problem_Starting_Server), + name, strerror (errno)); +#endif errbuf[sizeof(errbuf)-1] = 0; writen (fds[1], errbuf, strlen (errbuf)); _exit (4);