From dshaw at jabberwocky.com Thu Feb 1 00:10:02 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 31 Jan 2007 18:10:02 -0500 Subject: Feature Request: MS Exchange Server IDs In-Reply-To: <4C391E40D108AB45AB9982DF85AEA4DF5BFA12@VEXC215A.20thcentins.com> References: <4C391E40D108AB45AB9982DF85AEA4DF5BFA12@VEXC215A.20thcentins.com> Message-ID: <20070131231002.GA28818@jabberwocky.com> On Wed, Jan 31, 2007 at 01:25:28PM -0800, Crosland, Jerel wrote: > 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 Use the --allow-freeform-uid option and you can add whatever ID you like. David From wk at gnupg.org Thu Feb 1 09:13:33 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Feb 2007 09:13:33 +0100 Subject: Feature Request: MS Exchange Server IDs In-Reply-To: <20070131231002.GA28818@jabberwocky.com> (David Shaw's message of "Wed\, 31 Jan 2007 18\:10\:02 -0500") References: <4C391E40D108AB45AB9982DF85AEA4DF5BFA12@VEXC215A.20thcentins.com> <20070131231002.GA28818@jabberwocky.com> Message-ID: <87mz3y47o2.fsf@wheatstone.g10code.de> On Thu, 1 Feb 2007 00:10, dshaw at jabberwocky.com said: >> /O=20TH CENTURY/OU=TWENTIETHHQ/CN=RECIPIENTS/CN=Jerel.Crosland > > Use the --allow-freeform-uid option and you can add whatever ID you > like. However, it does not make sense to put an X.509 address into an OpenPGP key. No mail program will use it. PGP has a hack to include an actual X.509 key into an OpenPGP key but there is no standard for it and GnuPG does not support it. If you really want to have your X.509 DN in the user ID of your OpenPGP key, I suggest to use the comment field. From dshaw at jabberwocky.com Thu Feb 1 15:03:29 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 1 Feb 2007 09:03:29 -0500 Subject: Feature Request: MS Exchange Server IDs In-Reply-To: <87mz3y47o2.fsf@wheatstone.g10code.de> References: <4C391E40D108AB45AB9982DF85AEA4DF5BFA12@VEXC215A.20thcentins.com> <20070131231002.GA28818@jabberwocky.com> <87mz3y47o2.fsf@wheatstone.g10code.de> Message-ID: <20070201140329.GB29330@jabberwocky.com> On Thu, Feb 01, 2007 at 09:13:33AM +0100, Werner Koch wrote: > On Thu, 1 Feb 2007 00:10, dshaw at jabberwocky.com said: > > >> /O=20TH CENTURY/OU=TWENTIETHHQ/CN=RECIPIENTS/CN=Jerel.Crosland > > > > Use the --allow-freeform-uid option and you can add whatever ID you > > like. > > However, it does not make sense to put an X.509 address into an > OpenPGP key. No mail program will use it. PGP has a hack to include > an actual X.509 key into an OpenPGP key but there is no standard for > it and GnuPG does not support it. Didn't one of the MS Exchange plugins require this sort of user ID? David From wk at gnupg.org Thu Feb 1 17:20:46 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Feb 2007 17:20:46 +0100 Subject: Feature Request: MS Exchange Server IDs In-Reply-To: <20070201140329.GB29330@jabberwocky.com> (David Shaw's message of "Thu\, 1 Feb 2007 09\:03\:29 -0500") References: <4C391E40D108AB45AB9982DF85AEA4DF5BFA12@VEXC215A.20thcentins.com> <20070131231002.GA28818@jabberwocky.com> <87mz3y47o2.fsf@wheatstone.g10code.de> <20070201140329.GB29330@jabberwocky.com> Message-ID: <87r6t9x31d.fsf@wheatstone.g10code.de> On Thu, 1 Feb 2007 15:03, dshaw at jabberwocky.com said: > Didn't one of the MS Exchange plugins require this sort of user ID? You mean the Outlook plugins from G-Data or our GPGol? No. Salam-Shalom, Werner From dshaw at jabberwocky.com Thu Feb 1 18:10:00 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 1 Feb 2007 12:10:00 -0500 Subject: Feature Request: MS Exchange Server IDs In-Reply-To: <87r6t9x31d.fsf@wheatstone.g10code.de> References: <4C391E40D108AB45AB9982DF85AEA4DF5BFA12@VEXC215A.20thcentins.com> <20070131231002.GA28818@jabberwocky.com> <87mz3y47o2.fsf@wheatstone.g10code.de> <20070201140329.GB29330@jabberwocky.com> <87r6t9x31d.fsf@wheatstone.g10code.de> Message-ID: <20070201171000.GA23780@jabberwocky.com> On Thu, Feb 01, 2007 at 05:20:46PM +0100, Werner Koch wrote: > On Thu, 1 Feb 2007 15:03, dshaw at jabberwocky.com said: > > > Didn't one of the MS Exchange plugins require this sort of user ID? > > You mean the Outlook plugins from G-Data or our GPGol? No. No, one of the PGP ones (not the current PGP - NAI?). It doesn't matter, really. Just a half memory. David From wk at gnupg.org Fri Feb 2 10:14:16 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Feb 2007 10:14:16 +0100 Subject: [Announce] Libgcrypt 1.2.4 released Message-ID: <87wt30syzb.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of Libgcrypt 1.2.4. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on the code used in GnuPG. This is a bug fix release solving a few minor issues. There are no new features. If you experience problems with an application using libgcrypt, you might want to update to this version. Noteworthy changes are: * Fixed a bug in the memory allocator which could have been the reason for some non-duplicable bugs. * Other minor bug fixes. Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source files and there digital signatures are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.4.tar.bz2 (781k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.4.tar.bz2.sig These files are bzip2 compressed. If you can't use the bunzip2 tool, gzip compressed versions of the files are also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.4.tar.gz (990k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.4.tar.gz.sig As an alternative a patch against version 1.2.3 is available as: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.3-1.2.4.diff.bz2 (87k) SHA-1 checksums are: c72406c69d6ad9fb3fa1e9824b04566cf204093b libgcrypt-1.2.4.tar.bz2 d279e7a4464cccf0cc4e29c374a1e8325fc65b9a libgcrypt-1.2.4.tar.gz d4f5525fa26e92ade2914c6581435171f8b4fc44 libgcrypt-1.2.3-1.2.4.diff.bz2 For help on installing or developing with Libgcrypt you should send mail to the grcypt-devel mailing list. For details see http://www.gnupg.org/documentation/mailing-lists.html . Improving Libgcrypt is costly, but you can help! We are looking for organizations that find Libgcrypt useful and wish to contribute back. You can contribute by reporting bugs, improve the software [1], or by donating money. Commercial support contracts for Libgcrypt are available [2], and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by gpg's principal author, is currently funding Libgcrypt development. We are always looking for interesting development projects. Happy hacking, Werner [1] As a GNU project copyright assignments to the FSF are required. [2] See the service directory at http://www.gnupg.org/service.html . -- Werner Koch The GnuPG Experts http://g10code.com Join the Fellowship and protect your Freedom! http://www.fsfe.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20070202/6194bdae/attachment.pgp -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Fri Feb 2 10:36:55 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Feb 2007 10:36:55 +0100 Subject: [Announce] GnuPG 2.0.2 released Message-ID: <87sldosxxk.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.2 This is maintenance release to fix build problems found after the release of 2.0.1. There are also some minor enhancements. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data, create digital signatures, help authenticating using Secure Shell and to provide a framework for public key cryptography. It includes an advanced key management facility and is compliant with the OpenPGP and S/MIME standards. GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.6) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. GnuPG is distributed under the terms of the GNU General Public License (GPL). GnuPG-2 works best on GNU/Linux or *BSD systems. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.2 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the following files in the *gnupg* directory: gnupg-2.0.2.tar.bz2 (3.8M) gnupg-2.0.2.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.1-2.0.2.diff.bz2 (53k) A patch file to upgrade a 2.0.1 GnuPG source. Note, that we don't distribute gzip compressed tarballs. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-2.0.2.tar.bz2 you would use this command: gpg --verify gnupg-2.0.2.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a keyserver like gpg --recv-key 1CE0C630 The distribution key 1CE0C630 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-2.0.2.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.2.tar.bz2 and check that the output matches the first line from the following list: 1a3165c5b601f3244b8885143d02bea4210495e3 gnupg-2.0.2.tar.bz2 1d42f46ae2c0d00b56be34bcd95fff51b77163a6 gnupg-2.0.1-2.0.2.diff.bz2 What's New =========== * Fixed a serious and exploitable bug in processing encrypted packages. [CVE-2006-6235]. Note, that a patch was distributed along with the first report of that bug. * Added --passphrase-repeat to set the number of times GPG will prompt for a new passphrase to be repeated. This is useful to help memorize a new passphrase. The default is 1 repetition. * Using a PIN pad does now also work for the signing key. * A warning is displayed by gpg-agent if a new passphrase is too short. New option --min-passphrase-len defaults to 8. * The status code BEGIN_SIGNING now shows the used hash algorithms. Internationalization ==================== GnuPG comes with support for 27 languages. Due to a lot of new and changed strings most translations are not entirely complete. The Swedish, Turkish, German and Russian translations should be complete. Documentation ============= We are currently working on an installation guide to explain in more detail how to configure the new features. As of now the chapters on gpg-agent and gpgsm include brief information on how to set up the whole thing. Please watch the GnuPG website for updates of the documentation. In the meantime you may search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. KDE's KMail is the most prominent user of GnuPG. In fact it has been developed along with the Kmail folks. Mutt users might want to use the configure option "--enable-gpgme" and "set use_crypt_gpgme" in ~/.muttrc to make use of GnuPG-2 to enable S/MIME in addition to a reworked OpenPGP support. Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or by donating money. Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. A service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team (David, Marcus, Werner and all other contributors) -- Werner Koch The GnuPG Experts http://g10code.com Join the Fellowship and protect your Freedom! http://www.fsfe.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20070202/8925fbd8/attachment.pgp -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From alon.barlev at gmail.com Fri Feb 2 14:45:43 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 2 Feb 2007 15:45:43 +0200 Subject: [Announce] Libgcrypt 1.2.4 released In-Reply-To: <87wt30syzb.fsf@wheatstone.g10code.de> References: <87wt30syzb.fsf@wheatstone.g10code.de> Message-ID: <200702021545.43248.alon.barlev@gmail.com> On Friday 02 February 2007, Werner Koch wrote: > * Other minor bug fixes. Hello Werner, I've sent you these in past, you did not include them. The first one is for strict aliasing and the second one is for powerpc64. 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) { --- 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 wk at gnupg.org Fri Feb 2 16:16:07 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Feb 2007 16:16:07 +0100 Subject: [Announce] Libgcrypt 1.2.4 released In-Reply-To: <200702021545.43248.alon.barlev@gmail.com> (Alon Bar-Lev's message of "Fri\, 2 Feb 2007 15\:45\:43 +0200") References: <87wt30syzb.fsf@wheatstone.g10code.de> <200702021545.43248.alon.barlev@gmail.com> Message-ID: <87sldomvyg.fsf@wheatstone.g10code.de> On Fri, 2 Feb 2007 14:45, alon.barlev at gmail.com said: > I've sent you these in past, you did not include them. > The first one is for strict aliasing and the second one is for powerpc64. I fear that the ac functions have more problems than just that. Thus not included. I have not considered your patch because it had already been applied and I forgot to check 1.2. I just committed it to 1.2. There is another potential problem with netbsd and openbsd: powerpc*-*-netbsd* | powerpc*-*-openbsd*) echo '/* configured {Open,Net}BSD on powerpc */' >>./mpi/asm-syntax.h echo '#define ELF_SYNTAX' >>./mpi/asm-syntax.h cat $srcdir/mpi/powerpc32/syntax.h >>./mpi/asm-syntax.h mpi_sflags="-Wa,-mppc" path="powerpc32" ;; ppc620-*-* | \ powerpc64*-*-*) mpi_sflags="-Wa,-mppc" path="powerpc64" ;; If anyone with access to such a platform can tell how this needs to be configure, I will add it. Shalom-Salam, Werner From marcus.brinkmann at ruhr-uni-bochum.de Sat Feb 3 16:27:27 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sat, 03 Feb 2007 16:27:27 +0100 Subject: [PATCH] gnupg-2.0.1 - gpg-agent-info option fixup In-Reply-To: <87sldrocrs.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> <20070131024944.GC23455@curie-int.orbis-terrarum.net> <87sldrocrs.fsf@wheatstone.g10code.de> Message-ID: <87abzv5kio.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Wed, 31 Jan 2007 08:50:47 +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. The same problem is faced on an upgrade though. It's a general issue in configuration/namespace management, and this particular scenario points out a defect, or lack of functionality, in the infrastructure design. For example, in the GNU/Hurd one can send messages to processes to update their environment variables at run time. That's not a proper solution (at all), but it points into the general direction of a potential solution here (namely the ability for processes to communicate and exchange information about changes in the configuration). Of course, all projects from a certain size up face these or similar challenges, and have work-arounds of various degrees of ugliness. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Sat Feb 3 16:42:40 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sat, 03 Feb 2007 16:42:40 +0100 Subject: [Announce] GPGME 1.1.3 released Message-ID: <878xff5jtb.wl%marcus.brinkmann@ruhr-uni-bochum.de> Hi, We are pleased to announce version 1.1.3 of GnuPG Made Easy, a library designed to make access to GnuPG easier for applications. It may be found in the file (about 897 KB/690 KB compressed) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.1.3.tar.gz ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.1.3.tar.bz2 The following files are also available: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.1.3.tar.gz.sig ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.1.3.tar.bz2.sig ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.1.2-1.1.3.diff.gz It should soon appear on the mirrors listed at: http://www.gnupg.org/mirrors.html Bug reports and requests for assistance should be sent to: gnupg-devel at gnupg.org The sha1sum checksums for this distibution are bf88701162d09a1bfacf72594fc32f374144158c gpgme-1.1.2-1.1.3.diff.gz e416854cb41a2e8b92a148ed17d2f2b97eeeba4a gpgme-1.1.3.tar.bz2 c41ca6df0b32281135ed95623dd5f8c0789b5671 gpgme-1.1.3.tar.bz2.sig 98ed8563da4870e3dd2d922e96983bf6a3e7cfb1 gpgme-1.1.3.tar.gz 303f46a7dfcf3581d2e6bad984d909e4f9359af1 gpgme-1.1.3.tar.gz.sig Noteworthy changes in version 1.1.3 (2007-01-29) ------------------------------------------------ * Fixed a memory leak in gpgme_data_release_and_get_mem. * Fixed a bug in Windows command line quoting. Marcus Brinkmann mb at g10code.de -- 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 _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From alon.barlev at gmail.com Sat Feb 3 20:09:12 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 3 Feb 2007 21:09:12 +0200 Subject: [Announce] GPGME 1.1.3 released In-Reply-To: <878xff5jtb.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <878xff5jtb.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200702032109.12618.alon.barlev@gmail.com> On Saturday 03 February 2007, Marcus Brinkmann wrote: > Hi, > > We are pleased to announce version 1.1.3 of GnuPG Made Easy, Hello, Please consider the following patch for freebsd. Best Regards, Alon Bar-Lev diff -urNp gpgme-1.1.3.org/assuan/assuan.h gpgme-1.1.3/assuan/assuan.h --- gpgme-1.1.3.org/assuan/assuan.h 2007-01-29 22:16:18.000000000 +0200 +++ gpgme-1.1.3/assuan/assuan.h 2007-02-03 20:57:23.000000000 +0200 @@ -24,6 +24,7 @@ #include #include +#include #include diff -urNp gpgme-1.1.3.org/assuan/funopen.c gpgme-1.1.3/assuan/funopen.c --- gpgme-1.1.3.org/assuan/funopen.c 2007-01-29 22:16:19.000000000 +0200 +++ gpgme-1.1.3/assuan/funopen.c 2007-02-03 20:57:23.000000000 +0200 @@ -39,7 +39,7 @@ cookie instead of the fiel descripor. */ - +#ifndef HAVE_FUNOPEN #ifdef HAVE_FOPENCOOKIE FILE * _assuan_funopen(void *cookie, @@ -62,3 +62,4 @@ _assuan_funopen(void *cookie, #else #error No known way to implement funopen. #endif +#endif From alphasigmax at gmail.com Sun Feb 4 08:41:48 2007 From: alphasigmax at gmail.com (Alphax) Date: Sun, 04 Feb 2007 18:11:48 +1030 Subject: [Announce] GnuPG 2.0.2 released In-Reply-To: <87sldosxxk.fsf@wheatstone.g10code.de> References: <87sldosxxk.fsf@wheatstone.g10code.de> Message-ID: <45C58E3C.3020706@gmail.com> Werner Koch wrote: > Hello! > > We are pleased to announce the availability of a new stable GnuPG-2 > release: Version 2.0.2 > Werner, Gnus isn't correctly setting the PGP/MIME headers so your signature isn't verifying... -- 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/20070204/6bae71da/attachment.pgp From wk at gnupg.org Mon Feb 5 09:36:24 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Feb 2007 09:36:24 +0100 Subject: [Announce] GnuPG 2.0.2 released In-Reply-To: <45C58E3C.3020706@gmail.com> (alphasigmax@gmail.com's message of "Sun\, 04 Feb 2007 18\:11\:48 +1030") References: <87sldosxxk.fsf@wheatstone.g10code.de> <45C58E3C.3020706@gmail.com> Message-ID: <87bqk9t307.fsf@wheatstone.g10code.de> On Sun, 4 Feb 2007 08:41, alphasigmax at gmail.com said: > Werner, Gnus isn't correctly setting the PGP/MIME headers so your > signature isn't verifying... Sorry, I can't confirm that. Gnus verifies the message correctly as well as Mutt does. Note that Mailman adds an extra container around any signed mail to not break the signature - thus only the inner part is signed and Mutt (using set crypt_use_gpgme) displays "Part of this message has not been signed". Salam-Shalom, Werner From patrick at mozilla-enigmail.org Mon Feb 5 11:07:21 2007 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Mon, 05 Feb 2007 11:07:21 +0100 Subject: [Announce] GnuPG 2.0.2 released In-Reply-To: <87bqk9t307.fsf@wheatstone.g10code.de> References: <87sldosxxk.fsf@wheatstone.g10code.de> <45C58E3C.3020706@gmail.com> <87bqk9t307.fsf@wheatstone.g10code.de> Message-ID: <45C701D9.5040401@mozilla-enigmail.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Werner Koch wrote: > On Sun, 4 Feb 2007 08:41, alphasigmax at gmail.com said: > >> Werner, Gnus isn't correctly setting the PGP/MIME headers so your >> signature isn't verifying... > > Sorry, I can't confirm that. Gnus verifies the message correctly as > well as Mutt does. Note that Mailman adds an extra container around > any signed mail to not break the signature - thus only the inner part > is signed and Mutt (using set crypt_use_gpgme) displays "Part of this > message has not been signed". Sorry Werner, but I have to agree with Alphax. The content-type of your mail contains "micalg=sha1", but correct PGP/MIME according to RFC 3156 requires "micalg=pgp-sha1". Enigmail only verifies PGP/MIME messages if micalc=pgp-. - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRccB2HcOpHodsOiwAQLkuQgArupwgj1v45Q8m7p+Jce99K6EP2NU68VZ qs6v5DrrpgKrTW2QLAjbZP3YBaJIlSs/aIJQw93mRtUHSRocwWdJOUtCPZu5s+VY hgnqQoUVmVgSOiQy1t3iofm2Ux6U59ATA/CqNsH1InbVa8lyUveaezLNDT3mHqos XPZY8IINMWoZscL0I5AS+xGopOQKIkgpSDm7v4ABHm0vmqDnWcVg9Yrql24ckWwn P7gYsa09HJJ2VC87pwiFSee21kSqN9NVtp7oxXSSOBJdMIpT5hS63q+vGSu19OHE dE9q5n5Zjq9qJPcDtAshhyCMhyjDt33yuNWGQ+5c59enfee30zkNzQ== =e7/o -----END PGP SIGNATURE----- From albrecht.dress at arcor.de Mon Feb 5 11:02:29 2007 From: albrecht.dress at arcor.de (Albrecht Dreß) Date: Mon, 5 Feb 2007 11:02:29 +0100 (CET) Subject: Aw: Re: [Announce] GnuPG 2.0.2 released In-Reply-To: <87bqk9t307.fsf@wheatstone.g10code.de> References: <87bqk9t307.fsf@wheatstone.g10code.de> <87sldosxxk.fsf@wheatstone.g10code.de> <45C58E3C.3020706@gmail.com> Message-ID: <25341564.1170669749348.JavaMail.ngmail@webmail17> > > Werner, Gnus isn't correctly setting the PGP/MIME headers so your > > signature isn't verifying... > > Sorry, I can't confirm that. Gnus verifies the message correctly as > well as Mutt does. Note that Mailman adds an extra container around > any signed mail to not break the signature - thus only the inner part > is signed and Mutt (using set crypt_use_gpgme) displays "Part of this > message has not been signed". I can confirm this problem when trying to verify the message with Balsa, which also uses gpgme. The problem is apparently that Gnus violates RFC 3156 [1], section 5 which states that The "micalg" parameter for the "application/pgp-signature" protocol MUST contain exactly one hash-symbol of the format "pgp-", where identifies the Message Integrity Check (MIC) algorithm used to generate the signature. Gnus omits the "pgp-" in the micalg parameter. Cheers, Albrecht. [1] http://www.ietf.org/rfc/rfc3156 Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: g?nstig und schnell mit DSL - das All-Inclusive-Paket f?r clevere Doppel-Sparer, nur 44,85 ? inkl. DSL- und ISDN-Grundgeb?hr! http://www.arcor.de/rd/emf-dsl-2 From m-iizuka at cp.jp.nec.com Wed Feb 7 02:09:42 2007 From: m-iizuka at cp.jp.nec.com (Mitsuho Iizuka) Date: Wed, 07 Feb 2007 10:09:42 +0900 (JST) Subject: gpgsm(gnupg2.0.1) keydb.c classify_user_id() problem Message-ID: <20070207.100942.74752502.m-iizuka@cp.jp.nec.com> Hi, Could anybody give some hint to specify a user ID by email adress ? I can't sign because of 'No public key' error as follows on Fedora Core 5 Linux. It seems there are 3 problems such as, 1) bad user argment, 2) bad certification, 3) not good keydb.c classify_user_id() implementation might exist. gpgsm: can't sign using `': No public key [GNUPG:] INV_RECP 1 exact command line is as follows. % ./gpgsm --detach-sign --include-certs 3 --status-fd 2 --local-user '' --output smime.p7s mew5430s-F According to the manual of gpgsm(2.0.1), it seems this user id argment is valid. However It seems gpgsm fails to search the USER with no need trailing '>' at the end of user-id on classify_user_id() of keydb.c(gpgsm 2.0.1) implementation on my certification bellow. I tried 2 other user specifying way, such as, m-iizuka at ... and ' Hi all, I am getting segfaults when executing gpg --gen-key (and other operations like --sign) my system is running linux kernel 2.6.16.x, gcc 4.1.1 and glibc 2.3.6. seems like it segfaults when calling tty_printf, can you help? Thanks, Here is the backtrace (gdb) run --gen-key Starting program: /mnt/hdb/ying/gnupg-1.4.6/g10/gpg --gen-key Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xffffe000 gpg (GnuPG) 1.4.6; 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. Program received signal SIGSEGV, Segmentation fault. 0xb7d90bb6 in ctermid () from /lib/libc.so.6 (gdb) bt #0 0xb7d90bb6 in ctermid () from /lib/libc.so.6 #1 0x080dab5c in tty_get_ttyname () at ttyio.c:103 #2 0x080dabf8 in init_ttyfp () at ttyio.c:160 #3 0x080daec5 in tty_printf ( fmt=0x8100448 "Please select what kind of key you want:\n") at ttyio.c:231 #4 0x080a8fc9 in ask_algo (addmode=0, r_usage=0xbfe22a24) at keygen.c:1433 #5 0x080aeaee in generate_keypair (fname=0x0, card_serialno=0x0, backup_encryption_dir=0x0) at keygen.c:2630 #6 0x080513a8 in main (argc=Cannot access memory at address 0x0 ) at gpg.c:3530 (gdb) From sbt2 at megacceso.com Wed Feb 7 17:06:40 2007 From: sbt2 at megacceso.com (Sergi Blanch i =?iso-8859-1?q?Torn=E9?=) Date: Wed, 07 Feb 2007 17:06:40 +0100 Subject: Embedded GnuPG Message-ID: <200702071706.40929.sbt2@megacceso.com> Hi list, I am interested to put inside a linux embedded system the GnuPG. Now, I am more interested in the 1.4 branch because also we want to use the elliptic curve patch (remember, unofficial, experimental, and underdevelopment). But in the future we will use the 2.0 branch. My question is, which should be the best way to have the thinest libraries and binaries to run the application? What is interesting to have, and what could be sacrificed? Thanks! /Sergi. From dshaw at jabberwocky.com Thu Feb 8 01:54:38 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 7 Feb 2007 19:54:38 -0500 Subject: segfault with gnupg 1.4.6 In-Reply-To: <45C44493.6010203@yingternet.com> References: <45C44493.6010203@yingternet.com> Message-ID: <20070208005438.GA18183@jabberwocky.com> On Sat, Feb 03, 2007 at 04:15:15PM +0800, Ying-Hung Chen wrote: > Hi all, > > I am getting segfaults when executing gpg --gen-key (and other > operations like --sign) > > my system is running linux kernel 2.6.16.x, gcc 4.1.1 and glibc 2.3.6. > > seems like it segfaults when calling tty_printf, can you help? This is a (already fixed) glibc issue. You'll need to update your glibc. See http://sources.redhat.com/ml/libc-hacker/2006-01/msg00008.html David From wk at gnupg.org Thu Feb 8 06:37:39 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Feb 2007 06:37:39 +0100 Subject: Embedded GnuPG In-Reply-To: <200702071706.40929.sbt2@megacceso.com> (Sergi Blanch i. =?utf-8?Q?Torn=C3=A9's?= message of "Wed\, 07 Feb 2007 17\:06\:40 +0100") References: <200702071706.40929.sbt2@megacceso.com> Message-ID: <87sldhtdjw.fsf@wheatstone.g10code.de> On Wed, 7 Feb 2007 17:06, sbt2 at megacceso.com said: > I am interested to put inside a linux embedded system the GnuPG. Now, I am > more interested in the 1.4 branch because also we want to use the elliptic > curve patch (remember, unofficial, experimental, and underdevelopment). But > in the future we will use the 2.0 branch. 1.4 does even run on system without MMU like the ColdFire. Use "./autogen.sh --build-uclinux" to run the configure for such a system. That port is some years old, so you might want to add the new --enable-minimal to the list of configure options. > My question is, which should be the best way to have the thinest libraries and > binaries to run the application? What is interesting to have, and what could > be sacrificed? 2.0 will be much harder because it takes up more space and requires preemptive multitasking. I have not looked at how to get 2.0 smaller. Shalom-Salam, Werner From rjh at sixdemonbag.org Fri Feb 9 00:32:28 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 8 Feb 2007 17:32:28 -0600 Subject: Autotools => CMake? Message-ID: <6F7E118C-DCE4-4CED-99E4-CA92F1F2C807@sixdemonbag.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Is there any interest in converting the 1.4.x series away from Autotools as a build system and towards CMake? CMake is a FOSS build system currently in use by KDE 4.0, along with some other systems, and is fairly widely available. Converting to CMake would also make it possible to use native compilers on Win32, which would simplify the bootstrap-from-Win32 process immensely. If there's interest in it, I'd be happy to spend some time looking into the port process. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iQEcBAEBCAAGBQJFy7MMAAoJELcA9IL+r4EJTq0H/1oFEbzJUQh5Z+TECoB9ZahT dYcLpwhHlg1w4qyDpLoyAheNFeHyKakvDZD21T7C5fxYGmSQUpxQNTOpCkeVd9H6 GVG3vrEzUFYPbOsZLDzOJ2W8BKTS0CQenXXy1WVyA4n26dZMqn7o0+S0/6QQ2hTJ z/nJeBdtDSvQzBYj6TGtd8T6edC6X1crw17DcpbmRW2gP9DNRtYJ9r5o7Fqszq7q NKHVmTgh8XAHMZ6yjEfTzKNVlvwRuOdCeS1HBzhcDbhlk0l5FmBCikmpDTC3TKEu NnLKWZApRTr99EEgJ2Y6iw+cQTXxWmJmB1GfhnzDAmCI1BZ2BU9vvhMA2v39k1g= =f+ZW -----END PGP SIGNATURE----- From wk at gnupg.org Fri Feb 9 10:16:46 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Feb 2007 10:16:46 +0100 Subject: Autotools => CMake? In-Reply-To: <6F7E118C-DCE4-4CED-99E4-CA92F1F2C807@sixdemonbag.org> (Robert J. Hansen's message of "Thu\, 8 Feb 2007 17\:32\:28 -0600") References: <6F7E118C-DCE4-4CED-99E4-CA92F1F2C807@sixdemonbag.org> Message-ID: <87zm7nitc1.fsf@wheatstone.g10code.de> On Fri, 9 Feb 2007 00:32, rjh at sixdemonbag.org said: > Is there any interest in converting the 1.4.x series away from > Autotools as a build system and towards CMake? CMake is a FOSS build No chance. We won't replace a matured system by something new for new good reason. GnuPG is known to build on several dozens of platforms, something KDE can't say of it (well some of the systems do not have a Gui for example). > it possible to use native compilers on Win32, which would simplify > the bootstrap-from-Win32 process immensely. I am not inetrested in supporting a toolchain on Windows. Did that in the past with other projects and it is a major headache. Cross- building is the clean solution. Salam-Shalom, Werner From sbt at megacceso.com Thu Feb 8 22:05:26 2007 From: sbt at megacceso.com (Sergi Blanch i Torne) Date: Thu, 8 Feb 2007 22:05:26 +0100 Subject: eccGnuPG Message-ID: <200702082205.48034.sbt@megacceso.com> Hi, The elliptic curve project to GnuPG has been moved to a new server. Now the web address is: http://www.calcurco.cat/eccGnuPG/ And the sources patch sould be available in: http://www.calcurco.cat/eccGnuPG/src/gnupg-1.4.6-ecc0.1.6.diff.bz2 And the beta patch in: http://www.calcurco.cat/eccGnuPG/src/gnupg-1.4.6-ecc0.2.0beta1.diff.bz2 Have a nice hack /Sergi. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 203 bytes Desc: not available Url : /pipermail/attachments/20070208/2c6afe74/attachment.pgp From benjamin at py-soft.co.uk Sun Feb 11 18:44:59 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sun, 11 Feb 2007 17:44:59 +0000 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <45C0D588.70106@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> <45C0D588.70106@py-soft.co.uk> Message-ID: <45CF561B.90305@py-soft.co.uk> Benjamin Donnachie wrote: > 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. Ah no, that didn't work. But invoking gpg-agent with the option --pinentry-program "/bin/sh -c /Applications/pinentry-mac.app/Contents/MacOS/pinentry-mac" did. I'll modify my start gpg-agent script and release a new version soon. It's not a particularly great solution, but makes gnupg 2.0.2 usable under MacOS. I haven't had chance to look into the MacOS function NSTask yet but if it does what we want correctly, I'll then look into a MacOS specific version of the assuan library. Take care, Ben From benjamin at py-soft.co.uk Sun Feb 11 18:53:29 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sun, 11 Feb 2007 17:53:29 +0000 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <45C0DB94.30405@sixdemonbag.org> 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> <45C0DB94.30405@sixdemonbag.org> Message-ID: <45CF5819.7010708@py-soft.co.uk> Robert J. Hansen 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). Fair point... I was thinking in terms of MacOS - to use QT you need about 2Mb of libraries. However, on my Linux machine I didn't consider it bloat as I already need it for KDE. >> 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. Um, wibble... LGPL? :-) Ben From zahn at snafu.de Fri Feb 9 17:46:53 2007 From: zahn at snafu.de (Steffen Zahn) Date: Fri, 09 Feb 2007 17:46:53 +0100 Subject: Ohhhh jeeee: no verify() for 16 Message-ID: <45CCA57D.1050805@snafu.de> Hello, does anyone know how to get rid of the message gpg: Ohhhh jeeee: no verify() for 16 ? I had it with gnupg 1.4.6, thought it might be time to upgrade to 2.0.2, but now the error is replaced by this an mpi of size 0 is not allowed an mpi of size 0 is not allowed gpg: keyring_get_keyblock: read error: Invalid packet gpg: keyring_get_keyblock failed: Invalid keyring gpg: failed to rebuild keyring cache: Invalid keyring best regards Steffen Zahn From benjamin at py-soft.co.uk Sun Feb 11 20:31:19 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sun, 11 Feb 2007 19:31:19 +0000 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <45CF561B.90305@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> <45C0D588.70106@py-soft.co.uk> <45CF561B.90305@py-soft.co.uk> Message-ID: <45CF6F07.9040809@py-soft.co.uk> Benjamin Donnachie wrote: > Ah no, that didn't work. But invoking gpg-agent with the option > --pinentry-program "/bin/sh -c > /Applications/pinentry-mac.app/Contents/MacOS/pinentry-mac" did. How embarrassing... my mistake - I was still using the old patched version! Ooops... :-/ Ben From wk at gnupg.org Mon Feb 12 10:33:39 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Feb 2007 10:33:39 +0100 Subject: Ohhhh jeeee: no verify() for 16 In-Reply-To: <45CCA57D.1050805@snafu.de> (Steffen Zahn's message of "Fri\, 09 Feb 2007 17\:46\:53 +0100") References: <45CCA57D.1050805@snafu.de> Message-ID: <87k5ynbtzg.fsf@wheatstone.g10code.de> On Fri, 9 Feb 2007 17:46, zahn at snafu.de said: > gpg: Ohhhh jeeee: no verify() for 16 This is the Elgamal algorithm which can't be used for signing. Something with your message or key is broken. > ? I had it with gnupg 1.4.6, thought it might be time to upgrade to > 2.0.2, but now the error is replaced by this > > an mpi of size 0 is not allowed > an mpi of size 0 is not allowed Very good. That does not bail out but returns a proper error. It would nice if you could identify the public key which causes this problem and send me a copy. Salam-Shalom, Werner From smenzel at gmx-gmbh.de Tue Feb 13 13:32:09 2007 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Tue, 13 Feb 2007 13:32:09 +0100 Subject: [gpgme] threadsafe? Message-ID: <200702131332.10496.smenzel@gmx-gmbh.de> Hi Guys, I'd just like to know if libgpgme when used to check S/MIME Signatures is threadsafe from within an application when several threads may check using the same engine and database and whatever but each thread got it's own gpgme_ctx_t _ctx; gpgme_new(&_ctx)); and gpgme_release(_ctx); after use. That should mean, that each of those contexts is only used once and released afterwards. There are no data structures I could see that are shared among the threads. Could the still be a problem when several threads use the lib simultaneously or does the context capsule it sufficiently? Thanks for your help and greetings... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070213/ab4eefdc/attachment.pgp From smenzel at gmx-gmbh.de Tue Feb 13 15:43:56 2007 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Tue, 13 Feb 2007 15:43:56 +0100 Subject: [gpgme] fork() problem Message-ID: <200702131543.56950.smenzel@gmx-gmbh.de> Hi there, another not quite simple question I have regarding gpgme is: How exactly does it work? Am I seeing this correctly that it uses fork() to start an external process and communicates with it through pipes? And if so, what happens to mutexes in that case. I often heard forking processes with mutexes is always messy and results in strange behaviour. (Stevens, "Unix IPC") To give you an example: I've got a multithreaded process here which uses gpgme to check signatures. After this has run for a certain time I notice that the processe's internal locking (pthread mutexes) doesn't seem to work anymore. Several mutexes of my own apparently are not unlocked anymore. And even more strange: Usually when I look at the process in question I see something like this: root ? ? ?9128 ?0.0 ?0.1 33860 4584 ? ? ?SNs ?13:58 ? 0:00 /usr/sbin/mypro nobody ?9129 40.4 ?2.3 140648 95904 ? SNs ?13:58 ?29:29 ?\_ /usr/sbin/mypro The demonized process and the working process with different rights. Right now I see this: root ? ? ?9128 ?0.0 ?0.1 33860 4584 ? ? ?SNs ?13:58 ? 0:00 /usr/sbin/mypro nobody ?9129 40.4 ?2.3 140648 95904 ? SNs ?13:58 ?29:29 ?\_ /usr/sbin/mypro nobody ? ? 4882 ?0.0 ?1.4 113408 61368 ? ?SN ? 14:03 ?0:00 /usr/sbin/mypro nobody ? ? 2905 ?0.0 ?2.0 138020 84748 ? SN ? 14:08 ? 0:00 /usr/sbin/mypro nobody ? 10988 ?0.0 ?2.1 142816 90308 ? ?SN ? 14:56 ? 0:00 /usr/sbin/mypro The original two I expect to see plus several (I noticed up to three) additional ones. I suppose those come from gpgme which is the only thing that has changed. When I look at the internal thread management of this process I see three threads hanging for about the time when those three threads have been created. So I assume they are doing signature checking and are hanging somewhere. When I attach gdb to any of those processes I see something like this: 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 ?0xffffe410 in __kernel_vsyscall () #1 ?0xb7b0881b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 #2 ?0xb7b059f3 in _L_mutex_lock_26 () from /lib/tls/i686/cmov/libpthread.so.0 #3 ?0xb6496530 in ?? () #4 ?0x00000000 in ?? () What I'm afraid of now is, that gpgme might fork() in order to do it's magic and mess up it's own mutexes (or mine) doing so. Does all that say anything to you guys or am I completely mistaken here? Greetings and thanks for your help... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070213/0a5457ca/attachment-0001.pgp From stephan-menzel at web.de Tue Feb 13 15:37:10 2007 From: stephan-menzel at web.de (Stephan Menzel) Date: Tue, 13 Feb 2007 15:37:10 +0100 Subject: [gpgme] fork() questions Message-ID: <200702131537.17678.stephan-menzel@web.de> Hi there, another not quite simple question I have regarding gpgme is: How exactly does it work? Am I seeing this correctly that it uses fork() to start an external process and communicates with it through pipes? And if so, what happens to mutexes in that case. I often heard forking processes with mutexes is always messy and results in strange behaviour. (Stevens, "Unix IPC") To give you an example: I've got a multithreaded process here which uses gpgme to check signatures. After this has run for a certain time I notice that the processe's internal locking (pthread mutexes) doesn't seem to work anymore. Several mutexes of my own apparently are not unlocked anymore. And even more strange: Usually when I look at the process in question I see something like this: root 9128 0.0 0.1 33860 4584 ? SNs 13:58 0:00 /usr/sbin/mypro nobody 9129 40.4 2.3 140648 95904 ? SNs 13:58 29:29 \_ /usr/sbin/mypro The demonized process and the working process with different rights. Right now I see this: root 9128 0.0 0.1 33860 4584 ? SNs 13:58 0:00 /usr/sbin/mypro nobody 9129 40.4 2.3 140648 95904 ? SNs 13:58 29:29 \_ /usr/sbin/mypro nobody 4882 0.0 1.4 113408 61368 ? SN 14:03 0:00 /usr/sbin/mypro nobody 2905 0.0 2.0 138020 84748 ? SN 14:08 0:00 /usr/sbin/mypro nobody 10988 0.0 2.1 142816 90308 ? SN 14:56 0:00 /usr/sbin/mypro The original two I expect to see plus several (I noticed up to three) additional ones. I suppose those come from gpgme which is the only thing that has changed. When I look at the internal thread management of this process I see three threads hanging for about the time when those three threads have been created. So I assume they are doing signature checking and are hanging somewhere. When I attach gdb to any of those processes I see something like this: 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7b0881b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb7b059f3 in _L_mutex_lock_26 () from /lib/tls/i686/cmov/libpthread.so.0 #3 0xb6496530 in ?? () #4 0x00000000 in ?? () What I'm afraid of now is, that gpgme might fork() in order to do it's magic and mess up it's own mutexes (or mine) doing so. Does all that say anything to you guys or am I completely mistaken here? Greetings and thanks for your help... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070213/7bc4dfdc/attachment.pgp From benjamin at py-soft.co.uk Tue Feb 13 20:03:24 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Tue, 13 Feb 2007 19:03:24 +0000 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <45CF6F07.9040809@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> <45C0D588.70106@py-soft.co.uk> <45CF561B.90305@py-soft.co.uk> <45CF6F07.9040809@py-soft.co.uk> Message-ID: <45D20B7C.8030909@py-soft.co.uk> Benjamin Donnachie wrote: > How embarrassing... my mistake - I was still using the old patched version! Ah-ha! That's better! As a quick test I threw together the following helper application: /* ** Mac OS fails to process bundle information correctly ** for pinentry-mac. ** ** This quick hack attempts to address that. ** */ #include int main() { return system ("/Applications/pinentry-mac.app/Contents/MacOS/pinentry-mac"); } Compile this using "gcc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc pinentry-helper.c -o pinentry-helper" (Or download from http://www.py-soft.co.uk/~benjamin/download/mac-gpg/pinentry-helper) and copy it to "/Applications/pinentry-mac.app/Contents/MacOS/pinentry-helper". Then add the following to ~/.gnupg/gpg-agent.conf: pinentry-program "/Applications/pinentry-mac.app/Contents/MacOS/pinentry-helper" Unpatched gpg-agent (admittedly v1.9.21) correctly invokes pinentry-mac, reading the GUI bundle information correctly. It needs more work to achieve a tidy solution - especially since the location of pinentry-mac is fixed and it fails to pass any command line arguments. Plus I might still use NSTask instead. Ben From benjamin at py-soft.co.uk Tue Feb 13 21:38:46 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Tue, 13 Feb 2007 20:38:46 +0000 Subject: [Macgpg-users] Compiling GnuPG 2.0.2 on MacOS X In-Reply-To: <45D20B7C.8030909@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> <45C0D588.70106@py-soft.co.uk> <45CF561B.90305@py-soft.co.uk> <45CF6F07.9040809@py-soft.co.uk> <45D20B7C.8030909@py-soft.co.uk> Message-ID: <45D221D6.7090603@py-soft.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Benjamin Donnachie wrote: > Unpatched gpg-agent (admittedly v1.9.21) correctly invokes pinentry-mac, > reading the GUI bundle information correctly. GnuPG v2.0.2 compiled without any patches on MacOS Tiger! :-) I must get round to making an install package soon. Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRdIh1egNmph0Y1E2AQK/Ww/9EzfI0vI0y5jGRmadlJfEKt1bx4bYkD6/ DCh1Cqw7Ay9o3T9a3C+YHn/xo3SogF4BIGr4l/Cb9IRHThzlreXDibX28DG8Y7zN 5J73mbuxYun5MSnjUeIJ2BAP3SUCDu+J0h2yq5GALnxi5ELCoD2K6p2eg9OO47WM o+9zZXoTm3cn6ZmhRKyxu7HVCvq8Z25gtwdd6pQIJKgAeCgv4J1gPyccfEX0ioXS sGC+gSMeFG9apY6OmuBR7q6RjrtLdWT3UuPXWnV1TILYNqcvN/MRYTQuhUfjWYVK yiQG3VA4pAi+UE7UvepcFWql4sGy25TC5gIpKssFsJ++G1AUy7ncjfhIHB8ovXTH /c4y8c0+/anQfBWWTI/uXRAdogVCkKCHaSelrlDfmZBSaT1kDjjJGDgL7wt2xZQV mhVbToj0G3ZcAk1K64cY80JjKcjNBAF7eE21MvfMGIgO81+p5pjb9pc9Cx1P10Ny T7LaKN14XBToQ5vAHyRqvW6o2192FctT4VU/VSVy71wRrHD6oY/VtwIMOOKMkLxS mCvg8W5SLdtOCwiFvP7x+YYD1b62XBbgtCS4cLNhQysrxdE7fEmPHseKSNTCSL4i 2bml1vE07jYYmfHD3jB6zMrcFAWFy/UwXUKSG81sCutGSI87USTcvKO8ph2xiUUX 1ROYHu1l9M0= =mzmY -----END PGP SIGNATURE----- From benjamin at py-soft.co.uk Tue Feb 13 22:36:41 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Tue, 13 Feb 2007 21:36:41 +0000 Subject: [Macgpg-users] GPG Keychain Access 0.7.1 as an Universal binary ? In-Reply-To: <2D0B037F-DD7C-42A3-8D9F-2625D9D6F797@rotz.org> 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> <45C0D588.70106@py-soft.co.uk> <45CF561B.90305@py-soft.co.uk> <45CF6F07.9040809@py-soft.co.uk> <45D20B7C.8030909@py-soft.co.uk> <45D221D6.7090603@py-soft.co.uk> <2D0B037F-DD7C-42A3-8D9F-2625D9D6F797@rotz.org> Message-ID: <45D22F69.2050000@py-soft.co.uk> Aldert Hazenberg wrote: > Question: while you are at "it" could you see if you can compile > GPG Keychain Access 0.7.1 as an Universal binary ? I didn't know that program existed! :-) > I noticed it is (still) an PowerPC application and basically almost > the last one on my Macbook, so if you could release an Universal binary > it would be fantastic. I tried... but I keep getting compile errors. It might be quicker if you contact Alexander, the macgpg project admin. Take care, Ben From Jerel.Crosland at 21st.com Tue Feb 13 22:53:08 2007 From: Jerel.Crosland at 21st.com (Crosland, Jerel) Date: Tue, 13 Feb 2007 13:53:08 -0800 Subject: Feature Request: MS Exchange Server IDs Message-ID: <4C391E40D108AB45AB9982DF85AEA4DF5BFA3A@VEXC215A.20thcentins.com> >On Thu, Feb 01, 2007 at 05:20:46PM +0100, Werner Koch wrote: >> On Thu, 1 Feb 2007 15:03, dshaw at jabberwocky.com said: >> >> > Didn't one of the MS Exchange plugins require this sort of user ID? >> >> You mean the Outlook plugins from G-Data or our GPGol? No. > >No, one of the PGP ones (not the current PGP - NAI?). It doesn't >matter, really. Just a half memory. > >David The problem I'm trying to solve here is that I'm using OUTLOOK in an EXCHANGE environment and GPGol cannot find the public key of the recipient of a message. Sorry to repeat myself, but it seems the sense of my message was missed. I'll rephrase. I need to be able to add my MS Exchange Server ID to the list of user ids in my public key so that GPGol/gpg will be able to find it when another user in my Exchange environment who is also using GPGol tries to encrypt a message to me. Gnupg will not allow me to do so because it is considered an invalid email address. The ID which GPGol is using to try and find the public key looks like this: /O=20TH CENTURY/OU=TWENTIETHHQ/CN=RECIPIENTS/CN=Jerel.Crosland Of course I would rather it simply use my email address, then all would be well, but I can find no place in GPGol to configure this, so it must use the "MS Exchange Server ID" instead. I know that PGP has had this support for some time. Is the proper solution to simply do as David Shaw recommends, and use the --allow-freeform-uid option? If so, how can GPGol be configured to do this? Thanks for your patience. I'm just trying to make this easy enough that others here will use this. Jerel *********************************************************************** 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. *********************************************************************** From aldert at rotz.org Tue Feb 13 21:51:12 2007 From: aldert at rotz.org (Aldert Hazenberg) Date: Tue, 13 Feb 2007 21:51:12 +0100 Subject: GPG Keychain Access 0.7.1 as an Universal binary ? In-Reply-To: <45D221D6.7090603@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> <45C0D588.70106@py-soft.co.uk> <45CF561B.90305@py-soft.co.uk> <45CF6F07.9040809@py-soft.co.uk> <45D20B7C.8030909@py-soft.co.uk> <45D221D6.7090603@py-soft.co.uk> Message-ID: <2D0B037F-DD7C-42A3-8D9F-2625D9D6F797@rotz.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 13, 2007, at 9:38 PM, Benjamin Donnachie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Benjamin Donnachie wrote: >> Unpatched gpg-agent (admittedly v1.9.21) correctly invokes >> pinentry-mac, >> reading the GUI bundle information correctly. > > GnuPG v2.0.2 compiled without any patches on MacOS Tiger! :-) > > I must get round to making an install package soon. > > Ben Ben, you seem to be on fire lately :) Thanks for the great work, also on the 1.4(.6) branch that I use daily. Question: while you are at "it" could you see if you can compile GPG Keychain Access 0.7.1 as an Universal binary ? http://sourceforge.net/project/showfiles.php? group_id=20789&package_id=39077 I noticed it is (still) an PowerPC application and basically almost the last one on my Macbook, so if you could release an Universal binary it would be fantastic. Thanks in advance ! Aldert. - -- Aldert J.B.P. Hazenberg Email : aldert at rotz.org Phone : voip/skype on request IM : several on request The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" but "That's funny..." -- Isaac Asimov (1920-1992) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFF0iTCBzBfhr1N+1ARAvKlAJ9FJoeqskENqV3GPMrPRAfbpGeesACdFsYO u3qR2hbS67gSCP4tln0RgfM= =MiW0 -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Wed Feb 14 04:40:47 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 13 Feb 2007 22:40:47 -0500 Subject: Feature Request: MS Exchange Server IDs In-Reply-To: <4C391E40D108AB45AB9982DF85AEA4DF5BFA3A@VEXC215A.20thcentins.com> References: <4C391E40D108AB45AB9982DF85AEA4DF5BFA3A@VEXC215A.20thcentins.com> Message-ID: <20070214034047.GA4462@jabberwocky.com> On Tue, Feb 13, 2007 at 01:53:08PM -0800, Crosland, Jerel wrote: > I need to be able to add my MS Exchange Server ID to the list of user > ids in my public key so that GPGol/gpg will be able to find it when > another user in my Exchange environment who is also using GPGol tries to > encrypt a message to me. Gnupg will not allow me to do so because it is > considered an invalid email address. The ID which GPGol is using to try > and find the public key looks like this: > > /O=20TH CENTURY/OU=TWENTIETHHQ/CN=RECIPIENTS/CN=Jerel.Crosland > > Of course I would rather it simply use my email address, then all would > be well, but I can find no place in GPGol to configure this, so it must > use the "MS Exchange Server ID" instead. I know that PGP has had this > support for some time. > > Is the proper solution to simply do as David Shaw recommends, and use > the --allow-freeform-uid option? If so, how can GPGol be configured to > do this? GPGol does not need to be configured for this and can find any user ID. The --allow-freeform-uid option is used when creating the key or when adding the new user ID to the key. David From roam at ringlet.net Wed Feb 14 09:22:19 2007 From: roam at ringlet.net (Peter Pentchev) Date: Wed, 14 Feb 2007 10:22:19 +0200 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <45D20B7C.8030909@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> <45C0D588.70106@py-soft.co.uk> <45CF561B.90305@py-soft.co.uk> <45CF6F07.9040809@py-soft.co.uk> <45D20B7C.8030909@py-soft.co.uk> Message-ID: <20070214082219.GA1956@straylight.m.ringlet.net> On Tue, Feb 13, 2007 at 07:03:24PM +0000, Benjamin Donnachie wrote: > Benjamin Donnachie wrote: > > How embarrassing... my mistake - I was still using the old patched version! > > Ah-ha! That's better! As a quick test I threw together the following > helper application: > > /* > ** Mac OS fails to process bundle information correctly > ** for pinentry-mac. > ** > ** This quick hack attempts to address that. > ** > */ > > #include > > int main() > { > return system > ("/Applications/pinentry-mac.app/Contents/MacOS/pinentry-mac"); > } Is there any reason for not using execv(3)? (disclaimer: not tested on PPC or MacOS X or, really, anything besides FreeBSD/i386 and Debian/i386...) #include #include #ifndef __unused #if defined(__GNUC__) && !defined(__INTEL_COMPILER) #define __unused __attribute__((unused)) #else /* __GNUC__ */ #if defined(__INTEL_COMPILER) #define __unused __attribute__((__unused__)) #else /* __INTEL_COMPILER */ #define __unused #endif /* __INTEL_COMPILER */ #endif /* __GNUC__ */ #endif /* __unused */ #define APP "/Applications/pinentry-mac.app/Contents/MacOS/pinentry-mac" int main(int argc __unused, char * const argv[]) { execv(APP, argv); perror("execv"); return (1); } Of course, you may skip the whole __unused dance if you know that you are only ever going to compile it on a single OS/arch/compiler - or if you don't care about compiler warnings :) > Compile this using "gcc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch > i386 -arch ppc pinentry-helper.c -o pinentry-helper" (Or download from > http://www.py-soft.co.uk/~benjamin/download/mac-gpg/pinentry-helper) and > copy it to "/Applications/pinentry-mac.app/Contents/MacOS/pinentry-helper". > > Then add the following to ~/.gnupg/gpg-agent.conf: > > pinentry-program > "/Applications/pinentry-mac.app/Contents/MacOS/pinentry-helper" > > Unpatched gpg-agent (admittedly v1.9.21) correctly invokes pinentry-mac, > reading the GUI bundle information correctly. > > It needs more work to achieve a tidy solution - especially since the > location of pinentry-mac is fixed and it fails to pass any command line > arguments. The above will take care of passing command-line arguments; the executable location might be handled by a symlink or something. > Plus I might still use NSTask instead. G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at cnsys.bg roam at FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Nostalgia ain't what it used to be. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20070214/4b6be4f0/attachment-0001.pgp From christianbiere at gmx.de Wed Feb 14 15:06:35 2007 From: christianbiere at gmx.de (Christian Biere) Date: Wed, 14 Feb 2007 15:06:35 +0100 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <20070214082219.GA1956@straylight.m.ringlet.net> 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> <45C0D588.70106@py-soft.co.uk> <45CF561B.90305@py-soft.co.uk> <45CF6F07.9040809@py-soft.co.uk> <45D20B7C.8030909@py-soft.co.uk> <20070214082219.GA1956@straylight.m.ringlet.net> Message-ID: <20070214140635.GB17944@cyclonus> Peter Pentchev wrote: > #include > #include > > #ifndef __unused > #if defined(__GNUC__) && !defined(__INTEL_COMPILER) > #define __unused __attribute__((unused)) > #else /* __GNUC__ */ > #if defined(__INTEL_COMPILER) > #define __unused __attribute__((__unused__)) > #else /* __INTEL_COMPILER */ > #define __unused > #endif /* __INTEL_COMPILER */ > #endif /* __GNUC__ */ > #endif /* __unused */ > > #define APP "/Applications/pinentry-mac.app/Contents/MacOS/pinentry-mac" > > int main(int argc __unused, char * const argv[]) > { > execv(APP, argv); > perror("execv"); > return (1); > } > > Of course, you may skip the whole __unused dance if you know that you > are only ever going to compile it on a single OS/arch/compiler - or if > you don't care about compiler warnings :) How about sticking to portable standard C? (void) argc; works everywhere. You cannot defined __unused yourself. This namespace is reserved for the implementation. And it looks quite ugly anyway. It's not like you need C for this anyway: #! /bin/sh exec whatever "$@" exit 1 -- Christian From smenzel at gmx-gmbh.de Wed Feb 14 16:32:03 2007 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Wed, 14 Feb 2007 16:32:03 +0100 Subject: [gpgme] fork() problem In-Reply-To: <200702131543.56950.smenzel@gmx-gmbh.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> Message-ID: <200702141632.07698.smenzel@gmx-gmbh.de> Am Dienstag, 13. Februar 2007 15:43:56 schrieb Stephan Menzel: > What I'm afraid of now is, that gpgme might fork() in order to do it's > magic and mess up it's own mutexes (or mine) doing so. > Does all that say anything to you guys or am I completely mistaken here? I have some additional info here. I played around a bit and I tried to wrap my own mutex around the whole thing and disable it's internal locking by linking against libgpgme.so.11 instead of libgpgme-pthread.so.11 even though it's a multithreaded app. And indeed, I couldn't see anymore of those problems. Instead I got several crashes apparently due to failed assertions in the lib. The stacktraces look like this: #0 0xffffe410 in __kernel_vsyscall () (gdb) backtrace #0 0xffffe410 in __kernel_vsyscall () #1 0xb711d885 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb711f002 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7117318 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0xb6731e03 in _gpgme_ath_mutex_lock (lock=0x0) at ath.c:71 #5 0xb6741e2f in _gpgme_sema_cs_enter (s=0xb674db40) at posix-sema.c:48 #6 0xb673bd3b in _gpgme_engine_info_copy (r_info=0x0) at engine.c:225 #7 0xb6743070 in gpgme_new (r_ctx=0x0) at gpgme.c:58 #8 0xb732e9f3 in MyWrapperClass (this=0xb1782768) at MyWrapperClass.cc:187 It still doesn't crash all the time though. It mostly works so I think it's some strange race condition. Maybe this helps. Thanks and greetings... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070214/b3052a11/attachment.pgp From smenzel at gmx-gmbh.de Wed Feb 14 16:56:23 2007 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Wed, 14 Feb 2007 16:56:23 +0100 Subject: [gpgme] fork() problem In-Reply-To: <200702141632.07698.smenzel@gmx-gmbh.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> <200702141632.07698.smenzel@gmx-gmbh.de> Message-ID: <200702141656.24328.smenzel@gmx-gmbh.de> Am Mittwoch, 14. Februar 2007 16:32:03 schrieb Stephan Menzel: > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb711d885 in raise () from /lib/tls/i686/cmov/libc.so.6 > #2 0xb711f002 in abort () from /lib/tls/i686/cmov/libc.so.6 > #3 0xb7117318 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 > #4 0xb6731e03 in _gpgme_ath_mutex_lock (lock=0x0) at ath.c:71 > #5 0xb6741e2f in _gpgme_sema_cs_enter (s=0xb674db40) at posix-sema.c:48 > #6 0xb673bd3b in _gpgme_engine_info_copy (r_info=0x0) at engine.c:225 > #7 0xb6743070 in gpgme_new (r_ctx=0x0) at gpgme.c:58 ... but not all of them. Got another one like this: #0 0xffffe410 in __kernel_vsyscall () #1 0xb70c4885 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb70c6002 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb70be318 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0xb66d8e52 in _gpgme_ath_mutex_unlock (lock=0x0) at ath.c:83 #5 0xb66e8e5f in _gpgme_sema_cs_leave (s=0xb66f4b20) at posix-sema.c:54 #6 0xb66e2e84 in _gpgme_engine_info_copy (r_info=0x0) at engine.c:298 #7 0xb66ea074 in gpgme_new (r_ctx=0x0) at gpgme.c:55 perhaps those Macros LOCK and UNLOCK act on null initailized pointers when you do int ath_mutex_unlock (ath_mutex_t *lock) { #ifndef NDEBUG assert (*lock == MUTEX_LOCKED); *lock = MUTEX_UNLOCKED; #endif return 0; } It looks like there is a null pointer coming in all those cases. Stephan, hth -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070214/06916d78/attachment.pgp From benjamin at py-soft.co.uk Wed Feb 14 19:58:28 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Wed, 14 Feb 2007 18:58:28 +0000 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <20070214082219.GA1956@straylight.m.ringlet.net> 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> <45C0D588.70106@py-soft.co.uk> <45CF561B.90305@py-soft.co.uk> <45CF6F07.9040809@py-soft.co.uk> <45D20B7C.8030909@py-soft.co.uk> <20070214082219.GA1956@straylight.m.ringlet.net> Message-ID: <45D35BD4.1000703@py-soft.co.uk> Peter Pentchev wrote: > Is there any reason for not using execv(3)? 'cos I was searching through my MacOS programming book for a solution to MacOS X not reading the GUI bundle information and it suggested using system. > G'luck, Christian's suggestion of trying a shell script was perfect and makes my life soooooo much easier! :) Ben From Jerel.Crosland at 21st.com Wed Feb 14 20:24:24 2007 From: Jerel.Crosland at 21st.com (Crosland, Jerel) Date: Wed, 14 Feb 2007 11:24:24 -0800 Subject: Feature Request: MS Exchange Server IDs Message-ID: <4C391E40D108AB45AB9982DF85AEA4DF5BFA50@VEXC215A.20thcentins.com> Apparently not. Whenever I am sending an email using Outlook to another user within my local network/domain I must always manually select which key to encrypt to. It is not finding the external email address but only the internal, Exchange version of the ID, which is that long form I have listed. Jerel Crosland Technical Specialist 21st Century Insurance Stupidity does not qualify as a handicap, park elsewhere! -----Original Message----- From: gnupg-devel-bounces at gnupg.org [mailto:gnupg-devel-bounces at gnupg.org]On Behalf Of David Shaw Sent: Tuesday, February 13, 2007 7:41 PM To: gnupg-devel at gnupg.org Subject: Re: Feature Request: MS Exchange Server IDs On Tue, Feb 13, 2007 at 01:53:08PM -0800, Crosland, Jerel wrote: > I need to be able to add my MS Exchange Server ID to the list of user > ids in my public key so that GPGol/gpg will be able to find it when > another user in my Exchange environment who is also using GPGol tries to > encrypt a message to me. Gnupg will not allow me to do so because it is > considered an invalid email address. The ID which GPGol is using to try > and find the public key looks like this: > > /O=20TH CENTURY/OU=TWENTIETHHQ/CN=RECIPIENTS/CN=Jerel.Crosland > > Of course I would rather it simply use my email address, then all would > be well, but I can find no place in GPGol to configure this, so it must > use the "MS Exchange Server ID" instead. I know that PGP has had this > support for some time. > > Is the proper solution to simply do as David Shaw recommends, and use > the --allow-freeform-uid option? If so, how can GPGol be configured to > do this? GPGol does not need to be configured for this and can find any user ID. The --allow-freeform-uid option is used when creating the key or when adding the new user ID to the key. David _______________________________________________ Gnupg-devel mailing list Gnupg-devel at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-devel *********************************************************************** 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. *********************************************************************** From dshaw at jabberwocky.com Wed Feb 14 20:47:31 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 14 Feb 2007 14:47:31 -0500 Subject: Feature Request: MS Exchange Server IDs In-Reply-To: <4C391E40D108AB45AB9982DF85AEA4DF5BFA50@VEXC215A.20thcentins.com> References: <4C391E40D108AB45AB9982DF85AEA4DF5BFA50@VEXC215A.20thcentins.com> Message-ID: <20070214194731.GA8434@jabberwocky.com> On Wed, Feb 14, 2007 at 11:24:24AM -0800, Crosland, Jerel wrote: > Apparently not. Whenever I am sending an email using Outlook to > another user within my local network/domain I must always manually > select which key to encrypt to. It is not finding the external email > address but only the internal, Exchange version of the ID, which is > that long form I have listed. The thread up til now has been about adding the Exchange version of the ID because the external ID was not workable. Now it seems that goal has been reached, as the Exchange ID is being found. However now it seems this isn't what you wanted to happen. I'm afraid I can't help you further as I no longer understand what goal you are trying to reach. David From benjamin at py-soft.co.uk Wed Feb 14 19:56:04 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Wed, 14 Feb 2007 18:56:04 +0000 Subject: Compiling GnuPG 2.0.2 on MacOS X In-Reply-To: <20070214140635.GB17944@cyclonus> 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> <45C0D588.70106@py-soft.co.uk> <45CF561B.90305@py-soft.co.uk> <45CF6F07.9040809@py-soft.co.uk> <45D20B7C.8030909@py-soft.co.uk> <20070214082219.GA1956@straylight.m.ringlet.net> <20070214140635.GB17944@cyclonus> Message-ID: <45D35B44.7040405@py-soft.co.uk> Christian Biere wrote: > It's not like you need C for this anyway: > #! /bin/sh > exec whatever "$@" > exit 1 FANTASTIC! I just didn't think of that and a shell script works perfectly! :-) Ben From twoaday at gmx.net Wed Feb 14 21:18:50 2007 From: twoaday at gmx.net (Timo Schulz) Date: Wed, 14 Feb 2007 21:18:50 +0100 Subject: Feature Request: MS Exchange Server IDs In-Reply-To: <4C391E40D108AB45AB9982DF85AEA4DF5BFA50@VEXC215A.20thcentins.com> References: <4C391E40D108AB45AB9982DF85AEA4DF5BFA50@VEXC215A.20thcentins.com> Message-ID: <45D36EAA.3050906@gmx.net> Crosland, Jerel wrote: >> considered an invalid email address. The ID which GPGol is using to try >> and find the public key looks like this: >> >> /O=20TH CENTURY/OU=TWENTIETHHQ/CN=RECIPIENTS/CN=Jerel.Crosland I'm not sure if this is a good idea, but maybe Exchange address detection could be added to the GPGol code. It is actcually a plugin for Exchange and thus the scenario might be not a single case. But for this, the CN value needs to be mapped to a valid part of the user ID. Example CN=Jerel.Crosland -> uid: Jerel.Crosland Of course Jerel.Crosland needs to be unique in the keyring, or else GPGol would show the recipient dialog again, and this is the reason why I'm not sure it's a good idea. Timo From jbglaw at lug-owl.de Wed Feb 14 21:05:58 2007 From: jbglaw at lug-owl.de (Jan-Benedict Glaw) Date: Wed, 14 Feb 2007 21:05:58 +0100 Subject: Feature Request: MS Exchange Server IDs In-Reply-To: <4C391E40D108AB45AB9982DF85AEA4DF5BFA50@VEXC215A.20thcentins.com> References: <20070214034047.GA4462@jabberwocky.com> <4C391E40D108AB45AB9982DF85AEA4DF5BFA50@VEXC215A.20thcentins.com> Message-ID: <20070214200558.GZ23849@lug-owl.de> On Wed, 2007-02-14 11:24:24 -0800, Crosland, Jerel wrote: > > -----Original Message----- > > From: gnupg-devel-bounces at gnupg.org > > [mailto:gnupg-devel-bounces at gnupg.org]On Behalf Of David Shaw > > Sent: Tuesday, February 13, 2007 7:41 PM > > To: gnupg-devel at gnupg.org > > Subject: Re: Feature Request: MS Exchange Server IDs > > On Tue, Feb 13, 2007 at 01:53:08PM -0800, Crosland, Jerel wrote: > > > I need to be able to add my MS Exchange Server ID to the list of user > > > ids in my public key so that GPGol/gpg will be able to find it when > > > another user in my Exchange environment who is also using GPGol tries to > > > encrypt a message to me. Gnupg will not allow me to do so because it is > > > considered an invalid email address. The ID which GPGol is using to try > > > and find the public key looks like this: > > > > > > /O=20TH CENTURY/OU=TWENTIETHHQ/CN=RECIPIENTS/CN=Jerel.Crosland > > GPGol does not need to be configured for this and can find any user > > ID. The --allow-freeform-uid option is used when creating the key or > > when adding the new user ID to the key. > Apparently not. Whenever I am sending an email using Outlook to > another user within my local network/domain I must always manually > select which key to encrypt to. It is not finding the external > email address but only the internal, Exchange version of the ID, > which is that long form I have listed. See this example: jbglaw at bixie:~$ gpg --gen-key --allow-freeform-uid gpg (GnuPG) 1.4.6; 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. Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (5) RSA (sign only) Your selection? DSA keypair will have 1024 bits. ELG-E keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) " Real name: Jan-Benedict Glaw TEST KEY ONLY Email address: /O=20TH CENTURY/OU=TWENTIETHHQ/CN=RECIPIENTS/CN=Jerel.Crosland Comment: You selected this USER-ID: "Jan-Benedict Glaw TEST KEY ONLY " Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o You need a Passphrase to protect your secret key. You don't want a passphrase - this is probably a *bad* idea! I will do it anyway. You can change your passphrase at any time, using this program with the option "--edit-key". We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. ++++++++++.+++++.++++++++++.++++++++++++++++++++.+++++++++++++++.+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.................... ............>+++++...+++++ We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. +++++..+++++.+++++++++++++++.+++++......+++++++++++++++..++++++++++++++++++++++++++++++.+++++.+++++.+++++.+++++++++++++++++++++++++++++++++++++++++++++.+++++..+++++>..+++++.+++++>+++++>+++++...............................<.+++++...+++++^^^ gpg: key 576B8B6B marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u pub 1024D/576B8B6B 2007-02-14 Key fingerprint = 4C96 D2FF DE8E 1BCF F968 FC6C 1EF2 9C58 576B 8B6B uid Jan-Benedict Glaw TEST KEY ONLY sub 2048g/8C68F224 2007-02-14 jbglaw at bixie:~$ gpg --list-keys '/O=20TH CENTURY/OU=TWENTIE > THHQ/CN=RECIPIENTS/CN=Jerel.Crosland jbglaw at bixie:~$ gpg --list-keys '/O=20TH CENTURY/OU=TWENTIETHHQ/CN=RECIPIENTS/CN=Jerel.Crosland' pub 1024D/576B8B6B 2007-02-14 uid Jan-Benedict Glaw TEST KEY ONLY sub 2048g/8C68F224 2007-02-14 See? I can create a key with such an "email" address and I can search for it. jbglaw at bixie:~$ gpg --allow-freeform-uid --edit 0x576B8B6B gpg (GnuPG) 1.4.6; Copyright (C) 2006 Free Software Foundation, Inc. [...] This also works as expected. Could you please *exactly* describe the problem you're facing? Are you missing success generating a UID in certificate form? Or does it fail to find it? It would probably help if you'd describe step-by-step what you're doing, like I did in the example above. MfG, JBG -- Jan-Benedict Glaw jbglaw at lug-owl.de +49-172-7608481 Signature of: "really soon now": an unspecified period of time, likly to the second : be greater than any reasonable definition of "soon". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20070214/23e0fda7/attachment-0001.pgp From gnupg-devel_list at danner-net.de Fri Feb 16 13:00:16 2007 From: gnupg-devel_list at danner-net.de (Christian Danner) Date: Fri, 16 Feb 2007 13:00:16 +0100 Subject: UID ordering Message-ID: Hi! Is it possible that the list of a key's user-ids returned by GPG 1.4.6 is reordered and doesn't represent their positions within the key? What am I missing? ------------------------------------------------------------ GPGkeys - PGP Packets for Key 0x6C4BF737 :public key packet: version 3, algo 1, created 1154610531, expires 1187874531 pkey[0]: [2048 bits] pkey[1]: [5 bits] :user ID packet: "Panta Rhei Remailer RSA [Expires 23.08.2007] " :signature packet: algo 1, keyid 1B0F37346C4BF737 version 3, created 1154610531, md5len 5, sigclass 10 digest algo 1, begin of digest 55 7f data: [2048 bits] :signature packet: algo 1, keyid 621C2B8BB2FD58C5 version 3, created 1154893468, md5len 5, sigclass 10 digest algo 1, begin of digest ad 13 data: [2048 bits] :user ID packet: "Panta Rhei Remailer RSA [Expires 23.08.2007] " :signature packet: algo 1, keyid 1B0F37346C4BF737 version 3, created 1154610577, md5len 5, sigclass 10 digest algo 1, begin of digest d7 c1 data: [2046 bits] :signature packet: algo 1, keyid 621C2B8BB2FD58C5 version 3, created 1154893460, md5len 5, sigclass 10 digest algo 1, begin of digest 35 c8 data: [2048 bits] ------------------------------------------------------------ Befehl> list pub 2048R/6C4BF737 created: 2006-08-03 expires: 2007-08-23 usage: SCEA trust: unbekannt G?ltigkeit: unbekannt [ unknown] (1). Panta Rhei Remailer RSA [Expires 23.08.2007] [ unknown] (2) Panta Rhei Remailer RSA [Expires 23.08.2007] ------------------------------------------------------------ First appearing uid record: uid:-::::1154610577::1406DE961A7A9D1BF62021D9D90E061790284146::Panta Rhei Remailer RSA [Expires 23.08.2007] : ------------------------------------------------------------ But (o.k.) ------------------------------------------------------------ GPGkeys - PGP Packets for Key 0x98CAE13F :public key packet: version 4, algo 17, created 1154610183, expires 0 pkey[0]: [1024 bits] pkey[1]: [160 bits] pkey[2]: [1024 bits] pkey[3]: [1023 bits] :user ID packet: "Panta Rhei Remailer DSA [Expires 23.08.2007] " :signature packet: algo 17, keyid 9422C4C798CAE13F version 4, created 1154610183, md5len 0, sigclass 10 digest algo 2, begin of digest 98 06 hashed subpkt 2 len 4 (sig created 2006-08-03) hashed subpkt 9 len 4 (key expires after 1y20d0h0m) hashed subpkt 11 len 8 (pref-sym-algos: 9 10 8 2 7 3 1 4) hashed subpkt 25 len 1 (primary user ID) subpkt 16 len 8 (issuer key ID 9422C4C798CAE13F) data: [157 bits] data: [158 bits] :signature packet: algo 17, keyid D72B2D4AA6A032C8 version 4, created 1154892025, md5len 0, sigclass 10 digest algo 2, begin of digest 93 17 hashed subpkt 2 len 4 (sig created 2006-08-06) subpkt 16 len 8 (issuer key ID D72B2D4AA6A032C8) data: [159 bits] data: [159 bits] :user ID packet: "Panta Rhei Remailer DSA [Expires 23.08.2007] " :signature packet: algo 17, keyid 9422C4C798CAE13F version 4, created 1154610428, md5len 0, sigclass 10 digest algo 2, begin of digest 54 1c hashed subpkt 2 len 4 (sig created 2006-08-03) hashed subpkt 9 len 4 (key expires after 1y20d0h0m) hashed subpkt 11 len 8 (pref-sym-algos: 9 10 8 2 7 3 1 4) subpkt 16 len 8 (issuer key ID 9422C4C798CAE13F) data: [160 bits] data: [159 bits] :signature packet: algo 17, keyid D72B2D4AA6A032C8 version 4, created 1154892035, md5len 0, sigclass 10 digest algo 2, begin of digest 9e 17 hashed subpkt 2 len 4 (sig created 2006-08-06) subpkt 16 len 8 (issuer key ID D72B2D4AA6A032C8) data: [160 bits] data: [160 bits] :public sub key packet: version 4, algo 16, created 1154610331, expires 0 pkey[0]: [4096 bits] pkey[1]: [2 bits] pkey[2]: [4094 bits] :signature packet: algo 17, keyid 9422C4C798CAE13F version 4, created 1154610331, md5len 0, sigclass 18 digest algo 2, begin of digest 2b bc hashed subpkt 2 len 4 (sig created 2006-08-03) hashed subpkt 9 len 4 (key expires after 1y20d0h0m) subpkt 16 len 8 (issuer key ID 9422C4C798CAE13F) data: [160 bits] data: [156 bits] ------------------------------------------------------------ Befehl> list pub 1024D/98CAE13F created: 2006-08-03 expires: 2007-08-23 usage: SCA trust: unbekannt G?ltigkeit: unbekannt sub 4096g/9E51EBCB created: 2006-08-03 expires: 2007-08-23 usage: E [ unknown] (1). Panta Rhei Remailer DSA [Expires 23.08.2007] [ unknown] (2) Panta Rhei Remailer DSA [Expires 23.08.2007] ------------------------------------------------------------ First appearing uid record: uid:-::::1154610183::6C524A561C0F033B43802C2A49FD954737A93F3C::Panta Rhei Remailer DSA [Expires 23.08.2007] : ------------------------------------------------------------ Kind regards Christian -- OmniMix .. protect your privacy http://www.danner-net.de/om.htm From dshaw at jabberwocky.com Fri Feb 16 15:10:55 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 16 Feb 2007 09:10:55 -0500 Subject: UID ordering In-Reply-To: References: Message-ID: <20070216141055.GC27943@jabberwocky.com> On Fri, Feb 16, 2007 at 01:00:16PM +0100, Christian Danner wrote: > Hi! > > Is it possible that the list of a key's user-ids returned by GPG 1.4.6 > is reordered and doesn't represent their positions within the key? > What am I missing? Generally, GnuPG tries to put the most recent or primary user ID first, but there are no real requirements that user IDs are in any particular order. If you want a user ID to be the primary one, you can do that in the --edit-key menu with the "primary" command. David From gnupg-devel_list at danner-net.de Fri Feb 16 19:10:36 2007 From: gnupg-devel_list at danner-net.de (Christian Danner) Date: Fri, 16 Feb 2007 19:10:36 +0100 Subject: UID ordering In-Reply-To: <20070216141055.GC27943@jabberwocky.com> References: <20070216141055.GC27943@jabberwocky.com> Message-ID: <6osbt2tjgnp6mt6jpoklsa40b0442cdm2t@domain.is.invalid> Hello David! On Fri, 16 Feb 2007 09:10:55 -0500, David Shaw wrote: >> Is it possible that the list of a key's user-ids returned by GPG 1.4.6 >> is reordered and doesn't represent their positions within the key? >> What am I missing? > >Generally, GnuPG tries to put the most recent or primary user ID >first, but there are no real requirements that user IDs are in any >particular order. If you want a user ID to be the primary one, you >can do that in the --edit-key menu with the "primary" command. > >David Thanks for your kind answer, which unfortunately only raised new questions. Is there a real indicator for the primary uid defined within the key? In the first place I searched for such a flag at the 'uid:...' line, but found no information about it in the 'DETAILS' file. My addmittedly rudimentary tools show me, that rearranging the uid list by defining a 'primary' uid simply moves the concerning user ID packet on top of all others. So I assume that it's necessary to preserve that ordering when dealing with a --list-keys command. Kind regards Christian -- OmniMix .. protect your privacy http://www.danner-net.de/om.htm From dshaw at jabberwocky.com Fri Feb 16 20:00:20 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 16 Feb 2007 14:00:20 -0500 Subject: UID ordering In-Reply-To: <6osbt2tjgnp6mt6jpoklsa40b0442cdm2t@domain.is.invalid> References: <20070216141055.GC27943@jabberwocky.com> <6osbt2tjgnp6mt6jpoklsa40b0442cdm2t@domain.is.invalid> Message-ID: <20070216190020.GB32368@jabberwocky.com> On Fri, Feb 16, 2007 at 07:10:36PM +0100, Christian Danner wrote: > Hello David! > > On Fri, 16 Feb 2007 09:10:55 -0500, David Shaw > wrote: > > >> Is it possible that the list of a key's user-ids returned by GPG 1.4.6 > >> is reordered and doesn't represent their positions within the key? > >> What am I missing? > > > >Generally, GnuPG tries to put the most recent or primary user ID > >first, but there are no real requirements that user IDs are in any > >particular order. If you want a user ID to be the primary one, you > >can do that in the --edit-key menu with the "primary" command. > > > >David > > Thanks for your kind answer, which unfortunately only raised new > questions. > > Is there a real indicator for the primary uid defined within the key? > In the first place I searched for such a flag at the 'uid:...' line, > but found no information about it in the 'DETAILS' file. There is. When you set a primary UID, the self-signature on that UID is actually remade with a signature subpacket that tags the UID as the primary one. Note that if you have any photo UIDs on your key, there are two different primaries: one for the regular text UIDs, and one for the photo (aka "attribute") UIDs. David From hawke at hawkesnest.net Fri Feb 16 20:47:33 2007 From: hawke at hawkesnest.net (Alex Mauer) Date: Fri, 16 Feb 2007 13:47:33 -0600 Subject: UID ordering In-Reply-To: <20070216190020.GB32368@jabberwocky.com> References: <20070216141055.GC27943@jabberwocky.com> <6osbt2tjgnp6mt6jpoklsa40b0442cdm2t@domain.is.invalid> <20070216190020.GB32368@jabberwocky.com> Message-ID: David Shaw wrote: > There is. When you set a primary UID, the self-signature on that UID > is actually remade with a signature subpacket that tags the UID as the > primary one. By my understanding, it's merely the UID with the most recent signature that's considered "primary". I seem to recall running into this when I set a UID as primary, and then added another UID. At that time the new UID became the primary one. (This also seems to be a disadvantage of changing the primary key regularly: you get a bunch of extraneous self-signatures) Also, if it's just a flag that says "this one is primary", what happens if different UIDs are set as primary on different keyrings, and then they're merged? Or am I totally off in my understanding of this? -Alex Mauer "hawke" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20070216/8d2a491a/attachment.pgp From dshaw at jabberwocky.com Fri Feb 16 21:00:42 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 16 Feb 2007 15:00:42 -0500 Subject: UID ordering In-Reply-To: References: <20070216141055.GC27943@jabberwocky.com> <6osbt2tjgnp6mt6jpoklsa40b0442cdm2t@domain.is.invalid> <20070216190020.GB32368@jabberwocky.com> Message-ID: <20070216200042.GC32368@jabberwocky.com> On Fri, Feb 16, 2007 at 01:47:33PM -0600, Alex Mauer wrote: > David Shaw wrote: > > There is. When you set a primary UID, the self-signature on that UID > > is actually remade with a signature subpacket that tags the UID as the > > primary one. > > By my understanding, it's merely the UID with the most recent signature > that's considered "primary". No. Like I said, there is a signature subpacket that tags the UID as the primary one. If you don't tag any UID, then GnuPG will sort the most recent one first, but that doesn't make it primary. > Also, if it's just a flag that says "this one is > primary", what happens if different UIDs are set as primary on different > keyrings, and then they're merged? The most recent of the UIDs tagged as primary will be treated as the "true" primary. David From marcus.brinkmann at ruhr-uni-bochum.de Fri Feb 16 22:51:01 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri, 16 Feb 2007 22:51:01 +0100 Subject: [gpgme] threadsafe? In-Reply-To: <200702131332.10496.smenzel@gmx-gmbh.de> References: <200702131332.10496.smenzel@gmx-gmbh.de> Message-ID: <87odntai0q.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 13 Feb 2007 13:32:09 +0100, Stephan Menzel wrote: > > [1 ] > [1.1 ] > Hi Guys, > > I'd just like to know if libgpgme when used to check S/MIME Signatures is > threadsafe from within an application when several threads may check using > the same engine and database and whatever but each thread got it's own > > gpgme_ctx_t _ctx; > > gpgme_new(&_ctx)); > > and > > gpgme_release(_ctx); > > after use. > That should mean, that each of those contexts is only used once and released > afterwards. > There are no data structures I could see that are shared among the threads. > Could the still be a problem when several threads use the lib simultaneously > or does the context capsule it sufficiently? The idea is that GPGME is thread safe in the sense that it should be safe to use different GPGME objects in different threads at the same time. If you want to access the same GPGME objects in different threads, you are responsible for the necessary synchronization. This extends to GPGME contexts as well as GPGME data objects and other objects (keys, etc). If you have suggestions how to make this more clear in the manual, please let me know. That's the concept. There may be bugs, as this is not well tested. Heading over to your other mails on the subject... Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Fri Feb 16 23:11:51 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri, 16 Feb 2007 23:11:51 +0100 Subject: [gpgme] fork() problem In-Reply-To: <200702131543.56950.smenzel@gmx-gmbh.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> Message-ID: <87mz3dah20.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 13 Feb 2007 15:43:56 +0100, Stephan Menzel wrote: > > [1 ] > [1.1 ] > Hi there, > > another not quite simple question I have regarding gpgme is: How exactly does > it work? Am I seeing this correctly that it uses fork() to start an external > process and communicates with it through pipes? GPGME does a double-fork to make the engine process a child of init. After the first fork, it immediately forks a second time (the first child exits then), the first child exits. Then it prepares the file descriptors and execv's. The parent in the mean while just waits for the first child to exit: The engine execv proceeds asynchronously, and remaining synchronization happens via the file descriptors. This relieves GPGME from doing child management, which would require signal handling and that's tricky in multi-threaded environments. > And if so, what happens to mutexes in that case. I often heard forking > processes with mutexes is always messy and results in strange behaviour. > (Stevens, "Unix IPC") Mutexes are destroyed when the execv happens. pthread only inherits the calling thread at fork(). Thus such mutexes *in the child* would not be released, causing deadlocks *in the child* when you would continue. However, nothing in this should affect the parent, and we execv() almost immediately, so it should not be an issue. At least that's my understanding of the issue. So much about GPGME's fork. However, there is a corresponding issue. If the GPGME-using application does a fork, not to do an execv but to do some work, then GPGME's internal mutexes are in a possibly inconsistent state. Currently, GPGME does not support this configuration, in fact, it was never considered by me (an omission). Do you fork() in your program and then not execv? Thanks, Marcus From gnupg-devel_list at danner-net.de Sat Feb 17 11:49:06 2007 From: gnupg-devel_list at danner-net.de (Christian Danner) Date: Sat, 17 Feb 2007 11:49:06 +0100 Subject: UID ordering In-Reply-To: <20070216200042.GC32368@jabberwocky.com> References: <20070216141055.GC27943@jabberwocky.com> <6osbt2tjgnp6mt6jpoklsa40b0442cdm2t@domain.is.invalid> <20070216190020.GB32368@jabberwocky.com> <20070216200042.GC32368@jabberwocky.com> Message-ID: <8andt2dp5mbtgvf4u76qg9bccb8uupsuss@domain.is.invalid> Hello David! On Fri, 16 Feb 2007 15:00:42 -0500, David Shaw wrote: >No. Like I said, there is a signature subpacket that tags the UID as >the primary one. If you don't tag any UID, then GnuPG will sort the >most recent one first, but that doesn't make it primary. >The most recent of the UIDs tagged as primary will be treated as the >"true" primary. I finally got it: I have to parse the output of a '--list-sigs --list-options show-sig-subpackets --with-colons --fixed-list-mode --with-fingerprint' command for subpackets type 25 'primary user ID' ('spk:25:') and, based on those, select the primary uid with the most recent self-signature. If there are none the 'normal' uid with the most recent self-signature wins, which, however, is arbitrary. Many thanks and kind regards Christian -- OmniMix .. protect your privacy http://www.danner-net.de/om.htm From benjamin at py-soft.co.uk Sat Feb 17 13:20:30 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sat, 17 Feb 2007 12:20:30 +0000 Subject: GnuPG v2.0.2 fat binary compile... In-Reply-To: <45D64DED.1070800@py-soft.co.uk> References: <45D64DED.1070800@py-soft.co.uk> Message-ID: <45D6F30E.3000007@py-soft.co.uk> Benjamin Donnachie wrote: > No patches were needed to any of the code and only libgcrypt's config.h > needed a minor edit for endian issues with the fat build. Oh! And I also had to replace parts from the latest autoconf as per previous messages. Though my ENDIAN patch was a little different to previous ones: #if defined(__BIG_ENDIAN__) #define WORDS_BIGENDIAN 1 #endif The latest SVN version also seems to suffer from this. Ben From benjamin at py-soft.co.uk Sat Feb 17 14:36:42 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sat, 17 Feb 2007 13:36:42 +0000 Subject: [Macgpg-users] GnuPG v2.0.2 MAC OS install - TESTING NEEDED! In-Reply-To: <45D64DED.1070800@py-soft.co.uk> References: <45D64DED.1070800@py-soft.co.uk> Message-ID: <45D704EA.4030301@py-soft.co.uk> Benjamin Donnachie wrote: > No patches were needed to any of the code and only libgcrypt's config.h > needed a minor edit for endian issues with the fat build. Unfortunately, gpg v2.0.2 does not appear to recognise the option pcsc-driver anymore: $ gpg2 --pcsc-driver /System/Library/Frameworks/PCSC.framework/PCSC --card-status gpg: Invalid option "--pcsc-driver" Despite the following in the man page: --pcsc-driver file Use file to access the smartcard reader. The current default is `libpcsclite.so.1' for GLIBC based systems, `/Sys- tem/Library/Frameworks/PCSC.framework/PCSC' for MAC OS X, `win- scard.dll' for Windows and `libpcsclite.so' for other systems. Neither scdaemon: /* The card dirver we use by default for PC/SC. */ #if defined(HAVE_W32_SYSTEM) || defined(__CYGWIN__) #define DEFAULT_PCSC_DRIVER "winscard.dll" #elif defined(__GLIBC__) #define DEFAULT_PCSC_DRIVER "libpcsclite.so.1" #else #define DEFAULT_PCSC_DRIVER "libpcsclite.so" #endif ... or pcsc-wrapper correctly default correctly on the Mac: #define DEFAULT_PCSC_DRIVER "libpcsclite.so" This shouldn't matter if you are using a CCID compliant smartcard reader as TEST1 was compiled with libusb support (Though this still needs testing). However, if you are using a PCSC smartcard reader please download the newly patched TEST2 at http://www.py-soft.co.uk/~benjamin/download/mac-gpg/mac-gnupg-2.0.2-TEST2.zip Werner et al - any chance the source could please be patched for MacOS, or support for the pcsc-driver option returned? Ben From smenzel at gmx-gmbh.de Sun Feb 18 13:04:24 2007 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Sun, 18 Feb 2007 13:04:24 +0100 Subject: [gpgme] threadsafe? In-Reply-To: <87odntai0q.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200702131332.10496.smenzel@gmx-gmbh.de> <87odntai0q.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200702181304.25239.smenzel@gmx-gmbh.de> Hi Marcus, Am Freitag, 16. Februar 2007 22:51:01 schrieb Marcus Brinkmann: > The idea is that GPGME is thread safe in the sense that it should be > safe to use different GPGME objects in different threads at the same > time. If you want to access the same GPGME objects in different > threads, you are responsible for the necessary synchronization. This > extends to GPGME contexts as well as GPGME data objects and other > objects (keys, etc). OK. This is you I understood it. > If you have suggestions how to make this more clear in the manual, > please let me know. Well it appears you already did. The last time I consulted the manual because of this was quite long ago and it wasn't so clear back then. Meanwhile I looked it up and it is a lot better now. Just wanted to make sure since I got those weird problems. Greetings... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070218/aed3213b/attachment.pgp From smenzel at gmx-gmbh.de Sun Feb 18 13:00:12 2007 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Sun, 18 Feb 2007 13:00:12 +0100 Subject: [gpgme] fork() problem In-Reply-To: <87mz3dah20.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> <87mz3dah20.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200702181300.16298.smenzel@gmx-gmbh.de> Hi Marcus, thanks for your response. I'm already about to get crazy debugging this. ;-) Am Freitag, 16. Februar 2007 23:11:51 schrieb Marcus Brinkmann: > So much about GPGME's fork. However, there is a corresponding issue. > If the GPGME-using application does a fork, not to do an execv but to > do some work, then GPGME's internal mutexes are in a possibly > inconsistent state. Currently, GPGME does not support this > configuration, in fact, it was never considered by me (an omission). > > Do you fork() in your program and then not execv? Only before I use gpgme. Initially the server process forks to daemonize when starting up. After that it creates multiple threads but doesn't fork anymore for any purpose. These threads use gpgme occasionally. So as far as I understand the situation the only forks happening should be under gpgme's control. Greetings... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070218/d15abb5a/attachment.pgp From wk at gnupg.org Sun Feb 18 14:07:52 2007 From: wk at gnupg.org (Werner Koch) Date: Sun, 18 Feb 2007 14:07:52 +0100 Subject: [Macgpg-users] GnuPG v2.0.2 MAC OS install - TESTING NEEDED! In-Reply-To: <45D704EA.4030301@py-soft.co.uk> (Benjamin Donnachie's message of "Sat\, 17 Feb 2007 13\:36\:42 +0000") References: <45D64DED.1070800@py-soft.co.uk> <45D704EA.4030301@py-soft.co.uk> Message-ID: <87ps87havr.fsf@wheatstone.g10code.de> On Sat, 17 Feb 2007 14:36, benjamin at py-soft.co.uk said: > $ gpg2 --pcsc-driver /System/Library/Frameworks/PCSC.framework/PCSC > --card-status > gpg: Invalid option "--pcsc-driver" There has never been such an option. You need to specify this option with scdaemon. gpg2 has no internal fallback support for smart cards. It requires gpg-agent/scdaemon. > Despite the following in the man page: > > --pcsc-driver file I'll fix the doc. > Neither scdaemon: I just tested scdaemon and it definitely has this option. > #define DEFAULT_PCSC_DRIVER "libpcsclite.so" I added a default value for OS X. Salam-Shalom, Werner From benjamin at py-soft.co.uk Sun Feb 18 18:44:48 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sun, 18 Feb 2007 17:44:48 +0000 Subject: [Macgpg-users] GnuPG v2.0.2 MAC OS install - TESTING NEEDED! In-Reply-To: <87ps87havr.fsf@wheatstone.g10code.de> References: <45D64DED.1070800@py-soft.co.uk> <45D704EA.4030301@py-soft.co.uk> <87ps87havr.fsf@wheatstone.g10code.de> Message-ID: <45D89090.50401@py-soft.co.uk> Werner Koch wrote: > There has never been such an option. You need to specify this option > with scdaemon. gpg2 has no internal fallback support for smart > cards. It requires gpg-agent/scdaemon. [...] >> Despite the following in the man page: > I'll fix the doc. That'd be good - many thanks. >> Neither scdaemon: > I just tested scdaemon and it definitely has this option. But it wasn't defaulting correctly for Mac OS X though. >> #define DEFAULT_PCSC_DRIVER "libpcsclite.so" > I added a default value for OS X. That's great - many thanks! :-) Ben From smenzel at gmx-gmbh.de Mon Feb 19 16:01:12 2007 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Mon, 19 Feb 2007 16:01:12 +0100 Subject: [gpgme] fork() problem In-Reply-To: <200702181300.16298.smenzel@gmx-gmbh.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> <87mz3dah20.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200702181300.16298.smenzel@gmx-gmbh.de> Message-ID: <200702191601.16609.smenzel@gmx-gmbh.de> Am Sonntag, 18. Februar 2007 13:00:12 schrieb Stephan Menzel: > Only before I use gpgme. Initially the server process forks to daemonize > when starting up. After that it creates multiple threads but doesn't fork > anymore for any purpose. These threads use gpgme occasionally. So as far as > I understand the situation the only forks happening should be under gpgme's > control. Hi there, I think I've got it solved. I just took the functionality and moved it away out of the daemon and put it into a new daemon that doesn't use threading but rather uses fork() itself. The original daemon queries the functions now from this new one. It seems to work fine at the cost of just a little overhead. I know this is merely a curing the symptoms but it works for me ;-) Thank you anyway! Greetings.... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070219/e0a3df64/attachment.pgp From smenzel at gmx-gmbh.de Mon Feb 19 19:57:52 2007 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Mon, 19 Feb 2007 19:57:52 +0100 Subject: [gpgme] fork() problem In-Reply-To: <200702191601.16609.smenzel@gmx-gmbh.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> <200702181300.16298.smenzel@gmx-gmbh.de> <200702191601.16609.smenzel@gmx-gmbh.de> Message-ID: <200702191957.57134.smenzel@gmx-gmbh.de> Am Montag, 19. Februar 2007 16:01:12 schrieb Stephan Menzel: > I think I've got it solved. I just took the functionality and moved it away > out of the daemon and put it into a new daemon that doesn't use threading > but rather uses fork() itself. ...and just one little addition to this: I did some research on the subject and questioned some collegues and it turned out some of them have the strong opinion that forking around in a heavyly multithreaded process is evil[tm] in itself and should be avoided at all costs. This might just be a rumour but I don't think so. Do you think it would be feasible to do the job without forking another process? Do do the job inside the lib? I think that would enhance gpgme's usability for use cases such as mine. Thanks and Greetings... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070219/14efd8ad/attachment.pgp From cbienia at CS.Princeton.EDU Tue Feb 20 03:20:44 2007 From: cbienia at CS.Princeton.EDU (Christian Bienia) Date: Mon, 19 Feb 2007 21:20:44 -0500 Subject: multi-threaded encryption Message-ID: <1171938044.5549.158.camel@cbienia> Hi, I'm a computer science grad student at Princeton University and assistant instructor for the course COS 598A "Parallel Architecture & Programming". We're considering to offer GnuPG as a parallelization project to the students this semester. Our idea is to let a small number of students parallelize GnuPG with pthreads with some help and guidance from my side. After the parallelization, GnuPG will support encryption / decryption of a single stream with multiple CPUs (instead of mere thread-safety or multi-processing). Obviously, some cipher modes add dependencies between blocks which would make it very difficult to parallelize them efficiently, so the work would mostly focus on cipher modes such as CTR and stream ciphers. The goal of the project is to get a version of GnuPG which scales well up to 64 CPUs. We can submit the changes so they can eventually be merged with the GnuPG main distribution if there's interest in them. Before we can recommend the project, I wanted to get some feedback on the plausibility and feasibility of the project. How difficult would it be to implement the changes? And is there need for a parallel GnuPG? - Chris From dshaw at jabberwocky.com Tue Feb 20 06:23:07 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 20 Feb 2007 00:23:07 -0500 Subject: multi-threaded encryption In-Reply-To: <1171938044.5549.158.camel@cbienia> References: <1171938044.5549.158.camel@cbienia> Message-ID: <20070220052307.GA12489@jabberwocky.com> On Mon, Feb 19, 2007 at 09:20:44PM -0500, Christian Bienia wrote: > Hi, > > I'm a computer science grad student at Princeton University and > assistant instructor for the course COS 598A "Parallel Architecture & > Programming". We're considering to offer GnuPG as a parallelization > project to the students this semester. > > Our idea is to let a small number of students parallelize GnuPG with > pthreads with some help and guidance from my side. After the > parallelization, GnuPG will support encryption / decryption of a single > stream with multiple CPUs (instead of mere thread-safety or > multi-processing). Obviously, some cipher modes add dependencies between > blocks which would make it very difficult to parallelize them > efficiently, so the work would mostly focus on cipher modes such as CTR > and stream ciphers. The goal of the project is to get a version of GnuPG > which scales well up to 64 CPUs. We can submit the changes so they can > eventually be merged with the GnuPG main distribution if there's > interest in them. > > Before we can recommend the project, I wanted to get some feedback on > the plausibility and feasibility of the project. How difficult would it > be to implement the changes? And is there need for a parallel GnuPG? The main problem that jumps to mind is that (speaking about the 1.4 branch of GnuPG for the moment), GnuPG is an OpenPGP program. The OpenPGP standard only specifies a variant of CFB mode, which is obviously not easy to parallelize. Changing the cipher mode (even as an option) would make GnuPG not compatible with OpenPGP any longer when that mode is used. There are some things that can be parallelized, such as encrypting and hashing at the same time for a signed+encrypted message, but this may not be what you're looking for. David From rjh at sixdemonbag.org Tue Feb 20 07:08:47 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 20 Feb 2007 00:08:47 -0600 Subject: multi-threaded encryption In-Reply-To: <1171938044.5549.158.camel@cbienia> References: <1171938044.5549.158.camel@cbienia> Message-ID: <45DA906F.4080000@sixdemonbag.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Bienia wrote: > Before we can recommend the project, I wanted to get some feedback on > the plausibility and feasibility of the project. How difficult would it > be to implement the changes? And is there need for a parallel GnuPG? I'm not a GnuPG developer; however, I think I may have some useful information for you. As you've said, counter mode and stream ciphers lend themselves best to parallelization, but the OpenPGP RFC does not specify counter mode or stream ciphers. The RFC specifies a slightly perverse cipher feedback mode which does not lend itself well to parallelization. The RFC language allows for experimental algorithms. You may have better luck implementing this as an experimental, rather than trying to add this support to the core of GnuPG. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJF2pBvAAoJELcA9IL+r4EJTxAH/RG16NBezcOi4m5pfSofJUQt 0gI5uZNMbSoaf9bySg0n2hV8ysPCn75vS7aLSnhmbL23naOr0yN1rkK3dVmeapte kW0DPf/I1f5IaRDmczZ9ngaDudkiYmuuOfjshhYesA8zaA/HUS5nDR9HgMc8X8U/ FSHJAyYCqECLZhzjm0UvRF8jnrxvdsjosRPM93u/leZeLtDmXcaq0rooEOvhcCYv 0CAa7ciBTafoHdjuHy4vbPbXbFVvZp3wBjisXHoyb5UhxX6Kd0A0pSeiNFURv7m7 XUqbIdYm1k4FGTx7Dh7OHOMNti83AFU1ApkJN29O+ZPPVlT6lIY6+yPb5bjlUUI= =Bg3/ -----END PGP SIGNATURE----- From henman at it.to-be.co.jp Tue Feb 20 06:15:14 2007 From: henman at it.to-be.co.jp (djh) Date: Tue, 20 Feb 2007 14:15:14 +0900 Subject: multi-threaded encryption In-Reply-To: Your message of Mon, 19 Feb 2007 21:20:44 -0500 <1171938044.5549.158.camel@cbienia> References: <1171938044.5549.158.camel@cbienia> Message-ID: <20070220141514.1532@henman-np.b-eng.it.to-be.co.jp> Chris, >...snipped... "Parallel Architecture & Programming". > We're considering to offer GnuPG as a parallelization project to the students > this semester. I don't think its a good idea. Technically gpg is by nature a sequential process. Using pthreads isn't going to turn a sequential process into a parallel one. Actually using multiple threads has probably made it less robust, less efficient, and more likely to be breached as has been pointed out earlier. Though why don't you do a neuron network or some such or the traveling salesman's shortest distance. Take a look at ibm's new cell chip see what you can do with the eight identical synergistic (vector) processing elements (SPEs). They run independently of each other and can be used for real parallel processing, still synchronization is necessary if you want to use them all in coneert, like using a mailbox type communications between them. There are 128 registers, 128 bits wide and use simd. If you have unix/linux you can program them. Or consider about plugable authorization modules. Just my 2 cents. Darel From wk at gnupg.org Tue Feb 20 10:54:03 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Feb 2007 10:54:03 +0100 Subject: multi-threaded encryption In-Reply-To: <1171938044.5549.158.camel@cbienia> (Christian Bienia's message of "Mon\, 19 Feb 2007 21\:20\:44 -0500") References: <1171938044.5549.158.camel@cbienia> Message-ID: <87ejolb1dw.fsf@wheatstone.g10code.de> On Tue, 20 Feb 2007 03:20, cbienia at CS.Princeton.EDU said: > Our idea is to let a small number of students parallelize GnuPG with > pthreads with some help and guidance from my side. After the > parallelization, GnuPG will support encryption / decryption of a single > stream with multiple CPUs (instead of mere thread-safety or > multi-processing). Obviously, some cipher modes add dependencies between For the symmetric part that does not make sense as this is strictly a sequential operation. For the public key operations, using several CPUs at once might be useful to boost the modular operaions. However, it will be pretty tricky to do this and I am not sure whether it is possible at all. The only part where I can see that parallelization makes sense is in encrypting to several recipients. This can trivially be parallelized. In general I am strictly against using preemptive threading for a security applicaqtion. It is just too hard to get right. Salam-Shalom, Werner From wk at gnupg.org Tue Feb 20 11:23:50 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Feb 2007 11:23:50 +0100 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <45D35BD4.1000703@py-soft.co.uk> (Benjamin Donnachie's message of "Wed\, 14 Feb 2007 18\:58\:28 +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> <45C0D588.70106@py-soft.co.uk> <45CF561B.90305@py-soft.co.uk> <45CF6F07.9040809@py-soft.co.uk> <45D20B7C.8030909@py-soft.co.uk> <20070214082219.GA1956@straylight.m.ringlet.net> <45D35BD4.1000703@py-soft.co.uk> Message-ID: <87y7mt9lft.fsf@wheatstone.g10code.de> On Wed, 14 Feb 2007 19:58, benjamin at py-soft.co.uk said: > 'cos I was searching through my MacOS programming book for a solution to > MacOS X not reading the GUI bundle information and it suggested using > system. I might have a solution. In agent/call-pinentry you find this code: if ( !(pgmname = strrchr (opt.pinentry_program, '/'))) pgmname = opt.pinentry_program; else pgmname++; argv[0] = pgmname; What is does is to setup argv[0] so that there is no directory part. Now my guess is that OS X uses argv[0] to locate the bundle and won't find it if there is no directory part in argv[0]. To test it, you just need to change the last line to: argv[0] = opt.pinentry_program; Let me know if it works and I change the code. Using system helps because it creates a new argv[0]. Shalom-Salam, Werner From wk at gnupg.org Tue Feb 20 11:48:12 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Feb 2007 11:48:12 +0100 Subject: GnuPG v2.0.2 fat binary compile... In-Reply-To: <45D6F30E.3000007@py-soft.co.uk> (Benjamin Donnachie's message of "Sat\, 17 Feb 2007 12\:20\:30 +0000") References: <45D64DED.1070800@py-soft.co.uk> <45D6F30E.3000007@py-soft.co.uk> Message-ID: <87tzxh9kb7.fsf@wheatstone.g10code.de> On Sat, 17 Feb 2007 13:20, benjamin at py-soft.co.uk said: > #if defined(__BIG_ENDIAN__) > #define WORDS_BIGENDIAN 1 > #endif Libgcrypt 1.3 will come with a new option --disable-endian-check, similar to gnupg 1.4. Salam-Shalom, Werner From benjamin at py-soft.co.uk Tue Feb 20 13:57:39 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Tue, 20 Feb 2007 12:57:39 +0000 Subject: GnuPG v2.0.2 fat binary compile... In-Reply-To: <87tzxh9kb7.fsf@wheatstone.g10code.de> References: <45D64DED.1070800@py-soft.co.uk> <45D6F30E.3000007@py-soft.co.uk> <87tzxh9kb7.fsf@wheatstone.g10code.de> Message-ID: <45DAF043.9020505@py-soft.co.uk> Werner Koch wrote: > Libgcrypt 1.3 will come with a new option --disable-endian-check, > similar to gnupg 1.4. Unless I was going something wrong, I tried the version in the svn without success. I'm wondering whether a better solution to fat binaries would be to generate i386 and PPC binaries separately, complete with any assembly optimisations, and then join the binaries together. But that's a completely separate project in itself... Ben From benjamin at py-soft.co.uk Tue Feb 20 14:48:03 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Tue, 20 Feb 2007 13:48:03 +0000 Subject: Compiling GnuPG 2.0.1 on MacOS X In-Reply-To: <87y7mt9lft.fsf@wheatstone.g10code.de> 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> <45C0D588.70106@py-soft.co.uk> <45CF561B.90305@py-soft.co.uk> <45CF6F07.9040809@py-soft.co.uk> <45D20B7C.8030909@py-soft.co.uk> <20070214082219.GA1956@straylight.m.ringlet.net> <45D35BD4.1000703@py-soft.co.uk> <87y7mt9lft.fsf@wheatstone.g10code.de> Message-ID: <45DAFC13.40103@py-soft.co.uk> Werner Koch wrote: > Let me know if it works and I change the code. It works perfectly - many thanks! :-))) > Using system helps because it creates a new argv[0]. Unfortunately, I was barking up the wrong tree after reading that MacOSX relies upon modified copies of the shell interpreters to interpret the bundle information. I must remember to be more critical of what I read on the web! :-/ In theory, this should also mean that the QT version of pinentry when properly bundled up should also work correctly. Rather than produce a whole new install to test v2.0.2, I'll knock together an archive with just the files that have changed. Thanks again for all your help, Ben From marcus.brinkmann at ruhr-uni-bochum.de Tue Feb 20 15:09:56 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue, 20 Feb 2007 15:09:56 +0100 Subject: [gpgme] fork() problem In-Reply-To: <200702191957.57134.smenzel@gmx-gmbh.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> <200702181300.16298.smenzel@gmx-gmbh.de> <200702191601.16609.smenzel@gmx-gmbh.de> <200702191957.57134.smenzel@gmx-gmbh.de> Message-ID: <87r6skapjf.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 19 Feb 2007 19:57:52 +0100, Stephan Menzel wrote: > > [1 ] > [1.1 ] > Am Montag, 19. Februar 2007 16:01:12 schrieb Stephan Menzel: > > I think I've got it solved. I just took the functionality and moved it away > > out of the daemon and put it into a new daemon that doesn't use threading > > but rather uses fork() itself. > > ...and just one little addition to this: I did some research on the subject > and questioned some collegues and it turned out some of them have the strong > opinion that forking around in a heavyly multithreaded process is evil[tm] in > itself and should be avoided at all costs. This is advice of mixed quality: It's good advice in the sense that it is better to avoid a feature than use it without thorough understanding of the issues. But one should always be open to exploring new territory, even if it looks dangerous :) Concurrency is difficult to begin with. It's a good idea to stick to one model of concurrency, threads or forks. But the fork() calls that happen in GPGME are really fancy _posix_spawn() calls, not forks, and _posix_spawn() is reasonably harmless even in multi-threaded applications. > This might just be a rumour but I don't think so. Do you think it would be > feasible to do the job without forking another process? Do do the job inside > the lib? I think that would enhance gpgme's usability for use cases such as > mine. First, I think you are jumping to conclusions, which is always a bad idea. Let's face it: At this point we have not the slightest idea what was going on when you encountered the problems. The descriptions you gave where by no means sufficient to make a diagnosis, so we just don't know where the problem was. Now you found a work-around that avoids the problem altogether, which is fine if it works for you, although I am a believer in the saying: "Problems that go away by themselves come back by themselves." To answer your question: In some ways, GPG moves towards running as a daemon already. It may be feasible in the future to avoid the fork() in some situations and replace it with connecting to a socket (in fact, for GPGSM you could do this with a little work on GPGSM and GPGME already). But this has nothing to do with extending use cases. For all I know, GPGME supports your use case perfectly fine, and we can only file your error report under "mysterious" until further information is accumulated. Thanks, Marcus From wk at gnupg.org Tue Feb 20 16:34:52 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Feb 2007 16:34:52 +0100 Subject: GnuPG v2.0.2 fat binary compile... In-Reply-To: <45DAF043.9020505@py-soft.co.uk> (Benjamin Donnachie's message of "Tue\, 20 Feb 2007 12\:57\:39 +0000") References: <45D64DED.1070800@py-soft.co.uk> <45D6F30E.3000007@py-soft.co.uk> <87tzxh9kb7.fsf@wheatstone.g10code.de> <45DAF043.9020505@py-soft.co.uk> Message-ID: <874ppgvo4j.fsf@wheatstone.g10code.de> On Tue, 20 Feb 2007 13:57, benjamin at py-soft.co.uk said: > Unless I was going something wrong, I tried the version in the svn > without success. Lacking a way to test this, I simply implemented what we have in gnupg 1.4. Something like ./configure CFLAGS="-arch ppc -arch i386" --disable-endian-check \ --disable-dependency-tracking --disable-asm should doit. However, there might be issues with libtool. You ran ./autogen.sh, right? A "grep config.h" should show you a defined macro DISABLED_ENDIAN_CHECK. Shalom-Salam, Werner From smenzel at gmx-gmbh.de Tue Feb 20 16:51:27 2007 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Tue, 20 Feb 2007 16:51:27 +0100 Subject: [gpgme] fork() problem In-Reply-To: <87r6skapjf.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> <200702191957.57134.smenzel@gmx-gmbh.de> <87r6skapjf.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200702201651.31707.smenzel@gmx-gmbh.de> Am Dienstag, 20. Februar 2007 15:09:56 schrieb Marcus Brinkmann: > This is advice of mixed quality: It's good advice in the sense that it > is better to avoid a feature than use it without thorough > understanding of the issues. But one should always be open to > exploring new territory, even if it looks dangerous :) Indeed. > Concurrency is difficult to begin with. It's a good idea to stick to > one model of concurrency, threads or forks. But the fork() calls that > happen in GPGME are really fancy _posix_spawn() calls, not forks, and > _posix_spawn() is reasonably harmless even in multi-threaded applications. Well, the concurrency we are doing in the daemon in question is mostly done by pthread mutexes and boost mutexes (which are pthread* implemented as well as far as I know) The daemon itself didn't have any problems with it's concurrency at this point before I used those calls even though it's running at very heavy load, without leaking mem btw. on several hundred machines so I take the liberty and assume it's concurrency is implemented reasonably stable at this stage. > First, I think you are jumping to conclusions, which is always a bad > idea. Yes. > Let's face it: At this point we have not the slightest idea > what was going on when you encountered the problems. The descriptions > you gave where by no means sufficient to make a diagnosis, so we just > don't know where the problem was. Well, If I can provide any more, just ask. I gave everything I had and everything I know about this. It was just too rare to be provoked. > Now you found a work-around that > avoids the problem altogether, which is fine if it works for you, > although I am a believer in the saying: "Problems that go away by > themselves come back by themselves." Well, thank bob it didn't go away by itself. I just moved it out of the area where it would be problematic into a seperate daemon where it's not too much of an issue if a process would crash from time to time. Which didn't happen so far btw. But it's a forking daemon rather than a threaded one. > To answer your question: In some ways, GPG moves towards running as a > daemon already. It may be feasible in the future to avoid the fork() > in some situations and replace it with connecting to a socket (in > fact, for GPGSM you could do this with a little work on GPGSM and > GPGME already). Well, that would be a nice option too. If I could communicate with such a service via Domain Sockets (or TCP) I would be in control of any blocking time. > But this has nothing to do with extending use cases. > For all I know, GPGME supports your use case perfectly fine, and we > can only file your error report under "mysterious" until further > information is accumulated. Well, it is mysterious indeed: Perhaps it was just some kind of a load situation gpgme is not experiencing very often. But as I said, If I can provide any help accumulating further information, I'd be glad to help. Greetings... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070220/e316e443/attachment.pgp From benjamin at py-soft.co.uk Tue Feb 20 20:11:59 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Tue, 20 Feb 2007 19:11:59 +0000 Subject: GnuPG v2.0.2 fat binary compile... In-Reply-To: <874ppgvo4j.fsf@wheatstone.g10code.de> References: <45D64DED.1070800@py-soft.co.uk> <45D6F30E.3000007@py-soft.co.uk> <87tzxh9kb7.fsf@wheatstone.g10code.de> <45DAF043.9020505@py-soft.co.uk> <874ppgvo4j.fsf@wheatstone.g10code.de> Message-ID: <45DB47FF.5000404@py-soft.co.uk> Werner Koch wrote: > You ran ./autogen.sh, right? A "grep config.h" should show you a > defined macro DISABLED_ENDIAN_CHECK. Actually, now that I think about it, I think I got annoyed with ./autogen.sh complaining that all my tools were out of date. I didn't want to overwrite the ones that Apple had provided and started to install the new ones separately under /usr/local. In the end I found it easier to hack the released version of libgcrypt rather than continue with the svn version. Ben From cbienia at CS.Princeton.EDU Tue Feb 20 21:03:33 2007 From: cbienia at CS.Princeton.EDU (Christian Bienia) Date: Tue, 20 Feb 2007 15:03:33 -0500 Subject: multi-threaded encryption In-Reply-To: <87ejolb1dw.fsf@wheatstone.g10code.de> References: <1171938044.5549.158.camel@cbienia> <87ejolb1dw.fsf@wheatstone.g10code.de> Message-ID: <1172001812.5549.284.camel@cbienia> Hi, thanks a lot for all the feedback. I've already suspected that it wouldn't make too much sense. If anybody has a suggestion for an interesting parallelization project, I'd be glad to hear more. - Chris From marcus.brinkmann at ruhr-uni-bochum.de Wed Feb 21 02:06:08 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed, 21 Feb 2007 02:06:08 +0100 Subject: [gpgme] fork() problem In-Reply-To: <200702181300.16298.smenzel@gmx-gmbh.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> <87mz3dah20.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200702181300.16298.smenzel@gmx-gmbh.de> Message-ID: <87irdw9v5r.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sun, 18 Feb 2007 13:00:12 +0100, Stephan Menzel wrote: > > [1 ] > [1.1 ] > Hi Marcus, > > thanks for your response. > I'm already about to get crazy debugging this. ;-) It would be good to have some information about the platform you are using, in particular which Linux kernel version and which glibc library version, and if you are using Linux threads or the NPTL pthread package. Even if it doesn't help us now it may be useful information later when other stumble over similar issues. You may want to try different optimization levels. At least one stack trace looked bogus (the lock null pointer). It's always worth it to run valgrind on a program just to make sure there is no memory corruption which messes everything up for good of course. With your wrapper class which serializes all GPGME invocations, you can do something nifty: You can keep a trace of all GPGME invocations in a log file, with stacktraces at time of invocation. With a bit of hacking (making GPGME's engine_info_lock variable global and export it in the symbols file) you can also check before and after each invocation what the value of the PRIVATE member of the engine_info_lock semaphore structure is. It must be a (void *) 0 (unlocked state). Do you do funky stuff with signals? Maybe this gives you some ideas. I know how difficult these problems are to track down, but it is impossible to do it "remotely" and with almost no knowledge about the application and environment you are working with, so I can only stab in the dark here. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Wed Feb 21 01:56:07 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed, 21 Feb 2007 01:56:07 +0100 Subject: [gpgme] fork() problem In-Reply-To: <200702141632.07698.smenzel@gmx-gmbh.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> <200702141632.07698.smenzel@gmx-gmbh.de> Message-ID: <87k5yc9vmg.wl%marcus.brinkmann@ruhr-uni-bochum.de> Hi Stephan, I want to take a couple of steps back and maybe we can get more light into these issues. At Wed, 14 Feb 2007 16:32:03 +0100, Stephan Menzel wrote: > > [1 ] > [1.1 ] > Am Dienstag, 13. Februar 2007 15:43:56 schrieb Stephan Menzel: > > What I'm afraid of now is, that gpgme might fork() in order to do it's > > magic and mess up it's own mutexes (or mine) doing so. > > Does all that say anything to you guys or am I completely mistaken here? > > I have some additional info here. > I played around a bit and I tried to wrap my own mutex around the whole thing > and disable it's internal locking by linking against libgpgme.so.11 instead > of libgpgme-pthread.so.11 even though it's a multithreaded app. Did you serialize *all* calls into GPGME properly, with memory barrier (a single global mutex locked around all calls should do the trick)? > And indeed, I couldn't see anymore of those problems. Instead I got several > crashes apparently due to failed assertions in the lib. The stacktraces look > like this: > > #0 0xffffe410 in __kernel_vsyscall () > (gdb) backtrace > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb711d885 in raise () from /lib/tls/i686/cmov/libc.so.6 > #2 0xb711f002 in abort () from /lib/tls/i686/cmov/libc.so.6 > #3 0xb7117318 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 > #4 0xb6731e03 in _gpgme_ath_mutex_lock (lock=0x0) at ath.c:71 > #5 0xb6741e2f in _gpgme_sema_cs_enter (s=0xb674db40) at posix-sema.c:48 > #6 0xb673bd3b in _gpgme_engine_info_copy (r_info=0x0) at engine.c:225 > #7 0xb6743070 in gpgme_new (r_ctx=0x0) at gpgme.c:58 > #8 0xb732e9f3 in MyWrapperClass (this=0xb1782768) at MyWrapperClass.cc:187 > > It still doesn't crash all the time though. It mostly works so I think it's > some strange race condition. > Maybe this helps. I don't trust the "lock=0x0" parameter in the debug output, it is clearly bogus which indicates optimization (likely) or a corrupt stack (less likely). If you look at posix-sema.c's _gpgme_sema_cs_enter() implementation, you will see that it just adds OFFSETOF(struct critsect_s, private) to the S input parameter, which is 0xb674db40 above. So I assume that this is what it actually is, because otherwise you would get a segmentation fault and not an assertion failure. It would be important to know if any other thread is in GPGME at the same time. If you serialized all calls into GPGME, we would expect that not to be the case of course. The non-threaded version of GPGME has some rudimentary error checking: It makes the same mutex calls as the threaded version, but just checks if the locks are taken and released properly. This can catch some simple bugs where locks are not unlocked when they should be or used after they are destroyed. The above assertion failure means that it was attempted to take the engine_info_lock in engine.c twice without unlocking it inbetween. I have looked through all the users of this lock in engine.c, and I can't see an error in the LOCK/UNLOCK order. We also never heard about a similar assertion failure in a single-threaded program. This can mean that there is a bug in GPGME's engine.c here that we don't know about, or that your wrapper class fails to properly synchronize all calls into GPGME. You may want to put a watch point on the memory value of engine.c's engine_info_lock's PRIVATE member, which is a void pointer that becomes (void *) 0 if it is unlocked and (void *) 1 if it is locked. I am not sure that watch points help find a problem though if lack of memory barrier is an issue here, though. Frankly, aside from a "spurious writes to random memory locations" (and accidentially hitting the above PRIVATE member), I can not imagine what might cause this assertion failure if all calls into GPGME are properly serialized. It's a mystery. Mmh. There is one issue in GPGME which may not be handled properly. We set a null handler for SIGPIPE at initialization time, and one should make sure that this is also the case for all GPGME-using threads. You may want to check if this could be a potential cause for trouble in your application. I would expect this to show up differently though. Thanks, Marcus From smenzel at gmx-gmbh.de Wed Feb 21 08:50:00 2007 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Wed, 21 Feb 2007 08:50:00 +0100 Subject: [gpgme] fork() problem In-Reply-To: <87irdw9v5r.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> <200702181300.16298.smenzel@gmx-gmbh.de> <87irdw9v5r.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200702210850.04561.smenzel@gmx-gmbh.de> Am Mittwoch, 21. Februar 2007 02:06:08 schrieb Marcus Brinkmann: > It would be good to have some information about the platform you are > using, in particular which Linux kernel version and which glibc > library version, and if you are using Linux threads or the NPTL > pthread package. Even if it doesn't help us now it may be useful > information later when other stumble over similar issues. Hi Marcus, there are several platforms. All of them running debian with kernels ranging from 2.6.16 up to 2.6.18 libc says: sm at box:~> /lib/libc.so.6 GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.3.5 (Debian 1:3.3.5-13). Compiled on a Linux 2.6.0-test7 system on 2006-09-06. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. Report bugs using the `glibcbug' script to . And we are using pthreads. > You may want to try different optimization levels. At least one stack > trace looked bogus (the lock null pointer). I think they are. I often get stuff like that in the coredumps and yes, it mostly happens due to optimization. Unfortunatley, it's not easy to do this unoptimized since I would have to deploy it live to see the error and this might prove a bit tricky but I'll see what I can do. > It's always worth it to run valgrind on a program just to make sure > there is no memory corruption which messes everything up for good of > course. We do this on a regular base. The daemon is as far as I know free of memleaks. I just tried a little run locally here and indeed I found two little things in gpgme related parts: ==5676== 2,088 (96 direct, 1,992 indirect) bytes in 2 blocks are definitely lost in loss record 93 of 146 ==5676== at 0x40207E3: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==5676== by 0x4BCA6FC: (within /usr/lib/libgpgme-pthread.so.11.6.2) ==5676== by 0x4BCB7C0: (within /usr/lib/libgpgme-pthread.so.11.6.2) ==5676== by 0x4BD3B1C: (within /usr/lib/libgpgme-pthread.so.11.6.2) ==5676== by 0x4BC5D2D: (within /usr/lib/libgpgme-pthread.so.11.6.2) ==5676== by 0x4BC687D: (within /usr/lib/libgpgme-pthread.so.11.6.2) ==5676== by 0x4BCAE34: gpgme_op_keylist_next (in /usr/lib/libgpgme-pthread.so.11.6.2) ==5676== by 0x4BCAF94: gpgme_get_key (in /usr/lib/libgpgme-pthread.so.11.6.2) ==5676== by 0x4BAFC21: MyClass::getKey(char const*) (MyClass.cc:39) I'll try to find out if I was causing the leak here. > With your wrapper class which serializes all GPGME invocations, you > can do something nifty: You can keep a trace of all GPGME invocations > in a log file, with stacktraces at time of invocation. With a bit of > hacking (making GPGME's engine_info_lock variable global and export it > in the symbols file) you can also check before and after each > invocation what the value of the PRIVATE member of the > engine_info_lock semaphore structure is. It must be a (void *) 0 > (unlocked state). Well, I see if I can find time for this. Couldn't promise it though. > Do you do funky stuff with signals? No. But I'll see what I can do to provide further info. Greetings... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070221/f39beadc/attachment.pgp From smenzel at gmx-gmbh.de Wed Feb 21 11:53:20 2007 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Wed, 21 Feb 2007 11:53:20 +0100 Subject: [gpgme] fork() problem In-Reply-To: <87k5yc9vmg.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> <200702141632.07698.smenzel@gmx-gmbh.de> <87k5yc9vmg.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200702211153.21125.smenzel@gmx-gmbh.de> Am Mittwoch, 21. Februar 2007 01:56:07 schrieb Marcus Brinkmann: > Did you serialize *all* calls into GPGME properly, with memory barrier > (a single global mutex locked around all calls should do the trick)? Hang on a second! I just realized, I didn't wrap and protect the destructor properly. The call to gpgme_release() could happen simultaneously. Does this sound like a potential problem? Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070221/acb6b307/attachment-0001.pgp From smenzel at gmx-gmbh.de Wed Feb 21 11:42:02 2007 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Wed, 21 Feb 2007 11:42:02 +0100 Subject: [gpgme] fork() problem In-Reply-To: <87k5yc9vmg.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> <200702141632.07698.smenzel@gmx-gmbh.de> <87k5yc9vmg.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200702211142.02876.smenzel@gmx-gmbh.de> Hi Marcus, Am Mittwoch, 21. Februar 2007 01:56:07 schrieb Marcus Brinkmann: > Did you serialize *all* calls into GPGME properly, with memory barrier > (a single global mutex locked around all calls should do the trick)? Yes and no. I just doublechecked it once again to make sure. I think I can say that it's impossible for two calls into the lib to happen simultaneously. It's all protected by a scoped_lock around each of the objects. So I don't have global mutexes. The wrapper objects itself are boost_mutexes and lock within themselfes which if prefer. However, it is theoretically possible for subsequent calls to happen to different contexts (objects for me). Meaning something like this (simplified): GPGObject a(); // does initialization routines using gpgme_new() GPGObject b(); a->verify(); b->verify(); That would mean context switches to the engine. I think this not too likely but possible. Btw, all coredumps I got seemed to happen within gpgme_new(). None happening within the actual verify. But I was instanciating a bit unnessecarily at times, so this could be explained. I'm not any more though. > > #0 0xffffe410 in __kernel_vsyscall () > > (gdb) backtrace > > #0 0xffffe410 in __kernel_vsyscall () > > #1 0xb711d885 in raise () from /lib/tls/i686/cmov/libc.so.6 > > #2 0xb711f002 in abort () from /lib/tls/i686/cmov/libc.so.6 > > #3 0xb7117318 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 > > #4 0xb6731e03 in _gpgme_ath_mutex_lock (lock=0x0) at ath.c:71 > > #5 0xb6741e2f in _gpgme_sema_cs_enter (s=0xb674db40) at posix-sema.c:48 > > #6 0xb673bd3b in _gpgme_engine_info_copy (r_info=0x0) at engine.c:225 > > #7 0xb6743070 in gpgme_new (r_ctx=0x0) at gpgme.c:58 > > #8 0xb732e9f3 in MyWrapperClass (this=0xb1782768) at > > MyWrapperClass.cc:187 > > > > It still doesn't crash all the time though. It mostly works so I think > > it's some strange race condition. > > Maybe this helps. > > I don't trust the "lock=0x0" parameter in the debug output, it is > clearly bogus which indicates optimization (likely) or a corrupt stack > (less likely). Of course. I often get stuff like this and it's never to be trusted. We use -O2 btw. > above. So I assume that this is what it actually is, because > otherwise you would get a segmentation fault and not an assertion > failure. Yes. I didn't get any of those. All crashes I noticed were sig6. > The non-threaded version of GPGME has some rudimentary error checking: > It makes the same mutex calls as the threaded version, but just checks > if the locks are taken and released properly. This can catch some > simple bugs where locks are not unlocked when they should be or used > after they are destroyed. This is ath.c right? > The above assertion failure means that it was attempted to take the > engine_info_lock in engine.c twice without unlocking it inbetween. I patched around a bit and at times had a version running with this mutex removed altogether. I tried to rely on my own mutex instead. I tried this and linking against the non-pthread version. The result was that I didn't get thos crashes around this mutex (engine_info_lock) anymore but different ones. I just looked, but don't have the stacktraces anymore :-( > Frankly, aside from a "spurious writes to random memory locations" > (and accidentially hitting the above PRIVATE member), I can not > imagine what might cause this assertion failure if all calls into > GPGME are properly serialized. It's a mystery. It sure is to me. I looked briefly into it too but I came to the same conclusion. However, since we valgrinded the daemon a lot I just trust that we don't have any messing around in it's mem like you describe. Given our use cases that would be quite desastrous and I really think we would have already noticed that. Segfault crashes would have to result. > Mmh. There is one issue in GPGME which may not be handled properly. > We set a null handler for SIGPIPE at initialization time, and one > should make sure that this is also the case for all GPGME-using > threads. You may want to check if this could be a potential cause for > trouble in your application. I would expect this to show up > differently though. Could I with my limited time do anything to prove that right or wrong? many Thanks and Greetings.... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070221/a2984329/attachment.pgp From marcus.brinkmann at ruhr-uni-bochum.de Wed Feb 21 23:26:33 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed, 21 Feb 2007 23:26:33 +0100 Subject: [gpgme] fork() problem In-Reply-To: <200702211142.02876.smenzel@gmx-gmbh.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> <200702141632.07698.smenzel@gmx-gmbh.de> <87k5yc9vmg.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200702211142.02876.smenzel@gmx-gmbh.de> Message-ID: <873b4zm9k6.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Wed, 21 Feb 2007 11:42:02 +0100, Stephan Menzel wrote: > > [1 ] > [1.1 ] > Hi Marcus, > > Am Mittwoch, 21. Februar 2007 01:56:07 schrieb Marcus Brinkmann: > > Did you serialize *all* calls into GPGME properly, with memory barrier > > (a single global mutex locked around all calls should do the trick)? > > Yes and no. > I just doublechecked it once again to make sure. I think I can say that it's > impossible for two calls into the lib to happen simultaneously. It's all > protected by a scoped_lock around each of the objects. > So I don't have global mutexes. The wrapper objects itself are boost_mutexes > and lock within themselfes which if prefer. > However, it is theoretically possible for subsequent calls to happen to > different contexts (objects for me). Meaning something like this > (simplified): > > GPGObject a(); // does initialization routines using gpgme_new() > GPGObject b(); > a->verify(); > b->verify(); > > That would mean context switches to the engine. I think this not too likely > but possible. Btw, all coredumps I got seemed to happen within gpgme_new(). > None happening within the actual verify. But I was instanciating a bit > unnessecarily at times, so this could be explained. I'm not any more though. I don't know what a scope lock or a boost mutex is. I am also confused, as it seems to me you are now talking again about your original implementation, and not what I understood to be a second version which serialized all calls into GPGME. I am referring to this one: "I played around a bit and I tried to wrap my own mutex around the whole thing and disable it's internal locking by linking against libgpgme.so.11 instead of libgpgme-pthread.so.11 even though it's a multithreaded app." Clearly, you can not expect this to work with concurrent access even to different objects. GPGME has internal locking, and that needs to work if there is *any* concurrency. If you disable internal locking by linking to libgpgme.so.11 rather than libgpgme-pthread.so.11, then you have to serialize all calls into GPGME properly. > > > #0 0xffffe410 in __kernel_vsyscall () > > > (gdb) backtrace > > > #0 0xffffe410 in __kernel_vsyscall () > > > #1 0xb711d885 in raise () from /lib/tls/i686/cmov/libc.so.6 > > > #2 0xb711f002 in abort () from /lib/tls/i686/cmov/libc.so.6 > > > #3 0xb7117318 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 > > > #4 0xb6731e03 in _gpgme_ath_mutex_lock (lock=0x0) at ath.c:71 > > > #5 0xb6741e2f in _gpgme_sema_cs_enter (s=0xb674db40) at posix-sema.c:48 > > > #6 0xb673bd3b in _gpgme_engine_info_copy (r_info=0x0) at engine.c:225 > > > #7 0xb6743070 in gpgme_new (r_ctx=0x0) at gpgme.c:58 > > > #8 0xb732e9f3 in MyWrapperClass (this=0xb1782768) at > > > MyWrapperClass.cc:187 > > > > > > It still doesn't crash all the time though. It mostly works so I think > > > it's some strange race condition. > > > Maybe this helps. > > > > I don't trust the "lock=0x0" parameter in the debug output, it is > > clearly bogus which indicates optimization (likely) or a corrupt stack > > (less likely). > > Of course. I often get stuff like this and it's never to be trusted. We > use -O2 btw. > > > above. So I assume that this is what it actually is, because > > otherwise you would get a segmentation fault and not an assertion > > failure. > > Yes. I didn't get any of those. All crashes I noticed were sig6. > > > The non-threaded version of GPGME has some rudimentary error checking: > > It makes the same mutex calls as the threaded version, but just checks > > if the locks are taken and released properly. This can catch some > > simple bugs where locks are not unlocked when they should be or used > > after they are destroyed. > > This is ath.c right? Yes. > > The above assertion failure means that it was attempted to take the > > engine_info_lock in engine.c twice without unlocking it inbetween. > > I patched around a bit and at times had a version running with this mutex > removed altogether. I tried to rely on my own mutex instead. I tried this and > linking against the non-pthread version. > The result was that I didn't get thos crashes around this mutex > (engine_info_lock) anymore but different ones. I just looked, but don't have > the stacktraces anymore :-( > > > Frankly, aside from a "spurious writes to random memory locations" > > (and accidentially hitting the above PRIVATE member), I can not > > imagine what might cause this assertion failure if all calls into > > GPGME are properly serialized. It's a mystery. > > It sure is to me. > I looked briefly into it too but I came to the same conclusion. However, since > we valgrinded the daemon a lot I just trust that we don't have any messing > around in it's mem like you describe. Given our use cases that would be quite > desastrous and I really think we would have already noticed that. Segfault > crashes would have to result. Did you valgrind the version using GPGME that produced the failures? Again, I am not sure I can follow which versions you mean by any of your references. We can not have any hope making progress by following several variants at the same time. > > Mmh. There is one issue in GPGME which may not be handled properly. > > We set a null handler for SIGPIPE at initialization time, and one > > should make sure that this is also the case for all GPGME-using > > threads. You may want to check if this could be a potential cause for > > trouble in your application. I would expect this to show up > > differently though. > > Could I with my limited time do anything to prove that right or wrong? You could look at how your application installs and uses signal handlers for the various threads. But I think it is unlikely that this is relevant to the primary concerns we have here. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Wed Feb 21 23:32:12 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed, 21 Feb 2007 23:32:12 +0100 Subject: [gpgme] fork() problem In-Reply-To: <200702210850.04561.smenzel@gmx-gmbh.de> References: <200702131543.56950.smenzel@gmx-gmbh.de> <200702181300.16298.smenzel@gmx-gmbh.de> <87irdw9v5r.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200702210850.04561.smenzel@gmx-gmbh.de> Message-ID: <871wkjm9ar.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Wed, 21 Feb 2007 08:50:00 +0100, Stephan Menzel wrote: > > Am Mittwoch, 21. Februar 2007 02:06:08 schrieb Marcus Brinkmann: > > It would be good to have some information about the platform you are > > using, in particular which Linux kernel version and which glibc > > library version, and if you are using Linux threads or the NPTL > > pthread package. Even if it doesn't help us now it may be useful > > information later when other stumble over similar issues. > > Hi Marcus, > > there are several platforms. All of them running debian with kernels ranging > from 2.6.16 up to 2.6.18 > > libc says: > > sm at box:~> /lib/libc.so.6 > GNU C Library stable release version 2.3.2, by Roland McGrath et al. > Copyright (C) 2003 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. > Compiled by GNU CC version 3.3.5 (Debian 1:3.3.5-13). > Compiled on a Linux 2.6.0-test7 system on 2006-09-06. > Available extensions: > GNU libio by Per Bothner > crypt add-on version 2.1 by Michael Glad and others > linuxthreads-0.10 by Xavier Leroy > BIND-8.2.3-T5B > libthread_db work sponsored by Alpha Processor Inc > NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk > Thread-local storage support included. > Report bugs using the `glibcbug' script to . > > And we are using pthreads. You may want to try to compile your own glibc with NPTL. From what I have heard, NPTL is more standard conform to pthread than linuxthreads. Of course, that's just more stabbing in the dark, but it's worth it because it really is a completely different implementation. > > It's always worth it to run valgrind on a program just to make sure > > there is no memory corruption which messes everything up for good of > > course. > > We do this on a regular base. The daemon is as far as I know free of memleaks. > I just tried a little run locally here and indeed I found two little things in > gpgme related parts: > > ==5676== 2,088 (96 direct, 1,992 indirect) bytes in 2 blocks are definitely > lost in loss record 93 of 146 > ==5676== at 0x40207E3: calloc > (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) > ==5676== by 0x4BCA6FC: (within /usr/lib/libgpgme-pthread.so.11.6.2) > ==5676== by 0x4BCB7C0: (within /usr/lib/libgpgme-pthread.so.11.6.2) > ==5676== by 0x4BD3B1C: (within /usr/lib/libgpgme-pthread.so.11.6.2) > ==5676== by 0x4BC5D2D: (within /usr/lib/libgpgme-pthread.so.11.6.2) > ==5676== by 0x4BC687D: (within /usr/lib/libgpgme-pthread.so.11.6.2) > ==5676== by 0x4BCAE34: gpgme_op_keylist_next > (in /usr/lib/libgpgme-pthread.so.11.6.2) > ==5676== by 0x4BCAF94: gpgme_get_key > (in /usr/lib/libgpgme-pthread.so.11.6.2) > ==5676== by 0x4BAFC21: MyClass::getKey(char const*) (MyClass.cc:39) > > I'll try to find out if I was causing the leak here. Maybe you don't release a key acquired with gpgme_get_key with gpgme_key_unref? Thanks, Marcus From eric at debian.org Sun Feb 25 09:11:09 2007 From: eric at debian.org (Eric Dorland) Date: Sun, 25 Feb 2007 03:11:09 -0500 Subject: (forw) Re: Bug#314068: gnupg2: [INTL:de] German PO file corrections Message-ID: <20070225081109.GD17478@nightcrawler.kuroneko.ca> Hi gnupg developers, A debian user has submitted some corrections to the de.po file. Could you review them and apply them if you have no objections? Thanks. PS Please preserve the Cc header when replying to this mail. -- Eric Dorland ICQ: #61138586, Jabber: hooty at jabber.com 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -------------- next part -------------- An embedded message was scrubbed... From: Jens Seidel Subject: Re: Bug#314068: gnupg2: [INTL:de] German PO file corrections Date: Thu, 22 Feb 2007 23:35:14 +0100 Size: 21380 Url: /pipermail/attachments/20070225/2c00943f/attachment-0001.mht -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20070225/2c00943f/attachment-0001.pgp From albrecht.dress at arcor.de Sun Feb 25 14:50:01 2007 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Sun, 25 Feb 2007 14:50:01 +0100 Subject: GpgME BUG: list expired secret keys? Message-ID: <1172411401l.4301l.1l@antares.localdomain> Hi all, I noticed a confusing behaviour of gpgme 1.1.2 when I try to list keys and check their expiry status. Running the trivial attached code (which takes the second and third parameter of gpgme_op_keylist_start() as arguments), I try to list an expired secret key: [albrecht at antares ~]$ ./gpgme-key-expire [key_id_removed] 1 now is 1172581963 key: can_sign=1 can_encrypt=0 expired=0 subkey id=9FFF6E9CD027FFD1 can_sign=1 can_encrypt=0 expired=0 expires=1172493215 [1] subkey id=9AA774B7653B2476 can_sign=0 can_encrypt=1 expired=0 expires=0 [0] Although the current date is behind the expiry date of the secret sub-key (can_sign=1), gpgme returns expired=0! Running the app on the same public key, the returned data looks fine, though: [albrecht at antares ~]$ ./gpgme-key-expire [key_id_removed] 0 now is 1172581965 key: can_sign=1 can_encrypt=0 expired=1 subkey id=9FFF6E9CD027FFD1 can_sign=1 can_encrypt=0 expired=1 expires=1172493215 [1] subkey id=9AA774B7653B2476 can_sign=0 can_encrypt=1 expired=1 expires=0 [0] Did I completely misunderstand the concept of listing keys or miss some "vital" initialisation here? When I now use the "non expired" (as reported by the key list operation) secret key in gpgme_op_sign() with mode GPGME_SIG_MODE_CLEAR, this function returns GPG_ERR_NO_ERROR, as does gpgme_signers_add(). gpgme_op_sign_result() returns a valid structure, but both the "signatures" and "invalid_signers" elements are NULL, so there is no way to catch the real reason why the operation failed which is obviously a bad situation. Always "manually" checking the expiry date seems to be the obvious workaround here, but this should be done in the library IMHO... Any ideas? Cheers, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress at arcor.de GnuPG public key: http://www.mynetcologne.de/~nc-dreszal/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme-key-expire.c Type: text/x-csrc Size: 1135 bytes Desc: not available Url : /pipermail/attachments/20070225/8a2a2487/attachment.c -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070225/8a2a2487/attachment.pgp From robbat2 at gentoo.org Mon Feb 26 03:24:03 2007 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Sun, 25 Feb 2007 18:24:03 -0800 Subject: Bug with duplicate user IDs of different status Message-ID: <20070226022403.GD20493@curie-int.orbis-terrarum.net> Instructions to reproduce: 1. create any key 2. gpg --edit-key ; adduid foo at bar ; save+quit 3. gpg --edit-key ; revuid foo at bar ; save+quit 4. gpg -v --list-keys foo at bar (shows the revoked uid) 5. gpg --edit-key ; adduid foo at bar 6. display will now show both foo at bar uids 7. save+quit 8. gpg --edit-key (now we get this message: "gpg: key 34884E85: duplicated user ID detected - merged") 9. 'list' shows only the revoked version of the foo at bar uid, and we cannot select the new one to perform any operations on it. -- 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: 321 bytes Desc: not available Url : /pipermail/attachments/20070225/b55e4670/attachment.pgp From wk at gnupg.org Mon Feb 26 09:31:57 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Feb 2007 09:31:57 +0100 Subject: (forw) Re: Bug#314068: gnupg2: [INTL:de] German PO file corrections In-Reply-To: <20070225081109.GD17478@nightcrawler.kuroneko.ca> (Eric Dorland's message of "Sun\, 25 Feb 2007 03\:11\:09 -0500") References: <20070225081109.GD17478@nightcrawler.kuroneko.ca> Message-ID: <87y7mll3pe.fsf@wheatstone.g10code.de> On Sun, 25 Feb 2007 09:11, eric at debian.org said: > A debian user has submitted some corrections to the de.po file. Could > you review them and apply them if you have no objections? Thanks. Thanks for the fixes. However I won't apply them because we stick to regular German grammar and not that mostly silly new one pupils are forced to learn these days. We will look at the real typos, though. Shalom-Salam, Werner From eric at debian.org Mon Feb 26 10:26:30 2007 From: eric at debian.org (Eric Dorland) Date: Mon, 26 Feb 2007 04:26:30 -0500 Subject: (forw) Re: Bug#314068: gnupg2: [INTL:de] German PO file corrections In-Reply-To: <87y7mll3pe.fsf@wheatstone.g10code.de> References: <20070225081109.GD17478@nightcrawler.kuroneko.ca> <87y7mll3pe.fsf@wheatstone.g10code.de> Message-ID: <20070226092630.GE903@nightcrawler.kuroneko.ca> * Werner Koch (wk at gnupg.org) wrote: > On Sun, 25 Feb 2007 09:11, eric at debian.org said: > > > A debian user has submitted some corrections to the de.po file. Could > > you review them and apply them if you have no objections? Thanks. > > Thanks for the fixes. However I won't apply them because we stick to > regular German grammar and not that mostly silly new one pupils are > forced to learn these days. Thanks for considering it. I didn't mean to start a language debate. > We will look at the real typos, though. Great. Please keep me posted. -- Eric Dorland ICQ: #61138586, Jabber: hooty at jabber.com 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20070226/95e182c9/attachment.pgp From dshaw at jabberwocky.com Tue Feb 27 04:56:43 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 26 Feb 2007 22:56:43 -0500 Subject: Bug with duplicate user IDs of different status In-Reply-To: <20070226022403.GD20493@curie-int.orbis-terrarum.net> References: <20070226022403.GD20493@curie-int.orbis-terrarum.net> Message-ID: <20070227035643.GA6635@jabberwocky.com> On Sun, Feb 25, 2007 at 06:24:03PM -0800, Robin H. Johnson wrote: > Instructions to reproduce: > 1. create any key > 2. gpg --edit-key ; adduid foo at bar ; save+quit > 3. gpg --edit-key ; revuid foo at bar ; save+quit > 4. gpg -v --list-keys foo at bar (shows the revoked uid) > 5. gpg --edit-key ; adduid foo at bar > 6. display will now show both foo at bar uids > 7. save+quit > 8. gpg --edit-key (now we get this message: "gpg: key 34884E85: > duplicated user ID detected - merged") > 9. 'list' shows only the revoked version of the foo at bar uid, and we > cannot select the new one to perform any operations on it. There is a bug here, but this also needs a clarification. In step 9, it is proper that only one copy of the foo at bar uid is present and there is no way to select one of the foo at bar user IDs: OpenPGP does not have a real notion of multiple identical user IDs. GnuPG, as you noticed, collapses them together into one user ID that carries all of the signatures (self-signatures, revocation signatures, etc) that were on both original user IDs. The bug is that this new, joined, user ID appears as revoked (you had a 50% chance of that, as the user IDs are merged in order). If you exit the --edit-key menu, GnuPG will prompt you to save the modified key (the dupe-elimination is the modification). If you say yes and then do the --edit-key again, you'll see the user ID isn't really revoked. GnuPG should reprocess the key after the user ID collapse so the flags (revoked, expired, etc) are set properly. I will make this change. David From robbat2 at gentoo.org Tue Feb 27 05:25:34 2007 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Mon, 26 Feb 2007 20:25:34 -0800 Subject: Bug with duplicate user IDs of different status In-Reply-To: <20070227035643.GA6635@jabberwocky.com> References: <20070226022403.GD20493@curie-int.orbis-terrarum.net> <20070227035643.GA6635@jabberwocky.com> Message-ID: <20070227042534.GJ23359@curie-int.orbis-terrarum.net> On Mon, Feb 26, 2007 at 10:56:43PM -0500, David Shaw wrote: > On Sun, Feb 25, 2007 at 06:24:03PM -0800, Robin H. Johnson wrote: > > Instructions to reproduce: > > 1. create any key > > 2. gpg --edit-key ; adduid foo at bar ; save+quit > > 3. gpg --edit-key ; revuid foo at bar ; save+quit > > 4. gpg -v --list-keys foo at bar (shows the revoked uid) > > 5. gpg --edit-key ; adduid foo at bar > > 6. display will now show both foo at bar uids > > 7. save+quit > > 8. gpg --edit-key (now we get this message: "gpg: key 34884E85: > > duplicated user ID detected - merged") > > 9. 'list' shows only the revoked version of the foo at bar uid, and we > > cannot select the new one to perform any operations on it. > > There is a bug here, but this also needs a clarification. In step 9, > it is proper that only one copy of the foo at bar uid is present and > there is no way to select one of the foo at bar user IDs: OpenPGP does > not have a real notion of multiple identical user IDs. GnuPG, as you > noticed, collapses them together into one user ID that carries all of > the signatures (self-signatures, revocation signatures, etc) that were > on both original user IDs. Hmm, I'm wondering what the correct course of action is then. In my original case that I reduced to the above, I originally had an email address (rjohnsob at sfu.ca) from the university I attended, and revuid'd it after I graduated and the email address was recycled to another user, not dreaming that I'd be involved again with the university again (my departure was somewhat bitter). So for some time, that address was NOT a valid source for me, but now it is again. > The bug is that this new, joined, user ID appears as revoked (you had > a 50% chance of that, as the user IDs are merged in order). If you > exit the --edit-key menu, GnuPG will prompt you to save the modified > key (the dupe-elimination is the modification). If you say yes and > then do the --edit-key again, you'll see the user ID isn't really > revoked. GnuPG should reprocess the key after the user ID collapse so > the flags (revoked, expired, etc) are set properly. I will make this > change. See the attached sigdata.txt file. It does show the old signatures under the old instance of the uid. -- 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 -------------- pub 1024D/34884E85 2002-08-27 [expires: 2008-03-09] uid Robin Hugh Johnson sig 3 34884E85 2006-06-23 Robin Hugh Johnson sig 3 X 073E939F 2002-08-31 Gerard Escalante sig 2 X 89A343DB 2002-09-01 Graham Poulter sig 3 X 99455482 2003-05-18 Fred Van Andel sig 3 X 3BAA3AE0 2003-05-24 Rasmus Lerdorf sig 3 DDCAFEE6 2003-06-30 Mayo Jordanov sig P X 9E2BD1F2 2004-04-09 CA Cert Signing Authority (Low Security Key) sig 2 X 57983F73 2004-02-11 Piotr Banasik sig 3 34884E85 2002-08-27 Robin Hugh Johnson sig 3 34884E85 2002-08-27 Robin Hugh Johnson sig 3 34884E85 2002-08-27 Robin Hugh Johnson sig 3 34884E85 2002-08-27 Robin Hugh Johnson sig 3 X 22B40A2C 2004-04-20 Michael Sterrett -Mr. Bones.- sig 3 X CCF0FAEE 2004-09-02 Jack Cummings (John) sig 3 34884E85 2003-08-28 Robin Hugh Johnson sig 3 X 5A46A31B 2004-09-02 Drew Smith (mux) sig 3 X 6C27DEAB 2004-09-02 Randall Donald sig 3 X 5A827A2D 2004-09-02 Luca Filipozzi sig 3 X 57983F73 2004-09-02 Piotr Banasik sig 3 X B52E594E 2004-09-02 Piotr Banasik sig 3 X D87C6781 2004-09-02 Jonathan Walther sig 3 X 5230514A 2004-09-02 Shaun Jackman sig 3 X 746C51F4 2004-09-02 Kevin Lindsay (Trakker) sig 2 X 1A2870AD 2004-09-03 David Renardson sig 3 X CDC9A70D 2004-09-03 Simon Kirby sig 3 X 5135AF61 2004-09-03 Scott M. Rose sig X B32C5B38 2004-09-03 Michael Nugent sig 3 X EFA6B9D5 2004-09-04 Hamish Moffatt sig 2 FD6645AB 2004-09-04 Ryan Murray sig 3 F02EB55D 2004-09-06 Norman Hodges (key3) sig 2 X B24B0F19 2004-09-06 Trevor Schellhorn sig 3 X 2642186A 2004-09-08 Kenneth G Walker (Barrister, Solicitor, Notary http://qblaw.ca) sig 3 X 06D1D3CE 2004-09-08 kwalker sig 3 9E791EEE 2004-09-08 Ken Walker sig 3 X A6A68D7F 2004-09-07 Ross Kakuschke (Work) sig 3 X 36E58581 2004-09-23 Ernst Schneider sig 3 X DCDE7E08 2004-11-04 Karl Trygve Kalleberg sig 2 22B40A2C 2005-03-10 Michael Sterrett -Mr. Bones.- sig 3 34884E85 2004-08-27 Robin Hugh Johnson sig 2 X 67FF48C7 2004-08-31 Alexander M. Turek sig 1 DDCAFEE6 2005-03-10 Mayo Jordanov sig 3 57983F73 2005-03-11 Piotr Banasik sig 2 DDCAFEE6 2005-03-10 Mayo Jordanov sig 6D8ABE71 2005-06-26 Christoph Berg sig 3 33756619 2005-06-30 Daniel Faber sig 58510B5A 2005-06-26 Christoph Berg sig 2 36E75604 2005-06-24 Michal \xc4\x8ciha\xc5\x99 sig 60F96E8D 2005-06-27 Michael Brade sig A284E3D0 2005-06-28 Stephan Springer sig 3 9C67CD96 2005-06-29 Torsten Veller sig 2 94C09C7F 2005-06-29 Peter Palfrader sig 5A35FD42 2005-06-30 Christoph Ulrich Scholler (FNB) sig 03556F0E 2005-06-27 Marc Hildebrand sig 3 0E84D2EA 2005-06-26 Olivier L. Muller sig 3 26F170CA 2005-06-27 Florian Brand sig 3 2A623F72 2005-06-26 Christoph Probst sig 30C0F005 2005-06-26 Tobias Scherbaum sig 3DBD3B20 2005-06-26 Johannes Boeck sig 3 523C4663 2005-06-25 Mathias Landh\xe4\x75\xdf\x65r (Private) sig 667F3F30 2005-06-24 Stefan Schweizer (genstef) sig 3 9978AF86 2005-06-26 Christoph Probst sig CF7D6206 2005-06-25 Ulrich Plate sig 5B713DF0 2005-07-05 Frank Lichtenheld sig B3B2A12C 2005-07-08 ct magazine CERTIFICATE sig 16B0BE2E 2005-08-04 Alin Nastac sig P 65D0FD58 2006-07-30 CA Cert Signing Authority (Root CA) sig 3 34884E85 2005-03-10 Robin Hugh Johnson uid [ revoked] Robin Hugh Johnson rev 34884E85 2005-08-31 Robin Hugh Johnson sig 3 34884E85 2005-03-10 Robin Hugh Johnson sig 3 X 073E939F 2002-08-31 Gerard Escalante sig 2 X 89A343DB 2002-09-01 Graham Poulter sig 3 X 99455482 2003-05-18 Fred Van Andel sig 3 X 3BAA3AE0 2003-05-24 Rasmus Lerdorf sig 3 DDCAFEE6 2003-06-30 Mayo Jordanov sig P X 9E2BD1F2 2004-04-09 CA Cert Signing Authority (Low Security Key) sig 2 X 57983F73 2004-02-11 Piotr Banasik sig 3 34884E85 2002-08-27 Robin Hugh Johnson sig 3 34884E85 2002-08-27 Robin Hugh Johnson sig 3 34884E85 2002-08-27 Robin Hugh Johnson sig 3 X CCF0FAEE 2004-09-02 Jack Cummings (John) sig 3 34884E85 2003-08-28 Robin Hugh Johnson sig 3 X 6C27DEAB 2004-09-02 Randall Donald sig 3 X 5A827A2D 2004-09-02 Luca Filipozzi sig 3 X 57983F73 2004-09-02 Piotr Banasik sig 3 X B52E594E 2004-09-02 Piotr Banasik sig 3 X D87C6781 2004-09-02 Jonathan Walther sig 3 X 5230514A 2004-09-02 Shaun Jackman sig 3 X 746C51F4 2004-09-02 Kevin Lindsay (Trakker) sig 2 X 1A2870AD 2004-09-03 David Renardson sig 3 X CDC9A70D 2004-09-03 Simon Kirby sig 3 X 5135AF61 2004-09-03 Scott M. Rose sig 3 X EFA6B9D5 2004-09-04 Hamish Moffatt sig 2 FD6645AB 2004-09-04 Ryan Murray sig 3 F02EB55D 2004-09-06 Norman Hodges (key3) sig 2 X B24B0F19 2004-09-06 Trevor Schellhorn sig 3 X 2642186A 2004-09-08 Kenneth G Walker (Barrister, Solicitor, Notary http://qblaw.ca) sig 3 X 06D1D3CE 2004-09-08 kwalker sig 3 9E791EEE 2004-09-08 Ken Walker sig 3 X A6A68D7F 2004-09-07 Ross Kakuschke (Work) sig 3 X DCDE7E08 2004-11-04 Karl Trygve Kalleberg sig 2 22B40A2C 2005-03-10 Michael Sterrett -Mr. Bones.- sig 3 34884E85 2004-08-27 Robin Hugh Johnson sig 2 X 67FF48C7 2004-08-31 Alexander M. Turek sig 1 DDCAFEE6 2005-03-10 Mayo Jordanov sig 3 57983F73 2005-03-11 Piotr Banasik sig 2 DDCAFEE6 2005-03-10 Mayo Jordanov sig 3 9C67CD96 2005-06-29 Torsten Veller sig 2 94C09C7F 2005-06-29 Peter Palfrader sig 3 33756619 2005-06-30 Daniel Faber sig 6D8ABE71 2005-06-26 Christoph Berg sig 58510B5A 2005-06-26 Christoph Berg sig 2 36E75604 2005-06-24 Michal \xc4\x8ciha\xc5\x99 sig 60F96E8D 2005-06-27 Michael Brade sig A284E3D0 2005-06-28 Stephan Springer sig 03556F0E 2005-06-27 Marc Hildebrand sig 3 0E84D2EA 2005-06-26 Olivier L. Muller sig 3 26F170CA 2005-06-27 Florian Brand sig 3 2A623F72 2005-06-26 Christoph Probst sig 30C0F005 2005-06-26 Tobias Scherbaum sig 3DBD3B20 2005-06-26 Johannes Boeck sig 3 523C4663 2005-06-25 Mathias Landh\xe4\x75\xdf\x65r (Private) sig 667F3F30 2005-06-24 Stefan Schweizer (genstef) sig 3 9978AF86 2005-06-26 Christoph Probst sig CF7D6206 2005-06-25 Ulrich Plate sig B3B2A12C 2005-07-08 ct magazine CERTIFICATE sig 16B0BE2E 2005-08-04 Alin Nastac uid Robin Hugh Johnson sig 3 34884E85 2005-03-10 Robin Hugh Johnson sig 3 X 073E939F 2002-08-31 Gerard Escalante sig 2 X 89A343DB 2002-09-01 Graham Poulter sig 3 X 99455482 2003-05-18 Fred Van Andel sig 3 X 3BAA3AE0 2003-05-24 Rasmus Lerdorf sig 3 DDCAFEE6 2003-06-30 Mayo Jordanov sig P X 9E2BD1F2 2004-04-09 CA Cert Signing Authority (Low Security Key) sig 2 X 57983F73 2004-02-11 Piotr Banasik sig 3 34884E85 2002-08-27 Robin Hugh Johnson sig 3 34884E85 2002-08-27 Robin Hugh Johnson sig 3 34884E85 2002-08-27 Robin Hugh Johnson sig 3 X 22B40A2C 2004-04-20 Michael Sterrett -Mr. Bones.- sig 3 X CCF0FAEE 2004-09-02 Jack Cummings (John) sig 3 34884E85 2003-08-28 Robin Hugh Johnson sig 3 X 6C27DEAB 2004-09-02 Randall Donald sig 3 X 5A827A2D 2004-09-02 Luca Filipozzi sig 3 X 57983F73 2004-09-02 Piotr Banasik sig 3 X B52E594E 2004-09-02 Piotr Banasik sig 3 X D87C6781 2004-09-02 Jonathan Walther sig 3 X 5230514A 2004-09-02 Shaun Jackman sig 3 X 746C51F4 2004-09-02 Kevin Lindsay (Trakker) sig 2 X 1A2870AD 2004-09-03 David Renardson sig 3 X CDC9A70D 2004-09-03 Simon Kirby sig 3 X 5135AF61 2004-09-03 Scott M. Rose sig 3 X EFA6B9D5 2004-09-04 Hamish Moffatt sig 2 FD6645AB 2004-09-04 Ryan Murray sig 3 F02EB55D 2004-09-06 Norman Hodges (key3) sig 2 X B24B0F19 2004-09-06 Trevor Schellhorn sig 3 X 2642186A 2004-09-08 Kenneth G Walker (Barrister, Solicitor, Notary http://qblaw.ca) sig 3 X 06D1D3CE 2004-09-08 kwalker sig 3 9E791EEE 2004-09-08 Ken Walker sig 3 X A6A68D7F 2004-09-07 Ross Kakuschke (Work) sig 2 22B40A2C 2005-03-10 Michael Sterrett -Mr. Bones.- sig 3 34884E85 2004-08-27 Robin Hugh Johnson sig 2 X 67FF48C7 2004-08-31 Alexander M. Turek sig 1 DDCAFEE6 2005-03-10 Mayo Jordanov sig 3 57983F73 2005-03-11 Piotr Banasik sig 2 DDCAFEE6 2005-03-10 Mayo Jordanov sig 2 36E75604 2005-06-24 Michal \xc4\x8ciha\xc5\x99 sig 60F96E8D 2005-06-27 Michael Brade sig A284E3D0 2005-06-28 Stephan Springer sig 3 9C67CD96 2005-06-29 Torsten Veller sig 2 94C09C7F 2005-06-29 Peter Palfrader sig 3 33756619 2005-06-30 Daniel Faber sig 6D8ABE71 2005-06-26 Christoph Berg sig 58510B5A 2005-06-26 Christoph Berg sig 03556F0E 2005-06-27 Marc Hildebrand sig 3 0E84D2EA 2005-06-26 Olivier L. Muller sig 3 26F170CA 2005-06-27 Florian Brand sig 3 2A623F72 2005-06-26 Christoph Probst sig 30C0F005 2005-06-26 Tobias Scherbaum sig 3DBD3B20 2005-06-26 Johannes Boeck sig 3 523C4663 2005-06-25 Mathias Landh\xe4\x75\xdf\x65r (Private) sig 667F3F30 2005-06-24 Stefan Schweizer (genstef) sig 3 9978AF86 2005-06-26 Christoph Probst sig CF7D6206 2005-06-25 Ulrich Plate sig B3B2A12C 2005-07-08 ct magazine CERTIFICATE sig 16B0BE2E 2005-08-04 Alin Nastac sig P 65D0FD58 2006-07-30 CA Cert Signing Authority (Root CA) uid Robin Hugh Johnson sig 3 34884E85 2006-06-23 Robin Hugh Johnson sig 3 X 99455482 2003-05-18 Fred Van Andel sig 3 X 3BAA3AE0 2003-05-24 Rasmus Lerdorf sig 3 DDCAFEE6 2003-06-30 Mayo Jordanov sig P X 9E2BD1F2 2004-04-09 CA Cert Signing Authority (Low Security Key) sig 2 X 57983F73 2004-02-11 Piotr Banasik sig 3 34884E85 2003-04-03 Robin Hugh Johnson sig 3 34884E85 2003-04-03 Robin Hugh Johnson sig 3 X 22B40A2C 2004-04-20 Michael Sterrett -Mr. Bones.- sig 3 X CCF0FAEE 2004-09-02 Jack Cummings (John) sig 3 34884E85 2003-08-28 Robin Hugh Johnson sig 3 X 6C27DEAB 2004-09-02 Randall Donald sig 3 X 5A827A2D 2004-09-02 Luca Filipozzi sig 3 X 57983F73 2004-09-02 Piotr Banasik sig 3 X B52E594E 2004-09-02 Piotr Banasik sig 3 X D87C6781 2004-09-02 Jonathan Walther sig 3 X 5230514A 2004-09-02 Shaun Jackman sig 3 X 746C51F4 2004-09-02 Kevin Lindsay (Trakker) sig 2 X 1A2870AD 2004-09-03 David Renardson sig 3 X CDC9A70D 2004-09-03 Simon Kirby sig 3 X 5135AF61 2004-09-03 Scott M. Rose sig 3 X EFA6B9D5 2004-09-04 Hamish Moffatt sig 2 FD6645AB 2004-09-04 Ryan Murray sig 3 F02EB55D 2004-09-06 Norman Hodges (key3) sig 2 X B24B0F19 2004-09-06 Trevor Schellhorn sig 3 X 2642186A 2004-09-08 Kenneth G Walker (Barrister, Solicitor, Notary http://qblaw.ca) sig 3 X 06D1D3CE 2004-09-08 kwalker sig 3 9E791EEE 2004-09-08 Ken Walker sig 3 X A6A68D7F 2004-09-07 Ross Kakuschke (Work) sig 3 X DCDE7E08 2004-11-04 Karl Trygve Kalleberg sig 2 22B40A2C 2005-03-10 Michael Sterrett -Mr. Bones.- sig 3 34884E85 2004-08-27 Robin Hugh Johnson sig 2 X 67FF48C7 2004-08-31 Alexander M. Turek sig 1 DDCAFEE6 2005-03-10 Mayo Jordanov sig 3 57983F73 2005-03-11 Piotr Banasik sig 2 DDCAFEE6 2005-03-10 Mayo Jordanov sig A284E3D0 2005-06-28 Stephan Springer sig 6D8ABE71 2005-06-26 Christoph Berg sig 58510B5A 2005-06-26 Christoph Berg sig 2 36E75604 2005-06-24 Michal \xc4\x8ciha\xc5\x99 sig 60F96E8D 2005-06-27 Michael Brade sig 3 33756619 2005-06-30 Daniel Faber sig 2 94C09C7F 2005-06-29 Peter Palfrader sig 3 9C67CD96 2005-06-29 Torsten Veller sig 03556F0E 2005-06-27 Marc Hildebrand sig 3 0E84D2EA 2005-06-26 Olivier L. Muller sig 3 26F170CA 2005-06-27 Florian Brand sig 3 2A623F72 2005-06-26 Christoph Probst sig 30C0F005 2005-06-26 Tobias Scherbaum sig 3DBD3B20 2005-06-26 Johannes Boeck sig 3 523C4663 2005-06-25 Mathias Landh\xe4\x75\xdf\x65r (Private) sig 667F3F30 2005-06-24 Stefan Schweizer (genstef) sig 3 9978AF86 2005-06-26 Christoph Probst sig CF7D6206 2005-06-25 Ulrich Plate sig B3B2A12C 2005-07-08 ct magazine CERTIFICATE sig 16B0BE2E 2005-08-04 Alin Nastac sig P 65D0FD58 2006-07-30 CA Cert Signing Authority (Root CA) sig FBD72601 2006-07-29 Hisashi Todd Fujinaka sig 3 34884E85 2005-03-10 Robin Hugh Johnson uid [ revoked] Robin Hugh Johnson rev 34884E85 2004-04-20 Robin Hugh Johnson sig 3 DDCAFEE6 2003-06-30 Mayo Jordanov sig 2 X 57983F73 2004-02-11 Piotr Banasik sig 3 X 99455482 2003-05-18 Fred Van Andel sig 3 X 3BAA3AE0 2003-05-24 Rasmus Lerdorf sig 3 34884E85 2003-08-28 Robin Hugh Johnson sig 3 34884E85 2003-03-30 Robin Hugh Johnson sig 3 34884E85 2003-03-30 Robin Hugh Johnson uid [ revoked] Robin Hugh Johnson rev 34884E85 2004-04-20 Robin Hugh Johnson sig 3 DDCAFEE6 2003-06-30 Mayo Jordanov sig 2 X 89A343DB 2002-09-01 Graham Poulter sig 2 X 57983F73 2004-02-11 Piotr Banasik sig 3 X 073E939F 2002-08-31 Gerard Escalante sig 3 X 99455482 2003-05-18 Fred Van Andel sig 3 X 3BAA3AE0 2003-05-24 Rasmus Lerdorf sig 3 34884E85 2003-08-28 Robin Hugh Johnson sig 3 34884E85 2002-08-27 Robin Hugh Johnson sig 3 34884E85 2002-08-27 Robin Hugh Johnson sig 3 34884E85 2002-08-27 Robin Hugh Johnson uid [ revoked] Robin Hugh Johnson rev 34884E85 2004-04-20 Robin Hugh Johnson sig 2 X 89A343DB 2002-09-01 Graham Poulter sig 2 X 57983F73 2004-02-11 Piotr Banasik sig 3 X 073E939F 2002-08-31 Gerard Escalante sig 3 X 99455482 2003-05-18 Fred Van Andel sig 3 X 3BAA3AE0 2003-05-24 Rasmus Lerdorf sig 3 34884E85 2003-08-28 Robin Hugh Johnson sig 3 34884E85 2002-08-27 Robin Hugh Johnson sig 3 34884E85 2002-08-27 Robin Hugh Johnson sig 3 34884E85 2002-08-27 Robin Hugh Johnson uid [ revoked] Robin Hugh Johnson rev 34884E85 2005-08-31 Robin Hugh Johnson sig 3 34884E85 2005-03-10 Robin Hugh Johnson sig 3 X CCF0FAEE 2004-09-02 Jack Cummings (John) sig 3 34884E85 2004-06-01 Robin Hugh Johnson sig 3 X 6C27DEAB 2004-09-02 Randall Donald sig 3 X 5A827A2D 2004-09-02 Luca Filipozzi sig 3 X 57983F73 2004-09-02 Piotr Banasik sig 3 X B52E594E 2004-09-02 Piotr Banasik sig 3 X D87C6781 2004-09-02 Jonathan Walther sig 3 X 5230514A 2004-09-02 Shaun Jackman sig 3 X 746C51F4 2004-09-02 Kevin Lindsay (Trakker) sig 2 X 1A2870AD 2004-09-03 David Renardson sig 3 X CDC9A70D 2004-09-03 Simon Kirby sig 3 X 5135AF61 2004-09-03 Scott M. Rose sig 3 X EFA6B9D5 2004-09-04 Hamish Moffatt sig 2 FD6645AB 2004-09-04 Ryan Murray sig 3 F02EB55D 2004-09-06 Norman Hodges (key3) sig 2 X B24B0F19 2004-09-06 Trevor Schellhorn sig 3 X 2642186A 2004-09-08 Kenneth G Walker (Barrister, Solicitor, Notary http://qblaw.ca) sig 3 X 06D1D3CE 2004-09-08 kwalker sig 3 9E791EEE 2004-09-08 Ken Walker sig 3 X A6A68D7F 2004-09-07 Ross Kakuschke (Work) sig 2 22B40A2C 2005-03-10 Michael Sterrett -Mr. Bones.- sig 3 34884E85 2004-08-27 Robin Hugh Johnson sig 2 X 67FF48C7 2004-08-31 Alexander M. Turek sig 1 DDCAFEE6 2005-03-10 Mayo Jordanov sig 3 57983F73 2005-03-11 Piotr Banasik sig 2 DDCAFEE6 2005-03-10 Mayo Jordanov sig A284E3D0 2005-06-28 Stephan Springer sig 3 9C67CD96 2005-06-29 Torsten Veller sig 3 33756619 2005-06-30 Daniel Faber sig 6D8ABE71 2005-06-26 Christoph Berg sig 58510B5A 2005-06-26 Christoph Berg sig 2 36E75604 2005-06-24 Michal \xc4\x8ciha\xc5\x99 sig 60F96E8D 2005-06-27 Michael Brade sig 2 94C09C7F 2005-06-29 Peter Palfrader sig 03556F0E 2005-06-27 Marc Hildebrand sig 3 0E84D2EA 2005-06-26 Olivier L. Muller sig 3 26F170CA 2005-06-27 Florian Brand sig 3 2A623F72 2005-06-26 Christoph Probst sig 30C0F005 2005-06-26 Tobias Scherbaum sig 3DBD3B20 2005-06-26 Johannes Boeck sig 3 523C4663 2005-06-25 Mathias Landh\xe4\x75\xdf\x65r (Private) sig 667F3F30 2005-06-24 Stefan Schweizer (genstef) sig 3 9978AF86 2005-06-26 Christoph Probst sig CF7D6206 2005-06-25 Ulrich Plate sig B3B2A12C 2005-07-08 ct magazine CERTIFICATE sig 16B0BE2E 2005-08-04 Alin Nastac uid [ revoked] Robin Hugh Johnson rev 34884E85 2006-05-19 Robin Hugh Johnson sig 3 34884E85 2005-08-31 Robin Hugh Johnson uid Robin Hugh Johnson sig 3 34884E85 2006-06-23 Robin Hugh Johnson sig P 65D0FD58 2006-07-30 CA Cert Signing Authority (Root CA) uid Robin Hugh Johnson sig 3 34884E85 2006-07-30 Robin Hugh Johnson uid Robin Hugh Johnson sig 3 34884E85 2007-02-25 Robin Hugh Johnson uid Robin Hugh Johnson sig 3 34884E85 2007-02-25 Robin Hugh Johnson sub 2048g/CA05A397 2002-08-27 [expires: 2008-03-09] sig 34884E85 2005-03-10 Robin Hugh Johnson sub 2048g/67592A1F 2003-04-12 [expires: 2008-03-09] sig 34884E85 2005-03-10 Robin Hugh Johnson sub 1024D/FB33B3A4 2002-08-27 [revoked: 2004-09-09] rev 34884E85 2004-09-09 Robin Hugh Johnson sig 34884E85 2004-08-27 Robin Hugh Johnson sub 2048g/CC772FC3 2002-08-27 [revoked: 2004-09-09] rev 34884E85 2004-09-09 Robin Hugh Johnson sig 34884E85 2004-08-27 Robin Hugh Johnson sub 1024D/3233C22C 2004-08-29 [expires: 2008-03-09] sig 34884E85 2006-06-23 Robin Hugh Johnson sub 1024D/A8E87991 2006-06-23 [expires: 2008-06-22] sig 34884E85 2006-06-23 Robin Hugh Johnson sub 1024D/9CA1EFD7 2006-06-23 [expires: 2008-06-22] sig 34884E85 2006-06-23 Robin Hugh Johnson sub 2048R/66D8F49B 2006-06-23 [expires: 2008-06-22] sig 34884E85 2006-06-23 Robin Hugh Johnson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 321 bytes Desc: not available Url : /pipermail/attachments/20070226/13429b11/attachment-0001.pgp From dshaw at jabberwocky.com Tue Feb 27 13:25:04 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 27 Feb 2007 07:25:04 -0500 Subject: Bug with duplicate user IDs of different status In-Reply-To: <20070227042534.GJ23359@curie-int.orbis-terrarum.net> References: <20070226022403.GD20493@curie-int.orbis-terrarum.net> <20070227035643.GA6635@jabberwocky.com> <20070227042534.GJ23359@curie-int.orbis-terrarum.net> Message-ID: <20070227122504.GC6635@jabberwocky.com> On Mon, Feb 26, 2007 at 08:25:34PM -0800, Robin H. Johnson wrote: > On Mon, Feb 26, 2007 at 10:56:43PM -0500, David Shaw wrote: > > On Sun, Feb 25, 2007 at 06:24:03PM -0800, Robin H. Johnson wrote: > > > Instructions to reproduce: > > > 1. create any key > > > 2. gpg --edit-key ; adduid foo at bar ; save+quit > > > 3. gpg --edit-key ; revuid foo at bar ; save+quit > > > 4. gpg -v --list-keys foo at bar (shows the revoked uid) > > > 5. gpg --edit-key ; adduid foo at bar > > > 6. display will now show both foo at bar uids > > > 7. save+quit > > > 8. gpg --edit-key (now we get this message: "gpg: key 34884E85: > > > duplicated user ID detected - merged") > > > 9. 'list' shows only the revoked version of the foo at bar uid, and we > > > cannot select the new one to perform any operations on it. > > > > There is a bug here, but this also needs a clarification. In step 9, > > it is proper that only one copy of the foo at bar uid is present and > > there is no way to select one of the foo at bar user IDs: OpenPGP does > > not have a real notion of multiple identical user IDs. GnuPG, as you > > noticed, collapses them together into one user ID that carries all of > > the signatures (self-signatures, revocation signatures, etc) that were > > on both original user IDs. > Hmm, I'm wondering what the correct course of action is then. > In my original case that I reduced to the above, I originally had an > email address (rjohnsob at sfu.ca) from the university I attended, and revuid'd it > after I graduated and the email address was recycled to another user, not > dreaming that I'd be involved again with the university again (my departure was > somewhat bitter). So for some time, that address was NOT a valid source for me, > but now it is again. That's fine. The end result of the merge is that you have one user ID with the collected self-signatures on them. For example: foo at bar: signed 1/1/2007 revoked 1/2/2007 foo at bar: signed 1/10/2007 If that is collapsed then the result is: foo at bar: signed 1/1/2007 revoked 1/2/2007 signed 1/10/2007 Thus foo at bar is no longer revoked. The most recent signature is the one that applies in this case. > > The bug is that this new, joined, user ID appears as revoked (you had > > a 50% chance of that, as the user IDs are merged in order). If you > > exit the --edit-key menu, GnuPG will prompt you to save the modified > > key (the dupe-elimination is the modification). If you say yes and > > then do the --edit-key again, you'll see the user ID isn't really > > revoked. GnuPG should reprocess the key after the user ID collapse so > > the flags (revoked, expired, etc) are set properly. I will make this > > change. > See the attached sigdata.txt file. It does show the old signatures under the > old instance of the uid. Did you run the key through a pass with --edit-key to allow the merge? David From i.r.wezeman at hetnet.nl Sat Feb 17 02:29:22 2007 From: i.r.wezeman at hetnet.nl (Ron Wezeman) Date: Sat, 17 Feb 2007 01:29:22 -0000 Subject: gnupg + libreadline + undefined reference Message-ID: <1171673775.8796.3.camel@localhost> With packages: gpgme-1.0.3 libgcrypt-1.2.4 readline-5.2 gnupg-2.0.2 libassuan-1.0.1 ncurses-5.5 seahorse-0.9.91 -bash-3.1# the next error: gcc -I/srv/include -I/srv/include -g -O2 -Wall -Wno-pointer-sign -o gpg2 gpg.o server.o build-packet.o compress.o compress-bz2.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-packet.o status.o plaintext.o sig-check.o keylist.o pkglue.o pkclist.o skclist.o pubkey-enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdbio.o delkey.o keygen.o helptext.o keyserver.o photoid.o call-agent.o card-util.o exec.o -L/srv/lib -lgcrypt -lgpg-error ../common/libcommon.a ../jnlib/libjnlib.a ../gl/libgnu.a ../common/libgpgrl.a -lz -lbz2 -lresolv -lreadline -L/srv/lib -lassuan -lgpg-error /srv/lib/libreadline.so: undefined reference to `tgetnum' /srv/lib/libreadline.so: undefined reference to `tgoto' /srv/lib/libreadline.so: undefined reference to `tgetflag' /srv/lib/libreadline.so: undefined reference to `BC' /srv/lib/libreadline.so: undefined reference to `tputs' /srv/lib/libreadline.so: undefined reference to `PC' /srv/lib/libreadline.so: undefined reference to `tgetent' /srv/lib/libreadline.so: undefined reference to `UP' /srv/lib/libreadline.so: undefined reference to `tgetstr' collect2: ld returned 1 exit status make[2]: *** [gpg2] Error 1 make[2]: Leaving directory `/usr/src/SOURCES/AC/20070202/gnupg-2.0.2/g10' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/usr/src/SOURCES/AC/20070202/gnupg-2.0.2' make: *** [install-recursive] Error 1 -bash-3.1# It happens also with gnupg-1.4.6 Thanks. Ron