From kazu at iij.ad.jp Thu Jan 4 06:25:35 2007 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 04 Jan 2007 14:25:35 +0900 (JST) Subject: request for certificate extension Message-ID: <20070104.142535.91804127.kazu@iij.ad.jp> Hello, DoCoMo, the biggest cellular phone company in Japan, send messages signed with S/MIME to users. If we verify a signature of a message from DoCoMo, the verification process fails and the following warning message is displayed. ---- gpgsm: Signature made 2006-12-22 13:47:37 using certificate ID 64C04082 gpgsm: critical certificate extension 2.5.29.17 is not supported gpgsm: invalid certification chain: Unsupported certificate ---- I don't know this well, but I found the following in RFC3280: ---- 341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) ---- If possible, I would request to support this extension. --Kazu From kazu at iij.ad.jp Thu Jan 4 06:18:47 2007 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 04 Jan 2007 14:18:47 +0900 (JST) Subject: Compiling GnuPG 2.0.1 on MacOS X Message-ID: <20070104.141847.12788317.kazu@iij.ad.jp> This is just for your information. I have compiled GnuPG 2.0.1 on MacOS X (10.4.8) by hand. Most libraries are fine. But the following steps were required: 1) libgcrypt-1.2.3 The --disable-asm option is required for configure. Without this, "gpg" cannot pass "make check". 2) gnupg-2.0.1 The following patch must be applied. --Kazu *** tools/Makefile.in-dist Thu Dec 28 23:21:47 2006 --- tools/Makefile.in Thu Dec 28 23:29:12 2006 *************** *** 453,459 **** @BUILD_SYMCRYPTRUN_TRUE at symcryptrun = symcryptrun common_libs = ../jnlib/libjnlib.a ../common/libcommon.a ../gl/libgnu.a pwquery_libs = ../common/libsimple-pwquery.a ! gpgsplit_LDADD = $(common_libs) $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) $(ZLIBS) gpgconf_SOURCES = gpgconf.c gpgconf.h gpgconf-comp.c no-libgcrypt.c # jnlib/common sucks in gpg-error, will they, nil they (some compilers --- 453,459 ---- @BUILD_SYMCRYPTRUN_TRUE at symcryptrun = symcryptrun common_libs = ../jnlib/libjnlib.a ../common/libcommon.a ../gl/libgnu.a pwquery_libs = ../common/libsimple-pwquery.a ! gpgsplit_LDADD = $(common_libs) $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) $(ZLIBS) $(LIBICONV) $(LIBINTL) gpgconf_SOURCES = gpgconf.c gpgconf.h gpgconf-comp.c no-libgcrypt.c # jnlib/common sucks in gpg-error, will they, nil they (some compilers From michael at vorlon.ping.de Thu Jan 4 21:12:11 2007 From: michael at vorlon.ping.de (Michael Bienia) Date: Thu, 4 Jan 2007 21:12:11 +0100 Subject: GnuPG 2.0 and RIPEMD160 signatures with gpg-agent and an OpenPGP card In-Reply-To: <20061222213429.GA9526@vorlon.ping.de> References: <20061222213429.GA9526@vorlon.ping.de> Message-ID: <20070104201211.GA20389@vorlon.ping.de> On 2006-12-22 22:34:29 +0100, Michael Bienia wrote: > GnuPG 2.0 can only generate SHA1 signatures when used with gpg-agent and > an OpenPGP card. I've already had the same problem with GnuPG 1.4 in > March 2006 [1]. It was fixed with svn commits 4075 and 4076. Here is a patch for it. Michael --- gnupg2-2.0.1.orig/g10/call-agent.c +++ gnupg2-2.0.1/g10/call-agent.c @@ -668,7 +668,9 @@ snprintf (line, DIM(line)-1, "SCD PKAUTH %s", serialno); else #endif - snprintf (line, DIM(line)-1, "SCD PKSIGN %s", serialno); + snprintf (line, DIM(line)-1, "SCD PKSIGN %s%s", + hashalgo == GCRY_MD_RMD160? "--hash=rmd160 ": "", + serialno); line[DIM(line)-1] = 0; rc = assuan_transact (agent_ctx, line, membuf_data_cb, &data, NULL, NULL, NULL, NULL); From dshaw at jabberwocky.com Fri Jan 5 04:28:36 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 4 Jan 2007 22:28:36 -0500 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <20070104.141847.12788317.kazu@iij.ad.jp> References: <20070104.141847.12788317.kazu@iij.ad.jp> Message-ID: <20070105032836.GB19817@jabberwocky.com> On Thu, Jan 04, 2007 at 02:18:47PM +0900, Kazu Yamamoto wrote: > This is just for your information. > > I have compiled GnuPG 2.0.1 on MacOS X (10.4.8) by hand. > Most libraries are fine. But the following steps were > required: > > 1) libgcrypt-1.2.3 > > The --disable-asm option is required for configure. > Without this, "gpg" cannot pass "make check". Kazu, can you clarify if you are building on an Intel or PowerPC Mac here? > 2) gnupg-2.0.1 > > The following patch must be applied. Thanks, this (and a few other places with the same problem) was fixed in SVN. It will be part of 2.0.2. David From kazu at iij.ad.jp Fri Jan 5 04:33:15 2007 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Fri, 05 Jan 2007 12:33:15 +0900 (JST) Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <20070105032836.GB19817@jabberwocky.com> References: <20070104.141847.12788317.kazu@iij.ad.jp> <20070105032836.GB19817@jabberwocky.com> Message-ID: <20070105.123315.66881450.kazu@iij.ad.jp> Hello, > > 1) libgcrypt-1.2.3 > > > > The --disable-asm option is required for configure. > > Without this, "gpg" cannot pass "make check". > > Kazu, can you clarify if you are building on an Intel or PowerPC Mac > here? My Mac is Intel. --Kazu From wk at gnupg.org Fri Jan 5 12:10:38 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Jan 2007 12:10:38 +0100 Subject: request for certificate extension In-Reply-To: <20070104.142535.91804127.kazu@iij.ad.jp> (Kazu Yamamoto's message of "Thu\, 04 Jan 2007 14\:25\:35 +0900 \(JST\)") References: <20070104.142535.91804127.kazu@iij.ad.jp> Message-ID: <87hcv5pw41.fsf@wheatstone.g10code.de> On Thu, 4 Jan 2007 06:25, kazu at iij.ad.jp said: > ---- > gpgsm: Signature made 2006-12-22 13:47:37 using certificate ID 64C04082 > gpgsm: critical certificate extension 2.5.29.17 is not supported > gpgsm: invalid certification chain: Unsupported certificate > ---- Never seen the subjectAltName marked as critical. Of course we support it. If it is possible, I'd appreciate to get such a certificate by PM for use with the regression tests. Patch below. Shalom-Salam, Werner --- sm/certchain.c (revision 4389) +++ sm/certchain.c (working copy) @@ -137,6 +137,12 @@ { static const char *known[] = { "2.5.29.15", /* keyUsage */ + "2.5.29.17", /* subjectAltName + Japanese DoCoMo certs mark them as critical. PKIX + only requires them as critical if subjectName is + empty. I don't know whether our code gracefully + handles such empry subjectNames but that is + another story. */ "2.5.29.19", /* basic Constraints */ "2.5.29.32", /* certificatePolicies */ "2.5.29.37", /* extendedKeyUsage - handled by certlist.c */ From kristian.fiskerstrand at kfwebs.net Fri Jan 5 18:17:23 2007 From: kristian.fiskerstrand at kfwebs.net (Kristian Fiskerstrand) Date: Fri, 05 Jan 2007 18:17:23 +0100 Subject: Secret key storage Message-ID: <459E8823.1090509@kfwebs.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Greetings, While trying to add backwards compatibility to PGP 2.0 for GnuPG 2.0, I'm beginning to bang my head against a wall. Some of the discussion can be found at http://bugs.gentoo.org/show_bug.cgi?id=159870 , but trying to sum things up, the effort so far only works whenever the secret key is not password protected (and hence encrypted). I tried to manually set the s2k cipher algo to CAST5 using gnupg 1.4.6 to be sure that wasn't the problem itself, but that didn't result in any change. The key has the following attributes: Old: Secret Key Packet(tag 5)(492 bytes) Ver 3 - old Public key creation time - Fri Jan 5 00:55:53 CET 2007 Valid days - 0[0 is forever] Pub alg - RSA Encrypt or Sign(pub 1) RSA n(1024 bits) - ... RSA e(5 bits) - ... Sym alg - CAST5(sym 3).. Is there any obvious reason why an RSAv3 key would only work when not being password protected, that I'm overlooking? Your's sincerely - -- - ---------------------------- Kristian Fiskerstrand kristian.fiskerstrand at kfwebs.net 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 - ---------------------------- Public PGP key 0x6B0B9508 at http://www.kfwebs.net/pgp/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRZ6IIhbgz41rC5UIAQj26g//V8bodXlfeVGVlZW6Bde4wddms6o6jxy5 p8wcHtP/VeoYgO5rZ5RedG6yXhirOACgYs5XzVyRW0dJwTjovehsHYZ8ujoNMIt+ fCi/+F0S/ikARhnklAXAuwGfdodi0jZjFWyS1+aCqXclIkUDeRxagg8C+EUZAEMP xlCDy9yBEebpLkF9aptT/IqLXqC2FWrSWRc0MbSBJTcyiGMIc5Rr4g871JgfTKo/ oDbX4+7C/XOVMCzYUNfwiqRAJLjycouEuYjFlyDeP8cDG9HyWrCdN/ll+JlVePuW W42naKDpjxRJegnaXQIuC4o35Cukub7hymgHonJawkg+do5bJ8/zpfIJsjliCPSk qHHU0VMO3V+e7smNmMXFbKUjbBhcY4tqKgwG9vrxPjvnwsPHAyy5rXhys+QIH5y5 K1ZDBT9iu9IH242NtOZDRj3nJ0fYrJ8Czc35JxUmXZsc2MoaEQIYbXiA22gOAp3p S6d5qfSuEea1NfpYLhPtw2yB6bGoGUENrKYSsdpcpJGqnTrmJMx3MxR9UzmE3W7N JtsNAEq45qygRVsXV9NAm2TkhaXFvRvhP2YqFnVQ4eD4FWtI17JMwPWBRPsqm2On E4O0DpS56NyeyBC+1RoXLBEW1XU5IDEYOa4RXOvJe4+M1DEQf69KRJbKxfUupSSU JK6kIFoa8Ts= =mP45 -----END PGP SIGNATURE----- From robbat2 at gentoo.org Fri Jan 5 20:43:02 2007 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Fri, 5 Jan 2007 11:43:02 -0800 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <20070104.141847.12788317.kazu@iij.ad.jp> References: <20070104.141847.12788317.kazu@iij.ad.jp> Message-ID: <20070105194302.GH1278@curie-int.orbis-terrarum.net> On Thu, Jan 04, 2007 at 02:18:47PM +0900, Kazu Yamamoto wrote: > 2) gnupg-2.0.1 > The following patch must be applied. Independently of Kazu, some of our more obscure Gentoo users noted build problems on Gentoo/OSX and Gentoo/FreeBSD. Same issue that Kazu noted, just in a few more spots. Attached is a patch that corrects all of them. -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robbat2 at gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -------------- next part -------------- Signed-off-by: Robin H. Johnson Date: Fri Jan 5 11:30:30 PST 2007 This patch adds LIBICONV wherever LIBINTL is used. This is needed for compiles on Gentoo/OSX and Gentoo/BSD. There are two cases (t-convert, gpgsplit) where neither LIBINTL nor LIBICONV were brought in before, and I added them as well. It might be overkill. diff -Nuar --exclude '*~' gnupg-2.0.1.orig/agent/Makefile.am gnupg-2.0.1/agent/Makefile.am --- gnupg-2.0.1.orig/agent/Makefile.am 2006-10-20 07:07:09.000000000 -0700 +++ gnupg-2.0.1/agent/Makefile.am 2007-01-05 11:28:29.000000000 -0800 @@ -53,7 +53,7 @@ gpg_agent_CFLAGS = $(AM_CFLAGS) $(LIBASSUAN_PTH_CFLAGS) $(PTH_CFLAGS) gpg_agent_LDADD = $(commonpth_libs) \ $(LIBGCRYPT_LIBS) $(LIBASSUAN_PTH_LIBS) $(PTH_LIBS) \ - $(GPG_ERROR_LIBS) $(LIBINTL) $(NETLIBS) + $(GPG_ERROR_LIBS) $(LIBICONV) $(LIBINTL) $(NETLIBS) gpg_protect_tool_SOURCES = \ protect-tool.c \ @@ -62,14 +62,14 @@ # Needs $(NETLIBS) for libsimple-pwquery.la. gpg_protect_tool_LDADD = $(pwquery_libs) $(common_libs) \ - $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) $(LIBINTL) $(NETLIBS) + $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) $(LIBICONV) $(LIBINTL) $(NETLIBS) gpg_preset_passphrase_SOURCES = \ preset-passphrase.c # Needs $(NETLIBS) for libsimple-pwquery.la. gpg_preset_passphrase_LDADD = $(pwquery_libs) $(common_libs) \ - $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) $(LIBINTL) $(NETLIBS) + $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) $(LIBICONV) $(LIBINTL) $(NETLIBS) # Make sure that all libs are build before we use them. This is @@ -83,7 +83,7 @@ TESTS = t-protect t_common_ldadd = $(common_libs) \ - $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) $(LIBINTL) + $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) $(LIBICONV) $(LIBINTL) t_protect_SOURCES = t-protect.c protect.c t_protect_LDADD = $(t_common_ldadd) diff -Nuar --exclude '*~' gnupg-2.0.1.orig/common/Makefile.am gnupg-2.0.1/common/Makefile.am --- gnupg-2.0.1.orig/common/Makefile.am 2006-11-05 06:32:09.000000000 -0800 +++ gnupg-2.0.1/common/Makefile.am 2007-01-05 11:29:09.000000000 -0800 @@ -79,7 +79,7 @@ module_tests = t-convert t_common_ldadd = ../jnlib/libjnlib.a ../common/libcommon.a ../gl/libgnu.a \ - $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) + $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) $(LIBICONV) $(LIBINTL) t_convert_DEPENDENCIES = convert.c libcommon.a t_convert_LDADD = $(t_common_ldadd) diff -Nuar --exclude '*~' gnupg-2.0.1.orig/g10/Makefile.am gnupg-2.0.1/g10/Makefile.am --- gnupg-2.0.1.orig/g10/Makefile.am 2006-11-21 06:49:41.000000000 -0800 +++ gnupg-2.0.1/g10/Makefile.am 2007-01-05 11:27:06.000000000 -0800 @@ -117,7 +117,7 @@ LDADD = $(needed_libs) ../common/libgpgrl.a \ $(ZLIBS) $(DNSLIBS) $(LIBREADLINE) \ - $(LIBINTL) $(CAPLIBS) $(NETLIBS) + $(LIBICONV) $(LIBINTL) $(CAPLIBS) $(NETLIBS) gpg2_LDADD = $(LIBGCRYPT_LIBS) $(LDADD) $(LIBASSUAN_LIBS) $(GPG_ERROR_LIBS) gpgv2_LDADD = $(LIBGCRYPT_LIBS) $(LDADD) $(LIBASSUAN_LIBS) $(GPG_ERROR_LIBS) diff -Nuar --exclude '*~' gnupg-2.0.1.orig/kbx/Makefile.am gnupg-2.0.1/kbx/Makefile.am --- gnupg-2.0.1.orig/kbx/Makefile.am 2006-09-20 02:35:52.000000000 -0700 +++ gnupg-2.0.1/kbx/Makefile.am 2007-01-05 11:24:46.000000000 -0800 @@ -48,6 +48,6 @@ kbxutil_SOURCES = kbxutil.c $(common_sources) kbxutil_LDADD = ../jnlib/libjnlib.a ../gl/libgnu.a \ $(KSBA_LIBS) $(LIBGCRYPT_LIBS) \ - -lgpg-error $(LIBINTL) ../common/libcommon.a + -lgpg-error $(LIBICONV) $(LIBINTL) ../common/libcommon.a $(PROGRAMS) : ../jnlib/libjnlib.a ../gl/libgnu.a ../common/libcommon.a diff -Nuar --exclude '*~' gnupg-2.0.1.orig/scd/Makefile.am gnupg-2.0.1/scd/Makefile.am --- gnupg-2.0.1.orig/scd/Makefile.am 2006-11-21 01:38:26.000000000 -0800 +++ gnupg-2.0.1/scd/Makefile.am 2007-01-05 11:27:24.000000000 -0800 @@ -46,7 +46,7 @@ scdaemon_LDADD = ../jnlib/libjnlib.a ../common/libcommonpth.a ../gl/libgnu.a \ $(LIBGCRYPT_LIBS) $(KSBA_LIBS) $(LIBASSUAN_PTH_LIBS) $(PTH_LIBS) \ - $(LIBUSB_LIBS) $(GPG_ERROR_LIBS) $(LIBINTL) $(DL_LIBS) $(NETLIBS) + $(LIBUSB_LIBS) $(GPG_ERROR_LIBS) $(LIBICONV) $(LIBINTL) $(DL_LIBS) $(NETLIBS) # Removed for now: We need to decide whether it makes sense to # continue it at all, given that gpg has now all required diff -Nuar --exclude '*~' gnupg-2.0.1.orig/sm/Makefile.am gnupg-2.0.1/sm/Makefile.am --- gnupg-2.0.1.orig/sm/Makefile.am 2006-11-05 06:32:08.000000000 -0800 +++ gnupg-2.0.1/sm/Makefile.am 2007-01-05 11:26:33.000000000 -0800 @@ -58,7 +58,7 @@ gpgsm_LDADD = $(common_libs) \ $(LIBGCRYPT_LIBS) $(KSBA_LIBS) $(LIBASSUAN_LIBS) \ - $(GPG_ERROR_LIBS) $(LIBINTL) $(ZLIBS) + $(GPG_ERROR_LIBS) $(LIBICONV) $(LIBINTL) $(ZLIBS) # Make sure that all libs are build before we use them. This is # important for things like make -j2. diff -Nuar --exclude '*~' gnupg-2.0.1.orig/tools/Makefile.am gnupg-2.0.1/tools/Makefile.am --- gnupg-2.0.1.orig/tools/Makefile.am 2006-11-23 06:48:46.000000000 -0800 +++ gnupg-2.0.1/tools/Makefile.am 2007-01-05 11:28:45.000000000 -0800 @@ -54,34 +54,34 @@ common_libs = ../jnlib/libjnlib.a ../common/libcommon.a ../gl/libgnu.a pwquery_libs = ../common/libsimple-pwquery.a -gpgsplit_LDADD = $(common_libs) $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) $(ZLIBS) +gpgsplit_LDADD = $(common_libs) $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) $(ZLIBS) $(LIBICONV) $(LIBINTL) gpgconf_SOURCES = gpgconf.c gpgconf.h gpgconf-comp.c no-libgcrypt.c # jnlib/common sucks in gpg-error, will they, nil they (some compilers # do not eliminate the supposed-to-be-unused-inline-functions). -gpgconf_LDADD = $(common_libs) $(LIBINTL) $(GPG_ERROR_LIBS) +gpgconf_LDADD = $(common_libs) $(LIBICONV) $(LIBINTL) $(GPG_ERROR_LIBS) gpgparsemail_SOURCES = gpgparsemail.c rfc822parse.c rfc822parse.h gpgparsemail_LDADD = symcryptrun_SOURCES = symcryptrun.c symcryptrun_LDADD = $(LIBUTIL_LIBS) $(common_libs) $(pwquery_libs) \ - $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) $(LIBINTL) + $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) $(LIBICONV) $(LIBINTL) watchgnupg_SOURCES = watchgnupg.c watchgnupg_LDADD = $(NETLIBS) gpg_connect_agent_SOURCES = gpg-connect-agent.c no-libgcrypt.c gpg_connect_agent_LDADD = $(common_libs) $(LIBASSUAN_LIBS) \ - $(GPG_ERROR_LIBS) $(LIBINTL) $(NETLIBS) + $(GPG_ERROR_LIBS) $(LIBICONV) $(LIBINTL) $(NETLIBS) gpgkey2ssh_SOURCES = gpgkey2ssh.c gpgkey2ssh_CFLAGS = $(LIBGCRYPT_CFLAGS) $(GPG_ERROR_CFLAGS) # common sucks in jnlib, via use of BUG() in an inline function, which # some compilers do not eliminate. gpgkey2ssh_LDADD = $(common_libs) \ - $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) $(LIBINTL) + $(LIBGCRYPT_LIBS) $(GPG_ERROR_LIBS) $(LIBICONV) $(LIBINTL) # Make sure that all libs are build before we use them. This is -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: not available Url : /pipermail/attachments/20070105/87f4260a/attachment.pgp From rjh at sixdemonbag.org Fri Jan 5 22:51:10 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 05 Jan 2007 16:51:10 -0500 Subject: Secret key storage In-Reply-To: <459E8823.1090509@kfwebs.net> References: <459E8823.1090509@kfwebs.net> Message-ID: <459EC84E.5000800@sixdemonbag.org> Kristian Fiskerstrand wrote: > I tried to manually set the s2k cipher algo to CAST5 using gnupg 1.4.6 > to be sure that wasn't the problem itself, but that didn't result in any > change. Perhaps I'm missing something incredibly obvious, but didn't PGP 2.6 use IDEA exclusively for symmetric encryption? If so, why are you using CAST as the S2K algorithm? From news at kfwebs.net Fri Jan 5 23:03:39 2007 From: news at kfwebs.net (Kristian Fiskerstrand) Date: Fri, 05 Jan 2007 23:03:39 +0100 Subject: Secret key storage In-Reply-To: <459EC84E.5000800@sixdemonbag.org> References: <459E8823.1090509@kfwebs.net> <459EC84E.5000800@sixdemonbag.org> Message-ID: <459ECB3B.2000208@kfwebs.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Robert J. Hansen wrote, On 01/05/2007 10:51 PM: > Kristian Fiskerstrand wrote: >> I tried to manually set the s2k cipher algo to CAST5 using gnupg 1.4.6 >> to be sure that wasn't the problem itself, but that didn't result in any >> change. > > Perhaps I'm missing something incredibly obvious, but didn't PGP 2.6 use > IDEA exclusively for symmetric encryption? If so, why are you using > CAST as the S2K algorithm? > This was only done in an attempt to exclude IDEA being the issue for decrypting the secret key, not on the messages itself. IDEA encryption and decryption seems to work as it should, and getting the session key from the message works as long as the secret key is not encrypted. However, it will always fail with a BAD PASSKEY whenever encrypted / password protected. - -- - ---------------------------- Kristian Fiskerstrand http://www.kfwebs.net - ---------------------------- http://www.secure-my-email.com http://www.secure-my-internet.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRZ7LOxbgz41rC5UIAQg7VxAAqgXDCeB1gz7fTV0o23D11nlEOcP8Hp3P YRVpf3HCD5AECVV0Quak+6nkv2+1cYIfrGk2T12M4RndVggCZrg5qMIzkaenTCnD uDUTAqi/ZJWI8TWuFqYm8fK72cNzsMTZbysA961Qmyqv91txp7TDo8qU9iopT2r/ dnN9NKYsh467zDUNV1rzImr0SLR1ETzNzM0LHUG27lCvrHLYHf8e5AG1HUCSQANO A7nfSYNpwosn2tJYiV2BullTbTQXcPvFUpOsBtna+56OL6PCtmo5LsSwihc5YMox hwkAWyMtzDpG2NGx74Na3GbjhqflY4xmo8X0Cj2bae4hOZV0x4kK7rdoOaLUvcM1 Yxx4NZL4ffYrnPMtKt7iVEUCD3krzCiiooBE8oiLJF1umDziBNtv2h+ji2xGly5w kBXT3MNhgz/1fNSYahXy4E4F5rkdZsXj3JLL63ak490FY++1oRkqxeGV2goy6D9O xK6v0VFLYqE338ChyWqMfTv9RDmTPYAdTCLSgKcHWTWcuS95vMqeYEgL38SfOBgo jIKNw3X4e6pzV9LebNyy/Sd4uua7duZ4oEmyg9VQPn+6ira9AIeKId+NzntGQkqR vVO3yg+1ZvgBH4qhti+p6GRvPN5rgL99v2O2vO4LpxMPBvdHnhvEUJ8T13fw0rXC 4+wWkp5y5ww= =hw/E -----END PGP SIGNATURE----- From alex at bofh.net.pl Sat Jan 6 15:38:10 2007 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Sat, 6 Jan 2007 15:38:10 +0100 Subject: Secret key storage In-Reply-To: <459EC84E.5000800@sixdemonbag.org> References: <459E8823.1090509@kfwebs.net> <459EC84E.5000800@sixdemonbag.org> Message-ID: <20070106143810.GA12736@hell.pl> On Fri, Jan 05, 2007 at 04:51:10PM -0500, Robert J. Hansen wrote: > Kristian Fiskerstrand wrote: > > I tried to manually set the s2k cipher algo to CAST5 using gnupg 1.4.6 > > to be sure that wasn't the problem itself, but that didn't result in any > > change. > > Perhaps I'm missing something incredibly obvious, but didn't PGP 2.6 use > IDEA exclusively for symmetric encryption? If so, why are you using It did. > CAST as the S2K algorithm? plus, there is --pgp2 switch in gnupg to enforce compatibility -- JID: alex at hell.pl PGP: 0x46399138 od zwracania uwagi na detale s? lekarze, adwokaci, programi?ci i zegarmistrze -- Czerski From news at kfwebs.net Sat Jan 6 15:54:04 2007 From: news at kfwebs.net (Kristian Fiskerstrand) Date: Sat, 06 Jan 2007 15:54:04 +0100 Subject: Secret key storage In-Reply-To: <20070106143810.GA12736@hell.pl> References: <459E8823.1090509@kfwebs.net> <459EC84E.5000800@sixdemonbag.org> <20070106143810.GA12736@hell.pl> Message-ID: <459FB80C.6040904@kfwebs.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Janusz A. Urbanowicz wrote, On 01/06/2007 03:38 PM: > On Fri, Jan 05, 2007 at 04:51:10PM -0500, Robert J. Hansen wrote: >> Kristian Fiskerstrand wrote: >>> I tried to manually set the s2k cipher algo to CAST5 using gnupg 1.4.6 >>> to be sure that wasn't the problem itself, but that didn't result in any >>> change. >> Perhaps I'm missing something incredibly obvious, but didn't PGP 2.6 use >> IDEA exclusively for symmetric encryption? If so, why are you using > > It did. > Remember, I was talking about encryption of the secret key, not the messages sent, the cast approach was solely to ensure that the secret key was encrypted / passphrase protected using CAST5 as I know that works for gnupg 2.0 too, hence it helped rule out some possible points of failure. >> CAST as the S2K algorithm? > > plus, there is --pgp2 switch in gnupg to enforce compatibility The issue also happens when receiving messages, which is the example in the bug report. --pgp2 by default won't have any meaning in GnuPG 2.0, as there wasn't any IDEA plugin (that I'm aware of) prior to this effort. The issue arises whenever the RSAv3 key is passphrase protected, remove the passphrase using gnupg 1.4 or pgp2 and things works as it should. Add a passphrase again and it constantly gives a bad key in gnupg 2.0, although the same passphrase works in gnupg 1.4. To rule out any pinentry issues I used --password-fd 0 and piped the password to it, with the same results. I'm just trying to figure out why this happens, and more importantly: how to get around it. - -- - ---------------------------- Kristian Fiskerstrand http://www.kfwebs.net - ---------------------------- http://www.secure-my-email.com http://www.secure-my-internet.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRZ+4Cxbgz41rC5UIAQgn7w/+OK4RUX2mnbsVUJqMuefI21TTHv9UeOcY QvDV8OYmIQb2Mot2B5/TibZBmLF70TC0M0cVrBWd3CzESvdvmcn2bEw7VQh4RBIN lc63FzDDagpA1Ouk0wT/PUTZYPFVuUI81UOWMe8smcTcDkE3RN0Lh/QbvV6fm7n2 0HFM5SpmyvsDQknJ8BK1RUElsjV57WAOj2XziF3Tj8ZGyzAKlfvU/tO7VOSvOntK eSmmgITtJcdiXAJgX2/4BQADSiF3vv+fZnMX1mHtVyZUW1mmC+EHYYmo7IF66cMt TH7B86GzhJLK8n+s5hlQBN+P2CpZPv/Z6lOfGIG8zT2h4+FdNXyaOJnqImKzOATl yG3/JUaOkEnaV+t7GqTpxESXOxA7DtqzkxcRAfYk7Q1AqtmlveOpa1hfTeftGUTd Vzzs7nm/d7zeH7+Ki2mU/UvI5487YISDiUNDetQkYxnMzpTmQPlTEy4xooSlThYy ZCAx2d1AvWv+OWuAiZP0jSBgrVuG9DEtBUAmrpIXWM/liJ9KfWcZSYQgW3Ia7hrd 9f/3RIErpQqDUAkyGh+/7y0WlfB5FtQyUcZNXVRWdPrMJ2VXCFC+JPRc/zYslTPm TBoOrGbv76Ym4OB4dxOOMIPcNksQWF/MiIZefajVrB42i7B9QqJBFq1Zb2JhwYVp VavL0k8wK6A= =qK2i -----END PGP SIGNATURE----- From alex at bofh.net.pl Sat Jan 6 18:46:38 2007 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Sat, 6 Jan 2007 18:46:38 +0100 Subject: Secret key storage In-Reply-To: <459FB80C.6040904@kfwebs.net> References: <459E8823.1090509@kfwebs.net> <459EC84E.5000800@sixdemonbag.org> <20070106143810.GA12736@hell.pl> <459FB80C.6040904@kfwebs.net> Message-ID: <20070106174637.GC12736@hell.pl> On Sat, Jan 06, 2007 at 03:54:04PM +0100, Kristian Fiskerstrand wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Janusz A. Urbanowicz wrote, On 01/06/2007 03:38 PM: > > On Fri, Jan 05, 2007 at 04:51:10PM -0500, Robert J. Hansen wrote: > >> Kristian Fiskerstrand wrote: > >>> I tried to manually set the s2k cipher algo to CAST5 using gnupg 1.4.6 > >>> to be sure that wasn't the problem itself, but that didn't result in any > >>> change. > >> Perhaps I'm missing something incredibly obvious, but didn't PGP 2.6 use > >> IDEA exclusively for symmetric encryption? If so, why are you using > > > > It did. > > > Remember, I was talking about encryption of the secret key, not the > messages sent, the cast approach was solely to ensure that the secret > key was encrypted / passphrase protected using CAST5 as I know that > works for gnupg 2.0 too, hence it helped rule out some possible points > of failure. You lost me. In every place PGP 2.x used symmetric encryption, it used IDEA. It couln't use CAST for many reasons, first one being that CAST didn't exit yet. > >> CAST as the S2K algorithm? > > > > plus, there is --pgp2 switch in gnupg to enforce compatibility > > The issue also happens when receiving messages, which is the example in > the bug report. --pgp2 by default won't have any meaning in GnuPG 2.0, > as there wasn't any IDEA plugin (that I'm aware of) prior to this effort. And you're wrong: alex at FUCKUP:~$ gpg --version gpg (GnuPG) 1.4.3 Copyright (C) 2006 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512 Compression: Uncompressed, ZIP, ZLIB alex at FUCKUP:~$ It is just that the plugin cannot be distributed along GPG for patent reasons. Alex -- JID: alex at hell.pl PGP: 0x46399138 od zwracania uwagi na detale s? lekarze, adwokaci, programi?ci i zegarmistrze -- Czerski From news at kfwebs.net Sat Jan 6 19:08:07 2007 From: news at kfwebs.net (Kristian Fiskerstrand) Date: Sat, 06 Jan 2007 19:08:07 +0100 Subject: Secret key storage In-Reply-To: <20070106174637.GC12736@hell.pl> References: <459E8823.1090509@kfwebs.net> <459EC84E.5000800@sixdemonbag.org> <20070106143810.GA12736@hell.pl> <459FB80C.6040904@kfwebs.net> <20070106174637.GC12736@hell.pl> Message-ID: <459FE587.3060401@kfwebs.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Janusz A. Urbanowicz wrote, On 01/06/2007 06:46 PM: > > You lost me. > > In every place PGP 2.x used symmetric encryption, it used IDEA. It > couln't use CAST for many reasons, first one being that CAST didn't > exit yet. I'm not looking for compatibility in key storage, but message exchange. Don't get too caught up in the s2k change, it was a debugging factor, and it didn't help. > >>>> CAST as the S2K algorithm? >>> plus, there is --pgp2 switch in gnupg to enforce compatibility >> The issue also happens when receiving messages, which is the example in >> the bug report. --pgp2 by default won't have any meaning in GnuPG 2.0, >> as there wasn't any IDEA plugin (that I'm aware of) prior to this effort. > > And you're wrong: No, I'm not. > > alex at FUCKUP:~$ gpg --version > gpg (GnuPG) 1.4.3 Note the "GnuPG 2.0" in my reply, I'm fully aware of the compatibility in 1.4, I'm trying to reproduce it in 2.0 - -- - ---------------------------- Kristian Fiskerstrand http://www.kfwebs.net - ---------------------------- http://www.secure-my-email.com http://www.secure-my-internet.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRZ/lhhbgz41rC5UIAQhQKxAAsx6LVkiZ+o7aJ05Fdwauguq+FaliTJR5 1mxHt1yB+VVKyUqaWET+xW4ayCsrR8/zSfTuHhtxFRgV3zFfFv4w10MVOaoIZGXi U8Cg7nVgnpY6UUtMQo/dTcvPsZOBNKaZNelmg2QZ/cZ0Ab5WlB34lCS2Oq7Qc3Yg i/xNAdrYTHr3x+VCmtFDSwRLwR2F2OIbnFEV7RhOlBt036fPQNYPWJZ4HCf9Dwxx +/1SDuo7Ph6ul5iuWuhfl6piMgb8Yo0g8rZD+6jZsiobFg+AOZO0VQAl7nicnSmm 53eC48UuBsTkd/M9W/bzzph02ST87a7V5ja2KZ2oggyKP2U4/jqJcdmnzWtGOvk7 EEhUsK5U2TS7eE/egpe4+d5zSwO/EZAJZBrxQjgz+Q6dB42IRjjfYpCBSKXLT4jH jQpdWbKj4T8BoZctfgjfccpljW7zhbMxq16gVHNI/+5DuNf0EUnCWABK59/SnB+8 QcK4vwf10Xm5zf1JcKtyDgDj8zzaka+rcimLL2b8sYvahHonRoxAyUWnvcHQHT9Y kJ5idsSjHWEkgDvoiqm0xUSnVakDv8L55waC675Jj4uY85BBrog+5e2oKhQgp5QI s3L0R6DS+vfBGL8i3wb/2qsTiql+UcEep5FPulX0kFxAVWU/JPpY2696CDwP5CSH K3dp3gC2wAo= =UN1g -----END PGP SIGNATURE----- From gkajmowi at tbaytel.net Sun Jan 7 03:58:43 2007 From: gkajmowi at tbaytel.net (Garrett Kajmowicz) Date: Sun, 7 Jan 2007 02:58:43 +0000 Subject: [GPGME] gpgme data buffer not showing any data Message-ID: <200701070258.43120.gkajmowi@tbaytel.net> I'm trying to push some data into a gogme_data_t buffer from an object and I'm not having any luck. The following code should return 8, but insted I'm getting -1. Please advise as to what I am missing. - Garrett #define D_FILE_OFFSET_BITS 64 #include #include #include int main(){ gpgme_error_t err; std::string msg("Message"); gpgme_data_t In; err = gpgme_data_new_from_mem(&In, msg.c_str(), msg.length(), 1); if(err){ std::cout << "An error occured copying data" << std::endl; } off_t len; len = gpgme_data_seek(In, 0, SEEK_END); std::cout << "Size of data: " << len << std::endl; return 0; } From gkajmowi at tbaytel.net Sun Jan 7 02:15:18 2007 From: gkajmowi at tbaytel.net (Garrett Kajmowicz) Date: Sun, 7 Jan 2007 01:15:18 +0000 Subject: [GPGME] gpgme data buffer not showing any data Message-ID: <200701070115.19107.gkajmowi@tbaytel.net> I'm trying to push some data into a gogme_data_t buffer from an object and I'm not having any luck. The following code should return 8, but insted I'm getting -1. Please advise as to what I am missing. - Garrett #define D_FILE_OFFSET_BITS 64 #include #include #include int main(){ gpgme_error_t err; std::string msg("Message"); gpgme_data_t In; err = gpgme_data_new_from_mem(&In, msg.c_str(), msg.length(), 1); if(err){ std::cout << "An error occured copying data" << std::endl; } off_t len; len = gpgme_data_seek(In, 0, SEEK_END); std::cout << "Size of data: " << len << std::endl; return 0; } From patrick at mozilla-enigmail.org Mon Jan 8 15:44:01 2007 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Mon, 08 Jan 2007 15:44:01 +0100 Subject: gpg2: stack smashing detected Message-ID: <45A258B1.2020403@mozilla-enigmail.org> When I try to import the attached key, then gpg2 fails with the error: *** stack smashing detected ***: gpg2 terminated Aborted The more problematic one is that I get the same error upon running "gpg2 --check-trustdb" if the key was imported with gpg 1.4.x. I'm using gnupg 2.0.1 with the patch from 6. Dec. 06. I have some more keys exposing the same bug. -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: problem.key Type: application/pgp-keys Size: 9227 bytes Desc: not available Url : /pipermail/attachments/20070108/a0e77fbe/attachment-0001.key From n3g4s at hotmail.com Tue Jan 9 13:30:32 2007 From: n3g4s at hotmail.com (Ricardo Oliveira) Date: Tue, 09 Jan 2007 12:30:32 +0000 Subject: [GPGME] gpgme data buffer not showing any data Message-ID: Hi, I have the exact same problem. Worst even: my code worked before and it's not working anymore. I believe this is a linking/library problem. Somehow I changed my compile options in KDevelop and now this happens. I tried your code with the same result. I compiled it like so: gcc -o gpgme-test gpgme-test.c /usr/lib/libgpgme.so.11 and gcc -o gpgme-test gpgme-test.c `gpgme-config --libs --cflags` but the result was the same. Any ideas? Regards. >I'm trying to push some data into a gogme_data_t buffer from an object and >I'm not having any luck. The following code should return 8, but insted >I'm getting -1. Please advise as to what I am missing. > > >- Garrett > >#define D_FILE_OFFSET_BITS 64 > >#include >#include >#include > >int main(){ > gpgme_error_t err; > std::string msg("Message"); > > gpgme_data_t In; > > err = gpgme_data_new_from_mem(&In, msg.c_str(), msg.length(), 1); > > if(err){ > std::cout << "An error occured copying data" << std::endl; > } > > off_t len; > len = gpgme_data_seek(In, 0, SEEK_END); > std::cout << "Size of data: " << len << std::endl; > > return 0; >} _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From n3g4s at hotmail.com Tue Jan 9 15:45:49 2007 From: n3g4s at hotmail.com (Ricardo Oliveira) Date: Tue, 09 Jan 2007 14:45:49 +0000 Subject: [GPGME] gpgme data buffer not showing any data In-Reply-To: Message-ID: P.S.: I used C instead of C++, but the code is basically the same. > >Hi, > >I have the exact same problem. Worst even: my code worked before and it's >not working anymore. I believe this is a linking/library problem. Somehow I >changed my compile options in KDevelop and now this happens. I tried your >code with the same result. I compiled it like so: > >gcc -o gpgme-test gpgme-test.c /usr/lib/libgpgme.so.11 > >and > >gcc -o gpgme-test gpgme-test.c `gpgme-config --libs --cflags` > >but the result was the same. > >Any ideas? > >Regards. > > >I'm trying to push some data into a gogme_data_t buffer from an object >and > >I'm not having any luck. The following code should return 8, but insted > >I'm getting -1. Please advise as to what I am missing. > > > > > >- Garrett > > > >#define D_FILE_OFFSET_BITS 64 > > > >#include > >#include > >#include > > > >int main(){ > > gpgme_error_t err; > > std::string msg("Message"); > > > > gpgme_data_t In; > > > > err = gpgme_data_new_from_mem(&In, msg.c_str(), msg.length(), 1); > > > > if(err){ > > std::cout << "An error occured copying data" << >std::endl; > > } > > > > off_t len; > > len = gpgme_data_seek(In, 0, SEEK_END); > > std::cout << "Size of data: " << len << std::endl; > > > > return 0; > >} > >_________________________________________________________________ >Express yourself instantly with MSN Messenger! Download today it's FREE! >http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > >_______________________________________________ >Gnupg-devel mailing list >Gnupg-devel at gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-devel _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From alon.barlev at gmail.com Wed Jan 10 21:30:27 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 10 Jan 2007 22:30:27 +0200 Subject: [PATCH][TRIVIAL] - libgcrypt-1.2.3 - strict-aliasing rules fixup Message-ID: <200701102230.28578.alon.barlev@gmail.com> Hello, The following solves gcc strict-aliasing rules warning. Best Regards, Alon Bar-Lev. diff -urNp libgcrypt-1.2.3.org/cipher/ac.c libgcrypt-1.2.3/cipher/ac.c --- libgcrypt-1.2.3.org/cipher/ac.c 2005-07-29 16:45:48.000000000 +0300 +++ libgcrypt-1.2.3/cipher/ac.c 2007-01-10 22:13:05.000000000 +0200 @@ -137,9 +137,11 @@ gcry_ac_data_copy_internal (gcry_ac_data data_new->data_n = data->data_n; if (! err) - /* Allocate space for named MPIs. */ - err = _gcry_malloc (sizeof (gcry_ac_mpi_t) * data->data_n, 0, - (void **) &data_new->data); + { + /* Allocate space for named MPIs. */ + err = _gcry_malloc (sizeof (gcry_ac_mpi_t) * data->data_n, 0, &p); + data_new->data = (gcry_ac_mpi_t *)p; + } if (! err) { From alon.barlev at gmail.com Wed Jan 10 21:41:38 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 10 Jan 2007 22:41:38 +0200 Subject: [PATCH] libgcrypt-1.2.3 - powerpc64 issue Message-ID: <200701102241.38388.alon.barlev@gmail.com> Hello, I don't think I sent this before. powerpc64 needs to be before powerpc*. Best Regards, Alon Bar-Lev. --- mpi/config.links.orig 2005-11-25 21:37:25.000000000 -0600 +++ mpi/config.links 2005-11-25 21:39:37.000000000 -0600 @@ -221,6 +221,11 @@ path="m68k/mc68020 m68k" ;; + powerpc64*-*-linux*) + mpi_sflags="-Wa,-mppc" + path="powerpc64" + ;; + powerpc*-*-linux*) echo '/* configured for powerpc/ELF */' >>./mpi/asm-syntax.h echo '#define ELF_SYNTAX' >>./mpi/asm-syntax.h From marcus.brinkmann at ruhr-uni-bochum.de Sat Jan 13 12:14:29 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sat, 13 Jan 2007 12:14:29 +0100 Subject: [GPGME] gpgme data buffer not showing any data In-Reply-To: <200701070115.19107.gkajmowi@tbaytel.net> References: <200701070115.19107.gkajmowi@tbaytel.net> Message-ID: <87lkk741re.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sun, 7 Jan 2007 01:15:18 +0000, Garrett Kajmowicz wrote: > > I'm trying to push some data into a gogme_data_t buffer from an object and I'm > not having any luck. The following code should return 8, but insted I'm > getting -1. Please advise as to what I am missing. http://gnupg.unixmexico.org/faq/gpgme-faq.html.de 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. Thanks, Marcus > > > - Garrett > > #define D_FILE_OFFSET_BITS 64 > > #include > #include > #include > > int main(){ > gpgme_error_t err; > std::string msg("Message"); > > gpgme_data_t In; > > err = gpgme_data_new_from_mem(&In, msg.c_str(), msg.length(), 1); > > if(err){ > std::cout << "An error occured copying data" << std::endl; > } > > off_t len; > len = gpgme_data_seek(In, 0, SEEK_END); > std::cout << "Size of data: " << len << std::endl; > > return 0; > } > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From christianbiere at gmx.de Sat Jan 13 12:55:51 2007 From: christianbiere at gmx.de (Christian Biere) Date: Sat, 13 Jan 2007 12:55:51 +0100 Subject: [GPGME] gpgme data buffer not showing any data In-Reply-To: <87lkk741re.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200701070115.19107.gkajmowi@tbaytel.net> <87lkk741re.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <20070113115551.GD4313@cyclonus> Marcus Brinkmann wrote: > At Sun, 7 Jan 2007 01:15:18 +0000, > Garrett Kajmowicz wrote: > > > > I'm trying to push some data into a gogme_data_t buffer from an object and I'm > > not having any luck. The following code should return 8, but insted I'm > > getting -1. Please advise as to what I am missing. > > http://gnupg.unixmexico.org/faq/gpgme-faq.html.de > > Why does the function gpgme_data_seek not work? > 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. For what it's worth, the header file could possibly include something like #if defined(_FILE_OFFSET_BITS) && _FILE_OFFSET_BITS != 64 #error "API mismatch; largefile support is mandatory" #endif That's just a raw sketch of course. > > #define D_FILE_OFFSET_BITS 64 ^^ Indeed, he prolly meant #define _FILE_OFFSET_BITS 64 -- Christian From christianbiere at gmx.de Sat Jan 13 13:04:28 2007 From: christianbiere at gmx.de (Christian Biere) Date: Sat, 13 Jan 2007 13:04:28 +0100 Subject: [CarlM@Prism.co.za: Out of Office AutoReply: [GPGME] gpgme data buffer not showing an y data] Message-ID: <20070113120428.GA15973@cyclonus> ----- Forwarded message from Carl Meijer ----- From: Carl Meijer To: Christian Biere Subject: Out of Office AutoReply: [GPGME] gpgme data buffer not showing an y data Date: Sat, 13 Jan 2007 13:57:33 +0200 I will be out of the office from 6 January 2007 - 14 January 2007. I will return on the 15th. Regards, Carl NOTICE : this electronic mail and any attachments (?message?) contains privileged information intended only for the addressee(s) use. If you are not the/an intended recipient, you may not disclose, review, disseminate, retransmit, copy, use or take action in reliance upon or otherwise deal with or publish this message, which is subject to copyright (?Use?). You may not use this message for anything other than the purpose for which it is intended. If you have received this message in error, you are required to notify the writer and delete it. Prism Holdings Limited, its holding companies and its subsidiaries (?Prism?) accept no liability whatsoever as a result of any losses arising from persons placing reliance on any information contained in this message or and Use thereof. The views expressed in this message are those of the individual transmitting it, unless they are expressly stated to be those of Prism. It is the recipient?s obligation to scan this message and ensure that it contains no viruses or other malicious programs and the recipient is warned that, notwithstanding reasonable checks performed by Prism, viruses and harmful programs may be contained in this message and Prism accepts no liability whatsoever for any loss, damage, or liability of any nature, whether direct or indirect, resulting from the recipient accessing or Using this message or any files attached to it. ----- End forwarded message ----- Could someone drag this guy back into office please? -- Christian From bernhard at intevation.de Sat Jan 13 11:55:42 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Sat, 13 Jan 2007 11:55:42 +0100 Subject: control channel??? Message-ID: <200701131155.44092.bernhard@intevation.de> There is some criticism by Felix von Leitner about the gnupg code in German: http://blog.fefe.de/?ts=bb581702 I cannot evaluate it, but as it is published anyway, I thought you might be interested to know. Explaining the code in question seems useful. Bernhard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070113/c94c0365/attachment.pgp From marcus.brinkmann at ruhr-uni-bochum.de Sat Jan 13 17:39:19 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sat, 13 Jan 2007 17:39:19 +0100 Subject: [GPGME] gpgme data buffer not showing any data In-Reply-To: <20070113115551.GD4313@cyclonus> References: <200701070115.19107.gkajmowi@tbaytel.net> <87lkk741re.wl%marcus.brinkmann@ruhr-uni-bochum.de> <20070113115551.GD4313@cyclonus> Message-ID: <87k5zq51ag.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sat, 13 Jan 2007 12:55:51 +0100, Christian Biere wrote: > > Marcus Brinkmann wrote: > > At Sun, 7 Jan 2007 01:15:18 +0000, > > Garrett Kajmowicz wrote: > > > > > > I'm trying to push some data into a gogme_data_t buffer from an object and I'm > > > not having any luck. The following code should return 8, but insted I'm > > > getting -1. Please advise as to what I am missing. > > > > http://gnupg.unixmexico.org/faq/gpgme-faq.html.de > > > > Why does the function gpgme_data_seek not work? > > > 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. > > For what it's worth, the header file could possibly include something like > > #if defined(_FILE_OFFSET_BITS) && _FILE_OFFSET_BITS != 64 > #error "API mismatch; largefile support is mandatory" > #endif > > That's just a raw sketch of course. In principle, yes, but this would mean that gpgme.h needs to be generated by configure, which has the relevant tests what needs to happen for large file support (and knows if it was switched off deliberately). Making these changes and testing them(!) is quite a hassle. Yet, it's one of the main problems that people have these days when using GPGME, so it's worth considering. Thanks, Marcus From taviso at sdf.lonestar.org Sat Jan 13 19:06:55 2007 From: taviso at sdf.lonestar.org (Tavis Ormandy) Date: Sat, 13 Jan 2007 18:06:55 +0000 Subject: control channel??? References: <200701131155.44092.bernhard@intevation.de> Message-ID: Bernhard Reiter wrote: > There is some criticism by Felix von Leitner about the gnupg code in > German: > > http://blog.fefe.de/?ts=bb581702 > > I cannot evaluate it, but as it is published anyway, I thought you > might be interested to know. Explaining the code in question seems > useful. > > Bernhard > I audited the code in question in detail a few months ago, and found no problems. I cant read german, but if he is complaining about the volatile trick, I suspect it is used so as not to deplete any entropy pool, which seems perfectly reasonable to me (it doesnt buy an attacker any advantage if he can guess it). Id be interested to hear any attack I might have missed, could any german speakers give a rough translation? Thanks, Tavis. -- ------------------------------------- taviso at sdf.lonestar.org | finger me for my pgp key. ------------------------------------------------------- From ametzler at downhill.at.eu.org Sat Jan 13 20:12:02 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 13 Jan 2007 20:12:02 +0100 Subject: control channel??? References: <200701131155.44092.bernhard@intevation.de> Message-ID: <2hnn74-shg.ln1@argenau.downhill.at.eu.org> Tavis Ormandy wrote: > Bernhard Reiter wrote: >> There is some criticism by Felix von Leitner about the gnupg code in >> German: >> http://blog.fefe.de/?ts=bb581702 [...] > I audited the code in question in detail a few months ago, and found > no problems. I cant read german, but if he is complaining about the > volatile trick, I suspect it is used so as not to deplete any entropy > pool, which seems perfectly reasonable to me (it doesnt buy an attacker > any advantage if he can guess it). > Id be interested to hear any attack I might have missed, could any > german speakers give a rough translation? ------------------------------- | [code snippet] | Ich habe da genau so viel Kontext wie ihr, aber ich w?rde das so | interpretieren, da? Herr Koch hier ein Protokoll mit in-band | signalling gebaut hat, und ein Angreifer hier Pakete einf?gen kann, | und er will das jetzt "reparieren", indem er "Zufallswerte" einf?gt, | die der Angreifer nicht raten k?nnen soll. | | Also ich k?nnte euch jetzt erz?hlen, da? Werte auf dem Stack alles | andere als zuf?llig sind, da? PID und Uhrzeit auch eher gut ratbar | sind, aber die eigentliche Nachricht ist: gnupg hat einen "control | channel", der in-band signalling benutzt, und auf dem Angreifer Daten | einschleusen k?nnen. Mehr mu? man nicht sagen. Und diesen M?ll-Code | habe ich seit Jahren eingesetzt! OMFG! Ich glaube nicht, da? das mit | einem Patch fixbar ist. Wegschmei?en, neu machen. Im ?brigen schreibt | man das "although", nicht "also". [code snippet] I have got as much context as you but I think that Mr Koch has created a protocol with in-band signaling and that an attacker could insert packages here. Mr Koch seems to be trying to "repair" this by inserting "random values" which the attacker should not be able to guess. Well, I could start telling you that values on the stack are very much not random and that PID and time are rather well guessable, too but the real message is this one: gnupg has got a "control channel" which is using in-band signalling and which could be used by an attacker to insert packets. That is all there is to say. I do not think this is fixable at all. Throw away, rewrite. An BTW the comment should say "although" instead of "also". ------------------------------- I probably made some errors when translating so please take with a heap of salt. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken. (c) Jasper Ffforde From rjh at sixdemonbag.org Sat Jan 13 20:18:52 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 13 Jan 2007 14:18:52 -0500 Subject: control channel??? In-Reply-To: References: <200701131155.44092.bernhard@intevation.de> Message-ID: <45A9309C.9030201@sixdemonbag.org> Tavis Ormandy wrote: > it doesnt buy an attacker any advantage if he can guess it. If so, it raises the question of why GnuPG bothers with any attempt at obfuscating it. From taviso at sdf.lonestar.org Sat Jan 13 20:40:55 2007 From: taviso at sdf.lonestar.org (Tavis Ormandy) Date: Sat, 13 Jan 2007 19:40:55 +0000 Subject: control channel??? References: <200701131155.44092.bernhard@intevation.de> <45A9309C.9030201@sixdemonbag.org> Message-ID: "Robert J. Hansen" wrote: > Tavis Ormandy wrote: > > it doesnt buy an attacker any advantage if he can guess it. > > If so, it raises the question of why GnuPG bothers with any attempt at > obfuscating it. > I havnt read any rationale, but I assume that a packet with the same id could be generated by another implementation, and this is a safeguard against interpreting that. Andreas Metzler wrote: Thanks for the translation Andreas, I believe he has not discovered any new attack against gpg and is just spreading FUD. > Well, I could start telling you that values on the stack are very much > not random and that PID and time are rather well guessable, too but > the real message is this one: gnupg has got a "control channel" which > is using in-band signalling and which could be used by an attacker to > insert packets. So his attack is inserting packets into the stream, allowing him to insert packets into the stream. I fail to see the vulnerability :) > That is all there is to say. I do not think this is > fixable at all. Throw away, rewrite. This is a very sensationalist statement, he has not yet established any attack against this code. Thanks, Tavis. -- ------------------------------------- taviso at sdf.lonestar.org | finger me for my pgp key. ------------------------------------------------------- From wk at gnupg.org Sun Jan 14 13:23:03 2007 From: wk at gnupg.org (Werner Koch) Date: Sun, 14 Jan 2007 13:23:03 +0100 Subject: control channel??? In-Reply-To: (Tavis Ormandy's message of "Sat\, 13 Jan 2007 19\:40\:55 +0000") References: <200701131155.44092.bernhard@intevation.de> <45A9309C.9030201@sixdemonbag.org> Message-ID: <87bql1lrvc.fsf@wheatstone.g10code.de> On Sat, 13 Jan 2007 20:40, taviso at sdf.lonestar.org said: > I havnt read any rationale, but I assume that a packet with the same id > could be generated by another implementation, and this is a safeguard > against interpreting that. This is one reason. Another reason is defensive programming. Although that the control packets used with cleartext signatures are not exploitable at all (they emulate a one-pass signature packet), it is safer to not allow the user to add data which gpg considers as internally generated. It also helps to analyze bug reports Another use of the control packet is with the --pipemode feature. I have not looked into this right now, as this feature has always been experimental and will be removed in future versions. The last use of control packets is to run a syntax check on packet compositions. Here the control packet is used to replace a plaintext packet by a short marker packet. This is required because a plaintext packet can be of any size but we need to know the sequence of packets processed later. Using the control packet is the most straightforward method of implementing this syntax check. I concur that gpg's method of checking the structure of OpenPGP messages is too flexible and thus not easy to get right. However, this is the core of gpg and it seems pretty matured by now and thus I see no immediate need to rewrite it and introduce new bus and incompatibilities. A rationale for not using a true RNG derived nonce is stated in g10/misc.c: /* also this marker is guessable it is not easy to use this * for a faked control packet because an attacker does not * have enough control about the time the verification does * take place. Of course, we can add just more random but * than we need the random generator even for verification * tasks - which does not make sense. */ [s/also/Although/]. gpg has always used a faked one-time signature packet to verify cleartext signatures. Back in July 2000, a vulnerability was found when composing messages out of different signature types. In the course of fixing this problem, the ad-hoc method of faking a one-time signature packet has been generalized to the control packet scheme and used for the syntax check. Shalom-Salam, Werner From marcus.brinkmann at ruhr-uni-bochum.de Wed Jan 17 20:28:26 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed, 17 Jan 2007 20:28:26 +0100 Subject: 1.4.6: Build problem with doc/yat2m In-Reply-To: <20061207134444.GA9526@lx-xeon-8.ibw.intel.com> References: <20061207134444.GA9526@lx-xeon-8.ibw.intel.com> Message-ID: <87wt3lpi5h.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Thu, 7 Dec 2006 14:44:44 +0100, Moritz Barsnick wrote: > > Hi, > > I'm to lazy to get YAPW (yet another password) for bugs.gnupg.org, so > I'm posting here according to the README. (I'm not subscribed.) ;-) That's OK. > With gnupg-1.4.6, I have encountered a newly introduced build problem. > > doc/yat2m now uses the new $(CC_FOR_BUILD) [*]. This is generally okay, > but it totally ignores if I explicitly set LDFLAGS which are _required_ > for building. As it should, as LDFLAGS is only relevant to the host environment. > Background: I (try to) compile all my apps with the Intel C++ Compiler > (icc). This compiler creates binaries which depend on a certain dynamic > lib (libimf.so) if not explicitly told to link that lib statically > (with the -i-static LDFLAG). What's the problem in having that dependency for yat2m? Note that it is not an installed program (see below). > I do _not_ provide this flag as CC="icc -i-static" because it is _not_ > a compiler flag, and the compiler would warn with every call. > > My suggestion (it works for me, I don't think there are any drawbacks): The drawback is that it is wrong, and can break down in cross compilation settings (the only ones where CC_FOR_BUILD makes sense anyway). If this is really needed (please explain why), you have the option to define CC_FOR_BUILD as above, which will only generate a few warnings because it's not used often, or we can add an LDFLAGS_FOR_BUILD which you would have to define in addition. > [*] What for? yat2m is a program which should be compiled for the build environment, because it is run in the build environment during the build. It is not installed and never run in the host environment. This is because it is semantically in the same class of programs as your compiler (in fact, it compiles texi sources into manpages). Thanks, Marcus From twoaday at gmx.net Mon Jan 15 23:02:44 2007 From: twoaday at gmx.net (Timo Schulz) Date: Mon, 15 Jan 2007 23:02:44 +0100 Subject: [gpgme] hidden recipient support Message-ID: <45ABFA04.7000803@gmx.net> Hi, I know it's not a very important issue, but I would like to ask for --hidden-recipient support in gpgme. It's not that much in use, but still some user frequently use it and because gpgme has no support for it, all kind of gpgme front-ends, include WinPT[1], have no chance to offer the anonymous recipient mode for encryption. If time is a problem, I would create a patch which could be, after inspection, comitted to the svn repository. Timo [1] WinPT: http://wald.intevation.org/projects/winpt http://www.stud.uni-hannover.de/~twoaday/winpt.html Hint: http://www.winpt.org is *not* available for the moment (!) From wk at gnupg.org Sun Jan 21 19:43:42 2007 From: wk at gnupg.org (Werner Koch) Date: Sun, 21 Jan 2007 19:43:42 +0100 Subject: [gpgme] hidden recipient support In-Reply-To: <45ABFA04.7000803@gmx.net> (Timo Schulz's message of "Mon\, 15 Jan 2007 23\:02\:44 +0100") References: <45ABFA04.7000803@gmx.net> Message-ID: <873b6443vl.fsf@wheatstone.g10code.de> On Mon, 15 Jan 2007 23:02, twoaday at gmx.net said: > I know it's not a very important issue, but I would like > to ask for --hidden-recipient support in gpgme. It's not I considere -R an esoteric option which is in general not very useful. It is designed to add some privacy but it can't be used alone to accomplish this. it is also often abused to hide the key used for self-encryption. This does not make sense and in fact raises suspicion at the receiving end on who owns that unidentified key. Unlikely BCC in mail, the existence of wildcard recipients (the OpenPGP option -R uses) is visible. You should think twice before adding support for such an option to a frontend. If you still think that is is required, we can add support for it. Shalom-Salam, Werner From jam at jamux.com Sun Jan 21 21:49:48 2007 From: jam at jamux.com (John A. Martin) Date: Sun, 21 Jan 2007 15:49:48 -0500 Subject: [gpgme] hidden recipient support References: <45ABFA04.7000803@gmx.net> <873b6443vl.fsf@wheatstone.g10code.de> Message-ID: <87irf085qr.fsf@athene.jamux.com> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 154 bytes Desc: not available Url : /pipermail/attachments/20070121/09869254/attachment.pgp From wk at gnupg.org Mon Jan 22 08:12:38 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Jan 2007 08:12:38 +0100 Subject: [gpgme] hidden recipient support In-Reply-To: <87irf085qr.fsf@athene.jamux.com> (John A. Martin's message of "Sun\, 21 Jan 2007 15\:49\:48 -0500") References: <45ABFA04.7000803@gmx.net> <873b6443vl.fsf@wheatstone.g10code.de> <87irf085qr.fsf@athene.jamux.com> Message-ID: <87lkjv357d.fsf@wheatstone.g10code.de> On Sun, 21 Jan 2007 21:49, jam at jamux.com said: > FWIW ISTM that -R is useful at least between trusted parties using > anonymous remailers. I don't use gpme and don't know whether > knowledgeable users of -R would be likely users of gpme, but is the > fact that something can be used foolishly a sufficient reason not to > support it in this case? My point is that it is not useful to use a standard GUI to prepare messages for a remailer. You should also use --throw-keyid when using remailers. With -R it is easy to forget one recipient; e.g. the one set with --encrypt-to :-((. Salam-Shalom, Werner From moritz at barsnick.net Mon Jan 22 08:03:12 2007 From: moritz at barsnick.net (Moritz Barsnick) Date: Mon, 22 Jan 2007 08:03:12 +0100 Subject: 1.4.6: Build problem with doc/yat2m In-Reply-To: <87wt3lpi5h.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <20061207134444.GA9526@lx-xeon-8.ibw.intel.com> <87wt3lpi5h.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <20070122070312.GA3790@sunshine.barsnick.net> Hi Marcus, On Wed, Jan 17, 2007 at 20:28:26 +0100, Marcus Brinkmann wrote: > > doc/yat2m now uses the new $(CC_FOR_BUILD) [*]. This is generally okay, > > but it totally ignores if I explicitly set LDFLAGS which are _required_ > > for building. > > As it should, as LDFLAGS is only relevant to the host environment. I guess in a cross environment, LDFLAGS et.al. is ambiguous, and autoconf provides ways of providing differing flags for host and target. But I'm in a non-cross environment. My LDFLAGS are valid for host and target. > > (icc). This compiler creates binaries which depend on a certain dynamic > > lib (libimf.so) if not explicitly told to link that lib statically > > (with the -i-static LDFLAG). > > What's the problem in having that dependency for yat2m? Note that it > is not an installed program (see below). Well, the RPATH or LD_LIBRARY_PATH don't need to be set, for one. And I do not want this dependency for my target. > The drawback is that it is wrong, and can break down in cross > compilation settings (the only ones where CC_FOR_BUILD makes sense > anyway). If this is really needed (please explain why), you have the > option to define CC_FOR_BUILD as above, which will only generate a few > warnings because it's not used often, or we can add an > LDFLAGS_FOR_BUILD which you would have to define in addition. Which means that, in a non-cross environment, I need to set specific cross flags. This complicates things. I don't care much, I'm a hacker at heart. But non-cross builds of autoconf'd tools usually "just work (TM)", but not in this case. IM ever so HO, non-cross builds should work easily, and cross builds need to evaluate all the special host vs. target stuff. But basically not in my case, I would have thought. I'll just hack around with my build environment's LD_LIBRARY_PATH, and make a note to assume any program _could_ require this sooner or later... *shrug* > > [*] What for? > > yat2m is a program which should be compiled for the build environment, > because it is run in the build environment during the build. It is > not installed and never run in the host environment. Fair enough. Regards, Moritz From jam at jamux.com Mon Jan 22 14:29:05 2007 From: jam at jamux.com (John A. Martin) Date: Mon, 22 Jan 2007 08:29:05 -0500 Subject: [gpgme] hidden recipient support References: <45ABFA04.7000803@gmx.net> <873b6443vl.fsf@wheatstone.g10code.de> <87irf085qr.fsf@athene.jamux.com> <87lkjv357d.fsf@wheatstone.g10code.de> Message-ID: <87ps972nry.fsf@athene.jamux.com> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 154 bytes Desc: not available Url : /pipermail/attachments/20070122/6d917286/attachment.pgp From marcus.brinkmann at ruhr-uni-bochum.de Wed Jan 24 14:12:25 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed, 24 Jan 2007 14:12:25 +0100 Subject: 1.4.6: Build problem with doc/yat2m In-Reply-To: <20070122070312.GA3790@sunshine.barsnick.net> References: <20061207134444.GA9526@lx-xeon-8.ibw.intel.com> <87wt3lpi5h.wl%marcus.brinkmann@ruhr-uni-bochum.de> <20070122070312.GA3790@sunshine.barsnick.net> Message-ID: <877ivc7eme.wl%marcus.brinkmann@ruhr-uni-bochum.de> Hi Moritz, At Mon, 22 Jan 2007 08:03:12 +0100, Moritz Barsnick wrote: > On Wed, Jan 17, 2007 at 20:28:26 +0100, Marcus Brinkmann wrote: > > > > doc/yat2m now uses the new $(CC_FOR_BUILD) [*]. This is generally okay, > > > but it totally ignores if I explicitly set LDFLAGS which are _required_ > > > for building. > > > > As it should, as LDFLAGS is only relevant to the host environment. > > I guess in a cross environment, LDFLAGS et.al. is ambiguous, and > autoconf provides ways of providing differing flags for host and > target. It's not ambiguous. LDFLAGS et al are for files compiled for the host architecture, and not for the build architecture. As these are (potentially) two completely different environments, they must not be mixed. Other restrictions are for example that source files built for the build architecture must not include "config.h". Unfortunately, autoconf support for compiling programs to be run on the build architecture is limited, so there is no canonical variable to set. The GNU world seems to settle on FOO_FOR_BUILD, though (see for example gdb sources), with some flags, like warning switches, included in all FOO's. > But I'm in a non-cross environment. My LDFLAGS are valid for host and > target. I hope you agree that we can not write our source code so that it works in your environment, but is broken in many other environments. > > > (icc). This compiler creates binaries which depend on a certain dynamic > > > lib (libimf.so) if not explicitly told to link that lib statically > > > (with the -i-static LDFLAG). > > > > What's the problem in having that dependency for yat2m? Note that it > > is not an installed program (see below). > > Well, the RPATH or LD_LIBRARY_PATH don't need to be set, for one. And I > do not want this dependency for my target. Please let's say "host" here and not "target", because target has already another meaning in Canadian-cross compilation environments (three different architectures, build, host and target). You should not have a dependency for your host by setting RPATH and LD_LIBRARY_RPATH for your build system. Setting LDFLAGS as you did will prevent this successfully. The only programs that will have such a dependency are the tools used during the build (in this case yat2m). These are not installed programs. > > The drawback is that it is wrong, and can break down in cross > > compilation settings (the only ones where CC_FOR_BUILD makes sense > > anyway). If this is really needed (please explain why), you have the > > option to define CC_FOR_BUILD as above, which will only generate a few > > warnings because it's not used often, or we can add an > > LDFLAGS_FOR_BUILD which you would have to define in addition. > > Which means that, in a non-cross environment, I need to set specific cross > flags. This complicates things. I don't care much, I'm a hacker at > heart. But non-cross builds of autoconf'd tools usually "just work > (TM)", but not in this case. The reason they don't work in your case is that you have a broken environment that requires extra flags to be passed to the build (and host) compiler to work. Specifically, you suppress the LD_LIBRARY_PATH environment variable that is necessary. I can understand the reason to do so (it helps to catch undesired run-time dependencies), but if you choose to set up such an environment, you will have to deal with the extra costs that this entails. Note that the reasons you have to specify LDFLAGS are quite different from the reasons to have to specify LDFLAGS_FOR_BUILD. Therefore it makes sense that you have to specify two variables, not one, even if they end up holding the same value. > IM ever so HO, non-cross builds should work easily, and cross builds > need to evaluate all the special host vs. target stuff. But basically > not in my case, I would have thought. But you should be cross compiling: Your build architecture is the intel compiler architecture, while your host architecture is the sanitized environment without dependencies on the run-time of the intel compiler. The reason you have problems is that you crippled your build architecture intentionally, to make it look more like the host architecture, but without changing the compiler. This does not mean that you are not cross-compiling, though, it just makes it less obvious that you are. > I'll just hack around with my build environment's LD_LIBRARY_PATH, and > make a note to assume any program _could_ require this sooner or > later... *shrug* I think that this is the right solution. The bad thing is that you may encounter other problems with packages which are not correctly set up for such a "cross" compilation setup as yours. However, note that I have no objections to do both: There are good reasons to support LDFLAGS_FOR_BUILD, and we can add them to the source. It would be great if you could submit a patch for that which is already tested in your environment, then we avoid an extra turn-around to get a possible fix tested. Thanks, Marcus g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 From gnupg-devel_list at danner-net.de Sun Jan 28 11:27:08 2007 From: gnupg-devel_list at danner-net.de (Christian Danner) Date: Sun, 28 Jan 2007 11:27:08 +0100 Subject: Feature request: --creation-date option Message-ID: <84uor29d9cc2r9ilnvt5bc16non5elup05@domain.is.invalid> Hi! Is there a chance to get an additional GPG option that allows to set the creation date of keys and signatures? I'm developing a Windows proxy server that works as a gateway to anon remailers and nym servers. For such an application it's mandatory to disguise all timestamps within messages, as e.g. getting knowledge of the exact shipping time would make it a lot easier for an adversary to compromise the author. Currently I see no alternative to a temporary manipulation of the system time when such sensitive action takes place. But that strategy entails a lot of potential side effects, especially in a server environment. BTW, PGP offers a PGPOCreationDate parameter, which, however, isn't very useful as long as the self-signatures of keys generated with a bogus creation date still carry the unadulterated system time. From the PGP SDK Reference Guide: PGPOCreationDate: Sets the creation date of keys, sub-keys, and signatures generated for the specified context. When a key, sub-keys, or signature is actually generated, the PGPsdk sets its creation date to that specified. Many thanks in advance. Kind regards Christian -- OmniMix .. protect your privacy http://www.danner-net.de/om.htm From wk at gnupg.org Sun Jan 28 16:22:32 2007 From: wk at gnupg.org (Werner Koch) Date: Sun, 28 Jan 2007 16:22:32 +0100 Subject: Feature request: --creation-date option In-Reply-To: <84uor29d9cc2r9ilnvt5bc16non5elup05@domain.is.invalid> (Christian Danner's message of "Sun\, 28 Jan 2007 11\:27\:08 +0100") References: <84uor29d9cc2r9ilnvt5bc16non5elup05@domain.is.invalid> Message-ID: <87tzybkwg7.fsf@wheatstone.g10code.de> On Sun, 28 Jan 2007 11:27, gnupg-devel_list at danner-net.de said: > Is there a chance to get an additional GPG option that allows to set > the creation date of keys and signatures? Would a option @item --faked-system-time @var{epoch} @opindex faked-system-time This option is only useful for testing; it sets the system time back or forth to @var{epoch} which is the number of seconds elapsed since the year 1970. be sufficient? We already have this for gpgsm. OTOH, a way to set the timestamp for new (sub)keys has applications too. Shalom-Salam, Werner From alphasigmax at gmail.com Sun Jan 28 17:22:33 2007 From: alphasigmax at gmail.com (Alphax) Date: Mon, 29 Jan 2007 02:52:33 +1030 Subject: Feature request: --creation-date option In-Reply-To: <87tzybkwg7.fsf@wheatstone.g10code.de> References: <84uor29d9cc2r9ilnvt5bc16non5elup05@domain.is.invalid> <87tzybkwg7.fsf@wheatstone.g10code.de> Message-ID: <45BCCDC9.5070103@gmail.com> Werner Koch wrote: > On Sun, 28 Jan 2007 11:27, gnupg-devel_list at danner-net.de said: > >> Is there a chance to get an additional GPG option that allows to set >> the creation date of keys and signatures? > > Would a option > > @item --faked-system-time @var{epoch} > @opindex faked-system-time > This option is only useful for testing; it sets the system time back or > forth to @var{epoch} which is the number of seconds elapsed since the year > 1970. > > be sufficient? We already have this for gpgsm. > > OTOH, a way to set the timestamp for new (sub)keys has applications > too. > eg. subkeys that only become valid /after/ a certain time? -- 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: 542 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20070129/399f910d/attachment.pgp From wk at gnupg.org Sun Jan 28 17:31:39 2007 From: wk at gnupg.org (Werner Koch) Date: Sun, 28 Jan 2007 17:31:39 +0100 Subject: Feature request: --creation-date option In-Reply-To: <45BCCDC9.5070103@gmail.com> (alphasigmax@gmail.com's message of "Mon\, 29 Jan 2007 02\:52\:33 +1030") References: <84uor29d9cc2r9ilnvt5bc16non5elup05@domain.is.invalid> <87tzybkwg7.fsf@wheatstone.g10code.de> <45BCCDC9.5070103@gmail.com> Message-ID: <878xfnkt90.fsf@wheatstone.g10code.de> On Sun, 28 Jan 2007 17:22, alphasigmax at gmail.com said: > eg. subkeys that only become valid /after/ a certain time? Right. This is useful to have a smooth key roll over. Subkeys with a timestamp in the future are not used unless the option --ignore-valid-from has been given. Salam-Shalom, Werner From dshaw at jabberwocky.com Sun Jan 28 18:17:13 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 28 Jan 2007 12:17:13 -0500 Subject: Feature request: --creation-date option In-Reply-To: <87tzybkwg7.fsf@wheatstone.g10code.de> References: <84uor29d9cc2r9ilnvt5bc16non5elup05@domain.is.invalid> <87tzybkwg7.fsf@wheatstone.g10code.de> Message-ID: <20070128171713.GB3166@jabberwocky.com> On Sun, Jan 28, 2007 at 04:22:32PM +0100, Werner Koch wrote: > On Sun, 28 Jan 2007 11:27, gnupg-devel_list at danner-net.de said: > > > Is there a chance to get an additional GPG option that allows to set > > the creation date of keys and signatures? > > Would a option > > @item --faked-system-time @var{epoch} > @opindex faked-system-time > This option is only useful for testing; it sets the system time back or > forth to @var{epoch} which is the number of seconds elapsed since the year > 1970. > > be sufficient? We already have this for gpgsm. > > OTOH, a way to set the timestamp for new (sub)keys has applications > too. I think these both have a good purpose. Perhaps they should be two different options, as the first sets all times (creation dates for keys and signatures), and the other sets just the creation date for a subkey (and not the selfsig). David From benjamin at py-soft.co.uk Sun Jan 28 18:38:12 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sun, 28 Jan 2007 17:38:12 +0000 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <20070105032836.GB19817@jabberwocky.com> References: <20070104.141847.12788317.kazu@iij.ad.jp> <20070105032836.GB19817@jabberwocky.com> Message-ID: <45BCDF84.5010109@py-soft.co.uk> David Shaw wrote: > Thanks, this (and a few other places with the same problem) was fixed > in SVN. It will be part of 2.0.2. Will v2.0.2 be released soon? I intend to package it up for the Mac. Take care, Ben From gnupg-devel_list at danner-net.de Sun Jan 28 20:12:45 2007 From: gnupg-devel_list at danner-net.de (Christian Danner) Date: Sun, 28 Jan 2007 20:12:45 +0100 Subject: Feature request: --creation-date option In-Reply-To: <87tzybkwg7.fsf@wheatstone.g10code.de> References: <84uor29d9cc2r9ilnvt5bc16non5elup05@domain.is.invalid> <87tzybkwg7.fsf@wheatstone.g10code.de> Message-ID: Hello all, on Sun, 28 Jan 2007 16:22:32 +0100, Werner Koch wrote: >Would a option > >@item --faked-system-time @var{epoch} >@opindex faked-system-time >This option is only useful for testing; it sets the system time back or >forth to @var{epoch} which is the number of seconds elapsed since the year >1970. > >be sufficient? We already have this for gpgsm. For my purpose already a uniform value would be great news as everyone knows the timestamps aren't authentic. Others may have problems with identical key creation and self-signature dates as they might indicate that the holder either owns a supercomputer or deals with timestamp forging. But your description doesn't say whether the transferred value exactly represents the resulting timestamps or is only used to calculate an internal timestamp offset initially so that the seconds passed while key creation still influence the timestamp of the signature. If the latter applies the time interval between creation and signing would allow to draw conclusions concerning the equipment that was used. >OTOH, a way to set the timestamp for new (sub)keys has applications >too. Don't the users resp. frontend developers bear responsibility to suit those data to their respective tasks? Many thanks for your efforts. Kind regards Christian -- OmniMix .. protect your privacy http://www.danner-net.de/om.htm From fw at deneb.enyo.de Mon Jan 29 14:23:37 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 29 Jan 2007 14:23:37 +0100 Subject: Feature request: --creation-date option In-Reply-To: <84uor29d9cc2r9ilnvt5bc16non5elup05@domain.is.invalid> (Christian Danner's message of "Sun, 28 Jan 2007 11:27:08 +0100") References: <84uor29d9cc2r9ilnvt5bc16non5elup05@domain.is.invalid> Message-ID: <87d54yvuee.fsf@mid.deneb.enyo.de> * Christian Danner: > Is there a chance to get an additional GPG option that allows to set > the creation date of keys and signatures? I agree that this might be useful. For a test suite, I had to create keys with a special DSO and LD_PRELOAD: A time-faking option in GnuPG would make this easier. From wk at gnupg.org Mon Jan 29 18:06:10 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Jan 2007 18:06:10 +0100 Subject: Request for a new status code for untrusted keys In-Reply-To: (Daiki Ueno's message of "Tue\, 26 Dec 2006 14\:05\:44 +0900") References: Message-ID: <87y7nl3gql.fsf@wheatstone.g10code.de> On Tue, 26 Dec 2006 06:05, ueno at unixuser.org said: > Hello, > > When I encrypt to a user whose key is not marked as trusted, gpg shows > detail information about the key and asks me to confirm. However, if > --no-tty is specified, there is no status code to indicate which > (sub)key is untrusted. > > $ gpg2 --no-tty --status-fd=1 --command-fd=0 -r 5B0358A2 \ > --encrypt /dev/null > gpg: C3680A6E: There is no assurance this key belongs to the named user > [GNUPG:] GET_BOOL untrusted_key.override > > Sorry for bothering you again, may I request a new status code (perhaps > NEED_TRUST )? What about this? $ gpg2 --no-tty --status-fd=1 --command-fd=0 -r B15813FE --encrypt -o /dev/null /dev/null gpg: 2A9BEA2D: There is no assurance this key belongs to the named user [GNUPG:] USERID_HINT 4447461B2A9BEA2D Daiki Ueno [GNUPG:] GET_BOOL untrusted_key.override This has the advantage of reusing the USERID_HINT as used with the passphrase prompt. It will display the subkey but that should not be a problem. Shalom-Salam, Werner From alon.barlev at gmail.com Mon Jan 29 23:21:53 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 30 Jan 2007 00:21:53 +0200 Subject: gnupg-2.0.1 - agen Message-ID: <200701300021.54497.alon.barlev@gmail.com> Hello, gnupg-2.01 ignores gpg-agent-info option. This should fix this. Best Regards, Alon Bar-Lev. --- diff -urNp gnupg-2.0.1.org/g10/call-agent.c gnupg-2.0.1/g10/call-agent.c --- gnupg-2.0.1.org/g10/call-agent.c 2006-10-04 16:49:27.000000000 +0200 +++ gnupg-2.0.1/g10/call-agent.c 2007-01-29 21:46:57.000000000 +0200 @@ -87,7 +87,10 @@ start_agent (void) return 0; /* fixme: We need a context for each thread or serialize the access to the agent. */ - infostr = force_pipe_server? NULL : getenv ("GPG_AGENT_INFO"); + if (opt.gpg_agent_info != NULL) + infostr = opt.gpg_agent_info; + else + infostr = force_pipe_server? NULL : getenv ("GPG_AGENT_INFO"); if (!infostr || !*infostr) { const char *pgmname; From alon.barlev at gmail.com Mon Jan 29 23:23:37 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 30 Jan 2007 00:23:37 +0200 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup Message-ID: <200701300023.37460.alon.barlev@gmail.com> [[Previous had incorrect subject]] Hello, gnupg-2.01 ignores gpg-agent-info option. This should fix this. Best Regards, Alon Bar-Lev. --- diff -urNp gnupg-2.0.1.org/g10/call-agent.c gnupg-2.0.1/g10/call-agent.c --- gnupg-2.0.1.org/g10/call-agent.c 2006-10-04 16:49:27.000000000 +0200 +++ gnupg-2.0.1/g10/call-agent.c 2007-01-29 21:46:57.000000000 +0200 @@ -87,7 +87,10 @@ start_agent (void) return 0; /* fixme: We need a context for each thread or serialize the access to the agent. */ - infostr = force_pipe_server? NULL : getenv ("GPG_AGENT_INFO"); + if (opt.gpg_agent_info != NULL) + infostr = opt.gpg_agent_info; + else + infostr = force_pipe_server? NULL : getenv ("GPG_AGENT_INFO"); if (!infostr || !*infostr) { const char *pgmname; From ueno at unixuser.org Tue Jan 30 06:52:10 2007 From: ueno at unixuser.org (Daiki Ueno) Date: Tue, 30 Jan 2007 14:52:10 +0900 Subject: Request for a new status code for untrusted keys In-Reply-To: <87y7nl3gql.fsf@wheatstone.g10code.de> (Werner Koch's message of "Mon, 29 Jan 2007 18:06:10 +0100") References: <87y7nl3gql.fsf@wheatstone.g10code.de> Message-ID: <87e22972-ecca-4d97-b473-ccc4a1990776@well-done.deisui.org> >>>>> In <87y7nl3gql.fsf at wheatstone.g10code.de> >>>>> Werner Koch wrote: > > When I encrypt to a user whose key is not marked as trusted, gpg shows > > detail information about the key and asks me to confirm. However, if > > --no-tty is specified, there is no status code to indicate which > > (sub)key is untrusted. > What about this? > $ gpg2 --no-tty --status-fd=1 --command-fd=0 -r B15813FE --encrypt -o /dev/null /dev/null > gpg: 2A9BEA2D: There is no assurance this key belongs to the named user > [GNUPG:] USERID_HINT 4447461B2A9BEA2D Daiki Ueno > [GNUPG:] GET_BOOL untrusted_key.override > This has the advantage of reusing the USERID_HINT as used with the > passphrase prompt. > It will display the subkey but that should not be a problem. Good idea. I just made a change to epg.el to utilize it. Thanks. -- Daiki Ueno From wk at gnupg.org Tue Jan 30 09:01:58 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jan 2007 09:01:58 +0100 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup In-Reply-To: <200701300023.37460.alon.barlev@gmail.com> (Alon Bar-Lev's message of "Tue\, 30 Jan 2007 00\:23\:37 +0200") References: <200701300023.37460.alon.barlev@gmail.com> Message-ID: <878xfl0wp5.fsf@wheatstone.g10code.de> On Mon, 29 Jan 2007 23:23, alon.barlev at gmail.com said: > gnupg-2.01 ignores gpg-agent-info option. > This should fix this. This was on purpose. --gpg-agent-info was a hack useful while developong gpg-agent. It should not be used anymore. Using the GPG_AGENT_INFO environment variable directly is better. gpg 1.4 will continue to support it but gpg2 won't support it. gpg2 will print a warning if this option has been used. The rationale for this is that the environment variable is the main anchor to keep all the GnupG modules together. Requiring all modules to have an extra --gpg-agent-info option is error prone and confusing. Salam-Shalom, Werner From wk at gnupg.org Tue Jan 30 09:03:26 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jan 2007 09:03:26 +0100 Subject: Request for a new status code for untrusted keys In-Reply-To: <87e22972-ecca-4d97-b473-ccc4a1990776@well-done.deisui.org> (Daiki Ueno's message of "Tue\, 30 Jan 2007 14\:52\:10 +0900") References: <87y7nl3gql.fsf@wheatstone.g10code.de> <87e22972-ecca-4d97-b473-ccc4a1990776@well-done.deisui.org> Message-ID: <871wld0wmp.fsf@wheatstone.g10code.de> On Tue, 30 Jan 2007 06:52, ueno at unixuser.org said: > Good idea. I just made a change to epg.el to utilize it. Okay. Will be in the next release. I hope to be able to release it tomorrow. Shalom-Salam, Werner From wk at gnupg.org Tue Jan 30 09:08:09 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jan 2007 09:08:09 +0100 Subject: GnuPG 2.0 and RIPEMD160 signatures with gpg-agent and an OpenPGP card In-Reply-To: <20070104201211.GA20389@vorlon.ping.de> (Michael Bienia's message of "Thu\, 4 Jan 2007 21\:12\:11 +0100") References: <20061222213429.GA9526@vorlon.ping.de> <20070104201211.GA20389@vorlon.ping.de> Message-ID: <87wt35ym1i.fsf@wheatstone.g10code.de> On Thu, 4 Jan 2007 21:12, michael at vorlon.ping.de said: > On 2006-12-22 22:34:29 +0100, Michael Bienia wrote: >> GnuPG 2.0 can only generate SHA1 signatures when used with gpg-agent and >> an OpenPGP card. I've already had the same problem with GnuPG 1.4 in >> March 2006 [1]. It was fixed with svn commits 4075 and 4076. > > Here is a patch for it. Thanks. Salam-Shalom, Werner From alon.barlev at gmail.com Tue Jan 30 09:16:02 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 30 Jan 2007 10:16:02 +0200 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup In-Reply-To: <878xfl0wp5.fsf@wheatstone.g10code.de> References: <200701300023.37460.alon.barlev@gmail.com> <878xfl0wp5.fsf@wheatstone.g10code.de> Message-ID: <9e0cf0bf0701300016h1d3ff9eal7a85f3e82d0cd371@mail.gmail.com> On 1/30/07, Werner Koch wrote: > This was on purpose. --gpg-agent-info was a hack useful while > developong gpg-agent. It should not be used anymore. Using the > GPG_AGENT_INFO environment variable directly is better. gpg 1.4 will > continue to support it but gpg2 won't support it. > > gpg2 will print a warning if this option has been used. > > The rationale for this is that the environment variable is the main > anchor to keep all the GnupG modules together. Requiring all modules > to have an extra --gpg-agent-info option is error prone and confusing. > Hello, But software like seahorse uses this option in order to redirect agent calls. It is more comfortable than using an environment variable in xinit, since the order of execution is not an issue. So please rethink of this... And no... I did not notice any warning... :) Best Regards, Alon Bar-Lev. From wk at gnupg.org Tue Jan 30 13:51:03 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jan 2007 13:51:03 +0100 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup In-Reply-To: <9e0cf0bf0701300016h1d3ff9eal7a85f3e82d0cd371@mail.gmail.com> (Alon Bar-Lev's message of "Tue\, 30 Jan 2007 10\:16\:02 +0200") References: <200701300023.37460.alon.barlev@gmail.com> <878xfl0wp5.fsf@wheatstone.g10code.de> <9e0cf0bf0701300016h1d3ff9eal7a85f3e82d0cd371@mail.gmail.com> Message-ID: <87veiowudk.fsf@wheatstone.g10code.de> On Tue, 30 Jan 2007 09:16, alon.barlev at gmail.com said: > But software like seahorse uses this option in order to redirect agent calls. > It is more comfortable than using an environment variable in xinit, since the > order of execution is not an issue. Sorry, I don't understand that argument. I can't see why gpg --gpg-agent-info $FOO is more complicated than GPG_AGENT_INFO=$FOO gpg Well, for fork/exec you need to use an extra putenv() but that is not a real issue. Dropping this options makes it even easier for seahorse as it goes into great lengths to detect such an option and remove it. BTW, soemone should file a bug with seahorse: instead of using its own conf file parser, it should make use of gpgconf which provides a standard interface to change options. > And no... I did not notice any warning... :) Well, I was a bit ahead of time. It will be in 2.0.2 :-) Shalom-Salam, Werner From alon.barlev at gmail.com Tue Jan 30 14:04:24 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 30 Jan 2007 15:04:24 +0200 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup In-Reply-To: <87veiowudk.fsf@wheatstone.g10code.de> References: <200701300023.37460.alon.barlev@gmail.com> <878xfl0wp5.fsf@wheatstone.g10code.de> <9e0cf0bf0701300016h1d3ff9eal7a85f3e82d0cd371@mail.gmail.com> <87veiowudk.fsf@wheatstone.g10code.de> Message-ID: <9e0cf0bf0701300504h45278958k2a3dc96d2ed39a32@mail.gmail.com> On 1/30/07, Werner Koch wrote: > Sorry, I don't understand that argument. I can't see why > > gpg --gpg-agent-info $FOO > > is more complicated than > > GPG_AGENT_INFO=$FOO gpg Hmmm.... :) The difference it when the software update ~/.gnupg/gpg.conf and put there: gpg-agent-info /tmp/foo.S > BTW, soemone should file a bug with seahorse: instead of using its > own conf file parser, it should make use of gpgconf which provides a > standard interface to change options. Well... OK... But first let's solve the first issue... I patched it to work with gpg2... so this is a good start, right :) I don't understand why in this case you should break backward compatibility... It is not like you removed a complicated workaround or logic... Best Regards, Alon Bar-Lev. From wk at gnupg.org Tue Jan 30 14:03:41 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jan 2007 14:03:41 +0100 Subject: Feature request: --creation-date option In-Reply-To: (Christian Danner's message of "Sun\, 28 Jan 2007 20\:12\:45 +0100") References: <84uor29d9cc2r9ilnvt5bc16non5elup05@domain.is.invalid> <87tzybkwg7.fsf@wheatstone.g10code.de> Message-ID: <87r6tcwtsi.fsf@wheatstone.g10code.de> On Sun, 28 Jan 2007 20:12, gnupg-devel_list at danner-net.de said: > But your description doesn't say whether the transferred value exactly > represents the resulting timestamps or is only used to calculate an > internal timestamp offset initially so that the seconds passed while It is an offset. > key creation still influence the timestamp of the signature. If the > latter applies the time interval between creation and signing would > allow to draw conclusions concerning the equipment that was used. That is a good suggestion we will change the self-signature creation routine to not reveal this information. Filed as bugs 750 and 751 (http://bugs.gnupg.org/750) Won't go into 2.02, though. Salam-Shalom, Werner From wk at gnupg.org Tue Jan 30 15:33:02 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jan 2007 15:33:02 +0100 Subject: How to Determine Digest Algorithm In-Reply-To: (Patrick Brunschwig's message of "Wed\, 20 Dec 2006 17\:40\:41 +0100") References: <4587A3D5.9060404@mozilla-enigmail.org> <20061219135031.GB14338@jabberwocky.com> Message-ID: <87lkjkwpnl.fsf@wheatstone.g10code.de> On Wed, 20 Dec 2006 17:40, patrick at mozilla-enigmail.org said: >> At the moment, not really, but it's not impossible to add a way to ask >> GPG the question "if you were going to make a signature, which hash >> algorithm would you use". > > That would be nice for the future, but I think in short term, I'll find > a way to cache the passphrase for the 2nd call to gpg. I have implemented the following: [GNUPG:] GOOD_PASSPHRASE [GNUPG:] BEGIN_SIGNING H2 [GNUPG:] SIG_CREATED S 1 2 00 1170166837 1DFED28E885CE98C170CEE80907B5D1640619DD0 -----BEGIN PGP MESSAGE----- Version: GnuPG v2.0.2-svn4352 (GNU/Linux) owGbwMvMwMQ4oTpWzCFx7gXG0/5JDK77Q0xssjOLEu0UMosVEhWKS4vSM5MTcxTK E4sUyjNSi1IVKvNLFdLzFdIzy1IVSjJSFdLyi1Iz0/MUSory8wuKFfLyi1MVsvKT iu25OuawMDAyMbCxMgGNNWXg4hSA2ZX2g/l/0o+PwTIm03i+HK3L+Pdy9tROgYg9 pUo/XXu+zTwSFHG9fxJ7KZeqzr40q8lfRSweSqcdfGAZ8P3KgYmO7ScnczLul1WM OjBpWtMX0b+XhK5uN2AV/lr1b93/M3OsgosvuG3REzFdaZYilHE3IMlN4fa7Q8ey pJy/pVr0hN4P3p76a69eiOgWAA== =kybe -----END PGP MESSAGE----- The thing here is that BEGIN_SIGANTURE is emitted before the input is processed. This means that it will work with very long files. This allows for constructing micalg while still right away. Note, that SIG_CREATED will only be emitted after the signature has been created (i.e. after all input data has been processed) and for each signature created. I general you will see only one argument, but be prepared that things like [GNUPG:] BEGIN_SIGNING H2 H8 are also possible. I suggest to take only the first one and ignore any possible extra hash algorithms (iirc, PGP/MIME does not allow to specify more than one micalg. This will be available in 2.0.2 and backported to 1.4 Shalom-Salam, Werner From wk at gnupg.org Tue Jan 30 15:36:56 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jan 2007 15:36:56 +0100 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup In-Reply-To: <9e0cf0bf0701300504h45278958k2a3dc96d2ed39a32@mail.gmail.com> (Alon Bar-Lev's message of "Tue\, 30 Jan 2007 15\:04\:24 +0200") References: <200701300023.37460.alon.barlev@gmail.com> <878xfl0wp5.fsf@wheatstone.g10code.de> <9e0cf0bf0701300016h1d3ff9eal7a85f3e82d0cd371@mail.gmail.com> <87veiowudk.fsf@wheatstone.g10code.de> <9e0cf0bf0701300504h45278958k2a3dc96d2ed39a32@mail.gmail.com> Message-ID: <87bqkgwph3.fsf@wheatstone.g10code.de> On Tue, 30 Jan 2007 14:04, alon.barlev at gmail.com said: > Well... OK... But first let's solve the first issue... > I patched it to work with gpg2... so this is a good start, right :) > > I don't understand why in this case you should break backward compatibility... > It is not like you removed a complicated workaround or logic... It is the other way around. --gpg-agent-info requires aspplications to scan and modify the conf file to make effective use of the envrionment variable. Salam-Shalom, Werner From alon.barlev at gmail.com Tue Jan 30 15:45:07 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 30 Jan 2007 16:45:07 +0200 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup In-Reply-To: <87bqkgwph3.fsf@wheatstone.g10code.de> References: <200701300023.37460.alon.barlev@gmail.com> <878xfl0wp5.fsf@wheatstone.g10code.de> <9e0cf0bf0701300016h1d3ff9eal7a85f3e82d0cd371@mail.gmail.com> <87veiowudk.fsf@wheatstone.g10code.de> <9e0cf0bf0701300504h45278958k2a3dc96d2ed39a32@mail.gmail.com> <87bqkgwph3.fsf@wheatstone.g10code.de> Message-ID: <9e0cf0bf0701300645i30e2b6e2k70fe0f9d909f8d2b@mail.gmail.com> On 1/30/07, Werner Koch wrote: > It is the other way around. --gpg-agent-info requires aspplications > to scan and modify the conf file to make effective use of the > envrionment variable. I don't follow you... Can you please explain what you mean? Thanks! Alon Bar-Lev. From patrick at mozilla-enigmail.org Tue Jan 30 15:42:02 2007 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Tue, 30 Jan 2007 15:42:02 +0100 Subject: How to Determine Digest Algorithm In-Reply-To: <87lkjkwpnl.fsf@wheatstone.g10code.de> References: <4587A3D5.9060404@mozilla-enigmail.org> <20061219135031.GB14338@jabberwocky.com> <87lkjkwpnl.fsf@wheatstone.g10code.de> Message-ID: <45BF593A.2000905@mozilla-enigmail.org> Werner Koch wrote: > On Wed, 20 Dec 2006 17:40, patrick at mozilla-enigmail.org said: > >>> At the moment, not really, but it's not impossible to add a way to ask >>> GPG the question "if you were going to make a signature, which hash >>> algorithm would you use". >> That would be nice for the future, but I think in short term, I'll find >> a way to cache the passphrase for the 2nd call to gpg. > > I have implemented the following: > > [GNUPG:] GOOD_PASSPHRASE > [GNUPG:] BEGIN_SIGNING H2 > [GNUPG:] SIG_CREATED S 1 2 00 1170166837 1DFED28E885CE98C170CEE80907B5D1640619DD0 > is a surgical war where you go give the foreign troops nose jobs? > The thing here is that BEGIN_SIGANTURE is emitted before the input is > processed. This means that it will work with very long files. This > allows for constructing micalg while still right away. Note, that > SIG_CREATED will only be emitted after the signature has been created > (i.e. after all input data has been processed) and for each signature > created. > > I general you will see only one argument, but be prepared that things > like > > [GNUPG:] BEGIN_SIGNING H2 H8 > > are also possible. I suggest to take only the first one and ignore > any possible extra hash algorithms (iirc, PGP/MIME does not allow to > specify more than one micalg. > This will be available in 2.0.2 and backported to 1.4 > Shalom-Salam, Great, thanks a lot! This will make it easier and more consistent to determine the hash algorithm. -Patrick From wk at gnupg.org Tue Jan 30 16:30:29 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jan 2007 16:30:29 +0100 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup In-Reply-To: <9e0cf0bf0701300645i30e2b6e2k70fe0f9d909f8d2b@mail.gmail.com> (Alon Bar-Lev's message of "Tue\, 30 Jan 2007 16\:45\:07 +0200") References: <200701300023.37460.alon.barlev@gmail.com> <878xfl0wp5.fsf@wheatstone.g10code.de> <9e0cf0bf0701300016h1d3ff9eal7a85f3e82d0cd371@mail.gmail.com> <87veiowudk.fsf@wheatstone.g10code.de> <9e0cf0bf0701300504h45278958k2a3dc96d2ed39a32@mail.gmail.com> <87bqkgwph3.fsf@wheatstone.g10code.de> <9e0cf0bf0701300645i30e2b6e2k70fe0f9d909f8d2b@mail.gmail.com> Message-ID: <87hcu8v8fe.fsf@wheatstone.g10code.de> On Tue, 30 Jan 2007 15:45, alon.barlev at gmail.com said: > I don't follow you... > Can you please explain what you mean? Please reread my previous message about Seehorse: They need a lot of code to remove the --gpg-agent-info option from gpg.conf so that they can set the one they want. [Checked today using the current Debian version of Seahorse]. Shalom-Salam, Werner From gnupg-devel_list at danner-net.de Tue Jan 30 16:40:22 2007 From: gnupg-devel_list at danner-net.de (Christian Danner) Date: Tue, 30 Jan 2007 16:40:22 +0100 Subject: Feature request: --creation-date option In-Reply-To: <87r6tcwtsi.fsf@wheatstone.g10code.de> References: <84uor29d9cc2r9ilnvt5bc16non5elup05@domain.is.invalid> <87tzybkwg7.fsf@wheatstone.g10code.de> <87r6tcwtsi.fsf@wheatstone.g10code.de> Message-ID: Hello Werner, on Tue, 30 Jan 2007 14:03:41 +0100, you wrote: >Won't go into 2.02, though. Hope you consider 1.4 as well? I see no chance to migrate to 2.0 as my project requires optional IDEA support. :-( Kind regards Christian -- OmniMix .. protect your privacy http://www.danner-net.de/om.htm From alon.barlev at gmail.com Tue Jan 30 16:52:59 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 30 Jan 2007 17:52:59 +0200 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup In-Reply-To: <87hcu8v8fe.fsf@wheatstone.g10code.de> References: <200701300023.37460.alon.barlev@gmail.com> <878xfl0wp5.fsf@wheatstone.g10code.de> <9e0cf0bf0701300016h1d3ff9eal7a85f3e82d0cd371@mail.gmail.com> <87veiowudk.fsf@wheatstone.g10code.de> <9e0cf0bf0701300504h45278958k2a3dc96d2ed39a32@mail.gmail.com> <87bqkgwph3.fsf@wheatstone.g10code.de> <9e0cf0bf0701300645i30e2b6e2k70fe0f9d909f8d2b@mail.gmail.com> <87hcu8v8fe.fsf@wheatstone.g10code.de> Message-ID: <9e0cf0bf0701300752n592664b9sab2e469799ac6a9d@mail.gmail.com> On 1/30/07, Werner Koch wrote: > On Tue, 30 Jan 2007 15:45, alon.barlev at gmail.com said: > > > I don't follow you... > > Can you please explain what you mean? > > Please reread my previous message about Seehorse: They need a lot of > code to remove the --gpg-agent-info option from gpg.conf so that they > can set the one they want. [Checked today using the current Debian > version of Seahorse]. I read carefully all your responses. And I do not follow you... I don't think I am stupid. Please explain again why you removed a simple option and broke backward compatibility. I would have understood if you had removed a good chunk of code... Please explain again how a program that is running at one X window, can affect the environment of another window, not all users wish to run the agent at xinit. I understand that writing the conf file directly and not use gpgconf is one issue... But it is irrelevant if you don't support specifying the agent-info at some place other than the environment. Currently seahorse takes a very simple approach with is very simple to users... You run their agent (it updates conf file), and gpg works! No environment no process tree dependencies no new arguments... You made this option available in the past, I don't understand why drop it now. Best Regards, Alon Bar-Lev. From wk at gnupg.org Tue Jan 30 21:42:16 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jan 2007 21:42:16 +0100 Subject: Feature request: --creation-date option In-Reply-To: (Christian Danner's message of "Tue\, 30 Jan 2007 16\:40\:22 +0100") References: <84uor29d9cc2r9ilnvt5bc16non5elup05@domain.is.invalid> <87tzybkwg7.fsf@wheatstone.g10code.de> <87r6tcwtsi.fsf@wheatstone.g10code.de> Message-ID: <87lkjkp7pz.fsf@wheatstone.g10code.de> On Tue, 30 Jan 2007 16:40, gnupg-devel_list at danner-net.de said: > Hope you consider 1.4 as well? I see no chance to migrate to 2.0 as my Yes. > project requires optional IDEA support. :-( It is a shame that Mixmaster is still based on an aged and patented algorithm. Even worse, Mixmaster is still non Free Software. I really wonder how long it will take until the Debian folks eventually remove it from main to bring some momentum in the development of a free implementation. Mixminion is not a suitable drop in replacement. Salam-Shalom, Werner From wk at gnupg.org Tue Jan 30 21:49:38 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jan 2007 21:49:38 +0100 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup In-Reply-To: <9e0cf0bf0701300752n592664b9sab2e469799ac6a9d@mail.gmail.com> (Alon Bar-Lev's message of "Tue\, 30 Jan 2007 17\:52\:59 +0200") References: <200701300023.37460.alon.barlev@gmail.com> <878xfl0wp5.fsf@wheatstone.g10code.de> <9e0cf0bf0701300016h1d3ff9eal7a85f3e82d0cd371@mail.gmail.com> <87veiowudk.fsf@wheatstone.g10code.de> <9e0cf0bf0701300504h45278958k2a3dc96d2ed39a32@mail.gmail.com> <87bqkgwph3.fsf@wheatstone.g10code.de> <9e0cf0bf0701300645i30e2b6e2k70fe0f9d909f8d2b@mail.gmail.com> <87hcu8v8fe.fsf@wheatstone.g10code.de> <9e0cf0bf0701300752n592664b9sab2e469799ac6a9d@mail.gmail.com> Message-ID: <87hcu8p7dp.fsf@wheatstone.g10code.de> On Tue, 30 Jan 2007 16:52, alon.barlev at gmail.com said: > Please explain again how a program that is running at one X window, > can affect the environment of another window, not all users wish to > run the agent at xinit. The seahorse agent seems to be a reincarnation of the quintuple-agent. That is not a proper solution. The gpg-agent solution is a far better one. You may disagree here but so be it. There is still 1.4 available implementing this option. Anyway, the seahorse agent won't work with future versions of gpg2. gpg2 will eventually move all secret key operation to gpg-agent and require support for the full, gpg-agent API. gpgsm already works this way and it is logical to do the same with gpg2. Shalom-Salam, Werner From robbat2 at gentoo.org Wed Jan 31 03:49:44 2007 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Tue, 30 Jan 2007 18:49:44 -0800 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup In-Reply-To: <87hcu8p7dp.fsf@wheatstone.g10code.de> References: <200701300023.37460.alon.barlev@gmail.com> <878xfl0wp5.fsf@wheatstone.g10code.de> <9e0cf0bf0701300016h1d3ff9eal7a85f3e82d0cd371@mail.gmail.com> <87veiowudk.fsf@wheatstone.g10code.de> <9e0cf0bf0701300504h45278958k2a3dc96d2ed39a32@mail.gmail.com> <87bqkgwph3.fsf@wheatstone.g10code.de> <9e0cf0bf0701300645i30e2b6e2k70fe0f9d909f8d2b@mail.gmail.com> <87hcu8v8fe.fsf@wheatstone.g10code.de> <9e0cf0bf0701300752n592664b9sab2e469799ac6a9d@mail.gmail.com> <87hcu8p7dp.fsf@wheatstone.g10code.de> Message-ID: <20070131024944.GC23455@curie-int.orbis-terrarum.net> On Tue, Jan 30, 2007 at 09:49:38PM +0100, Werner Koch wrote: > On Tue, 30 Jan 2007 16:52, alon.barlev at gmail.com said: > > > Please explain again how a program that is running at one X window, > > can affect the environment of another window, not all users wish to > > run the agent at xinit. > > The seahorse agent seems to be a reincarnation of the quintuple-agent. > That is not a proper solution. The gpg-agent solution is a far better > one. You may disagree here but so be it. There is still 1.4 > available implementing this option. > > Anyway, the seahorse agent won't work with future versions of gpg2. > gpg2 will eventually move all secret key operation to gpg-agent and > require support for the full, gpg-agent API. gpgsm already works this > way and it is logical to do the same with gpg2. I believe that the problem Alon is raising here is that how to get the agent-info string out to the right level without hacks every time. Consider this: 1. Your agent is running. 2. Your previous agent has crashed or is gone for some reason. 3. Open a terminal. 5. Start your agent (one that does not modify gpg.conf). 6. Agent prints out the socket location. 7. From your window manager, launch whatever GUI app that would use gpg via the agent. The GUI app in #5 there is no way to export the GPG_AGENT_INFO env var to the GUI app. If the agent is started prior to X, or during the startup of your window manager, and the GPG_AGENT_INFO env var is exported at that time, it does correctly exist while the agent is running. The only way to send that agent info string back is via a file. Modifying gpg.conf is one way to accomplish this. The other way is a wrapper for gpg that looks at a file for the socket, and sets the GPG_AGENT_INFO env var per that file. -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robbat2 at gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 329 bytes Desc: not available Url : /pipermail/attachments/20070130/5a79752d/attachment-0001.pgp From wk at gnupg.org Wed Jan 31 08:50:47 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Jan 2007 08:50:47 +0100 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup In-Reply-To: <20070131024944.GC23455@curie-int.orbis-terrarum.net> (Robin H. Johnson's message of "Tue\, 30 Jan 2007 18\:49\:44 -0800") References: <200701300023.37460.alon.barlev@gmail.com> <878xfl0wp5.fsf@wheatstone.g10code.de> <9e0cf0bf0701300016h1d3ff9eal7a85f3e82d0cd371@mail.gmail.com> <87veiowudk.fsf@wheatstone.g10code.de> <9e0cf0bf0701300504h45278958k2a3dc96d2ed39a32@mail.gmail.com> <87bqkgwph3.fsf@wheatstone.g10code.de> <9e0cf0bf0701300645i30e2b6e2k70fe0f9d909f8d2b@mail.gmail.com> <87hcu8v8fe.fsf@wheatstone.g10code.de> <9e0cf0bf0701300752n592664b9sab2e469799ac6a9d@mail.gmail.com> <87hcu8p7dp.fsf@wheatstone.g10code.de> <20070131024944.GC23455@curie-int.orbis-terrarum.net> Message-ID: <87sldrocrs.fsf@wheatstone.g10code.de> On Wed, 31 Jan 2007 03:49, robbat2 at gentoo.org said: > 1. Your agent is running. > 2. Your previous agent has crashed or is gone for some reason. This is a severe bug mich must never happen. Disguising such a bug by restarting the agent is a no-no. Keep in mind that the agent takes care of your secret keys - you wan't it as bug free as possible. Shalom-Salam, Werner From robbat2 at gentoo.org Wed Jan 31 12:24:13 2007 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Wed, 31 Jan 2007 03:24:13 -0800 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup In-Reply-To: <87sldrocrs.fsf@wheatstone.g10code.de> References: <9e0cf0bf0701300016h1d3ff9eal7a85f3e82d0cd371@mail.gmail.com> <87veiowudk.fsf@wheatstone.g10code.de> <9e0cf0bf0701300504h45278958k2a3dc96d2ed39a32@mail.gmail.com> <87bqkgwph3.fsf@wheatstone.g10code.de> <9e0cf0bf0701300645i30e2b6e2k70fe0f9d909f8d2b@mail.gmail.com> <87hcu8v8fe.fsf@wheatstone.g10code.de> <9e0cf0bf0701300752n592664b9sab2e469799ac6a9d@mail.gmail.com> <87hcu8p7dp.fsf@wheatstone.g10code.de> <20070131024944.GC23455@curie-int.orbis-terrarum.net> <87sldrocrs.fsf@wheatstone.g10code.de> Message-ID: <20070131112413.GH23455@curie-int.orbis-terrarum.net> On Wed, Jan 31, 2007 at 08:50:47AM +0100, Werner Koch wrote: > On Wed, 31 Jan 2007 03:49, robbat2 at gentoo.org said: > > 1. Your agent is running. > > 2. Your previous agent has crashed or is gone for some reason. > This is a severe bug mich must never happen. Disguising such a bug by > restarting the agent is a no-no. Keep in mind that the agent takes > care of your secret keys - you wan't it as bug free as possible. I agree totally, but forcing the user to restart X just to get their agent going again is completely unreasonable. -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robbat2 at gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 329 bytes Desc: not available Url : /pipermail/attachments/20070131/64b26d10/attachment.pgp From wk at gnupg.org Wed Jan 31 12:55:50 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Jan 2007 12:55:50 +0100 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup In-Reply-To: <20070131112413.GH23455@curie-int.orbis-terrarum.net> (Robin H. Johnson's message of "Wed\, 31 Jan 2007 03\:24\:13 -0800") References: <9e0cf0bf0701300016h1d3ff9eal7a85f3e82d0cd371@mail.gmail.com> <87veiowudk.fsf@wheatstone.g10code.de> <9e0cf0bf0701300504h45278958k2a3dc96d2ed39a32@mail.gmail.com> <87bqkgwph3.fsf@wheatstone.g10code.de> <9e0cf0bf0701300645i30e2b6e2k70fe0f9d909f8d2b@mail.gmail.com> <87hcu8v8fe.fsf@wheatstone.g10code.de> <9e0cf0bf0701300752n592664b9sab2e469799ac6a9d@mail.gmail.com> <87hcu8p7dp.fsf@wheatstone.g10code.de> <20070131024944.GC23455@curie-int.orbis-terrarum.net> <87sldrocrs.fsf@wheatstone.g10code.de> <20070131112413.GH23455@curie-int.orbis-terrarum.net> Message-ID: <87d54vmmux.fsf@wheatstone.g10code.de> On Wed, 31 Jan 2007 12:24, robbat2 at gentoo.org said: > I agree totally, but forcing the user to restart X just to get their > agent going again is completely unreasonable. And what a about the sshd for a remote session or on the local host the windowmanager or the sesssionmanager. If one of tehses processes crahsed, the X-session will simply die. So what is special with -gpg-agent? Well, it allows you to save your session and restart cleany. Shalom-Salam, Werner From gnupg-devel_list at danner-net.de Wed Jan 31 14:04:03 2007 From: gnupg-devel_list at danner-net.de (Christian Danner) Date: Wed, 31 Jan 2007 14:04:03 +0100 Subject: Feature request: --creation-date option In-Reply-To: <87lkjkp7pz.fsf@wheatstone.g10code.de> References: <84uor29d9cc2r9ilnvt5bc16non5elup05@domain.is.invalid> <87tzybkwg7.fsf@wheatstone.g10code.de> <87r6tcwtsi.fsf@wheatstone.g10code.de> <87lkjkp7pz.fsf@wheatstone.g10code.de> Message-ID: <97u0s29rvb4gvj8de359t7s914kqf3d7sl@domain.is.invalid> Hello Werner, on Tue, 30 Jan 2007 21:42:16 +0100, Werner Koch wrote: >On Tue, 30 Jan 2007 16:40, gnupg-devel_list at danner-net.de said: > >> Hope you consider 1.4 as well? I see no chance to migrate to 2.0 as my > >Yes. Glad to hear. >> project requires optional IDEA support. :-( > >It is a shame that Mixmaster is still based on an aged and patented >algorithm. Mixmaster can do without it. It's more about the ancient cypherpunk part used for nym reply messages, especially the 'Esub' directive, where currently there's no way around IDEA. 'Encrypt-Key' (IDEA) can be avoided, as there are the alternatives 'Encrypt-CAST' and 'Encrypt-3DES. But look at other well-known projects like Tor. AFAICS it's still accompanied by OpenSSL DLLs with built-in IDEA support, though IMHO there's no need to do so and it would be no problem to compile them without. >Even worse, Mixmaster is still non Free Software. I really wonder how >long it will take until the Debian folks eventually remove it from >main to bring some momentum in the development of a free >implementation. As long as anon remailing doesn't attract attention I'm sceptical about that. > Mixminion is not a suitable drop in replacement. It's still in an early stage of development with nym support not implemented yet. Within a few years we'll know. ;-) Kind regards Christian -- OmniMix .. protect your privacy http://www.danner-net.de/om.htm From wk at gnupg.org Wed Jan 31 15:15:48 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Jan 2007 15:15:48 +0100 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <20070105194302.GH1278@curie-int.orbis-terrarum.net> (Robin H. Johnson's message of "Fri\, 5 Jan 2007 11\:43\:02 -0800") References: <20070104.141847.12788317.kazu@iij.ad.jp> <20070105194302.GH1278@curie-int.orbis-terrarum.net> Message-ID: <87wt33l1t7.fsf@wheatstone.g10code.de> On Fri, 5 Jan 2007 20:43, robbat2 at gentoo.org said: > Independently of Kazu, some of our more obscure Gentoo users noted build > problems on Gentoo/OSX and Gentoo/FreeBSD. Same issue that Kazu noted, > just in a few more spots. Most of them are already fixed in the SVN and I hope I have fixed the rest of them now. I am currently preparing 2.0.2 Salam-Shalom, Werner From wk at gnupg.org Wed Jan 31 15:24:18 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Jan 2007 15:24:18 +0100 Subject: Feature request: --creation-date option In-Reply-To: <97u0s29rvb4gvj8de359t7s914kqf3d7sl@domain.is.invalid> (Christian Danner's message of "Wed\, 31 Jan 2007 14\:04\:03 +0100") References: <84uor29d9cc2r9ilnvt5bc16non5elup05@domain.is.invalid> <87tzybkwg7.fsf@wheatstone.g10code.de> <87r6tcwtsi.fsf@wheatstone.g10code.de> <87lkjkp7pz.fsf@wheatstone.g10code.de> <97u0s29rvb4gvj8de359t7s914kqf3d7sl@domain.is.invalid> Message-ID: <87sldrl1f1.fsf@wheatstone.g10code.de> On Wed, 31 Jan 2007 14:04, gnupg-devel_list at danner-net.de said: > But look at other well-known projects like Tor. AFAICS it's still > accompanied by OpenSSL DLLs with built-in IDEA support, though IMHO > there's no need to do so and it would be no problem to compile them > without. My OpenSSL has not support for IDEA ;-) > As long as anon remailing doesn't attract attention I'm sceptical > about that. Though I am running a big TOR exit node, I am more interested in anon remailing than in TOR. That is what would make GnuPG a real guard of privacy. >> Mixminion is not a suitable drop in replacement. > > It's still in an early stage of development with nym support not > implemented yet. Within a few years we'll know. ;-) Not using the GPL for it definitely didn't helped to gain attraction. For the next time in which we have to live with the semi-centralized email system, Mixmaster is a Good Thing. Thus I am really keen to see a free Mixmaster implementation. Shalom-Salam, Werner From benjamin at py-soft.co.uk Wed Jan 31 15:36:27 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Wed, 31 Jan 2007 14:36:27 +0000 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <87wt33l1t7.fsf@wheatstone.g10code.de> References: <20070104.141847.12788317.kazu@iij.ad.jp> <20070105194302.GH1278@curie-int.orbis-terrarum.net> <87wt33l1t7.fsf@wheatstone.g10code.de> Message-ID: <45C0A96B.6090301@py-soft.co.uk> Werner Koch wrote: > Most of them are already fixed in the SVN and I hope I have fixed the > rest of them now. I am currently preparing 2.0.2 Do you have any particular time scale in mind? I've had a quick look at the source, and I think the solution to the pinentry problem on the Mac lies in writing a Mac specific version of assuan-pipe-connect. (Assuming that NSTask does what I need). Take care, Ben From wk at gnupg.org Wed Jan 31 16:02:51 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Jan 2007 16:02:51 +0100 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <45C0A96B.6090301@py-soft.co.uk> (Benjamin Donnachie's message of "Wed\, 31 Jan 2007 14\:36\:27 +0000") References: <20070104.141847.12788317.kazu@iij.ad.jp> <20070105194302.GH1278@curie-int.orbis-terrarum.net> <87wt33l1t7.fsf@wheatstone.g10code.de> <45C0A96B.6090301@py-soft.co.uk> Message-ID: <877iv3kzms.fsf@wheatstone.g10code.de> On Wed, 31 Jan 2007 15:36, benjamin at py-soft.co.uk said: > Do you have any particular time scale in mind? I am currently testing the release. Shalom-Salam, Werner From benjamin at py-soft.co.uk Wed Jan 31 18:44:40 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Wed, 31 Jan 2007 17:44:40 +0000 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <45C0A96B.6090301@py-soft.co.uk> References: <20070104.141847.12788317.kazu@iij.ad.jp> <20070105194302.GH1278@curie-int.orbis-terrarum.net> <87wt33l1t7.fsf@wheatstone.g10code.de> <45C0A96B.6090301@py-soft.co.uk> Message-ID: <45C0D588.70106@py-soft.co.uk> Benjamin Donnachie wrote: > I've had a quick look at the source, and I think the solution to the > pinentry problem on the Mac lies in writing a Mac specific version of > assuan-pipe-connect. (Assuming that NSTask does what I need). Actually, I wonder whether creating bundle information for gpg-agent would be the solution... I'll give it a go soon and will let you know the outcome. Take care, Ben From benjamin at py-soft.co.uk Wed Jan 31 18:55:24 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Wed, 31 Jan 2007 17:55:24 +0000 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <70f41ba20701310723m6f892cfdy5fcfb1f1cbb38a8f@mail.gmail.com> References: <20070104.141847.12788317.kazu@iij.ad.jp> <20070105194302.GH1278@curie-int.orbis-terrarum.net> <87wt33l1t7.fsf@wheatstone.g10code.de> <45C0A96B.6090301@py-soft.co.uk> <70f41ba20701310723m6f892cfdy5fcfb1f1cbb38a8f@mail.gmail.com> Message-ID: <45C0D80C.5030406@py-soft.co.uk> snowcrash+gnupg-users wrote: > if made to work, then, _one_ solution fits all platforms, no? Personally, I'd rather do without the QT bloat. Perhaps wxWidgets is the answer; it's free, open source and comes with support for Windows 95/98/ME, Windows NT/2K/XP, Linux/Unix with the GTK+ toolkit (or plain X11, or Motif), and MacOS. It might turn out to be just as bloated but at least the licensing isn't as restrictive! Um, I'll see what I can do when I get time... Ben From alon.barlev at gmail.com Wed Jan 31 19:20:03 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 31 Jan 2007 20:20:03 +0200 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup In-Reply-To: <87d54vmmux.fsf@wheatstone.g10code.de> References: <9e0cf0bf0701300016h1d3ff9eal7a85f3e82d0cd371@mail.gmail.com> <87bqkgwph3.fsf@wheatstone.g10code.de> <9e0cf0bf0701300645i30e2b6e2k70fe0f9d909f8d2b@mail.gmail.com> <87hcu8v8fe.fsf@wheatstone.g10code.de> <9e0cf0bf0701300752n592664b9sab2e469799ac6a9d@mail.gmail.com> <87hcu8p7dp.fsf@wheatstone.g10code.de> <20070131024944.GC23455@curie-int.orbis-terrarum.net> <87sldrocrs.fsf@wheatstone.g10code.de> <20070131112413.GH23455@curie-int.orbis-terrarum.net> <87d54vmmux.fsf@wheatstone.g10code.de> Message-ID: <9e0cf0bf0701311020j4a127d02ha7abe8454520d476@mail.gmail.com> On 1/31/07, Werner Koch wrote: > And what a about the sshd for a remote session or on the local host > the windowmanager or the sesssionmanager. If one of tehses processes > crahsed, the X-session will simply die. So what is special with > -gpg-agent? Well, it allows you to save your session and restart > cleany. The question is not how ssh-agent manage this... or how it is right to implement it. The question is why you break backward compatibility, provided there is no complexity to keep supporting previous interface. Best Regards, Alon Bar-Lev. From gnupg-devel_list at danner-net.de Wed Jan 31 19:41:11 2007 From: gnupg-devel_list at danner-net.de (Christian Danner) Date: Wed, 31 Jan 2007 19:41:11 +0100 Subject: Feature request: --creation-date option In-Reply-To: <87sldrl1f1.fsf@wheatstone.g10code.de> References: <84uor29d9cc2r9ilnvt5bc16non5elup05@domain.is.invalid> <87tzybkwg7.fsf@wheatstone.g10code.de> <87r6tcwtsi.fsf@wheatstone.g10code.de> <87lkjkp7pz.fsf@wheatstone.g10code.de> <97u0s29rvb4gvj8de359t7s914kqf3d7sl@domain.is.invalid> <87sldrl1f1.fsf@wheatstone.g10code.de> Message-ID: <8ko1s21da2vdoqcnud45qr99383uv07sp2@domain.is.invalid> Hello Werner, on Wed, 31 Jan 2007 15:24:18 +0100, Werner Koch wrote: >> As long as anon remailing doesn't attract attention I'm sceptical >> about that. > >Though I am running a big TOR exit node, I am more interested in anon >remailing than in TOR. That is what would make GnuPG a real guard of >privacy. Tor is nice to have, but it's neither really secure nor does it cover the most sensitive kind of communication, which is individual email conversation. That's why I made it my business to develop an easy to use Windows proxy as a gateway to the Mixmaster network that has to work with every mail/news client application, is it in a native environment or from within Wine. Security and convenience have to meet to make anon remailing a success, hand rolling of messages is no alternative. And even if the latency of remailing can't be tolerated automated Whole-Message-Encryption would bring a huge amount of privacy. And of course with all those strategies GnuPG is a central component. >>> Mixminion is not a suitable drop in replacement. >> >> It's still in an early stage of development with nym support not >> implemented yet. Within a few years we'll know. ;-) > >Not using the GPL for it definitely didn't helped to gain attraction. > >For the next time in which we have to live with the semi-centralized >email system, Mixmaster is a Good Thing. Thus I am really keen to see >a free Mixmaster implementation. The Mixmaster license doesn't imply any restriction of use. I see one problem in the disregard of Windows users, so that there are no official binaries for years now. But mainly it's the handling of the remailer system that deters or overstretches most potential users. IMHO only a background service that handles the complete message I/O transparently in an unattended manner will make it accepted on a broader base. PGP/GPG also wouldn't have gained momentum without all those more or less ergonomic frontends, which mostly still leave a lot of room for improvement as well. There are similar deficits and, maybe, solutions. Kind regards Christian -- OmniMix .. protect your privacy http://www.danner-net.de/om.htm From schneecrash+gnupg-users at gmail.com Wed Jan 31 19:25:17 2007 From: schneecrash+gnupg-users at gmail.com (snowcrash+gnupg-users) Date: Wed, 31 Jan 2007 10:25:17 -0800 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <45C0D80C.5030406@py-soft.co.uk> References: <20070104.141847.12788317.kazu@iij.ad.jp> <20070105194302.GH1278@curie-int.orbis-terrarum.net> <87wt33l1t7.fsf@wheatstone.g10code.de> <45C0A96B.6090301@py-soft.co.uk> <70f41ba20701310723m6f892cfdy5fcfb1f1cbb38a8f@mail.gmail.com> <45C0D80C.5030406@py-soft.co.uk> Message-ID: <70f41ba20701311025t364fc102w2a339c19074d2932@mail.gmail.com> hi, > Personally, I'd rather do without the QT bloat. > Perhaps wxWidgets is the answer; it's free, open source and comes with > support for Windows 95/98/ME, Windows NT/2K/XP, Linux/Unix with the GTK+ > toolkit (or plain X11, or Motif), and MacOS. > > It might turn out to be just as bloated but at least the licensing isn't > as restrictive! Um, I'll see what I can do when I get time... the several wxwidgets apps that i've built/used haven't turned out to be the 'leanest' either ... but, in comparison, i don't know :-/ as for Qt, how's the licence 'restrictive'? it's GPL: http://www.trolltech.com/products/qt/licenses/licensing/opensource whereas wx is L-GPL: http://wxwidgets.org/about/newlicen.htm atm, Qt has the 'weight' of KDE behind it ... as GTK+ has Gnome (iirc -- not a gnome user, myself). wx may be a *fine* solution, but it IS *an additional* solution. From 567994 at mail.ru Fri Jan 26 00:57:10 2007 From: 567994 at mail.ru (Autoexport Firma aus Russland) Date: Fri, 26 Jan 2007 02:57:10 +0300 Subject: In-Reply-To: <1169769428.4235037055@mx30.mail.ru> References: <1169769428.4235037055@mx30.mail.ru> Message-ID: Gruss Gott! Wir sind Autoexport Firma aus Russland und haben unsere Autoankauf-Stutzpunkte in Osterreich und Deutschland. Sollten sie Ihr Auto jetzt oder zu einem spateren Zeitpunkt verkaufen wollen, bitte rufen sie uns an. Telefon in Osterreich: 0043-664-3434582 Telefon in Deutschland: 0049-171-6754088 Gerne kaufen wir Fahrzeuge mit Unfallschaden oder viel Kilometerleistung, Leasingrucklaufer, Firmenfahrzeuge, auch Tuv-fallig. Wir garantieren seriose Barabwicklung und sofortige Abholung Bundesweit ------------------------------------ Mail.Ru - ??????, ????????, ???????! ------------------------------------ From rjh at sixdemonbag.org Wed Jan 31 19:10:28 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 31 Jan 2007 12:10:28 -0600 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <45C0D80C.5030406@py-soft.co.uk> References: <20070104.141847.12788317.kazu@iij.ad.jp> <20070105194302.GH1278@curie-int.orbis-terrarum.net> <87wt33l1t7.fsf@wheatstone.g10code.de> <45C0A96B.6090301@py-soft.co.uk> <70f41ba20701310723m6f892cfdy5fcfb1f1cbb38a8f@mail.gmail.com> <45C0D80C.5030406@py-soft.co.uk> Message-ID: <45C0DB94.30405@sixdemonbag.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Benjamin Donnachie wrote: > Personally, I'd rather do without the QT bloat. I've always had an allergic reaction whenever people describe J. Random C++ Code as 'bloated'. Especially when the code in question has been shown to be very effective in the embedded hardware space (QTEmbedded). > It might turn out to be just as bloated but at least the licensing isn't > as restrictive! Um, I'll see what I can do when I get time... [scratches head] How, precisely, is the GPL a 'restrictive' license? I don't mean to be dense, but I just don't see it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBCAAGBQJFwNtZAAoJELcA9IL+r4EJz5gH/2/9phGR+lzNaoMqqcGSyF3D 4/fVdkWm6K79Tr4vMR4jXIMsFWH9GfC6GUCDTxtvNcP52uUnjtcwgkspGc/n5q2Z zCecJFPBmJkUC+ygYSvgzWD524Vx3xs3QK5lO6WgjraRxyEAQ6IoO+Yuhk3zwNrc IHNKOr3zuOS+Ooac7IFC1rl3sJpFBNu23gToA+A/PiYEnmYY8LAzV9PDkaxdXTZQ bZcHzPQ/VXcsKDTzxsoJYJ/g4X5LrYeyaZjzbADNh9ojnF7oxmw3/O5Wj5YMER/t r1G/1bONyyofn0rAv+0L0pd7D/ouvgxVrSbPxqBeFOPwtVaQMcdg/jkC6Byqd6I= =wnlH -----END PGP SIGNATURE----- From Jerel.Crosland at 21st.com Wed Jan 31 22:25:28 2007 From: Jerel.Crosland at 21st.com (Crosland, Jerel) Date: Wed, 31 Jan 2007 13:25:28 -0800 Subject: Feature Request: MS Exchange Server IDs Message-ID: <4C391E40D108AB45AB9982DF85AEA4DF5BFA12@VEXC215A.20thcentins.com> I need to be able to add my MS Exchange Server ID to the list of user ids in my public key, but gpg will not allow me to do so because it is considered an invalid email address. The ID looks like this: /O=20TH CENTURY/OU=TWENTIETHHQ/CN=RECIPIENTS/CN=Jerel.Crosland I know that PGP has had this support for some time. How hard would this be to add to gpg? Jerel Crosland x3187 It is dangerous to be sincere unless you are also stupid. - George Bernard Shaw *********************************************************************** This e-mail and any files transmitted with it are intended solely for the use of the addressee. This e-mail may contain confidential and/or legally privileged information. Any review, transmission, disclosure, copying, or any action taken or not taken, by other than the intended recipient, in reliance on the information, is prohibited. If you received this e-mail in error, notify the sender and delete this e-mail (and any accompanying material) from your computer and network. In addition, please be advised that 21st Century Insurance Group reserves the right to monitor, access and review all messages, data and images transmitted through our electronic mail system. By using our e-mail system, you consent to this monitoring. ***********************************************************************