From clbianco at tiscalinet.it Sat Dec 4 11:40:08 2004 From: clbianco at tiscalinet.it (Carlo Luciano Bianco) Date: Sat Dec 4 11:36:39 2004 Subject: Win32 GnuPG with MinGW/MSYS: all tests passed Message-ID: Dear all, I have just updated my GnuPG page with the instructions to get all 25 tests passed with "make check". For "conventional-mdc" it is enough to install dd.exe in MinGW. For "seat" there is a little workaround due to the fact that the plain text files are in Unix (LF) and not in DOS (CRLF) text format. Maybe such a workaround can be enabled or disabled at build time by the "configure" script... As soon as I have some time I will try to look at it. Best regards, Carlo Luciano -- | Carlo Luciano Bianco | ICQ UIN: 109517158 | |______________________| Home page: | |GPG DSA/ElG 1024/4096:|_________________________________________________| |KeyID:0x5324A0DA - Fingerprint:8B00C61034120506111B143DEDBF71B45324A0DA | From ramon at jonjay.com Mon Dec 6 02:16:31 2004 From: ramon at jonjay.com (Ramon F Herrera) Date: Mon Dec 6 02:13:07 2004 Subject: How to decide which private key to use?? Message-ID: <41B3B2EF.2070306@jonjay.com> I am using the GPGme library to write a program that will decrypt many files prorgamatically. The files to be decrypted have been encrypted with exactly one out of three keys. When I decrypt those files interactively, gpg shows me what key(s) was used and I type the passphrase corresponding to that particular key. The problem is, I am not sure how to replicate that behavior within a program: - should I keep on trying our 3 corporate private keys (passphrases) until one of them works? (trial and error) or: - is there any way to request the key from the file, in advance, and use the corresponding passphrase? TIA, -Ramon F Herrera From ramon at jonjay.com Fri Dec 3 22:29:37 2004 From: ramon at jonjay.com (Ramon F Herrera) Date: Mon Dec 13 16:33:22 2004 Subject: How to select the appropriate private key to use? Message-ID: <41B0DAC1.9000700@jonjay.com> I am using the GPGme library to write a program that will decrypt files. The files to be decrypted are encrypted with exactly one out of three possible keys. When I decrypt those files interactively, gpg shows me what key was used and I type the passphrase corresponding to that particular key. The problem is, I am not sure how to do that within a program: - should I keep on trying the 3 private keys (passphrases) until one of them works? (trial and error) or: - is there any way to request the key from the file, in advance, and use the corresponding passphrase? TIA, -Ramon F Herrera From tobias.winkler at s1998.tu-chemnitz.de Fri Dec 3 23:24:15 2004 From: tobias.winkler at s1998.tu-chemnitz.de (Tobias Winkler) Date: Mon Dec 13 16:33:30 2004 Subject: 'HAVE_DOSISH_SYSTEM' - conversion of backslashes to slashes kills fd_cache_invalidate() from iobuf.c Message-ID: <82877969.20041203232415@s1998.tu-chemnitz.de> Hi, I got some problems when importing a (public) key to pubkeys.pgp here under win32. >> gpg: renaming `n:/!--Files--/GnuPG\pubring.gpg' to `n:/!--Files--/GnuPG\pubring.bak' failed: Permission denied >> gpg: error writing keyring `n:/!--Files--/GnuPG\pubring.gpg': file rename error >> ... Renaming the old keyring to backup failed because it was still held open by gpg.exe. Obviously that iobuf_ioctl (NULL, 2, 0, (char*)fname ); in rename_tmp_file() [keyring.c] did NOT close the handle. Actually it was fd_cache_invalidate() which failed here. (called indirectly by iobuf_ioctl()) The reason is that the file paths from the close_cache are stored with backslashes (in win32 of course ;) and the given file path (the one to close) was using (some) slashes instead - therefore the string comparison in fd_cache_invalidate() failed. The slashes came from a conversion of the home path at the beginning of main() [g10.c line 1409 for gnupg-1.2.6] >> #ifdef HAVE_DOSISH_SYSTEM >> if ( strchr (opt.homedir,'\\') ) { >> char *d, *buf = m_alloc (strlen (opt.homedir)+1); >> const char *s = opt.homedir; >> for (d=buf,s=opt.homedir; *s; s++) >> *d++ = *s == '\\'? '/': *s; >> *d = 0; >> set_homedir (buf); >> } >> #endif I removed that part and everything works right for me now. But I didn't do any deeper checks, if that conversion is actually needed somewhere. (maybe there are parts which rely on slashes?) Alternatively one could replace the strcmp() from fd_cache_invalidate() with a function which does recognize backslashes as slashes. Bye, TW. From micron at madlab.it Mon Dec 6 09:48:42 2004 From: micron at madlab.it (micron) Date: Mon Dec 13 16:33:42 2004 Subject: [gpgme] change work dir Message-ID: <200412060948.43005.micron@madlab.it> How can I make gpgme to store/read data from a different dir instead of ~/.gpg? I've seen something into context's key listining mode but I haven't understand how to use it. Thanks in advance micron -- |? micron<- ICQ #118796665 |? GPG Key: |? ~ Keyserver: pgp.mit.edu |? ~ KeyID: 6D632BED ~ "Progress is merely a realisation of utopias" ~ From wk at gnupg.org Mon Dec 6 10:45:46 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Dec 13 16:33:47 2004 Subject: 'HAVE_DOSISH_SYSTEM' - conversion of backslashes to slashes kills fd_cache_invalidate() from iobuf.c In-Reply-To: <82877969.20041203232415@s1998.tu-chemnitz.de> (Tobias Winkler's message of "Fri, 3 Dec 2004 23:24:15 +0100") References: <82877969.20041203232415@s1998.tu-chemnitz.de> Message-ID: <87mzwrg3p1.fsf@wheatstone.g10code.de> On Fri, 3 Dec 2004 23:24:15 +0100, Tobias Winkler said: > The reason is that the file paths from the close_cache > are stored with backslashes (in win32 of course ;) > and the given file path (the one to close) was using (some) > slashes instead - therefore the string comparison in Thanks for that clue. This is probably the reason of a couple of bugs we have never been able to replicate. > Alternatively one could replace the strcmp() from fd_cache_invalidate() > with a function which does recognize backslashes as slashes. That is waht I am going to do. Thanks, Werner From marcus.brinkmann at ruhr-uni-bochum.de Tue Dec 7 11:51:35 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Dec 13 16:34:20 2004 Subject: [gpgme] change work dir In-Reply-To: <200412060948.43005.micron@madlab.it> References: <200412060948.43005.micron@madlab.it> Message-ID: <87llca5qko.wl@ulysses.g10code.de> At Mon, 6 Dec 2004 09:48:42 +0100, micron wrote: > > How can I make gpgme to store/read data from a different dir instead of > ~/.gpg? To werner: skip to proposal at the end if you want. You start the program using GPGME with GNUPGHOME=..., or set the environment variable in your program before creating the context (current implementation: before starting the operation). Note that semantically, we consider gpg/gpgsm to be like daemons to gpgme. Currently those are started by GPGME, but this is merely an implementation detail. You don't expect to be able to change the environment of a webserver from a browser either, and it's conceptually the same here. Of course, you still want to be able to "contact differently configured services", by whatever means. And maybe you even want it on a per-context basis. Usually, you are supposed to use whatever crypto engine configuration the user specified. But there are certainly applications with different requirements (incl. test suites etc). Now that we have versioned symbols, I don't really see a problem with adding an implementation specific interface to set the crypto engine configuration. What about the following interface: * Add a new field "config_dir" to gpgme_engine_info_t, where NULL means the default. * Add gpgme_set_engine_info (gpgme_protocol_t protocol, const char *file_name, const char *config_dir); to allow to set the binary executable and config directory to be used. > I've seen something into context's key listining mode but I haven't understand > how to use it. I don't know what you are referring to. Thanks, Marcus From wk at gnupg.org Tue Dec 7 12:05:16 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Dec 13 16:34:24 2004 Subject: [gpgme] change work dir In-Reply-To: <87llca5qko.wl@ulysses.g10code.de> (Marcus Brinkmann's message of "Tue, 07 Dec 2004 11:51:35 +0100") References: <200412060948.43005.micron@madlab.it> <87llca5qko.wl@ulysses.g10code.de> Message-ID: <874qiy9xn7.fsf@wheatstone.g10code.de> On Tue, 07 Dec 2004 11:51:35 +0100, Marcus Brinkmann said: > * Add a new field "config_dir" to gpgme_engine_info_t, where NULL > means the default. > * Add > gpgme_set_engine_info (gpgme_protocol_t protocol, const char *file_name, > const char *config_dir); > to allow to set the binary executable and config directory to be used. Makes sense to me. Please go ahead. Werner From marcus.brinkmann at ruhr-uni-bochum.de Tue Dec 7 13:13:21 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Dec 13 16:34:37 2004 Subject: [gpgme] change work dir In-Reply-To: <874qiy9xn7.fsf@wheatstone.g10code.de> References: <200412060948.43005.micron@madlab.it> <87llca5qko.wl@ulysses.g10code.de> <874qiy9xn7.fsf@wheatstone.g10code.de> Message-ID: <87is7e5mse.wl@ulysses.g10code.de> At Tue, 07 Dec 2004 12:05:16 +0100, Werner Koch wrote: > > On Tue, 07 Dec 2004 11:51:35 +0100, Marcus Brinkmann said: > > > * Add a new field "config_dir" to gpgme_engine_info_t, where NULL > > means the default. > > > * Add > > > gpgme_set_engine_info (gpgme_protocol_t protocol, const char *file_name, > > const char *config_dir); > > > to allow to set the binary executable and config directory to be used. > > Makes sense to me. Please go ahead. Ok. Actually, I wanted to do this per context, so we need another function like the above which gets a gpgme_ctx_t argument, too. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Tue Dec 7 19:36:02 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Dec 13 16:35:07 2004 Subject: [gpgme] change work dir In-Reply-To: <200412060948.43005.micron@madlab.it> References: <200412060948.43005.micron@madlab.it> Message-ID: <877jnu552l.wl@ulysses.g10code.de> At Mon, 6 Dec 2004 09:48:42 +0100, micron wrote: > > How can I make gpgme to store/read data from a different dir instead of > ~/.gpg? > > I've seen something into context's key listining mode but I haven't understand > how to use it. Ok, here is a deal. I have committed changes to GPGME that should do that. That's my part of the deal. Your part is to actually try them out :) I have only run the included test suite. I did not try to actually change the home dir. This is up to you. The changes are in CVS HEAD (see below for the ChangeLog entry). The way to change the default is to call: gpgme_set_engine_info (GPGME_PROTOCOL_OpenPGP, NULL, "/home/foo/other/gpgrc"); or on a per-context basis: gpgme_ctx_set_engine_info (ctx, GPGME_PROTOCOL_OpenPGP, NULL, "/home/foo/other/gpgrc"); Easy, isn't it? You can also change the binary: gpgme_set_engine_info (GPGME_PROTOCOL_OpenPGP, "/home/foo/bin/gpg2", NULL); Or both. Try it out, and tell me if it works for you. When they do, I can document them and then they'll be part of GPGME 1.1. Thanks, Marcus 2004-12-07 Marcus Brinkmann * libgpgme.vers (GPGME_1.1): New version. * engine-backend.h (struct engine_ops): Add argument FILE_NAME to member get_version(). Add arguments FILE_NAME and HOME_DIR to member new(). Change return type of get_file_name and get_version to char *. * engine-gpgsm.c (gpgsm_get_version): Change return type to char pointer. Do not cache result. (gpgsm_new): Add file_name and home_dir argument, and use them instead of the defaults, if set. * rungpg.c (struct engine_gpg): New member file_name. (gpg_get_version): Change return type to char pointer, and do not cache result. (gpg_release): Free gpg->file_name. (gpg_new): Take new arguments file_name and home_dir. Set the --homedir argument if HOME_DIR is not NULL. Set gpg->file_name. (start): Use gpg->file_name instead _gpgme_get_gpg_path, if set. * engine.h (_gpgme_engine_info_copy, _gpgme_engine_info_release): New prototypes. (_gpgme_engine_new): Change first argument to gpgme_engine_info_t info. * engine.c: Include . (gpgme_get_engine_info): Set *INFO within the lock. Move ENGINE_INFO and ENGINE_INFO_LOCK to .... (engine_info, engine_info_lock): ... here. New static variables. (engine_get_version): Add file_name argument to get_version invocation. Change return type to char pointer. (gpgme_engine_check_version): Rewritten to free() the return value of engine_get_version after using it. (_gpgme_engine_info_release): New function. (gpgme_get_engine_info): Rewritten. (_gpgme_engine_info_copy): New function. (_gpgme_set_engine_info): New function. (gpgme_set_engine_info): New function. (_gpgme_engine_new): Change first argument to gpgme_engine_info_t info, and use that. * gpgme.h (struct _gpgme_engine_info): Change type of file_name and version to char * (remove the const). New member home_dir. (gpgme_set_engine_info, gpgme_ctx_get_engine_info, gpgme_ctx_set_engine_info): New prototypes. * context.h (struct gpgme_context): New member engine_info. * gpgme.c (gpgme_new): Allocate CTX->engine_info. (gpgme_release): Deallocate CTX->engine_info. (gpgme_ctx_get_engine_info, gpgme_ctx_set_engine_info): New functions. * op-support.c (_gpgme_op_reset): Look for correct engine info and pass it to _gpgme_engine_new. * version.c (gpgme_check_version): Adjust to _gpgme_compare_versions returning an int. (_gpgme_compare_versions): Return an int value, not a const char pointer. * ops.h (_gpgme_compare_versions): Same for prototype. From marcus.brinkmann at ruhr-uni-bochum.de Tue Dec 7 19:54:58 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Dec 13 16:35:18 2004 Subject: GPGME CVS branched Message-ID: <874qiy5471.wl@ulysses.g10code.de> Hi, I have just branched off the 1.0.x tree of GPGME to continue on 1.1.x, or whatever it will become when it is ready. No dramatic changes are expected for the 1.1.x tree, at least not in the interfaces. But some development is planned which is destabilizing, so 1.0.x will be kept around for bug fixes only. 1.0.x is basically backward compatible all the way down to 0.4.1 (with minor glitches), and no API or ABI changes are scheduled for that branch. For the time being, most people will want to stay with gpgme 1.0.x, until the new development version has stabilized and 1.1.0 has been released. To do this, move to the gpgme-1-0-branch: If you check out the source, do: cvs checkout -r gpgme-1-0-branch gpgme -d -P If you already have a checkout and want to move it to the branch: cvs update -r gpgme-1-0-branch -d -P If you don't do that, and just stay on the HEAD branch, you will get to see all the new breakages and bugs ;) If you want to move back from the branch to CVS HEAD: cvs update -A -d -P Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Tue Dec 7 20:04:43 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Dec 13 16:35:32 2004 Subject: Unconsistence in gpgme.info In-Reply-To: <41A7C2BC.1040609@rolamasao.org> References: <41A7C2BC.1040609@rolamasao.org> Message-ID: <873byi53qs.wl@ulysses.g10code.de> At Fri, 26 Nov 2004 23:56:44 +0000, Noel Torres wrote: > > I found an unconsistence in gpgme.info, section 7.1 > > Funktion: gpgme_error_t gpgme_new (gpgme_ctx_t *CTX) > The function `gpgme_data_new' creates a new `gpgme_ctx_t' object > and returns a handle for it in CTX. > > As you can see, it gives two diferent names to the same function: > gpgme_new > gpgme_data_new Right, it's a cut and paste error, and corrected now in the HEAD and the gpgme-1-0-branch. Thanks a lot! doc/ 2004-12-07 Marcus Brinkmann * gpgme.texi (Creating Contexts): Fix cut&paste error. Reported by Noel Torres . Marcus From atom at suspicious.org Wed Dec 8 08:12:30 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Mon Dec 13 16:36:00 2004 Subject: intermitent memory warning Message-ID: <20041208014034.A62757@willy.wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 this is just *weird* %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% $ for n in `jot 100` do { date | gpg_1.2.6 --no-options -er smasher > /dev/null ; } 2>&1 | egrep 'using insecure memory!' done | wc -l 84 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% lrwxr-xr-x 1 root wheel 25B Dec 5 11:02 /usr/local/bin/gpg -> /usr/local/bin/gpg_1.3.92 - -r-sr-xr-x 1 root wheel 580K Dec 5 10:52 /usr/local/bin/gpg_1.2.6 - -r-sr-xr-x 1 root wheel 1.6M Dec 5 10:56 /usr/local/bin/gpg_1.3.92 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% i thought i was either going crazy or stupid, but i really am getting intermittent warnings: WARNING: using insecure memory! the test above is unique, because usually in a test of 100, 500, or 1000 trials i get either 0% or 100% warnings. before getting that result, i got a bunch of 100% error... after running that test i got a bunch of 0% error. i suspect that it might be a bug in FreeBSD 5.3-RELEASE since i haven't noticed it before. now i'm having the same problem with 1.2.6 and 1.3.92. has anyone else noticed this? please advise how to trace this problem when it appears... i'm not sure which --debug flag(s) or process-tracking applications (with what options) will be most useful. - -- ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "It's unfair to the American public not to be honest." -- Steven Parrish, Senior Vice President, Philip Morris (Tobacco) Wall Street Journal, August 14, 1995 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.92 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBtqlmAAoJEAx/d+cTpVciKr8H/02zIvhWQFqNdVogQfnbUg47 RLakHyDY3Zj7jPOQd+tCei7Ez9/FZQba+gIQ4oOgm3g6eRoTzpkgIqqmzU0zGaJg dDmbNNkmiVjnN3PzyhBEiCitt9aCtQG47I4b2v23Fff0iIb/crwEPhV++bPAoHOk CbWNHa1dxtt8vs0SGDE7h71GAQ4dg5Uwv6+hhgakLhOPGwAcr3UhKL3Ik/Tno0bX oyfqeoxGro9kJ76qEpZTA0wIaS0eWqM1tdj9uK8b0E4oebX9ryK3Z/2GATskkBKM 2+Vcwpp+HlzxnMSQtj8KacU2QZWqM/wzSxp0RSjOCg5rO0djb1FU2Vz0yv44pQQ= =rLuF -----END PGP SIGNATURE----- From atom at suspicious.org Wed Dec 8 08:15:16 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Mon Dec 13 16:36:02 2004 Subject: ungraceful failure: block_filter Message-ID: <20041208010502.D62757@willy.wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 it seems that the file i was trying to decrypt is borked. gpg 1.2.6 and 1.3.92 both hang and consume cycles at this point... %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% $ gpg_1.2.6 --no-options < file.asc > file gpg: TWOFISH encrypted data Enter passphrase: gpg: encrypted with 1 passphrase gpg: no valid OpenPGP data found. gpg: block_filter 0x80db100: read error (size=15874,a->size=15874) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% $ pgpdump file.asc Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes) New version(4) Sym alg - Twofish with 256-bit key(sym 10) Iterated and salted string-to-key(s2k 3): Hash alg - SHA1(hash 2) Salt - 87 4d 54 a2 22 31 9f dd Count - 65536(coded count 96) New: Symmetrically Encrypted and MDC Packet(tag 18)(8192 bytes) partial start Ver 1 Encrypted data [sym alg is specified in sym-key encrypted session key] (plain text + MDC SHA1(20 bytes)) New: (8192 bytes) partial continue New: (8192 bytes) partial continue pgpdump: unexpected end of file. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - -- ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "This society began with stolen labor on stolen land, which makes all such claims to a tradition of freedom, null and void. It must also be said, that democracy and slavery cannot exist side by side. Nor can democracy and capitalism for that matter. No class society, based on exploitation of the many to enrich a greedy few, can properly claim to be a democracy." -- Ron Wilkins, KPFK (Pacifica), Los Angeles -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.92 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBtqoNAAoJEAx/d+cTpVciEMUIAJDB6mrVpq87C+4iYKF9HYQe 3DilXmpemgb+qZpu3o9zjiQK2L2mP/DLkczjbt5oGl9rwLa4OBcPzYLAN15mx/fd R/vGMaN5w4/TmKjwfQTVR468M4bwSF4wSPEx8hcd1MmZA4VBSnSvGJfGX7UUfAZc uAUh+Z69ClK3jpK5K6ctDA4SaPiMVzlr+xeraojopBTrSe6GOjoZjH+Q2NkaeTSQ 29x93jmEbcNUZCD3+5+JNG9fz5RWdlQZnk69vPcVAcFH8gXamev93TrL3p0D3obP OVqAnOQcwez3xd+RzvPaUyJs3JfLYmj+5Y01WHSTx/Kjga+ql2KVUEgQeHobpAE= =dB4W -----END PGP SIGNATURE----- From albrecht.dress at arcor.de Wed Dec 8 21:14:00 2004 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Mon Dec 13 16:36:20 2004 Subject: New pinentry release? Message-ID: <1102536841l.29937l.1l@antares.localdomain> Hi all, what do you think about preparing a new pinentry release? There has been no change in the CVS sice end-september, and frequently people are asking me about the gtk+-2 extension.... Cheers, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20041208/657e3b5d/attachment-0001.bin From micron at madlab.it Wed Dec 8 22:49:10 2004 From: micron at madlab.it (micron) Date: Mon Dec 13 16:36:22 2004 Subject: [gpgme] change work dir In-Reply-To: <877jnu552l.wl@ulysses.g10code.de> References: <200412060948.43005.micron@madlab.it> <877jnu552l.wl@ulysses.g10code.de> Message-ID: <200412082249.10634.micron@madlab.it> On Tuesday 07 December 2004 19:36, Marcus Brinkmann wrote: > Ok, here is a deal. I have committed changes to GPGME that should do > that. That's my part of the deal. Your part is to actually try them > out :) Wow, thanks a lot! :) I'll try it out as soon as I can, for the next two days I'll be out of home without a computer :( > I have only run the included test suite. I did not try to actually > change the home dir. This is up to you. I'll make some test and make a report here. > The way to change the default is to call: [...] > Easy, isn't it? Yes, good job > Try it out, and tell me if it works for you. When they do, I can > document them and then they'll be part of GPGME 1.1. It'll be a pleasure Cheers micron -- |? micron<- ICQ #118796665 |? GPG Key: |? ~ Keyserver: pgp.mit.edu |? ~ KeyID: 6D632BED ~ "Progress is merely a realisation of utopias" ~ From vectro at yahoo.com Thu Dec 9 03:03:38 2004 From: vectro at yahoo.com (Richard Patterson) Date: Mon Dec 13 16:36:38 2004 Subject: Invalid headers as fatal error Message-ID: <20041209020338.72865.qmail@web13523.mail.yahoo.com> Hello, A certain new release of an unnamed other implementation of OpenPGP creates a very long Version: header that is line-wrapped by some mailers. This in turn causes GPG to issue an "invalid header" fatal error. I suggest that this error should be non-fatal in the abscece of --openpgp. The following patch implements this change: --- gnupg-1.3.92/g10/armor.c-old 2004-10-14 13:47:47.000000000 -0700 +++ gnupg-1.3.92/g10/armor.c 2004-12-08 18:01:47.000000000 -0800 @@ -443,7 +443,7 @@ i = parse_header_line( afx, line, len ); if( i <= 0 ) { - if( i ) + if( i && RFC2440 ) rc = G10ERR_INVALID_ARMOR; break; } As I am not subscribed to the gnupg-devel mailing list, replies should CC vectro@yahoo.com. Thank you for your consideration. --Richard Patterson __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From wk at gnupg.org Thu Dec 9 12:29:58 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Dec 13 16:37:00 2004 Subject: New pinentry release? In-Reply-To: <1102536841l.29937l.1l@antares.localdomain> (Albrecht =?utf-8?q?Dre=C3=9F's?= message of "Wed, 08 Dec 2004 20:14:00 +0000") References: <1102536841l.29937l.1l@antares.localdomain> Message-ID: <87zn0nogjt.fsf@wheatstone.g10code.de> On Wed, 08 Dec 2004 20:14:00 +0000, Albrecht Dre? said: > what do you think about preparing a new pinentry release? There has been > no change in the CVS sice end-september, and frequently people are asking > me about the gtk+-2 extension.... Marcus: Didn't we changed this in the CVS already? I can't check right now because I am on the train and using the Debian packages one. Anyway, we should do such a release soon. We are also preparing another pinentry version but I am not sure whether this will be ready by Christmas. I'd like to include that (still secret one) into the next release. Salam-Shalom, Werner From wk at gnupg.org Thu Dec 9 17:16:22 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Dec 13 16:37:18 2004 Subject: [Announce] sha1sum for MS Windows released Message-ID: <871xdz8n1l.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From atom at suspicious.org Wed Dec 8 08:12:30 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Mon Dec 13 16:37:20 2004 Subject: intermitent memory warning Message-ID: <20041208014034.A62757@willy.wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 this is just *weird* %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% $ for n in `jot 100` do { date | gpg_1.2.6 --no-options -er smasher > /dev/null ; } 2>&1 | egrep 'using insecure memory!' done | wc -l 84 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% lrwxr-xr-x 1 root wheel 25B Dec 5 11:02 /usr/local/bin/gpg -> /usr/local/bin/gpg_1.3.92 - -r-sr-xr-x 1 root wheel 580K Dec 5 10:52 /usr/local/bin/gpg_1.2.6 - -r-sr-xr-x 1 root wheel 1.6M Dec 5 10:56 /usr/local/bin/gpg_1.3.92 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% i thought i was either going crazy or stupid, but i really am getting intermittent warnings: WARNING: using insecure memory! the test above is unique, because usually in a test of 100, 500, or 1000 trials i get either 0% or 100% warnings. before getting that result, i got a bunch of 100% error... after running that test i got a bunch of 0% error. i suspect that it might be a bug in FreeBSD 5.3-RELEASE since i haven't noticed it before. now i'm having the same problem with 1.2.6 and 1.3.92. has anyone else noticed this? please advise how to trace this problem when it appears... i'm not sure which --debug flag(s) or process-tracking applications (with what options) will be most useful. - -- ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "It's unfair to the American public not to be honest." -- Steven Parrish, Senior Vice President, Philip Morris (Tobacco) Wall Street Journal, August 14, 1995 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.92 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBtqlmAAoJEAx/d+cTpVciKr8H/02zIvhWQFqNdVogQfnbUg47 RLakHyDY3Zj7jPOQd+tCei7Ez9/FZQba+gIQ4oOgm3g6eRoTzpkgIqqmzU0zGaJg dDmbNNkmiVjnN3PzyhBEiCitt9aCtQG47I4b2v23Fff0iIb/crwEPhV++bPAoHOk CbWNHa1dxtt8vs0SGDE7h71GAQ4dg5Uwv6+hhgakLhOPGwAcr3UhKL3Ik/Tno0bX oyfqeoxGro9kJ76qEpZTA0wIaS0eWqM1tdj9uK8b0E4oebX9ryK3Z/2GATskkBKM 2+Vcwpp+HlzxnMSQtj8KacU2QZWqM/wzSxp0RSjOCg5rO0djb1FU2Vz0yv44pQQ= =rLuF -----END PGP SIGNATURE----- From atom at suspicious.org Wed Dec 8 08:15:16 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Mon Dec 13 16:37:23 2004 Subject: ungraceful failure: block_filter Message-ID: <20041208010502.D62757@willy.wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 it seems that the file i was trying to decrypt is borked. gpg 1.2.6 and 1.3.92 both hang and consume cycles at this point... %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% $ gpg_1.2.6 --no-options < file.asc > file gpg: TWOFISH encrypted data Enter passphrase: gpg: encrypted with 1 passphrase gpg: no valid OpenPGP data found. gpg: block_filter 0x80db100: read error (size=15874,a->size=15874) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% $ pgpdump file.asc Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes) New version(4) Sym alg - Twofish with 256-bit key(sym 10) Iterated and salted string-to-key(s2k 3): Hash alg - SHA1(hash 2) Salt - 87 4d 54 a2 22 31 9f dd Count - 65536(coded count 96) New: Symmetrically Encrypted and MDC Packet(tag 18)(8192 bytes) partial start Ver 1 Encrypted data [sym alg is specified in sym-key encrypted session key] (plain text + MDC SHA1(20 bytes)) New: (8192 bytes) partial continue New: (8192 bytes) partial continue pgpdump: unexpected end of file. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - -- ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "This society began with stolen labor on stolen land, which makes all such claims to a tradition of freedom, null and void. It must also be said, that democracy and slavery cannot exist side by side. Nor can democracy and capitalism for that matter. No class society, based on exploitation of the many to enrich a greedy few, can properly claim to be a democracy." -- Ron Wilkins, KPFK (Pacifica), Los Angeles -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.92 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBtqoNAAoJEAx/d+cTpVciEMUIAJDB6mrVpq87C+4iYKF9HYQe 3DilXmpemgb+qZpu3o9zjiQK2L2mP/DLkczjbt5oGl9rwLa4OBcPzYLAN15mx/fd R/vGMaN5w4/TmKjwfQTVR468M4bwSF4wSPEx8hcd1MmZA4VBSnSvGJfGX7UUfAZc uAUh+Z69ClK3jpK5K6ctDA4SaPiMVzlr+xeraojopBTrSe6GOjoZjH+Q2NkaeTSQ 29x93jmEbcNUZCD3+5+JNG9fz5RWdlQZnk69vPcVAcFH8gXamev93TrL3p0D3obP OVqAnOQcwez3xd+RzvPaUyJs3JfLYmj+5Y01WHSTx/Kjga+ql2KVUEgQeHobpAE= =dB4W -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Fri Dec 10 16:07:49 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Mon Dec 13 16:37:48 2004 Subject: intermitent memory warning In-Reply-To: <20041208014034.A62757@willy.wonka> References: <20041208014034.A62757@willy.wonka> Message-ID: <20041210150749.GA1379@jabberwocky.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Dec 08, 2004 at 02:12:30AM -0500, Atom 'Smasher' wrote: > i thought i was either going crazy or stupid, but i really am getting > intermittent warnings: > WARNING: using insecure memory! > > the test above is unique, because usually in a test of 100, 500, or 1000 > trials i get either 0% or 100% warnings. before getting that result, i got > a bunch of 100% error... after running that test i got a bunch of 0% > error. > > i suspect that it might be a bug in FreeBSD 5.3-RELEASE since i haven't > noticed it before. now i'm having the same problem with 1.2.6 and 1.3.92. > has anyone else noticed this? I tried to duplicate it on Linux, but without any luck. It might be a FreeBSD thing, or it might be something particular to your machine? I've never heard of this happenening, even on FreeBSD, so I don't know what to think yet. > please advise how to trace this problem when it appears... i'm not sure > which --debug flag(s) or process-tracking applications (with what options) > will be most useful. If you do C, take a peek at the code in util/secmem.c:lock_pool. It is unfortunately quite rich in #ifdefs since locking memory is pretty platform-specific. Add some debugging there - say, printing out errno whenever mlock() returns -1. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.93-cvs (GNU/Linux) iGoEARECACoFAkG5u8UjGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2tleS5h c2MACgkQ4mZch0nhy8lcbgCdFi5ioNdT8EJ+17zKRSIV0l/HLwIAn1EMzmcmIyMl M7h3oBlwZFtvSpFo =hC/b -----END PGP SIGNATURE----- From michaelnottebrock at gmx.net Sat Dec 11 13:04:43 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Dec 13 16:37:59 2004 Subject: GPGME CVS branched In-Reply-To: <874qiy5471.wl@ulysses.g10code.de> References: <874qiy5471.wl@ulysses.g10code.de> Message-ID: <200412111304.48280.michaelnottebrock@gmx.net> On Tuesday, 7. December 2004 19:54, Marcus Brinkmann wrote: gpgme has recently been changed to use ttyname_r in gpgsm-engine.c. ttyname_r is not available on a lot of platforms, including FreeBSD - it would be nice if ttyname_r usage could be optionalised and checked for by configure. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20041211/3052dc71/attachment-0001.bin From michaelnottebrock at gmx.net Sat Dec 11 13:11:55 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Dec 13 16:38:00 2004 Subject: GPGME CVS branched In-Reply-To: <200412111304.48280.michaelnottebrock@gmx.net> References: <874qiy5471.wl@ulysses.g10code.de> <200412111304.48280.michaelnottebrock@gmx.net> Message-ID: <200412111311.56786.michaelnottebrock@gmx.net> On Saturday, 11. December 2004 13:04, Michael Nottebrock wrote: > On Tuesday, 7. December 2004 19:54, Marcus Brinkmann wrote: > > gpgme has recently been changed to use ttyname_r in gpgsm-engine.c. > ttyname_r is not available on a lot of platforms, including FreeBSD - it > would be nice if ttyname_r usage could be optionalised and checked for by > configure. Well, actually not so recently, but I haven't had a chance to work on gpgme on FreeBSD in a long time... :) -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20041211/b3cb2585/attachment-0001.bin From marcus.brinkmann at ruhr-uni-bochum.de Sat Dec 11 14:42:23 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Dec 13 16:38:03 2004 Subject: GPGME CVS branched In-Reply-To: <200412111304.48280.michaelnottebrock@gmx.net> References: <874qiy5471.wl@ulysses.g10code.de> <200412111304.48280.michaelnottebrock@gmx.net> Message-ID: <87r7lxc5og.wl@ulysses.g10code.de> At Sat, 11 Dec 2004 13:04:43 +0100, Michael Nottebrock wrote: > > [1 ] > On Tuesday, 7. December 2004 19:54, Marcus Brinkmann wrote: > > gpgme has recently been changed to use ttyname_r in gpgsm-engine.c. ttyname_r > is not available on a lot of platforms, including FreeBSD - it would be nice > if ttyname_r usage could be optionalised and checked for by configure. Please add ttyname_r to FreeBSD if at all possible. It is POSIX by now. Is ttyname() on FreeBSD thread safe? Not having a thread-safe way means you make GPGME thread-unsafe. It's a small race, and ttyname is not used much, and even if it is used its value usually doesn't change. But nevertheless it is there. So please consider adding ttyname_r to FreeBSD also. I can put in a check and fall back to ttyname with a warning. It's what we do for getenv already. Can you please test the patch below? If it detects the lack of ttyname_r, issues a warning and compiles and links in the replacement function, I will apply it. Please let me know. (Of course you need to rerun autogen.sh after applying). Thanks, Marcus Index: configure.ac =================================================================== RCS file: /cvs/gnupg/gpgme/configure.ac,v retrieving revision 1.94 diff -u -p -r1.94 configure.ac --- configure.ac 7 Dec 2004 21:13:36 -0000 1.94 +++ configure.ac 11 Dec 2004 13:36:13 -0000 @@ -169,6 +170,15 @@ AC_REPLACE_FUNCS(stpcpy) AC_REPLACE_FUNCS(vasprintf) if test "$ac_cv_func_vasprintf" != yes; then GNUPG_CHECK_VA_COPY +fi + +# Try to find a thread-safe version of ttyname(). +AC_REPLACE_FUNCS(ttyname_r) +if test "$ac_cv_func_ttyname_r" != yes; then + AC_MSG_WARN([ +*** +*** ttyname() is not thread-safe and ttyname_r() does not exist +***]) fi # Try to find a thread-safe version of getenv(). --- /dev/null 2004-09-14 00:34:58.000000000 +0200 +++ gpgme/ttyname_r.c 2004-12-11 14:32:29.000000000 +0100 @@ -0,0 +1,43 @@ +/* ttyname_r.c - A ttyname_r() replacement. + Copyright (C) 2003, 2004 g10 Code GmbH + + This file is part of GPGME. + + GPGME is free software; you can redistribute it and/or modify it + under the terms of the GNU Lesser General Public License as + published by the Free Software Foundation; either version 2.1 of + the License, or (at your option) any later version. + + GPGME is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with this program; if not, write to the Free Software + Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA + 02111-1307, USA. */ + +#if HAVE_CONFIG_H +#include +#endif +#include +#include +#include +#include + + +#warning ttyname is not thread-safe, and ttyname_r is missing + +int ttyname_r(int fd, char *buf, size_t buflen) +{ + char *tty; + + tty = ttyname (fd); + if (!tty) + return errno; + + strncpy (buf, tty, buflen); + buf[buflen - 1] = '\0'; + return (strlen (tty) >= buflen) ? ERANGE : 0; +} From micron at madlab.it Sat Dec 11 15:35:42 2004 From: micron at madlab.it (micron) Date: Mon Dec 13 16:38:04 2004 Subject: [gpgme] change work dir In-Reply-To: <877jnu552l.wl@ulysses.g10code.de> References: <200412060948.43005.micron@madlab.it> <877jnu552l.wl@ulysses.g10code.de> Message-ID: <200412111535.42558.micron@madlab.it> On Tuesday 07 December 2004 19:36, Marcus Brinkmann wrote: > Ok, here is a deal. I have committed changes to GPGME that should do > that. That's my part of the deal. Your part is to actually try them > out :) Ok, I've tried out gpgme_ctx_set_engine_info function with the silly attached program. gpgme_ctx_set_engine_info return this error: a.out: engine.c:308: _gpgme_set_engine_info: Assertion `file_name' failed. Aborted Looking into engine.c i made this changes: Index: engine.c =================================================================== RCS file: /cvs/gnupg/gpgme/gpgme/engine.c,v retrieving revision 1.46 diff -u -r1.46 engine.c --- engine.c 7 Dec 2004 21:13:36 -0000 1.46 +++ engine.c 11 Dec 2004 12:20:11 -0000 @@ -305,8 +305,9 @@ else { new_file_name = engine_get_file_name (proto); - assert (file_name); - new_file_name = strdup (new_file_name); + assert (new_file_name); + file_name = strdup (new_file_name); + } if (!new_file_name) return gpg_error_from_errno (errno); In this way the program list all keys stored into the specified directory but, in the end it segments. The problem comes from gpgme_release function. With a little debug I found that the signal SIGSEGV is raised into engine.c:130 free (info->file_name) at the second iteration. info->file_name seems correct, I wasn't able to discover the real problem. Cheers micron |? micron<- ICQ #118796665 |? GPG Key: |? ~ Keyserver: pgp.mit.edu |? ~ KeyID: 6D632BED ~ "Progress is merely a realisation of utopias" ~ -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme_context.c Type: text/x-csrc Size: 1342 bytes Desc: not available Url : /pipermail/attachments/20041211/689426b1/gpgme_context-0001.bin From michaelnottebrock at gmx.net Sat Dec 11 15:49:52 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Dec 13 16:38:06 2004 Subject: GPGME CVS branched In-Reply-To: <87r7lxc5og.wl@ulysses.g10code.de> References: <874qiy5471.wl@ulysses.g10code.de> <200412111304.48280.michaelnottebrock@gmx.net> <87r7lxc5og.wl@ulysses.g10code.de> Message-ID: <200412111549.56166.michaelnottebrock@gmx.net> On Saturday, 11. December 2004 14:42, Marcus Brinkmann wrote: > At Sat, 11 Dec 2004 13:04:43 +0100, > > Michael Nottebrock wrote: > > [1 ] > > On Tuesday, 7. December 2004 19:54, Marcus Brinkmann wrote: > > > > gpgme has recently been changed to use ttyname_r in gpgsm-engine.c. > > ttyname_r is not available on a lot of platforms, including FreeBSD - it > > would be nice if ttyname_r usage could be optionalised and checked for by > > configure. > > Please add ttyname_r to FreeBSD if at all possible. It is POSIX by now. It probably won't be added anymore to FreeBSD 4.x - I'm not sure what the status of ttyname_r of 5.x is because the configure check thinks it exists, but compilation issues a warning "implicit declaration of ttyname_r" (but completes). > I can put in a check and fall back to ttyname with a warning. It's > what we do for getenv already. Can you please test the patch below? > If it detects the lack of ttyname_r, issues a warning and compiles and > links in the replacement function, I will apply it. Please let me > know. Yes, this works fine, thanks! One other thing: The included assuan bits have several problems on FreeBSD, which have all been ironed out by now (we and Werner actually ironed them out on gpa-devel, perhaps you remember) - could you consider updating the assuan import or perhaps just depend on the separate libassuan distribution? -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20041211/63f17880/attachment-0001.bin From marcus.brinkmann at ruhr-uni-bochum.de Sat Dec 11 16:51:09 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Dec 13 16:38:11 2004 Subject: GPGME CVS branched In-Reply-To: <200412111549.56166.michaelnottebrock@gmx.net> References: <874qiy5471.wl@ulysses.g10code.de> <200412111304.48280.michaelnottebrock@gmx.net> <87r7lxc5og.wl@ulysses.g10code.de> <200412111549.56166.michaelnottebrock@gmx.net> Message-ID: <87oeh0deaa.wl@ulysses.g10code.de> At Sat, 11 Dec 2004 15:49:52 +0100, Michael Nottebrock wrote: > > [1 ] > On Saturday, 11. December 2004 14:42, Marcus Brinkmann wrote: > > At Sat, 11 Dec 2004 13:04:43 +0100, > > > > Michael Nottebrock wrote: > > > [1 ] > > > On Tuesday, 7. December 2004 19:54, Marcus Brinkmann wrote: > > > > > > gpgme has recently been changed to use ttyname_r in gpgsm-engine.c. > > > ttyname_r is not available on a lot of platforms, including FreeBSD - it > > > would be nice if ttyname_r usage could be optionalised and checked for by > > > configure. > > > > Please add ttyname_r to FreeBSD if at all possible. It is POSIX by now. > > It probably won't be added anymore to FreeBSD 4.x - I'm not sure what the > status of ttyname_r of 5.x is because the configure check thinks it exists, > but compilation issues a warning "implicit declaration of ttyname_r" (but > completes). Are you saying that on BSD 5.x ttyname_r is found by configure, and not replaced, so gpgme/ttyname_r.c is not linked in, but yet the prototype is not defined in unistd.h? Does compiling and linking the test programs succeed? (This will reveal if the ttyname_r reference in gpgme can be resolved or not). If this is the case, then BSD lacks the prototype, but provides the function, and unistd.h needs to be fixed (but it will work). This reminds me, for systems missing it I added to util.h: #ifndef HAVE_TTYNAME_R int ttyname_r (int fd, char *buf, size_t buflen); #endif at the obvious place. This should get rid of the warning on BSD 4.* I have checked in the ttyname_r patch into HEAD and gpgme-1-0-branch. > > I can put in a check and fall back to ttyname with a warning. It's > > what we do for getenv already. Can you please test the patch below? > > If it detects the lack of ttyname_r, issues a warning and compiles and > > links in the replacement function, I will apply it. Please let me > > know. > > Yes, this works fine, thanks! One other thing: The included assuan bits have > several problems on FreeBSD, which have all been ironed out by now (we and > Werner actually ironed them out on gpa-devel, perhaps you remember) - could > you consider updating the assuan import or perhaps just depend on the > separate libassuan distribution? Note that this is only needed for gpgsm support. I can look at the changes on gpa-devel, and incorporate them. It would be even better if you just do it and send a patch to me, so that it is tested and really works for you. There are some changes necessary in libassuan for GPGME to make it usable as a third-party library (see assuan/README.1st). I will have to update libassuan anyway, but if you need the BSD patch right now, I can check it in, also for the 1.0.x branch (which I otherwise likely wouldn't update anymore). Thanks, Marcus From michaelnottebrock at gmx.net Sat Dec 11 17:54:23 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Dec 13 16:38:13 2004 Subject: GPGME CVS branched In-Reply-To: <87oeh0deaa.wl@ulysses.g10code.de> References: <874qiy5471.wl@ulysses.g10code.de> <200412111549.56166.michaelnottebrock@gmx.net> <87oeh0deaa.wl@ulysses.g10code.de> Message-ID: <200412111754.24826.michaelnottebrock@gmx.net> On Saturday, 11. December 2004 16:51, Marcus Brinkmann wrote: > Are you saying that on BSD 5.x ttyname_r is found by configure, and > not replaced, so gpgme/ttyname_r.c is not linked in, but yet the > prototype is not defined in unistd.h? Does compiling and linking the > test programs succeed? (This will reveal if the ttyname_r reference > in gpgme can be resolved or not). If this is the case, then BSD lacks > the prototype, but provides the function, and unistd.h needs to be > fixed (but it will work). That seems to be the case, thanks for clarifying! That reminds me of a different issue I forgot to report: If I compile with pth support, one of the tests fails to link: gcc -g -O2 -I/usr/local/include/pth -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o .libs/t-thread1 t-thread1.o ../../gpgme/.libs/libgpgme-pthread.so -lpthread -L/usr/local/lib /usr/local/lib/libgpg-error.so -lintl -Wl,--rpath -Wl,/usr/local/lib ../../gpgme/.libs/libgpgme-pthread.so: warning: warning: tmpnam() possibly used unsafely; consider using mkstemp() t-thread1.o(.text+0x12d): In function `passphrase_cb': /mnt/stable-usr/home/lofi/freebsd/ports/security/gpgme/work/gpgme-1.0.1/tests/gpg/t-support.h:67: undefined reference to `__pthread_write' ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to `__pthread_select' ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to `__pthread_connect' ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to `__pthread_accept' ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to `__pthread_waitpid' ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to `__pthread_read' This looks kind of bogus to me, what's going on there? It works if I configure with --disable-pth, but --disable-pth-test yields the same error (pth 2.0.3 is available on the system and found by configure). > > One other thing: The included assuan bits > > have several problems on FreeBSD, which have all been ironed out by now > > (we and Werner actually ironed them out on gpa-devel, perhaps you > > remember) - could you consider updating the assuan import or perhaps > > just depend on the separate libassuan distribution? > > Note that this is only needed for gpgsm support. > > I can look at the changes on gpa-devel, and incorporate them. It > would be even better if you just do it and send a patch to me, so that > it is tested and really works for you. False alarm, I was looking at the wrong sources prior to writing that. The included assuan bits are in fact fine on FreeBSD. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org From michaelnottebrock at gmx.net Sat Dec 11 18:17:06 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Dec 13 16:38:14 2004 Subject: GPGME CVS branched In-Reply-To: <200412111754.24826.michaelnottebrock@gmx.net> References: <874qiy5471.wl@ulysses.g10code.de> <87oeh0deaa.wl@ulysses.g10code.de> <200412111754.24826.michaelnottebrock@gmx.net> Message-ID: <200412111817.12469.michaelnottebrock@gmx.net> On Saturday, 11. December 2004 17:54, Michael Nottebrock wrote: > On Saturday, 11. December 2004 16:51, Marcus Brinkmann wrote: > > Are you saying that on BSD 5.x ttyname_r is found by configure, and > > not replaced, so gpgme/ttyname_r.c is not linked in, but yet the > > prototype is not defined in unistd.h? Does compiling and linking the > > test programs succeed? (This will reveal if the ttyname_r reference > > in gpgme can be resolved or not). If this is the case, then BSD lacks > > the prototype, but provides the function, and unistd.h needs to be > > fixed (but it will work). > > That seems to be the case, thanks for clarifying! > > That reminds me of a different issue I forgot to > report: If I compile with pth support, one of the tests fails to link: > > gcc -g -O2 -I/usr/local/include/pth -Wall -Wcast-align -Wshadow > -Wstrict-prototypes -o .libs/t-thread1 > t-thread1.o ../../gpgme/.libs/libgpgme-pthread.so -lpthread > -L/usr/local/lib /usr/local/lib/libgpg-error.so -lintl -Wl,--rpath > -Wl,/usr/local/lib > ../../gpgme/.libs/libgpgme-pthread.so: warning: warning: tmpnam() possibly > used unsafely; consider using mkstemp() > t-thread1.o(.text+0x12d): In function `passphrase_cb': > /mnt/stable-usr/home/lofi/freebsd/ports/security/gpgme/work/gpgme-1.0.1/tes >ts/gpg/t-support.h:67: undefined reference to `__pthread_write' > ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to > `__pthread_select' > ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to > `__pthread_connect' > ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to > `__pthread_accept' > ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to > `__pthread_waitpid' > ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to > `__pthread_read' > > This looks kind of bogus to me, what's going on there? Looking at the Makefile templates a bit, it seems to me that in the pth-case PTH_LDFLAGS would need to be added to the t_thread1_LDFLAGS. If I do this manually, the test compiles. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20041211/9039f02b/attachment-0001.bin From marcus.brinkmann at ruhr-uni-bochum.de Sat Dec 11 20:38:57 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Dec 13 16:38:16 2004 Subject: GPGME CVS branched In-Reply-To: <200412111817.12469.michaelnottebrock@gmx.net> References: <874qiy5471.wl@ulysses.g10code.de> <87oeh0deaa.wl@ulysses.g10code.de> <200412111754.24826.michaelnottebrock@gmx.net> <200412111817.12469.michaelnottebrock@gmx.net> Message-ID: <87llc4d3qm.wl@ulysses.g10code.de> At Sat, 11 Dec 2004 18:17:06 +0100, Michael Nottebrock wrote: > > gcc -g -O2 -I/usr/local/include/pth -Wall -Wcast-align -Wshadow > > -Wstrict-prototypes -o .libs/t-thread1 > > t-thread1.o ../../gpgme/.libs/libgpgme-pthread.so -lpthread > > -L/usr/local/lib /usr/local/lib/libgpg-error.so -lintl -Wl,--rpath > > -Wl,/usr/local/lib > > ../../gpgme/.libs/libgpgme-pthread.so: warning: warning: tmpnam() possibly > > used unsafely; consider using mkstemp() > > t-thread1.o(.text+0x12d): In function `passphrase_cb': > > /mnt/stable-usr/home/lofi/freebsd/ports/security/gpgme/work/gpgme-1.0.1/tes > >ts/gpg/t-support.h:67: undefined reference to `__pthread_write' > > ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to > > `__pthread_select' > > ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to > > `__pthread_connect' > > ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to > > `__pthread_accept' > > ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to > > `__pthread_waitpid' > > ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to > > `__pthread_read' > > > > This looks kind of bogus to me, what's going on there? > > Looking at the Makefile templates a bit, it seems to me that in the pth-case > PTH_LDFLAGS would need to be added to the t_thread1_LDFLAGS. If I do this > manually, the test compiles. I don't understand that at all. What does PTH have to do with libpthread, which is used in the test? The above indicates some breakage using pthread on your system. The undefined references clearly come from the system library, not from GPGME (ie, GPGME refers to write(), and that is replaced in the pthread case with __pthread_write(), I assume. You have to check why -lpthread is not enough on your system (or where the error lies). I don't see how pth could enter the picture in any way here. Thanks, Marcus From michaelnottebrock at gmx.net Sat Dec 11 21:04:45 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Dec 13 16:38:18 2004 Subject: GPGME CVS branched In-Reply-To: <87llc4d3qm.wl@ulysses.g10code.de> References: <874qiy5471.wl@ulysses.g10code.de> <200412111817.12469.michaelnottebrock@gmx.net> <87llc4d3qm.wl@ulysses.g10code.de> Message-ID: <200412112104.49744.michaelnottebrock@gmx.net> On Saturday, 11. December 2004 20:38, Marcus Brinkmann wrote: > At Sat, 11 Dec 2004 18:17:06 +0100, > > Michael Nottebrock wrote: > > > gcc -g -O2 -I/usr/local/include/pth -Wall -Wcast-align -Wshadow > > > -Wstrict-prototypes -o .libs/t-thread1 > > > t-thread1.o ../../gpgme/.libs/libgpgme-pthread.so -lpthread > > > -L/usr/local/lib /usr/local/lib/libgpg-error.so -lintl -Wl,--rpath > > > -Wl,/usr/local/lib > > > ../../gpgme/.libs/libgpgme-pthread.so: warning: warning: tmpnam() > > > possibly used unsafely; consider using mkstemp() > > > t-thread1.o(.text+0x12d): In function `passphrase_cb': > > > /mnt/stable-usr/home/lofi/freebsd/ports/security/gpgme/work/gpgme-1.0.1 > > >/tes ts/gpg/t-support.h:67: undefined reference to `__pthread_write' > > > ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to > > > `__pthread_select' > > > ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to > > > `__pthread_connect' > > > ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to > > > `__pthread_accept' > > > ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to > > > `__pthread_waitpid' > > > ../../gpgme/.libs/libgpgme-pthread.so: undefined reference to > > > `__pthread_read' > > > > > > This looks kind of bogus to me, what's going on there? > > > > Looking at the Makefile templates a bit, it seems to me that in the > > pth-case PTH_LDFLAGS would need to be added to the t_thread1_LDFLAGS. If > > I do this manually, the test compiles. > > I don't understand that at all. What does PTH have to do with > libpthread, which is used in the test? > > The above indicates some breakage using pthread on your system. No, like I said before this works fine if pth is disabled. In the pth case this test needs to be linked against pth's libpthread though, not the system threads library, i.e. an additional -L parameter is needed that points to (PREFIX)/lib/pth so the libpthread that resides there gets picked up (why exactly this is necessary I haven't investigated, but it's definitely the case here). Perhaps the tests should be modified so that they're compiled and performed twice - once for libgpgme-pthread and once for libgpgme-pth. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20041211/93f72221/attachment-0001.bin From marcus.brinkmann at ruhr-uni-bochum.de Sat Dec 11 21:58:09 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Dec 13 16:38:20 2004 Subject: GPGME CVS branched In-Reply-To: <200412112104.49744.michaelnottebrock@gmx.net> References: <874qiy5471.wl@ulysses.g10code.de> <200412111817.12469.michaelnottebrock@gmx.net> <87llc4d3qm.wl@ulysses.g10code.de> <200412112104.49744.michaelnottebrock@gmx.net> Message-ID: <87k6rod02m.wl@ulysses.g10code.de> At Sat, 11 Dec 2004 21:04:45 +0100, Michael Nottebrock wrote: > In the pth case this test needs to be linked against pth's libpthread though, > not the system threads library, i.e. an additional -L parameter is needed > that points to (PREFIX)/lib/pth so the libpthread that resides there gets > picked up (why exactly this is necessary I haven't investigated, but it's > definitely the case here). This makes no sense. pth and pthread are two completely different libraries, and GPGME supports both. gpgme-pthread is used with the systems pthread library, gpgme-pth is used with Pth. gpgme-pthread is not related to pth in whatever way. Pth doesn't even provide a pthread, as far as I know. At least not on Debian GNU/Linux, is that different on your system? > Perhaps the tests should be modified so that they're compiled and performed > twice - once for libgpgme-pthread and once for libgpgme-pth. Yes, maybe, but that is unrelated to your problem. Also, note that the test will be compiled even if you use --without-pthread, or no system pthread library is found. This is also a bug. But if you disable or enable pth, it should make no difference for this test case, which should work as long as you have a system pthread library. Thanks, Marcus From michaelnottebrock at gmx.net Sat Dec 11 22:13:37 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Dec 13 16:38:21 2004 Subject: GPGME CVS branched In-Reply-To: <200412112104.49744.michaelnottebrock@gmx.net> References: <874qiy5471.wl@ulysses.g10code.de> <87llc4d3qm.wl@ulysses.g10code.de> <200412112104.49744.michaelnottebrock@gmx.net> Message-ID: <200412112213.42205.michaelnottebrock@gmx.net> FWIW, what is the pth-support used for anyway (in gpgme and also gnupg-devel, I'm cc'ing Werner...)? Is it mainly used by the Windows port perhaps? Since I'm being pressured by my fellow packagers on FreeBSD to disable pth support n order to get rid of an "unnecessary" dependency, I'd like know what could break if I did - are there any applications out there known to only work with gpgme-pth, does gnupg-devel have bugs if pth isn't used, etc etc... -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20041211/9171d1fa/attachment-0001.bin From michaelnottebrock at gmx.net Sat Dec 11 22:27:49 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Dec 13 16:38:23 2004 Subject: GPGME CVS branched In-Reply-To: <87k6rod02m.wl@ulysses.g10code.de> References: <874qiy5471.wl@ulysses.g10code.de> <200412112104.49744.michaelnottebrock@gmx.net> <87k6rod02m.wl@ulysses.g10code.de> Message-ID: <200412112227.50452.michaelnottebrock@gmx.net> On Saturday, 11. December 2004 21:58, Marcus Brinkmann wrote: > At Sat, 11 Dec 2004 21:04:45 +0100, > > Michael Nottebrock wrote: > > In the pth case this test needs to be linked against pth's libpthread > > though, not the system threads library, i.e. an additional -L parameter > > is needed that points to (PREFIX)/lib/pth so the libpthread that resides > > there gets picked up (why exactly this is necessary I haven't > > investigated, but it's definitely the case here). > > This makes no sense. pth and pthread are two completely different > libraries, and GPGME supports both. gpgme-pthread is used with the > systems pthread library, gpgme-pth is used with Pth. gpgme-pthread is > not related to pth in whatever way. Pth doesn't even provide a > pthread, as far as I know. At least not on Debian GNU/Linux, is that > different on your system? Yes it does, if you configure pth with --enable-pthread. I suppose the debian package isn't configured that way. With --enable-pthread you'll get a pthread.h header in pth's include subdir and a libpthread shared library in pth's lib subdir. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20041211/8619d52c/attachment-0001.bin From bernhard at bksys.at Sun Dec 12 05:00:55 2004 From: bernhard at bksys.at (Bernhard Kuemel) Date: Mon Dec 13 16:38:25 2004 Subject: slow(&huge) password digest algorithm for GPG Message-ID: <41BBC277.4020703@bksys.at> Hi gnupg-devel! gpg needs a slow algorithm to digest the passphrase before it decrypts the secret key. If it takes 1 s then dictionary or brute force attacks will be substantially slowed down and much shorter passphrases will suffice. I forgot my passphrase and now I need a new key. And a new passphrase. And a way to memorize or store it. Hmm, frequent use of gpg would help, but I don't have gpg integrated in mozilla yet ... So ... I have some ideas about the passphrase digest: the passphrase (together with a salt) is hashed with e.g. SHA1. The result is hashed, and we keep computing hashes from the previous hash until a user selected time like approximately 1 s has passed. The last hash (and the salt) is stored in the secret key and the secret key is encrypted with the second last hash. When using the secret key the passphrase+salt is again hashed until a hash is produced that compares equal to the stored hash. The second last hash decrypts the secret key. A dictionary or brute force attaker would test a passphrase by computing hashes until he finds a matching hash. But with a wrong passphrase he won't find one. So he has to stop and try another passphrase. If he stops too early he will not make it to the matching hash when trying the correct passphrase. So he has to pick a number of hashes which he assumes is likely to be larger than the one used by the user and that may well be twice as much. SHA1 (IMO) is a good choice here, as 1.) it is not easy to speed it up, because many people want a fast SHA1 so it is already well optimized. If a significantly faster version comes up it is easy to upgrade GPG (unless patents ...) 2.) it has not shown cryptographic weaknesses for some time. Should it become possible to find the plain text for a given SHA1 then the second last hash (which decrypts the secret key) could be found via the last hash stored in the secret key. I'm not sure if this is of concern as hashig typically loses information about the plain text (it must, if the plain text is larger than the hash). A solution should be to compute the new hash over the last 2 hashes. Another way to harden the scheme is to make it consume much memory. So the guys who build custom chips to crack keys will need lots of silicon. I'm not sure which way really requires an ideally configurable amount of memory preferably for the whole runtime. We could scatter the computed hashes over a buffer with configurable size and at the end pick some (non zero) samples which will be hashed and used to en/decrypt the secret key. But when making the buffer too big it will contain too much empty space and smart memory management may do with less memory. We could fill the memory with a pseudo random number generator, but smart memory management might supply this fill data where it previously only declared the managed empty space to be zero filled. Maybe the internal state variables of the SHA1 algo can deliver more and fast high quality data to fill memory. Hey, if we could find something useful to do instead of this trash, like seti@home or this cancer research project, that would be great. But I'm afraid that's incompatible with our goal. I'm sorta tired now so any ideas I missed may come in future messages. Bernhard From marcus.brinkmann at ruhr-uni-bochum.de Sun Dec 12 15:50:26 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Dec 13 16:38:30 2004 Subject: GPGME CVS branched In-Reply-To: <200412112213.42205.michaelnottebrock@gmx.net> References: <874qiy5471.wl@ulysses.g10code.de> <87llc4d3qm.wl@ulysses.g10code.de> <200412112104.49744.michaelnottebrock@gmx.net> <200412112213.42205.michaelnottebrock@gmx.net> Message-ID: <87oegztvt9.wl@ulysses.g10code.de> At Sat, 11 Dec 2004 22:13:37 +0100, Michael Nottebrock wrote: > > [1 ] > FWIW, what is the pth-support used for anyway (in > gpgme and also gnupg-devel, I don't know if anybody actually uses it, but we at g10 Code like to use concurrent programming without actual multi-threading at times, so we support it and actually use it in various places. > Since I'm being pressured by my fellow packagers on FreeBSD to disable pth > support n order to get rid of an "unnecessary" dependency, I'd like know what > could break if I did - are there any applications out there known to only > work with gpgme-pth, does gnupg-devel have bugs if pth isn't used, etc etc... Actually, I don't know of any program using GPGME with Pth, so you might very well get away with disabling it. In the future, I think I will change GPGME's threading support to be like gcrypt, so you install callbacks. Then there won't be any build or run time dependency on the thread package you use in GPGME. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Sun Dec 12 15:58:32 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Dec 13 16:38:31 2004 Subject: [gpgme] change work dir In-Reply-To: <200412111535.42558.micron@madlab.it> References: <200412060948.43005.micron@madlab.it> <877jnu552l.wl@ulysses.g10code.de> <200412111535.42558.micron@madlab.it> Message-ID: <87llc3tvfr.wl@ulysses.g10code.de> At Sat, 11 Dec 2004 15:35:42 +0100, micron wrote: > a.out: engine.c:308: _gpgme_set_engine_info: Assertion `file_name' failed. > Aborted Excellent, you found a bug ;) > - assert (file_name); > - new_file_name = strdup (new_file_name); > + assert (new_file_name); > + file_name = strdup (new_file_name); Only the assert change is correct, the second change is incorrect. Try this patch instead (already checked in) 2004-12-12 Marcus Brinkmann * engine.c (_gpgme_set_engine_info): Fix assertion. --- engine.c 7 Dec 2004 21:13:36 -0000 1.46 +++ engine.c 12 Dec 2004 14:55:55 -0000 @@ -305,7 +305,7 @@ _gpgme_set_engine_info (gpgme_engine_inf else { new_file_name = engine_get_file_name (proto); - assert (file_name); + assert (new_file_name); new_file_name = strdup (new_file_name); } if (!new_file_name) > With a little debug I found that the signal SIGSEGV is raised into > engine.c:130 > free (info->file_name) > at the second iteration. > info->file_name seems correct, I wasn't able to discover the real problem. This is due to you not storing a pointer to allocated memory in new_file_name above, but a pointer to statically allocated memory (new_file_name is what ends up in info->file_name, and not file_name. The reason I use a different variable new_file_name is so that file_name can be const). I didn't try your test program with my fix, but I am sure you will ;) Thanks, Marcus From fscheerer1 at gmx.de Sun Dec 12 18:42:23 2004 From: fscheerer1 at gmx.de (Franz Scheerer) Date: Mon Dec 13 16:38:44 2004 Subject: [gpgme] change work dir In-Reply-To: <87llc3tvfr.wl@ulysses.g10code.de> References: <200412060948.43005.micron@madlab.it> <200412111535.42558.micron@madlab.it> <87llc3tvfr.wl@ulysses.g10code.de> Message-ID: <200412121842.23896.fscheerer1@gmx.de> Hi, I do not understand the sense behind gpg in general and especially not the sense of gpgme. But I just took a glance on that funny code: > > - assert (file_name); Obivously file_name is expected not to be empty at that point. > > - new_file_name = strdup (new_file_name); I never used strdup before. Therefore I used man. DESCRIPTION The strdup() function returns a pointer to a new string which is a duplicate of the string s. Memory for the new string is obtained with malloc(3), and can be freed with free(3). So, strdup does approximately the same as the familiar strcpy, but allocates memory for the destination, too. That makes sense, if no memory is allocated for the destination new_file_name. But, in this case the argument of strdup can not be new_file_name. Most likely one should use file_name (not new_file-name) as argument instead, which is not empty as asserted before. cu Franz From jas at extundo.com Sun Dec 12 18:44:14 2004 From: jas at extundo.com (Simon Josefsson) Date: Mon Dec 13 16:38:46 2004 Subject: GPGME CVS branched References: <874qiy5471.wl@ulysses.g10code.de> <87llc4d3qm.wl@ulysses.g10code.de> <200412112104.49744.michaelnottebrock@gmx.net> <200412112213.42205.michaelnottebrock@gmx.net> <87oegztvt9.wl__2560.95722220397$1102864183$gmane$org@ulysses.g10code.de> Message-ID: Marcus Brinkmann writes: > In the future, I think I will change GPGME's threading support to be > like gcrypt, so you install callbacks. I'm not sure I like this approach in gcrypt, so I'd like to ask exactly why are you considering this? I find that requiring threaded applications to provide thread hooks into libraries is problematic. The most common situation where a this causes problems is when a threaded application uses one library that in turn uses gcrypt/gpgme. The middle-library does not need thread hooks, so it does not provide any functions for the application to set them, and consequently does not set them any thread hooks in gcrypt. The application may use several libraries that look like this (e.g., gnutls and gsasl), so gcrypt may end up being invoked in multiple threads with no thread hooks. Requiring the application to be notice that gnutls/gsasl uses gcrypt, and have the application call the thread hooks in gcrypt, destroy abstraction layers. Forcing all libraries that use gcrypt to also provide thread hooks also does not look like a scalable solution to me. In a big application, different parts may use different thread implementations. E.g., the top-level application might use Pth, but some lower-level library can be written for the specific platform, and could use POSIX threads, or even NPTL. I reviewed all uses of thread hooks in libgcrypt (a lot!), and to me all of the uses could be avoided by choosing a simpler design. Compare Nettle. Perhaps the only exception I could find was randomness gathering, but then again I think that is such a critical function that the complexity of thread interaction should be avoided at all. I wish there were a paper that collected common wisdom about writing libraries that are used in multi-threaded applications, but I haven't seen any that discuss these issues in any detail. I'm imagining something like Ulrich Drepper's excellent paper about writing and maintaining shared libraries. Thanks, Simon From marcus.brinkmann at ruhr-uni-bochum.de Sun Dec 12 19:47:49 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Dec 13 16:38:48 2004 Subject: [gpgme] change work dir In-Reply-To: <200412121842.23896.fscheerer1@gmx.de> References: <200412060948.43005.micron@madlab.it> <200412111535.42558.micron@madlab.it> <87llc3tvfr.wl@ulysses.g10code.de> <200412121842.23896.fscheerer1@gmx.de> Message-ID: <87is77tktm.wl@ulysses.g10code.de> At Sun, 12 Dec 2004 18:42:23 +0100, Franz Scheerer wrote: > > Hi, > > I do not understand the sense behind gpg in general and especially not > the sense of gpgme. > > But I just took a glance on that funny code: > > > > - assert (file_name); > > Obivously file_name is expected not to be empty at that point. Wrong, as the surrounding code clearly shows. > > > - new_file_name = strdup (new_file_name); > > So, strdup does approximately the same as the familiar strcpy, but allocates > memory for the destination, too. That makes sense, if no memory is allocated > for the destination new_file_name. But, in this case the argument of strdup > can not be new_file_name. Most likely one should use file_name (not > new_file-name) as argument instead, which is not empty as asserted before. You are confused about how the code is supposed to work. Thanks, Marcus From micron at madlab.it Sun Dec 12 20:45:15 2004 From: micron at madlab.it (micron) Date: Mon Dec 13 16:38:50 2004 Subject: [gpgme] change work dir In-Reply-To: <87llc3tvfr.wl@ulysses.g10code.de> References: <200412060948.43005.micron@madlab.it> <200412111535.42558.micron@madlab.it> <87llc3tvfr.wl@ulysses.g10code.de> Message-ID: <200412122045.15659.micron@madlab.it> On Sunday 12 December 2004 15:58, Marcus Brinkmann wrote: > This is due to you not storing a pointer to allocated memory in > new_file_name above, but a pointer to statically allocated memory > (new_file_name is what ends up in info->file_name, and not file_name. > The reason I use a different variable new_file_name is so that > file_name can be const). All clear now ;) > I didn't try your test program with my fix, but I am sure you will ;) Yep, now both gpgme_ctx_set_engine_info and gpgme_set_engine_info work fine. Thanks for realizing my wish micron -- |? micron<- ICQ #118796665 |? GPG Key: |? ~ Keyserver: pgp.mit.edu |? ~ KeyID: 6D632BED ~ "Progress is merely a realisation of utopias" ~ From atom at suspicious.org Mon Dec 13 02:24:17 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Mon Dec 13 16:38:54 2004 Subject: GnuPG + FreeBSD 5.3 = intermitent memory warning In-Reply-To: <20041210150749.GA1379@jabberwocky.com> References: <20041208014034.A62757@willy.wonka> <20041210150749.GA1379@jabberwocky.com> Message-ID: <20041212192018.P99530@willy.wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ** cross posted ** for those not familiar with GnuPG, read here for relevant background info: http://www.gnupg.org/documentation/faqs.html#q6.1 if the binary is suid-root, it should not generate warnings about insecure memory. my binary *is* suid-root, and whether it's run as a privileged or unprivileged user i get intermittent warnings about insecure memory. i only noticed this intermittent behavior after upgrading from FreeBSD 4.9 to 5.3. i'm seeing essentially the same results with GnuPG 1.2 and 1.3 branches. attached is a script and the output from 1000000 invocations of gpg (just over 24 hours on a duron-1200). there were 543398 (almost 55%) errors. at first i thought that there was a relation between the errors and downloading large files, but now i'm not sure if that's a factor. SHA-1 checksums: 126694aa13085e757c1fb75e105549b9d6997fc2 gnupg_err.txt.gz 6332229dafcc8f5b4becfc74fd2f39b9af4d2164 gpg_memory_warning.sh.gz the "gnupg_err.txt" was produced by running: ./gpg_memory_warning.sh 1000 1000 | tee gnupg_err.txt On Fri, 10 Dec 2004, David Shaw wrote: > On Wed, Dec 08, 2004 at 02:12:30AM -0500, Atom 'Smasher' wrote: > >> i thought i was either going crazy or stupid, but i really am getting >> intermittent warnings: >> WARNING: using insecure memory! >> >> the test above is unique, because usually in a test of 100, 500, or 1000 >> trials i get either 0% or 100% warnings. before getting that result, i got >> a bunch of 100% error... after running that test i got a bunch of 0% >> error. >> >> i suspect that it might be a bug in FreeBSD 5.3-RELEASE since i haven't >> noticed it before. now i'm having the same problem with 1.2.6 and 1.3.92. >> has anyone else noticed this? > > I tried to duplicate it on Linux, but without any luck. It might be a > FreeBSD thing, or it might be something particular to your machine? > I've never heard of this happenening, even on FreeBSD, so I don't know > what to think yet. > >> please advise how to trace this problem when it appears... i'm not sure >> which --debug flag(s) or process-tracking applications (with what options) >> will be most useful. > > If you do C, take a peek at the code in util/secmem.c:lock_pool. It > is unfortunately quite rich in #ifdefs since locking memory is pretty > platform-specific. Add some debugging there - say, printing out errno > whenever mlock() returns -1. ================= i'm not much good in C :( - -- ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "Military men are just dumb stupid animals to be used as pawns in foreign policy." -- Henry Kissinger, Kiss the Boys Goodbye: How the United States Betrayed Its Own POWs in Vietnam -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.92 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBvO9JAAoJEAx/d+cTpVci1qIH/A2wqA3gUjm2waWnzqBsKEj1 NiEp4cIbxsrDRsFzmHxlJzSL322toXoDIbBVKvsBLqH9ZgtTos3Kc26sk+Vt1lo9 IpsKj2QxXEcXKgs6drVgLXacfgldcl/WCY2iuicdMs5gw/415rKZQyS/Eerhx7jm 0K+xGxhfJYaaS6lPswZvB1GeANwxU9nVrbmbTb/6roNiMxL6O8BThwP3jD/Ne+FB v7YxkbFQUyqq4WMO3Qfee2gy9zox+BG8oaC7xBNlvlGZXH7sPlotzJkpZhKVoBHF o5TM+vSYSGJV/OvXEH/XaWKApC1e+mfCKYqrCi0eMiT8X4bXofVAcry0oc1HMOQ= =z+OV -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg_memory_warning.sh.gz Type: application/octet-stream Size: 536 bytes Desc: Url : /pipermail/attachments/20041212/c79621d1/gpg_memory_warning.sh.exe -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg_err.txt.gz Type: application/octet-stream Size: 4081 bytes Desc: Url : /pipermail/attachments/20041212/c79621d1/gnupg_err.txt.exe From wk at gnupg.org Mon Dec 13 08:40:12 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Dec 13 16:38:58 2004 Subject: slow(&huge) password digest algorithm for GPG In-Reply-To: <41BBC277.4020703@bksys.at> (Bernhard Kuemel's message of "Sun, 12 Dec 2004 05:00:55 +0100") References: <41BBC277.4020703@bksys.at> Message-ID: <87k6rmwsrn.fsf@wheatstone.g10code.de> On Sun, 12 Dec 2004 05:00:55 +0100, Bernhard Kuemel said: > gpg needs a slow algorithm to digest the passphrase before it decrypts > the secret key. If it takes 1 s then dictionary or brute force attacks It does as required by OpenPGP. In fact you may even tune it to your desire: --s2k-digest-algo name Use name as the digest algorithm used to mangle the passphrases. The default algorithm is SHA-1. --s2k-mode n Selects how passphrases are mangled. If n is 0 a plain passphrase (which is not recommended) will be used, a 1 adds a salt to the passphrase and a 3 (the default) iterates the whole process a couple of times. Unless --rfc1991 is used, this mode is also used for conventional encryption. The iteration count is hardwired but easy to change (g10/passphrase.c:1327) Shalom-Salam, Werner From teenieberry at worldnet.att.net Mon Dec 13 11:20:24 2004 From: teenieberry at worldnet.att.net (FRANK HUBENY) Date: Tue Dec 14 09:54:03 2004 Subject: Signing uids Message-ID: <000001c4e0fd$70ef86b0$822e4e0c@administ0b8aee> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have been trying out your version "1.3.92". I find that I could not sing just one UID on a key. You are asked if you wish to sign all. But if you answer no. GPG exits. I am useing GPG on a windows 2000 PC, useing GPGshell as the GUI. - - -- <>< <>< <>< Greetings From: Frank D. Hubeny GSWoT Assurer Palm Bay, Florida USA My Public Key: http://www.biglumber.com/x/web?pk=C0F3E7E59ED67E0CE9500A087577FCCD63E3F723 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) - GPGrelay v0.955 iD8DBQFBvW0MdXf8zWPj9yMRAgSdAJoCHYSXz+xo4zUXizsdNcYOE4Km2gCgiODf 28JMFohPyavt1cStguOuZOM= =CxMj -----END PGP SIGNATURE----- From wk at gnupg.org Tue Dec 14 11:06:45 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Dec 14 11:41:34 2004 Subject: [Announce] GnuPG 1.3.93 released Message-ID: <87brcxfb2i.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Tue Dec 14 12:08:57 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Dec 14 12:09:36 2004 Subject: Signing uids In-Reply-To: <000001c4e0fd$70ef86b0$822e4e0c@administ0b8aee> (FRANK HUBENY's message of "Mon, 13 Dec 2004 05:20:24 -0500") References: <000001c4e0fd$70ef86b0$822e4e0c@administ0b8aee> Message-ID: <871xdtf86u.fsf@wheatstone.g10code.de> On Mon, 13 Dec 2004 05:20:24 -0500, FRANK HUBENY said: > I have been trying out your version "1.3.92". I find that I could not > sing just one UID on a key. > You are asked if you wish to sign all. But if you answer no. GPG > exits. Use --edit-key KEYID The enter "sign". You will be asked too but if you answer no, dropped back into the menu. Select then the user IDs to be signed (enter there numbers one by one) and enter "sign" again. The --sign-key command is a shortcut for common cases. Werner From cbonar at gmail.com Tue Dec 14 13:52:11 2004 From: cbonar at gmail.com (Nicolas BONARDELLE) Date: Tue Dec 14 13:48:57 2004 Subject: gpg-agent Message-ID: <41BEE1FB.8070804@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Does gpg-agent cache private keys like ssh-agent does or only password ? (I'm not sure because my MUA - thunderbid - says it uses it as a password-cache) If yes, how can I do that ? any doc ? For info, I'm trying to use an USB key to wear my GnuPG keyrings. The main goal is to insert the USB key only once per session, type my password in and remove it. Hope this is the good list ; if not please forgive me... ++ http://nicolas.bonardelle.free.fr/pgp.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBvuH702ub2lmWm/QRAgw3AJ9+IBp4mltTwl6qsluWlKfecoDKdgCfUbcS Uy6cC1uiebdzmSRtTBj3stI= =yisf -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: cbonar.vcf Type: text/x-vcard Size: 266 bytes Desc: not available Url : /pipermail/attachments/20041214/3c7f53c9/cbonar.bin From wk at gnupg.org Tue Dec 14 16:11:56 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Dec 14 16:14:39 2004 Subject: gpg-agent In-Reply-To: <41BEE1FB.8070804@gmail.com> (Nicolas BONARDELLE's message of "Tue, 14 Dec 2004 13:52:11 +0100") References: <41BEE1FB.8070804@gmail.com> Message-ID: <87y8g0didf.fsf@wheatstone.g10code.de> On Tue, 14 Dec 2004 13:52:11 +0100, Nicolas BONARDELLE said: > Does gpg-agent cache private keys like ssh-agent does or only password ? > (I'm not sure because my MUA - thunderbid - says it uses it as a > password-cache) Actually it should handle the private keys as ssh-agent does. However this does for now only work with gpgsm and not with gpg. For gpg, it merely caches the passphrase. > For info, I'm trying to use an USB key to wear my GnuPG keyrings. > The main goal is to insert the USB key only once per session, type my > password in and remove it. Ah, that won't work at all because gpg-agent always reads the protected private keys from disk and the used the cached passphrase to unprotect and use them. (as said only gpgsm). Shalom-Salam, Werner From dshaw at jabberwocky.com Wed Dec 15 05:05:34 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Dec 15 05:02:53 2004 Subject: GnuPG + FreeBSD 5.3 = intermitent memory warning In-Reply-To: <20041212192018.P99530@willy.wonka> References: <20041208014034.A62757@willy.wonka> <20041210150749.GA1379@jabberwocky.com> <20041212192018.P99530@willy.wonka> Message-ID: <20041215040534.GC32762@jabberwocky.com> On Sun, Dec 12, 2004 at 08:24:17PM -0500, Atom 'Smasher' wrote: > ** cross posted ** > > for those not familiar with GnuPG, read here for relevant background info: > http://www.gnupg.org/documentation/faqs.html#q6.1 > > if the binary is suid-root, it should not generate warnings about insecure > memory. my binary *is* suid-root, and whether it's run as a privileged or > unprivileged user i get intermittent warnings about insecure memory. It took me a while to track this down, and thanks to Atom for helping me run some FreeBSD tests. It turns out that this isn't a GnuPG specific problem. The same problem can be duplicated by running any program that calls mlock() on FreeBSD. FreeBSD has a "1/3 of memory" hard limit for mlock(). What seems to have happened is that for whatever reason, Atom's system was very close to the 1/3 magic number, and so when GnuPG tried to get its lock, it was sometimes refused. This also explains why a busy system seemed to aggravate the problem. In terms of what to do about this in GnuPG, I'm not sure if there should be anything done. I think the the current GnuPG behavior is pretty good: try to get locked memory, and if it can't, warn the user. David From atom at suspicious.org Wed Dec 15 07:28:16 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Wed Dec 15 07:24:04 2004 Subject: GnuPG + FreeBSD 5.3 = intermitent memory warning In-Reply-To: <20041215040534.GC32762@jabberwocky.com> References: <20041208014034.A62757@willy.wonka> <20041210150749.GA1379@jabberwocky.com> <20041212192018.P99530@willy.wonka> <20041215040534.GC32762@jabberwocky.com> Message-ID: <20041215062738.56187.qmail@suspicious.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 i'm curious if OS-X has the same bug... has anyone checked to see if the error can be duplicated under similar conditions? On Tue, 14 Dec 2004, David Shaw wrote: > It took me a while to track this down, and thanks to Atom for helping me > run some FreeBSD tests. It turns out that this isn't a GnuPG specific > problem. The same problem can be duplicated by running any program that > calls mlock() on FreeBSD. > > FreeBSD has a "1/3 of memory" hard limit for mlock(). What seems to > have happened is that for whatever reason, Atom's system was very close > to the 1/3 magic number, and so when GnuPG tried to get its lock, it was > sometimes refused. This also explains why a busy system seemed to > aggravate the problem. > > In terms of what to do about this in GnuPG, I'm not sure if there should > be anything done. I think the the current GnuPG behavior is pretty > good: try to get locked memory, and if it can't, warn the user. - -- ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "Some folks look for answers others look for fights, some folks up in treetops just looking for their kites" -- Grateful Dead -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.93 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBv9mGAAoJEAx/d+cTpVciMZYH/1snWBE4MjISivyryrGmclKj a3wKUc5BAOx66r/yotol6p6ltAqOI4mFpUEbTWp+vBT6Y86BvEKoJRKhGvFS+NMq IosKWqQoCgyLMy4WxdG4pHLT2SbjOjtg6E9osSLJ6XfVGUZDXnNKPD/ufcdo2gTu rRvWmuH5lefAsR3TcuP9o2dbKmA3o3o1MqtHoY/vgbd8RTb/oi/ZVUIOF1YCwgFf dJAGVY7ud4GRPdXTPGSQkW/ubbkU5ms7C+E9TWNsP2K0/UUSRG8kwbbH+XVKl4r5 rN9TtJwPwvGF0yfgm2ShRbodGu2ODWE0MLXa/bsowThgNT4MYomnOfB0RPBSNVM= =MWcF -----END PGP SIGNATURE----- From alex at bofh.net.pl Wed Dec 15 15:19:45 2004 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Wed Dec 15 15:16:50 2004 Subject: GnuPG + FreeBSD 5.3 = intermitent memory warning In-Reply-To: <20041215040534.GC32762@jabberwocky.com> References: <20041208014034.A62757@willy.wonka> <20041210150749.GA1379@jabberwocky.com> <20041212192018.P99530@willy.wonka> <20041215040534.GC32762@jabberwocky.com> Message-ID: <20041215141944.GC11965@syjon.fantastyka.net> On Tue, Dec 14, 2004 at 11:05:34PM -0500, David Shaw wrote: > In terms of what to do about this in GnuPG, I'm not sure if there > should be anything done. I think the the current GnuPG behavior is > pretty good: try to get locked memory, and if it can't, warn the user. I can imagione a situation when the user wants for the program to do more than spit out stderr warning. What about another ( :-(( ) --expert option along the lines of --no-secmem-fail with a specific error code if mlock() cannot be obtained? Alex -- mors ab alto 0x46399138 From sadam at CLEMSON.EDU Wed Dec 15 17:00:58 2004 From: sadam at CLEMSON.EDU (Adam Schreiber) Date: Wed Dec 15 16:57:46 2004 Subject: (no subject) Message-ID: <3764.67.85.157.39.1103126458.squirrel@rhblade2.clemson.edu> Greetings, I'm a developer of Seahorse, a GNOME GPG Key Manager. Not only does the project manage keys, but it provides GNOME integration for encryption, and signing. The developers of Seahorse were wondering about the status of a couple items and the general direction GPGME is headed in. The items are: * Exporting Secret Keys * Manipulation of image associated with a key I believe exporting secret keys was discussed a long time ago: http://lists.gnupg.org/pipermail/gnupg-devel/2002-April/018273.html We may be able to provide some assistance with adding these features. Adam Schreiber From micron at madlab.it Wed Dec 15 17:57:51 2004 From: micron at madlab.it (micron) Date: Wed Dec 15 17:56:53 2004 Subject: [gpgme] gpg home dir initialization Message-ID: <200412151757.52562.micron@madlab.it> If gpg has never been started or there's only an empty .gnupg dir, how can I made gpgme initialize gpg's home directory properly? What files are needed by gpgme? How can I create them? Thanks in advance micron -- |? micron<- ICQ #118796665 |? GPG Key: |? ~ Keyserver: pgp.mit.edu |? ~ KeyID: 6D632BED ~ "Progress is merely a realisation of utopias" ~ From dshaw at jabberwocky.com Wed Dec 15 18:25:31 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Dec 15 18:22:36 2004 Subject: GnuPG + FreeBSD 5.3 = intermitent memory warning In-Reply-To: <20041215062738.56187.qmail@suspicious.org> References: <20041208014034.A62757@willy.wonka> <20041210150749.GA1379@jabberwocky.com> <20041212192018.P99530@willy.wonka> <20041215040534.GC32762@jabberwocky.com> <20041215062738.56187.qmail@suspicious.org> Message-ID: <20041215172530.GH32762@jabberwocky.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Dec 15, 2004 at 01:28:16AM -0500, Atom 'Smasher' wrote: > i'm curious if OS-X has the same bug... has anyone checked to see if the > error can be duplicated under similar conditions? It depends on the OSX VM. However, it's important to note that this is not a bug in FreeBSD (or GnuPG). POSIX mlock() is documented to return EAGAIN. There isn't much the calling program can do after that point except call mlock() again or give up. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.93-cvs (GNU/Linux) iGoEARECACoFAkHAc4ojGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2tleS5h c2MACgkQ4mZch0nhy8kUCQCcCzAk9ex8n98fvUqFEMi6jefN8nwAnR21Jlncxt68 DG8djiNKKBWbUiAs =tg3f -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Wed Dec 15 18:26:32 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Dec 15 18:23:39 2004 Subject: GnuPG + FreeBSD 5.3 = intermitent memory warning In-Reply-To: <20041215141944.GC11965@syjon.fantastyka.net> References: <20041208014034.A62757@willy.wonka> <20041210150749.GA1379@jabberwocky.com> <20041212192018.P99530@willy.wonka> <20041215040534.GC32762@jabberwocky.com> <20041215141944.GC11965@syjon.fantastyka.net> Message-ID: <20041215172632.GI32762@jabberwocky.com> On Wed, Dec 15, 2004 at 03:19:45PM +0100, Janusz A. Urbanowicz wrote: > On Tue, Dec 14, 2004 at 11:05:34PM -0500, David Shaw wrote: > > In terms of what to do about this in GnuPG, I'm not sure if there > > should be anything done. I think the the current GnuPG behavior is > > pretty good: try to get locked memory, and if it can't, warn the user. > > I can imagione a situation when the user wants for the program to do more > than spit out stderr warning. What about another ( :-(( ) --expert option > along the lines of --no-secmem-fail with a specific error code if mlock() > cannot be obtained? I thought about something like that, but I worried it would cause confusion if it was set on a non-setuid binary. I'll take another look. David -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 251 bytes Desc: not available Url : /pipermail/attachments/20041215/ebd05895/attachment.bin From ekot at narod.ru Tue Dec 14 21:00:07 2004 From: ekot at narod.ru (Eugene Kotlyarov) Date: Thu Dec 16 14:54:12 2004 Subject: Problems building GPG 1.3.93 on Cygwin Message-ID: <41BF4647.3030002@narod.ru> Hello I have couple of problems when building new gpg on Cygwin. They are addressed in the following patches. Besides this is seems to work fine. -------------- next part -------------- --- passphrase.c.old 2004-12-14 10:59:34.000000000 +0300 +++ passphrase.c 2004-12-14 21:58:30.265625000 +0300 @@ -31,5 +31,5 @@ #include #endif -#if defined (_WIN32) || defined (__CYGWIN32__) +#if defined (_WIN32) # include #endif -------------- next part -------------- --- srv.h.old 2003-08-29 03:29:32.000000000 +0400 +++ srv.h 2004-12-14 22:07:11.421875000 +0300 @@ -26,7 +26,9 @@ #else #include +#ifndef __CYGWIN32__ #include #include #endif +#endif #ifndef MAXDNAME From wk at gnupg.org Wed Dec 15 19:06:06 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Dec 16 14:54:19 2004 Subject: (no subject) In-Reply-To: <3764.67.85.157.39.1103126458.squirrel@rhblade2.clemson.edu> (Adam Schreiber's message of "Wed, 15 Dec 2004 11:00:58 -0500 (EST)") References: <3764.67.85.157.39.1103126458.squirrel@rhblade2.clemson.edu> Message-ID: <877jnjo2r5.fsf@wheatstone.g10code.de> On Wed, 15 Dec 2004 11:00:58 -0500 (EST), Adam Schreiber said: > The developers of Seahorse were wondering about the status of a couple > items and the general direction GPGME is headed in. The items are: > * Exporting Secret Keys There will be no way of exporting secret keys. Yes, I said so 2 years ago but meanwhile I realized that secret keys are too sensitive and we should not make it too easy for users to tinker with them. If you need to copy secret keys forth and back between machines, something is wrong with your general setup or you have real special reasons for that which can and should be satisfied by well-thought out protocols. In particular, in gnupg 2, the gpg or gpgsm processes don't have any knowledge of the secret keys but delegate all tasks involving them to a specialized daemon (gpg-agent). Specialized tools working jointly with gpg-agent are to be used to manage secret keys. If a GUI needs to cope with that it should run tehse tools directly. > * Manipulation of image associated with a key Yes, we will eventually support them. Shalom-Salam, Werner From wk at gnupg.org Wed Dec 15 19:07:44 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Dec 16 14:54:24 2004 Subject: [gpgme] gpg home dir initialization In-Reply-To: <200412151757.52562.micron@madlab.it> (micron@madlab.it's message of "Wed, 15 Dec 2004 17:57:51 +0100") References: <200412151757.52562.micron@madlab.it> Message-ID: <873by7o2of.fsf@wheatstone.g10code.de> On Wed, 15 Dec 2004 17:57:51 +0100, micron said: > If gpg has never been started or there's only an empty .gnupg dir, how can I > made gpgme initialize gpg's home directory properly? GnuPG creates all required files. 1.2.6 has a bug in that the default home directry (~/.gnupg) won't be created. Salam-Shalom, Werner From patrick.brunschwig at gmx.net Wed Dec 15 21:46:32 2004 From: patrick.brunschwig at gmx.net (Patrick Brunschwig) Date: Thu Dec 16 14:54:41 2004 Subject: [Announce] GnuPG 1.3.93 released In-Reply-To: <87brcxfb2i.fsf__17572.9309711189$1103021773$gmane$org@wheatstone.g10code.de> References: <87brcxfb2i.fsf__17572.9309711189$1103021773$gmane$org@wheatstone.g10code.de> Message-ID: <41C0A2A8.8000900@gmx.net> Werner Koch wrote: > Hello! > > The latest and hopefully last release candidate for GnuPG 1.4 is ready > for public consumption. > > We strongly encourage people to try this release candidate and report > any feedback or problems to gnupg-devel@gnupg.org. If you have been > waiting until the 1.4 release is imminent before trying the code, that > time is now. It looks like the file renaming bug on Windows XP (and 2000) is still there. I have done some more testing, and with this version, it's not possible to generate any new key. Gnupg tries to rename c:/path/to/some/dir\secring.tmp to c:/path/to/some/dir\secring.gpg but this fails ("permission denied"), and consequently the public key is not saved at all. -Patrick From JPClizbe at comcast.net Thu Dec 16 04:03:05 2004 From: JPClizbe at comcast.net (John Clizbe) Date: Thu Dec 16 14:54:45 2004 Subject: Problems with --check-trustdb in 1.3.93 on Windows Message-ID: <41C0FAE9.3060100@comcast.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bash-2.05b$ gpg --version gpg (GnuPG) 1.3.93 bash-2.05b$ time gpg --check-trustdb gpg: renaming `C:/Documents and Settings/jpclizbe/Application Data/GnuPG\pubring.tmp' to `C:/Documents and Settings/jpclizbe/Application Data/GnuPG\pubring.gpg' failed: Permission denied gpg: failed to rebuild keyring cache: file rename error gpg: can't open `C:/Documents and Settings/jpclizbe/Application Data/GnuPG\pubring.gpg' gpg: keydb_search failed: file open error gpg: validate_key_list failed real 19m45.546s user 0m0.020s sys 0m0.020s pubring.gpg was renamed to pubring.bak, but pubring.tmp was left as it was. This was almost 20 minutes just for the cache rebuild, not even the trust check. bash-2.05b$ head/gpg --version gpg (GnuPG) 1.3.93-cvs-2004-12-11 bash-2.05b$ time head/gpg --check-trustdb gpg: renaming `C:/Documents and Settings/jpclizbe/Application Data/GnuPG\pubring.gpg' to `C:/Documents and Settings/jpclizbe/Application Data/GnuPG\pubring.bak' failed: Permission denied gpg: failed to rebuild keyring cache: file rename error gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model gpg: depth: 0 valid: 36 signed: 429 trust: 0-, 0q, 0n, 0m, 0f, 36u gpg: depth: 1 valid: 429 signed: 162 trust: 0-, 363q, 1n, 8m, 57f, 0u gpg: depth: 2 valid: 64 signed: 60 trust: 0-, 58q, 0n, 3m, 3f, 0u gpg: depth: 3 valid: 4 signed: 13 trust: 0-, 3q, 0n, 1m, 0f, 0u gpg: next trustdb check due at 2004-12-23 real 37m14.658s user 0m0.010s sys 0m0.060s bash-2.05b$ In 1.3.93-cvs from this last weekend, the first rename failed and allowed the check-trustdb to run. Please note the time taken. Compare the time taken with 1.2.x: bash-2.05b$ stable/gpg --version gpg (GnuPG) 1.2.7-cvs-2004-12-11 bash-2.05b$ time stable/gpg --check-trustdb gpg: checking at depth 0 signed=444 ot(-/q/n/m/f/u)=0/0/0/0/0/36 gpg: checking at depth 1 signed=172 ot(-/q/n/m/f/u)=0/377/1/9/57/0 gpg: checking at depth 2 signed=66 ot(-/q/n/m/f/u)=0/67/0/5/3/0 gpg: checking at depth 3 signed=9 ot(-/q/n/m/f/u)=0/3/0/0/0/0 gpg: next trustdb check due at 2004-12-23 real 0m19.438s user 0m0.040s sys 0m0.020s bash-2.05b$ 1.2.6/gpg --version gpg (GnuPG) 1.2.6 bash-2.05b$ time 1.2.6/gpg --check-trustdb gpg: next trustdb check due at 2004-12-23 real 0m18.455s user 0m0.010s sys 0m0.020s bash-2.05b$ Checking the trustdb takes < 20 sec in 1.2.x but nearly 40 minutes in 1.3.93? OUCH! Can this be worked on before 1.4? - -- John P. Clizbe Inet: JPClizbe(a)comcast DOT nyet Golden Bear Networks PGP/GPG KeyID: 0x608D2A10 "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.93 (Windows 2000 SP4) Comment: When cryptography is outlawed, b25seSBvdXRsYXdzIHdpbGwgdXNlIG Comment: Annoy John Asscraft -- Use Strong Encryption. Comment: It's YOUR right - for the time being. Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBwProHQSsSmCNKhARApi0AKCZUsYzAmOlVH1prsGGOcMsPXPTfwCfXZx5 /ntHCOi/E4X/3mpvp5og35k= =4FVM -----END PGP SIGNATURE----- From jvender at owensboro.net Thu Dec 16 06:02:25 2004 From: jvender at owensboro.net (Joe Vender) Date: Thu Dec 16 14:54:48 2004 Subject: GnuPG 1.3.93 under MinGW/MSYS now fails two checks Message-ID: <200412152302250290.01AB6AFA@216.135.2.37> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Windows MinGW/MSYS build of GnuPG 1.3.93 using instructions by Carlo Luciano Bianco at http://clbianco.altervista.org/gnupg/eng/gnupg.html fails two tests. genkey1024.test fails because gpg isn't able to rename pubring.tmp to pubring.gpg. It gives a "permission denied" error which, I'm pretty sure, is because of the "forward-slash vs. back-slash" issue that the new code in iobuf.c is supposed to address. Prior to the addition of fd_cache_strcmp() to iobuf.c, my MinGW/MSYS build of GnuPG (GnuPG 1.3.92 f.ex.) passed all 25 make checks. Now... multisig.test fails with the message "valid is invalid" In iobuf.c, when I change the calls to fd_cache_strcmp() back into calls to strcmp(), make check passes all 25 tests. Hmmm... Regards, Joe Vender -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.93 (MingW32) - GPGshell v3.30 iQEVAwUBQcEWzCbIfMqPbtHmAQgrYggAg0ph/96cyZdqPUyaLCTHNf3xINSPpw4w KR+J0Y2KR39XRt6m/AEN8nBC/vixm79EdtEz9wLVEXE23EHagonp+z5nSYuQk5pB CHgKejTbuf4THOz97tzAEy9lZrGAJj94XxqxQa+GM5Cp58KerOiAwk/meQB88gIm NS/2q1rwGnTFPb6vbQLau2cJoEOhNNGwK3a6/y8t9i68KJyeaBdqit0myNErvGr+ +ecaThaQBvct1JMjeWh1zKrfhdIdANLmF5QlkLtNQgAkW+QQCayKGuciIiQfrZlq SwKgGYreEL5nR9OGTqxdYZxIZU7gN9x3z6XtmUKyrjQuMIIp1JN7wg== =aJod -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Thu Dec 16 06:46:57 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Dec 16 14:54:49 2004 Subject: GnuPG + FreeBSD 5.3 = intermitent memory warning In-Reply-To: <20041215172632.GI32762@jabberwocky.com> References: <20041208014034.A62757@willy.wonka> <20041210150749.GA1379@jabberwocky.com> <20041212192018.P99530@willy.wonka> <20041215040534.GC32762@jabberwocky.com> <20041215141944.GC11965@syjon.fantastyka.net> <20041215172632.GI32762@jabberwocky.com> Message-ID: <20041216054657.GC1290@jabberwocky.com> On Wed, Dec 15, 2004 at 12:26:32PM -0500, David Shaw wrote: > On Wed, Dec 15, 2004 at 03:19:45PM +0100, Janusz A. Urbanowicz wrote: > > On Tue, Dec 14, 2004 at 11:05:34PM -0500, David Shaw wrote: > > > In terms of what to do about this in GnuPG, I'm not sure if there > > > should be anything done. I think the the current GnuPG behavior is > > > pretty good: try to get locked memory, and if it can't, warn the user. > > > > I can imagione a situation when the user wants for the program to do more > > than spit out stderr warning. What about another ( :-(( ) --expert option > > along the lines of --no-secmem-fail with a specific error code if mlock() > > cannot be obtained? > > I thought about something like that, but I worried it would cause > confusion if it was set on a non-setuid binary. I'll take another > look. Okay, I added a --require-secmem, which causes gpg to exit if it cannot get a lock. The default is off (i.e. the current behavior). David From wk at gnupg.org Thu Dec 16 09:26:57 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Dec 16 14:55:07 2004 Subject: (no subject) In-Reply-To: <20041216001142.8A7FB840481@mail.npubs.com> (nielsen@memberwebs.com's message of "Thu, 16 Dec 2004 00:11:43 +0000 (GMT)") References: <3764.67.85.157.39.1103126458.squirrel@rhblade2.clemson.edu> <877jnjo2r5.fsf@wheatstone.g10code.de> <20041216001142.8A7FB840481@mail.npubs.com> Message-ID: <87r7lqlkby.fsf@wheatstone.g10code.de> On Thu, 16 Dec 2004 00:11:43 +0000 (GMT), Nielsen said: > I don't understand. How would a user move his long-time secret keys to > another machine when he upgrades? Note I'm talking about a simple user > here, 'use the command line' is not an option. Backup and restore ~/.gnupg of course. > However, the fact that we (that's Seahorse) are currently depending > less and less on GPGME and more and more on home brewed command line The secret keys are special. Where else do you have problems? Direct access to keyservers? gpg supports colon formatted output and thus we are able to add this keyserver searches to gpgme. We ahve already done this for gpgsm, so the infrastructure is more or less available. Manipulation of options? gpgconf (from gnupg 1.9) does this job fine for KDE and works with all current gpg versions. Shalom-Salam, Werner From wk at gnupg.org Thu Dec 16 18:24:48 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Dec 16 18:50:34 2004 Subject: [Announce] GnuPG stable 1.4 released Message-ID: <87zn0egnq7.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Thu Dec 16 19:07:27 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Dec 16 19:09:47 2004 Subject: [Announce] GnuPG 1.3.93 released In-Reply-To: <41C0A2A8.8000900@gmx.net> (Patrick Brunschwig's message of "Wed, 15 Dec 2004 21:46:32 +0100") References: <87brcxfb2i.fsf__17572.9309711189$1103021773$gmane$org@wheatstone.g10code.de> <41C0A2A8.8000900@gmx.net> Message-ID: <87mzweglr4.fsf@wheatstone.g10code.de> On Wed, 15 Dec 2004 21:46:32 +0100, Patrick Brunschwig said: > It looks like the file renaming bug on Windows XP (and 2000) is still > there. I have done some more testing, and with this version, it's not > possible to generate any new key. Gnupg tries to rename Oops. I can replicate this on W2000. Unfortunately 1.4.0 has already been released and I did my tests accidently with an old versions (that was due to the command line completion which works differently under Windows than under GNU). Further the ML list machine is pretty busy filtering out spam which led to the delay of your and other mails. Werner From dshaw at jabberwocky.com Thu Dec 16 19:30:40 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Dec 16 19:28:08 2004 Subject: Problems building GPG 1.3.93 on Cygwin In-Reply-To: <41BF4647.3030002@narod.ru> References: <41BF4647.3030002@narod.ru> Message-ID: <20041216183040.GA9858@jabberwocky.com> On Tue, Dec 14, 2004 at 11:00:07PM +0300, Eugene Kotlyarov wrote: > Hello > > I have couple of problems when building new gpg on Cygwin. > They are addressed in the following patches. Besides this is seems to work > fine. > --- srv.h.old 2003-08-29 03:29:32.000000000 +0400 > +++ srv.h 2004-12-14 22:07:11.421875000 +0300 > @@ -26,7 +26,9 @@ > #else > #include > +#ifndef __CYGWIN32__ > #include > #include > #endif > +#endif I think I have a slightly more portable fix for this. Can you try this patch? David -------------- next part -------------- Index: configure.ac =================================================================== RCS file: /cvs/gnupg/gnupg/configure.ac,v retrieving revision 1.116 diff -u -r1.116 configure.ac --- configure.ac 16 Dec 2004 10:53:25 -0000 1.116 +++ configure.ac 16 Dec 2004 18:25:09 -0000 @@ -771,7 +771,7 @@ dnl Checks for header files. AC_HEADER_STDC -AC_CHECK_HEADERS(unistd.h langinfo.h termio.h locale.h getopt.h) +AC_CHECK_HEADERS([unistd.h langinfo.h termio.h locale.h getopt.h arpa/nameser.h]) # Note that we do not check for iconv here because this is done anyway # by the gettext checks and thus it allows us to disable the use of Index: util/srv.h =================================================================== RCS file: /cvs/gnupg/gnupg/util/srv.h,v retrieving revision 1.5 diff -u -r1.5 srv.h --- util/srv.h 28 Aug 2003 23:29:32 -0000 1.5 +++ util/srv.h 16 Dec 2004 18:25:09 -0000 @@ -1,5 +1,5 @@ /* srv.h - * Copyright (C) 2003 Free Software Foundation, Inc. + * Copyright (C) 2003, 2004 Free Software Foundation, Inc. * * This file is part of GNUPG. * @@ -25,9 +25,12 @@ #include #else #include +#ifdef HAVE_ARPA_NAMESER_H #include +#endif #include #endif +#include "types.h" #ifndef MAXDNAME #define MAXDNAME 1025 From wk at gnupg.org Thu Dec 16 19:49:28 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Dec 16 19:49:39 2004 Subject: GnuPG 1.3.93 under MinGW/MSYS now fails two checks In-Reply-To: <200412152302250290.01AB6AFA@216.135.2.37> (Joe Vender's message of "Wed, 15 Dec 2004 23:02:25 -0600") References: <200412152302250290.01AB6AFA@216.135.2.37> Message-ID: <87brcugjt3.fsf@wheatstone.g10code.de> On Wed, 15 Dec 2004 23:02:25 -0600, Joe Vender said: > In iobuf.c, when I change the calls to fd_cache_strcmp() back > into calls to strcmp(), make check passes all 25 tests. Hmmm... Thanks for the hint. here must be some trivial bug. However I checked it once using filemon and noticed that the problem was solved. Okay, doing code staring now. Werner From wk at gnupg.org Thu Dec 16 20:30:14 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Dec 16 20:34:38 2004 Subject: Fix for Windows version of GnuPG 1.4.0 Message-ID: <877jnighx5.fsf@wheatstone.g10code.de> Hi, I have figures out the problem, Really stupid one. Hope that gcc will soo feature a warning for using just "unsigned" or "signed" to mean an integer. Or does it already have one? diff -u -r1.71 iobuf.c --- util/iobuf.c 6 Dec 2004 10:32:20 -0000 1.71 +++ util/iobuf.c 16 Dec 2004 19:30:27 -0000 @@ -146,7 +146,7 @@ || (*a == '\\' && *b == '/')) ) break; } - return *(const unsigned *)a - *(const unsigned *)b; + return *(const unsigned char *)a - *(const unsigned char *)b; #else return strcmp (a, b); #endif I guess I will do a new Windows release RSN. Werner From wk at gnupg.org Thu Dec 16 20:54:10 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Dec 16 20:54:40 2004 Subject: gnupg-w32cli-1.4.0a.zip released Message-ID: <87y8fyf28t.fsf@wheatstone.g10code.de> Hi! subject says all. If someone else can test it too, I can send an updated announcemnt this evening. Werner From marcus.brinkmann at ruhr-uni-bochum.de Thu Dec 16 22:08:12 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Dec 16 22:06:35 2004 Subject: GPGME CVS branched In-Reply-To: References: <874qiy5471.wl@ulysses.g10code.de> <87llc4d3qm.wl@ulysses.g10code.de> <200412112104.49744.michaelnottebrock@gmx.net> <200412112213.42205.michaelnottebrock@gmx.net> <87oegztvt9.wl__2560.95722220397$1102864183$gmane$org@ulysses.g10code.de> Message-ID: <87zn0ej6ir.wl@ulysses.g10code.de> At Sun, 12 Dec 2004 18:44:14 +0100, Simon Josefsson wrote: > Marcus Brinkmann writes: > I find that requiring threaded applications to provide thread hooks > into libraries is problematic. The most common situation where a this > causes problems is when a threaded application uses one library that > in turn uses gcrypt/gpgme. This is in fact exactly the situation that required us to take the hook approach. We have done extensive analysis of this problem, and we have seen what happened to our other attempts at solving this. And we have tried everything we could think of: magic support via weak symbols, different versions of the same library a la foo-threadpackage, and the hooks. We have also looked at how other projects solve this, and have not seen anything better elsewhere. There is no perfect approach for this problem, it's impossible. The goals are conflicting (support for several thread libraries, portability to many platforms, supporting mixed library environments). So the best we can do is to be flexible and make the problem obvious in whatever ways we can. You can find an extensive defense of our approach in the gcrypt mailing list: http://lists.gnupg.org/pipermail/gcrypt-devel/2004-March/000566.html > The middle-library does not need thread > hooks, so it does not provide any functions for the application to set > them, This is wrong, as gcrypt is not thread safe without setting the hooks. Thus, by transfer, the middle-layer library is not thread safe either. In this sense, gcrypt "infects" the middle layer with non-thread-safeness. > and consequently does not set them any thread hooks in gcrypt. It should export an interface to the user to do so (assuming that the fact that gcrypt is used should be hidden). > The application may use several libraries that look like this (e.g., > gnutls and gsasl), so gcrypt may end up being invoked in multiple > threads with no thread hooks. A good part of my analysis is dedicated to this situation. It is awkward, but solvable by allowing multiple initialization and error out if different/incompatible thread configurations are selected. > Requiring the application to be notice that gnutls/gsasl uses gcrypt, > and have the application call the thread hooks in gcrypt, destroy > abstraction layers. I always found it a mistake by the gnutls developer to let the user of gnutls call a gcrypt function directly. I advised him to wrap the interface. Apart from that, the current design (using hooks) was suggested by the gnutls maintainer itself, and agreed to. > Forcing all libraries that use gcrypt to also provide thread hooks > also does not look like a scalable solution to me. In a big > application, different parts may use different thread implementations. > E.g., the top-level application might use Pth, but some lower-level > library can be written for the specific platform, and could use POSIX > threads, or even NPTL. Have you actually tried mixing thread libraries? I have never seen such a configuration work. You have a bunch of other problems (I mean really severe problems) before you can even think about gcrypt. Anybody trying to achieve such a configuration will have so much work to do, that adapting gcrypt to such an environment will mean nothing to them. We are making reasonable assumptions here. And then, how would such a mix of thread implementations work? You would _have_ to use interface hooks, and not only at the library level, but at the per-object level (and allow only object interaction among objects configured with the same hooks). Really, we are way, way beyond anything seemingly reasonable here (or even beyond anything that people seem to want and actually do). > I reviewed all uses of thread hooks in libgcrypt (a lot!), and to me > all of the uses could be avoided by choosing a simpler design. > Compare Nettle. Perhaps the only exception I could find was > randomness gathering, but then again I think that is such a critical > function that the complexity of thread interaction should be avoided > at all. Well, once you have mutex support, it doesn't hurt to use it when it comes in useful. So, unless you can eliminate all uses, it doesn't make sense to talk about eliminating some of them. Of course there are alternative approaches possible. But they come at a cost, too, and it is always a trade-off. Personally, I would have designed some of the gcrypt interfaces differently myself, but that's a different story. I am not sure I would opt for a design that does not require any mutual exclusion, but then, we have not even said explicitely how such a design in the context of gcrypt may look, so it's a moot point. We constantly revise our design and look what we can do, with the given limits (portability, backwards compatibility, feature completeness, ease of use, etc). And in fact I just did some work on GPGME which got rid of some mutual exclusion, and I did not hesitate to take advantage of that. This is also an invitation to make specific suggestions, patches preferred ;) > I wish there were a paper that collected common wisdom about writing > libraries that are used in multi-threaded applications, but I haven't > seen any that discuss these issues in any detail. I'm imagining > something like Ulrich Drepper's excellent paper about writing and > maintaining shared libraries. Well, I'd love to just have pthread support in every single application (ie, drop the distinction between single- and multi-threadedness), and build on that. However, the world does not agree, and we have to compromise. And considering that the semantics of multi-threaded programs are not particularly clear (just check out the POSIX signal semantics, or what happens at fork()), there is good reason to be cautious. Thanks, Marcus From JPClizbe at comcast.net Thu Dec 16 22:11:22 2004 From: JPClizbe at comcast.net (John Clizbe) Date: Thu Dec 16 22:08:24 2004 Subject: gnupg-w32cli-1.4.0a.zip released In-Reply-To: <87y8fyf28t.fsf@wheatstone.g10code.de> References: <87y8fyf28t.fsf@wheatstone.g10code.de> Message-ID: <41C1F9FA.8020101@comcast.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Werner Koch wrote: > Hi! > > subject says all. If someone else can test it too, I can send an > updated announcemnt this evening. Looks good. Speed appears to be back. Renaming works (even with a pubring.bak already in directory) bash-2.05b$ 1.4.0a/gpg --version gpg (GnuPG) 1.4.0 Copyright (C) 2004 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: C:/Documents and Settings/jpclizbe/Application Data/GnuPG Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512 Compression: Uncompressed, ZIP, ZLIB, BZIP2 bash-2.05b$ time 1.4.0a/gpg --rebuild-keydb-caches gpg: caching keyring `C:/Documents and Settings/jpclizbe/Application Data/GnuPG\pubring.gpg' gpg: 50 keys cached so far (1011 signatures) gpg: 100 keys cached so far (5954 signatures) gpg: 150 keys cached so far (19095 signatures) gpg: 200 keys cached so far (26836 signatures) gpg: 250 keys cached so far (29847 signatures) gpg: 300 keys cached so far (32052 signatures) gpg: 350 keys cached so far (32631 signatures) gpg: 400 keys cached so far (33198 signatures) gpg: 450 keys cached so far (33630 signatures) gpg: 500 keys cached so far (35347 signatures) gpg: 550 keys cached so far (36071 signatures) gpg: 600 keys cached so far (37345 signatures) gpg: 650 keys cached so far (38798 signatures) gpg: 700 keys cached so far (39582 signatures) gpg: 750 keys cached so far (40233 signatures) gpg: 800 keys cached so far (40563 signatures) gpg: 850 keys cached so far (41027 signatures) gpg: 900 keys cached so far (41358 signatures) gpg: 904 keys cached (41377 signatures) real 0m22.001s user 0m0.020s sys 0m0.010s bash-2.05b$ time 1.4.0a/gpg --check-trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model gpg: depth: 0 valid: 36 signed: 429 trust: 0-, 0q, 0n, 0m, 0f, 36u gpg: depth: 1 valid: 429 signed: 161 trust: 0-, 363q, 1n, 8m, 57f, 0u gpg: depth: 2 valid: 64 signed: 59 trust: 0-, 58q, 0n, 3m, 3f, 0u gpg: depth: 3 valid: 4 signed: 13 trust: 0-, 3q, 0n, 1m, 0f, 0u gpg: next trustdb check due at 2004-12-23 real 0m37.431s user 0m0.020s sys 0m0.020s bash-2.05b$ - -- John P. Clizbe Inet: JPClizbe(a)comcast DOT nyet Golden Bear Networks PGP/GPG KeyID: 0x608D2A10 "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7-cvs-2004-12-15 (Windows 2000 SP4) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBwfn5HQSsSmCNKhARAjrnAJ90vr8ostU9PIraBY/LEjQdaEqKdgCfc7A7 Na6rgya7gCi76heWZ01c8ec= =825t -----END PGP SIGNATURE----- From wk at gnupg.org Thu Dec 16 22:17:10 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Dec 16 22:39:43 2004 Subject: [Announce] Updated GnuPG 1.4.0 Windows binary In-Reply-To: <87zn0egnq7.fsf@wheatstone.g10code.de> (Werner Koch's message of "Thu, 16 Dec 2004 18:24:48 +0100") References: <87zn0egnq7.fsf@wheatstone.g10code.de> Message-ID: <87u0qmdju1.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Thu Dec 16 22:38:37 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Dec 16 22:40:00 2004 Subject: GPGME CVS branched In-Reply-To: <87zn0ej6ir.wl@ulysses.g10code.de> (Marcus Brinkmann's message of "Thu, 16 Dec 2004 22:08:12 +0100") References: <874qiy5471.wl@ulysses.g10code.de> <87llc4d3qm.wl@ulysses.g10code.de> <200412112104.49744.michaelnottebrock@gmx.net> <200412112213.42205.michaelnottebrock@gmx.net> <87oegztvt9.wl__2560.95722220397$1102864183$gmane$org@ulysses.g10code.de> <87zn0ej6ir.wl@ulysses.g10code.de> Message-ID: <87oegtexeq.fsf@wheatstone.g10code.de> On Thu, 16 Dec 2004 22:08:12 +0100, Marcus Brinkmann said: > Well, once you have mutex support, it doesn't hurt to use it when it > comes in useful. So, unless you can eliminate all uses, it doesn't > make sense to talk about eliminating some of them. Eventually libgcrypt will support hardware devices and then it will be more than unlikely to get away without thread synchronization. Libgcrypt's threads then need to get scheduled onto the available hardware devices. Well of course the hardware could provide this scheduling but what if you want to mix different hardware (please don't argument now, the OS kernel should do this). Shalom-Salam, Werner From wk at gnupg.org Fri Dec 17 12:27:54 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Dec 17 12:30:11 2004 Subject: [Announce] Dirmngr 0.9.0 released Message-ID: <87d5x9b1vp.fsf@wheatstone.g10code.de> Hi! We are pleased to announce the availability of Dirmngr 0.9.0. Dirmngr is a server for managing and downloading certificate revocation lists (CRLs) for X.509 certificates and for downloading the certificates themselves. Dirmngr also handles OCSP requests as an alternative to CRLs. Dirmngr is either invoked internaly by gpgsm (from gnupg 1.9) or when running as a system daemon through the dirmngr-client tool. Get it from: ftp://ftp.gnupg.org/gcrypt/alpha/dirmngr/dirmngr-0.9.0.tar.gz (555k) ftp://ftp.gnupg.org/gcrypt/alpha/dirmngr/dirmngr-0.9.0.tar.gz.sig or as a patch against the previous version: ftp://ftp.gnupg.org/gcrypt/alpha/dirmngr/dirmngr-0.5.6-0.9.0.diff.gz (180k) SHA1 checkums are: 05c8e2664c1d8ffe86270f331961f9a53f06d1e0 dirmngr-0.5.6-0.9.0.diff.gz 46dc0704abb5320465c9176d0dcc5eeafc0880fe dirmngr-0.9.0.tar.gz Whats new in this release ========================= * New option --daemon to start dirmngr as a system daemon. This switches to the use of different directories and also does CRL signing certificate validation on its own. * New tool dirmngr-client. * New options: --ldap-wrapper-program, --http-wrapper-program, --disable-ldap, --disable-http, --honor-http-proxy, --http-proxy, --ldap-proxy, --only-ldap-proxy, --ignore-ldap-dp and --ignore-http-dp. * Uses an external ldap wrapper to cope with timeouts and general LDAP problems. * SIGHUP may be used to reread the configuration and to flush the certificate cache. * An authorithyKeyIdentifier in a CRL is now handled correctly. We have changed quite a lot with this release so if you encounter build or runtime problems please report. Be sure to have read the manual before you do so. The LDAP detection code in configure as been repalced by the one used in GnuPG. Given the larger user base of GnuPG that code is likely more portable Happy Hacking, Werner -- Werner Koch The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.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/20041217/7da93724/attachment.bin From michaelnottebrock at gmx.net Fri Dec 17 14:34:06 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Fri Dec 17 14:39:52 2004 Subject: [Announce] Dirmngr 0.9.0 released In-Reply-To: <87d5x9b1vp.fsf@wheatstone.g10code.de> References: <87d5x9b1vp.fsf@wheatstone.g10code.de> Message-ID: <200412171434.10767.michaelnottebrock@gmx.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20041217/8393fcd2/attachment.bin From jvender at owensboro.net Fri Dec 17 15:32:24 2004 From: jvender at owensboro.net (Joe Vender) Date: Fri Dec 17 15:30:11 2004 Subject: GnuPG 1.4.0 vasprintf problem under WIN32 Message-ID: <200412170832240810.006B63BF@216.135.2.37> Attempts to "make" GnuPG 1.4.0 under MinGW/MSYS as per instructions by Carlo Luciano Bianco at http://clbianco.altervista.org/gnupg/eng/gnupg.html (alternative compilation instructions as modified slightly from 1.2.6 instructions) fail and return the following error: **** if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../intl -O0 -mtune=i386 -march=i386 -mfpmath=387 -mno-mmx -mno-sse -mno-3dnow -mno-sse2 -Wall -MT bftest.o -MD -MP -MF ".deps/bftest.Tpo" -c -o bftest.o bftest.c; \ then mv -f ".deps/bftest.Tpo" ".deps/bftest.Po"; else rm -f ".deps/bftest.Tpo"; exit 1; fi gcc -O0 -mtune=i386 -march=i386 -mfpmath=387 -mno-mmx -mno-sse -mno-3dnow -mno-sse2 -Wall -o bftest.exe bftest.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -liconv -lintl -lwsock32 ../util/libutil.a(ttyio.o)(.text+0x1c3):ttyio.c: undefined reference to `vasprintf' ../util/libutil.a(ttyio.o)(.text+0x2b2):ttyio.c: undefined reference to `vasprintf' collect2: ld returned 1 exit status make[2]: *** [bftest.exe] Error 1 make[2]: Leaving directory `/home/default/gnupg-1.4.0/tools' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/default/gnupg-1.4.0' make: *** [all] Error 2 **** I'm not a programmer, but playing around, here's what I've tried. In strgutil.c, if I modify the source with the following: **** --- strgutil.c~ Wed Nov 17 09:50:58 2004 +++ strgutil.c Fri Dec 17 08:00:16 2004 @@ -1161,6 +1161,11 @@ * found in gcc-2.95.2 and a little bit modernized. * FIXME: Write a new CRT for W32. */ + +#ifdef vasprintf + #undef vasprintf +#endif + int vasprintf (char **result, const char *format, va_list args) { Then make succeeds. Make also succeeds if, using an unmodified strgutil.c, references to vasprintf are changed to libintl_vasprintf in ttyio.c: --- ttyio.c~ Wed Nov 17 09:50:58 2004 +++ ttyio.c Fri Dec 17 08:06:38 2004 @@ -208,9 +208,9 @@ int n; DWORD nwritten; - n = vasprintf(&buf, fmt, arg_ptr); + n = libintl_vasprintf(&buf, fmt, arg_ptr); if( !buf ) - log_bug("vasprintf() failed\n"); + log_bug("libintl_vasprintf() failed\n"); if (!WriteConsoleA (con.out, buf, n, &nwritten, NULL)) log_fatal ("WriteConsole failed: %s", w32_strerror (0)); @@ -255,9 +255,9 @@ int n; DWORD nwritten; - n = vasprintf(&buf, fmt, arg_ptr); + n = libintl_vasprintf(&buf, fmt, arg_ptr); if( !buf ) - log_bug("vasprintf() failed\n"); + log_bug("libintl_vasprintf() failed\n"); if (!WriteConsoleA (con.out, buf, n, &nwritten, NULL)) log_fatal ("WriteConsole failed: %s", w32_strerror (0)); I have no idea if either one of these is correct. I've found that vasprintf if defined extern in libintl.h, which is #included in i18n.h under WIN32 which is itself #included in bftest.c where this problem seems to occur. The code references to vasprintf in libintl.h are: #undef asprintf #define asprintf libintl_asprintf extern int asprintf (char **, const char *, ...); #undef vasprintf #define vasprintf libintl_vasprintf extern int vasprintf (char **, const char *, va_list); If anyone has any idea what's going on with this failure due to the vasprintf code when building under MinGW/MSYS as per instructions by Carlo Luciano Bianco at http://clbianco.altervista.org/gnupg/eng/gnupg.html , please post a solution. Thanks. Joe Vender From stephane at sente.ch Fri Dec 17 15:45:07 2004 From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Fri Dec 17 15:41:58 2004 Subject: #warnings when compiling gpg 1.4.0 on OSX Message-ID: <3EE71445-503A-11D9-AF62-0003938D7B00@sente.ch> Here are the #warnings displayed when compiled on OSX 10.3.6: keylist.c: In function `list_keyblock_print': keylist.c:790: warning: field width is not type int (arg 2) passphrase.c: In function `agent_get_passphrase': passphrase.c:754: warning: passing arg 4 of `readn' from incompatible pointer type keyedit.c: In function `show_key_with_all_names': keyedit.c:2347: warning: field width is not type int (arg 2) On OSX, size_t is defined as an unsigned long. gpg 1.4.0 compiles fine, except the warnings, and all tests have passed. Thanks all, St?phane From wk at gnupg.org Fri Dec 17 15:42:00 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Dec 17 15:44:49 2004 Subject: [Announce] Dirmngr 0.9.0 released In-Reply-To: <200412171434.10767.michaelnottebrock@gmx.net> (Michael Nottebrock's message of "Fri, 17 Dec 2004 14:34:06 +0100") References: <87d5x9b1vp.fsf@wheatstone.g10code.de> <200412171434.10767.michaelnottebrock@gmx.net> Message-ID: <87k6rh7zrb.fsf@wheatstone.g10code.de> On Fri, 17 Dec 2004 14:34:06 +0100, Michael Nottebrock said: > N.B.: This introduces a dependency on GNU pth. Yes, it does. > FreeBSD requires an additional #include in jnlib/logging.c, patch attached. Thanks. > The ldap configure check probably should use the contents of --prefix (if > supplied to configure) to guess additional include and library paths for the > test programs (i.e. CFLAGS+=-I//include & LDFLAGS+=-I//lib. Do you see the same problem for gnupg 1.4 ? Salam-Shalom, Werner From alex at bofh.net.pl Fri Dec 17 16:44:53 2004 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Fri Dec 17 16:58:23 2004 Subject: (no subject) In-Reply-To: <877jnjo2r5.fsf@wheatstone.g10code.de> References: <3764.67.85.157.39.1103126458.squirrel@rhblade2.clemson.edu> <877jnjo2r5.fsf@wheatstone.g10code.de> Message-ID: <20041217154453.GB4917@syjon.fantastyka.net> On Wed, Dec 15, 2004 at 07:06:06PM +0100, Werner Koch wrote: > On Wed, 15 Dec 2004 11:00:58 -0500 (EST), Adam Schreiber said: > > > The developers of Seahorse were wondering about the status of a couple > > items and the general direction GPGME is headed in. The items are: > > > * Exporting Secret Keys > > There will be no way of exporting secret keys. Yes, I said so 2 years > ago but meanwhile I realized that secret keys are too sensitive and we > should not make it too easy for users to tinker with them. If you > need to copy secret keys forth and back between machines, something is > wrong with your general setup or you have real special reasons for > that which can and should be satisfied by well-thought out protocols. What about export of subkeys only? This is the situatrion where user has a good reason to mess with secret keys. (Note that I don't use GPGME, I am sking only about best key material management practices.) Alex -- mors ab alto 0x46399138 From wk at gnupg.org Fri Dec 17 19:46:57 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Dec 17 20:03:18 2004 Subject: #warnings when compiling gpg 1.4.0 on OSX In-Reply-To: <3EE71445-503A-11D9-AF62-0003938D7B00@sente.ch> =?utf-8?q?=28St=C3=A9phane_Corth=C3=A9sy's?= message of "Fri, 17 Dec 2004 15:45:07 +0100") References: <3EE71445-503A-11D9-AF62-0003938D7B00@sente.ch> Message-ID: <87d5x892zi.fsf@wheatstone.g10code.de> On Fri, 17 Dec 2004 15:45:07 +0100, St?phane Corth?sy said: > keylist.c: In function `list_keyblock_print': > keylist.c:790: warning: field width is not type int (arg 2) > passphrase.c: In function `agent_get_passphrase': > passphrase.c:754: warning: passing arg 4 of `readn' from incompatible > pointer type > keyedit.c: In function `show_key_with_all_names': > keyedit.c:2347: warning: field width is not type int (arg 2) Fixed in CVS. > On OSX, size_t is defined as an unsigned long. Are int and long both 32 bit? If not you should case the wield width arguments to int. > gpg 1.4.0 compiles fine, except the warnings, and all tests have passed. Thanks, Werner From wk at gnupg.org Fri Dec 17 19:49:20 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Dec 17 20:03:37 2004 Subject: (no subject) In-Reply-To: <20041217154453.GB4917@syjon.fantastyka.net> (Janusz A. Urbanowicz's message of "Fri, 17 Dec 2004 16:44:53 +0100") References: <3764.67.85.157.39.1103126458.squirrel@rhblade2.clemson.edu> <877jnjo2r5.fsf@wheatstone.g10code.de> <20041217154453.GB4917@syjon.fantastyka.net> Message-ID: <878y7w92vj.fsf@wheatstone.g10code.de> On Fri, 17 Dec 2004 16:44:53 +0100, Janusz A Urbanowicz said: > What about export of subkeys only? This is the situatrion where user has a > good reason to mess with secret keys. People who know what this means should also be able to do this on the command line. Werner From sadam at CLEMSON.EDU Fri Dec 17 22:11:41 2004 From: sadam at CLEMSON.EDU (Adam Schreiber) Date: Fri Dec 17 22:08:48 2004 Subject: (no subject) In-Reply-To: <878y7w92vj.fsf@wheatstone.g10code.de> References: <3764.67.85.157.39.1103126458.squirrel@rhblade2.clemson.edu> <877jnjo2r5.fsf@wheatstone.g10code.de> <20041217154453.GB4917@syjon.fantastyka.net> <878y7w92vj.fsf@wheatstone.g10code.de> Message-ID: <1502.67.85.157.39.1103317901.squirrel@67.85.157.39> On Fri, December 17, 2004 1:49 pm, Werner Koch said: > On Fri, 17 Dec 2004 16:44:53 +0100, Janusz A Urbanowicz said: > >> What about export of subkeys only? This is the situatrion where user has >> a >> good reason to mess with secret keys. > > People who know what this means should also be able to do this on the > command line. Shouldn't the goal of GPGME be to extend the power of the command line to users who choose to use a GUI or other tools to manage their keys? Adam From wk at gnupg.org Sat Dec 18 09:52:59 2004 From: wk at gnupg.org (Werner Koch) Date: Sat Dec 18 13:14:21 2004 Subject: (no subject) In-Reply-To: <1502.67.85.157.39.1103317901.squirrel@67.85.157.39> (Adam Schreiber's message of "Fri, 17 Dec 2004 16:11:41 -0500 (EST)") References: <3764.67.85.157.39.1103126458.squirrel@rhblade2.clemson.edu> <877jnjo2r5.fsf@wheatstone.g10code.de> <20041217154453.GB4917@syjon.fantastyka.net> <878y7w92vj.fsf@wheatstone.g10code.de> <1502.67.85.157.39.1103317901.squirrel@67.85.157.39> Message-ID: <874qik6l90.fsf@wheatstone.g10code.de> On Fri, 17 Dec 2004 16:11:41 -0500 (EST), Adam Schreiber said: > Shouldn't the goal of GPGME be to extend the power of the command line to > users who choose to use a GUI or other tools to manage their keys? Or secret key[1] should only be stored at one place. Everything else is only for people who really know what they are doing. And they wouldn't ask for GUI tool then. Werner [1] When I talk about a "secret key" I mean what's commonly also noted as the "private key", i.e. the private part of an asymmetric key pair. I don't mean a "shared secret" as used for symmetric encryption. From jvender at owensboro.net Sat Dec 18 12:49:51 2004 From: jvender at owensboro.net (Joe Vender) Date: Sat Dec 18 14:34:57 2004 Subject: Some MinGW/MSYS building observations for GnuPG 1.4.0 Message-ID: <41C4195F.9030406@owensboro.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 For those who are trying to build GnuPG 1.4.0 using MinGW/MSYS as per instructions provided at http://clbianco.altervista.org/gnupg/eng/gnupg.html and running into make failure with a message about "undefined reference to vasprintf", here's what I've found. The MinGW/MSYS Windows port of gettext-0.14.1-lib.zip contains a version of libintl.h which includes a bunch of redefinitions for the *printf functions Basically, #undef vasprintf #define vasprintf libintl_vasprintf extern int vasprintf (char **, const char *, va_list); and something similar for a bunch of other *printf functions. These redefinitions aren't present in the libintl-0.11.5-2-lib.zip version of libintl.h, but since the gettext-0.14.1-lib.zip version of libintl.h is newer than the libintl-0.11.5-2-lib.zip version, during the build system setup, the gettext verion overwrites the libintl version when setting up the build system as per Carlo's instructions. On my Windows98 machine, the libintl.h header file is found in "C:\MinGW\include" Under MinGW/MSYS on Windows (for me at least on Windows98 and the build system as described on Carlo's page), if these *printf redefinitions in libintl.h are commented out before doing a "./configure && make" on GnuPG 1.4.0, not only does this solve the error messages, "undefined reference to vasprintf", which result in failure of "make", but it also solves all of the warning messages which I was getting, "warning: libintl_printf is an unrecognized format function". Of course, commenting this code out isn't the proper way to handle this, since this will impact the gettext stuff somewhere. I'm not suggesting this course of action for anyone to build a set of binaries to be trusted. Suggestions would be helpful. Perhaps an #ifdef vasprintf #undef vasprintf #endif code block before the vasprintf function declaration in strgutil.c? Something similar for the printf function? Thanks. I'm not a programmer, just tinkering and learning. Regards, Joe Vender -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) - GPGshell v3.30 iQEVAwUBQcQYnibIfMqPbtHmAQgWHgf+NVCDJ5fpe34s+MElbH2YrF/gibBi9sfp +WpBysz7aRXz3rt4c8K7ZhO6WpB5euNOsrfk4gzL1ukHjEnanQ1CLp0jVNxD9njI QrtYo0d0ukjMs9mbVicsC6sRF3611E6W6d5PNCQXsZkCtQ7MOCMhdnRn6CAVppsz 16snw5WKVEjpWRVjw2ry2rN8kvcahP1ilkISKGoGzCo38OZGrQKOUI9bZs+UOyhi lkibCNE/aMeZKAj6RUZ8q0at5dZMplJ6xbuSEzQSvCjHMAfEbfnoD3gc6ncLxIL6 aRhTnbIwZfkbiJQ/xYqYdju3sY9w3PPzbPNngzXKRHJnj56j41pZ3g== =KRwL -----END PGP SIGNATURE----- From zuxy.meng at gmail.com Sat Dec 18 15:57:39 2004 From: zuxy.meng at gmail.com (Zuxy) Date: Sat Dec 18 15:55:05 2004 Subject: Some MinGW/MSYS building observations for GnuPG 1.4.0 In-Reply-To: <41C4195F.9030406@owensboro.net> References: <41C4195F.9030406@owensboro.net> Message-ID: I always download MSYS/MinGW components from http://prdownloads.sf.net/mingw/ and I don't find gettext-0.14.1 there, only gettext-0.11.5. I guess the MSYS/MinGW guys haven't tested it yet. On Sat, 18 Dec 2004 05:49:51 -0600, Joe Vender wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > The MinGW/MSYS Windows port of gettext-0.14.1-lib.zip contains a > version of libintl.h which includes a bunch of redefinitions for > the *printf functions > -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6 From stephane at sente.ch Sat Dec 18 14:20:06 2004 From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Sat Dec 18 22:27:51 2004 Subject: #warnings when compiling gpg 1.4.0 on OSX In-Reply-To: <87d5x892zi.fsf@wheatstone.g10code.de> References: <3EE71445-503A-11D9-AF62-0003938D7B00@sente.ch> <87d5x892zi.fsf@wheatstone.g10code.de> Message-ID: <886F4E0E-50F7-11D9-827C-0003936A3BE2@sente.ch> Hi, On Dec 17, 2004, at 7:46 PM, Werner Koch wrote: > On Fri, 17 Dec 2004 15:45:07 +0100, St?phane Corth?sy said: > >> keylist.c: In function `list_keyblock_print': >> keylist.c:790: warning: field width is not type int (arg 2) > >> passphrase.c: In function `agent_get_passphrase': >> passphrase.c:754: warning: passing arg 4 of `readn' from incompatible >> pointer type > >> keyedit.c: In function `show_key_with_all_names': >> keyedit.c:2347: warning: field width is not type int (arg 2) > > Fixed in CVS. > > >> On OSX, size_t is defined as an unsigned long. > > Are int and long both 32 bit? If not you should case the wield width > arguments to int. Even on a G5 (64bits), long and int are both 32 bit. >> gpg 1.4.0 compiles fine, except the warnings, and all tests have >> passed. > > Thanks, > > Werner > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel Thanks, St?phane From jas at extundo.com Sun Dec 19 01:14:05 2004 From: jas at extundo.com (Simon Josefsson) Date: Sun Dec 19 01:29:47 2004 Subject: GPGME CVS branched References: <874qiy5471.wl@ulysses.g10code.de> <87llc4d3qm.wl@ulysses.g10code.de> <200412112104.49744.michaelnottebrock@gmx.net> <200412112213.42205.michaelnottebrock@gmx.net> <87oegztvt9.wl__2560.95722220397$1102864183$gmane$org@ulysses.g10code.de> <87zn0ej6ir.wl__37373.1810403571$1103231668$gmane$org@ulysses.g10code.de> Message-ID: Marcus Brinkmann writes: > At Sun, 12 Dec 2004 18:44:14 +0100, > Simon Josefsson wrote: >> Marcus Brinkmann writes: >> I find that requiring threaded applications to provide thread hooks >> into libraries is problematic. The most common situation where a this >> causes problems is when a threaded application uses one library that >> in turn uses gcrypt/gpgme. > > This is in fact exactly the situation that required us to take the > hook approach. > > We have done extensive analysis of this problem, and we have seen what > happened to our other attempts at solving this. And we have tried > everything we could think of: magic support via weak symbols, > different versions of the same library a la foo-threadpackage, and the > hooks. We have also looked at how other projects solve this, and have > not seen anything better elsewhere. There is no perfect approach for > this problem, it's impossible. The goals are conflicting (support for > several thread libraries, portability to many platforms, supporting > mixed library environments). So the best we can do is to be flexible > and make the problem obvious in whatever ways we can. > > You can find an extensive defense of our approach in the gcrypt > mailing list: > > http://lists.gnupg.org/pipermail/gcrypt-devel/2004-March/000566.html Thanks. I did not read this very carefully, but I cannot find any discussion of WHY you actually require thread primitives in libgcrypt. I understand that once you have a design that uses thread primitives like mutexes, you will get into all the problems you went through. And I agree it probably can't be solved cleanly. So I'm trying to explore the consequence of that conclusion, and attack the reason you needed mutexes in the first place: why? Compare libgcrypt with Nettle (that I use in GSASL/Shishi, via a abstraction layer that may use libgcrypt instead). Nettle does not require any mutexes, and consequently doesn't suffer from the issues you bring up. I'm trying to understand why libgcrypt couldn't use a similar strategy to solve this problem, instead of "infecting" the users of libgcrypt with the hooks-approach. >> and consequently does not set them any thread hooks in gcrypt. > > It should export an interface to the user to do so (assuming that the > fact that gcrypt is used should be hidden). The fact that gcrypt is used is not very well hidden right now, because of the secure memory issues. But is complex when libgcrypt is an optional dependency of my library. Making applications link to libgcrypt "just in case" my library uses libgcryp seems bad. >> Requiring the application to be notice that gnutls/gsasl uses gcrypt, >> and have the application call the thread hooks in gcrypt, destroy >> abstraction layers. > > I always found it a mistake by the gnutls developer to let the user of > gnutls call a gcrypt function directly. I advised him to wrap the > interface. I have written both libraries and applications that use GnuTLS, and I have never had to call gcrypt functions directly because of that. Perhaps everything is wrapped now. > Have you actually tried mixing thread libraries? No, it was a hypothetical example. I recall seeing the issue come up with some big applications, like OpenOffice or GNOME, but don't know the details. >> I reviewed all uses of thread hooks in libgcrypt (a lot!), and to me >> all of the uses could be avoided by choosing a simpler design. >> Compare Nettle. Perhaps the only exception I could find was >> randomness gathering, but then again I think that is such a critical >> function that the complexity of thread interaction should be avoided >> at all. > > Well, once you have mutex support, it doesn't hurt to use it when it > comes in useful. So, unless you can eliminate all uses, it doesn't > make sense to talk about eliminating some of them. Right. But when trying to figure out what critical uses of libgcrypt have for mutexes, it would help to get rid of the non-critical parts. (I'm not proposing to change libgcrypt, it is probably too late for that. I'm talking about these issues in general, taking libgcrypt and possibly gpgme as examples.) > Of course there are alternative approaches possible. But they come at > a cost, too, and it is always a trade-off. Personally, I would have > designed some of the gcrypt interfaces differently myself, but that's > a different story. I am not sure I would opt for a design that does > not require any mutual exclusion, but then, we have not even said > explicitely how such a design in the context of gcrypt may look, so > it's a moot point. What costs do you see with a mutex-free design? I'm looking from the application point of view, and the Nettle API seems simpler than the Libgcrypt API, because I don't have to worry about thread interactions. I'm not sure I can identify any cost that the Nettle API brings me that the libgcrypt API doesn't also suffer from. Thanks, Simon From wk at gnupg.org Sun Dec 19 14:41:02 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Dec 20 11:02:10 2004 Subject: GPGME CVS branched In-Reply-To: (Simon Josefsson's message of "Sun, 19 Dec 2004 01:14:05 +0100") References: <874qiy5471.wl@ulysses.g10code.de> <87llc4d3qm.wl@ulysses.g10code.de> <200412112104.49744.michaelnottebrock@gmx.net> <200412112213.42205.michaelnottebrock@gmx.net> <87oegztvt9.wl__2560.95722220397$1102864183$gmane$org@ulysses.g10code.de> <87zn0ej6ir.wl__37373.1810403571$1103231668$gmane$org@ulysses.g10code.de> Message-ID: <873by24d8x.fsf@wheatstone.g10code.de> On Sun, 19 Dec 2004 01:14:05 +0100, Simon Josefsson said: > And I agree it probably can't be solved cleanly. So I'm trying to > explore the consequence of that conclusion, and attack the reason you > needed mutexes in the first place: why? Maintaining the entropy pool of the RNG is the most important one. Another one is the feature to allow adding new cipher modules. And eventually we will have hardware devices. Shalom-Salam, Werner From dirk.traulsen at lypso.de Sun Dec 19 22:11:30 2004 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Mon Dec 20 11:27:16 2004 Subject: Revoked UID and subkey is shown when listing secret keyring Message-ID: <41C5FC92.20046.4BA993@localhost> Hi! I tried gpg 1.4.0a for Windows on a german Windows95-Installation. After generating a testkey, I found a bug. As you can see in the key info, there is a revoked subkey and a revoked uid in the key. C:\Programme\GnuPG>gpg --list-keys --with-colons xx tru::1:1103485092:1139767092:3:1:5 pub:f:1024:17:953A6E46FD4A4739:2004-12-18:::-:xxxx5 ::scESC: uid:f::::2004-12-19::8518392C677FE8D5E546F5CE32967DB951793C13::xx3x5 : uid:r::::::8226C3E7B1F72D39A449DC2C15718CC9A267A485::x2xx5 : sub:r:1024:16:5356ECF361705F04:2004-12-18::::::e: sub:f:1504:16:C9302575EF711C2A:2004-12-18::::::e: sub:f:1024:16:087AA91389ECC00A:2004-12-19::::::e: sub:f:1024:17:BAFAD77F2BEE00B9:2004-12-19::::::s: When I list the public key, it shows only the valid keys and UIDs: C:\Programme\GnuPG>gpg -k xx pub 1024D/FD4A4739 2004-12-18 uid xxxx5 uid xx3x5 sub 1504g/EF711C2A 2004-12-18 sub 1024g/89ECC00A 2004-12-19 sub 1024D/2BEE00B9 2004-12-19 When I list the secret keys, it shows only the valid UIDs, but additionally the revoked subkey (Is this intended or also a bug?): C:\Programme\GnuPG>gpg -K xx sec 1024D/FD4A4739 2004-12-18 uid xxxx5 uid xx3x5 ssb 1024g/61705F04 2004-12-18 ssb 1504g/EF711C2A 2004-12-18 ssb 1024g/89ECC00A 2004-12-19 ssb 1024D/2BEE00B9 2004-12-19 Now comes the inconsistency (bug?): When I list the whole secret keyring, it shows both - the revoked subkey AND the revoked UID! C:\Programme\GnuPG>gpg -K C:/Programme/GnuPG\secring.gpg ------------------------------ sec 1024D/FD4A4739 2004-12-18 uid xxxx5 uid x2xx5 uid xx3x5 ssb 1024g/61705F04 2004-12-18 ssb 1504g/EF711C2A 2004-12-18 ssb 1024g/89ECC00A 2004-12-19 ssb 1024D/2BEE00B9 2004-12-19 sec 1024D/2EDFB41E 1998-11-04 uid Dirk Traulsen ssb 4096g/0B9DCED2 1998-11-04 This behavior is not connected to this key alone, but every key behaves like this. I hope my information helps you. Dirk Traulsen PS: Don't the slashes and backslashes look really weired... C:\Programme\GnuPG>gpg -K C:/Programme/GnuPG\secring.gpg From dirk.traulsen at lypso.de Sun Dec 19 22:11:30 2004 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Mon Dec 20 11:27:21 2004 Subject: Explicitely choosing a subkey leads to breakdown of gpg 1.4.0a for windows Message-ID: <41C5FC92.19501.4BA819@localhost> Hi! I tried gpg 1.4.0a for Windows on a german Windows95-Installation. First I generated a testkey. While playing around with it, I wanted to explicitely use older, but valid subkeys. (As normally gpg uses the newest ones, even if they have a lower bit number.) gpg -r EF711C2A! -e FILE Then gpg broke down and the system gave me the following error message: ###### GPG verursachte einen Fehler durch eine ung?ltige Seite in Modul GPG.EXE bei 014f:004aade0. Register: EAX=dd043ac4 CS=014f EIP=004aade0 EFLGS=00010282 EBX=00835810 SS=0157 ESP=0080ea14 EBP=0080ea18 ECX=dd0512b4 DS=0157 ESI=00000000 FS=1c57 EDX=00843000 ES=0157 EDI=00930c90 GS=0000 Bytes bei CS:EIP: c6 02 ff 42 48 75 f9 85 c9 89 da 89 c8 74 08 90 Stapelwerte: 00933950 0080ea28 004a404c 00835818 00933950 0080ea68 0044d1fd 00933950 0093393c 00933950 00930cf4 008354d8 008354a8 00000020 00933930 009332e0 ###### The key is attached (and not send to any keyserver). I tried to use its primary key for signing instead of the newer signing subkey and it worked. I generated another key and there signing and encrypting to older subkey worked. I booted Windows again. (Standard procedure..) But the described breakdown was reproducible everytime. So it seems to be a problem that comes especially with this key and encrypting to older subkeys. (Standard use of this key is completely normal.) I hope my information helps you. Dirk Traulsen PS: The key is attached, but here is an overview: C:\Programme\GnuPG>gpg -k --with-c xx tru::1:1103485092:1139767092:3:1:5 pub:f:1024:17:953A6E46FD4A4739:2004-12-18:::-:xxxx5 ::scESC: uid:f::::2004-12-19::8518392C677FE8D5E546F5CE32967DB951793C13::xx3x5 : uid:r::::::8226C3E7B1F72D39A449DC2C15718CC9A267A485::x2xx5 : sub:r:1024:16:5356ECF361705F04:2004-12-18::::::e: sub:f:1504:16:C9302575EF711C2A:2004-12-18::::::e: sub:f:1024:16:087AA91389ECC00A:2004-12-19::::::e: sub:f:1024:17:BAFAD77F2BEE00B9:2004-12-19::::::s: -------------- next part -------------- -----BEGIN PGP PRIVATE KEY BLOCK----- Version: GnuPG v1.4.0 (MingW32) lQHhBEHEQjIRBADJVY8EKUkRmi3OvspCqLhXWGW3S5JDc3u3EWdWLYkKbuu1y6Q+ rkjLQxuizHtZfXB4TOc6L4aBcPVjdACAmoToZGacMi/t88QMWSk8IGb3Ih6W5m/K jkfeGpNbmL56w6FT33rL/8BRX7LiAj4B5KlFsrR8819v6SKbkKVUsrpecwCgnM88 jqB/+0g8HZ18rUKfxRt6O58D/AvHjZKYUXZvQZ8WDVbqyyNb3rjWReZcNzUAmtNJ zgli7wckIee0SZbnEBaGxnOvRpm6Y9d6Ue5FalPQjo8gbbmATNSyzPgqtGlgv/jN vjs3Mb/MR6a33//FSsA73tKMQ7cZng5DRk5Eedi5uNIkZKHIsV0HNh33ySzJROa6 7xlEBACHRAeQGjpVocrN6JffiH2jFViVa1RKmvScUmWLgNIL9VxahdzeSDHSxtRH 5grht0do72CtDXz/vTe8+WiJCZcmtZXJ3AMdsDkLoKKK1dUvSDQQmBKN5XCVVWb0 tWaz0O/bmbfVujQr7L0XpfVOzRi1VX0Q6i1nhqULJJRyy794uf4DAwIWGuNdH8o9 dmAHEZWwxOUv9P1RrOMUvB4Aeq9+YQQS/kUKfx/M5YKe0A3nd5kqe9317HoyWe5U KKTvc4hhBB8RAgAhBQJBxEMaFwyAEeIIHAD3Lbc1rO2xDNr6ZnUu37QeAgcAAAoJ EJU6bkb9Skc5wGoAn36xKvl9b08wMAr+Ejy1G/y5w8TAAKCDPCRT1qJg2yyxOKYx PfrYM3FmUYhhBB8RAgAhBQJBxETMFwyAEUtamGvizXiQBaEeP7U6LMy4U9NGAgcA AAoJEJU6bkb9Skc5FZwAoJnc71JL6SW/fKxKsMv6e2PYRF6rAJ9sxQwCE3EJ8piz wN7D5rSLhjLedbQLeHh4eDUgPHhAeD6IXgQTEQIAHgUCQcRCMgIbAwYLCQgHAwID FQIDAxYCAQIeAQIXgAAKCRCVOm5G/UpHOdnjAJ9vL/pYf+jLiEmnJaEIM+sixk6b HQCcCD5q2IZZVy7KOdKey/WYni//gUW0C3gyeHg1IDx4QHk+iF4EExECAB4FAkHE Qn0CGwMGCwkIBwMCAxUCAwMWAgECHgECF4AACgkQlTpuRv1KRzm0rACfXVdRqnBx zoz3I18okXc2or91wrYAnjJxJ65EghPaQLildBqNLWD9fooKtAt4eDN4NSA8eEB4 PoheBBMRAgAeBQJBxZOkAhsDBgsJCAcDAgMVAgMDFgIBAh4BAheAAAoJEJU6bkb9 Skc50/4AnihGqVv3d5q4LvaFN1OXgPz0pyehAJ9bS0J0CJ8hFNzEXNXTbn/8/wpl TZ0BWARBxEI7EAQAk5HW6Id3lBy1yrjePsgml/fHcyM6j2jmAHscHVihJP1KVCuI 8PUmzbA6nxyE1fRUgWSjfffJg06+DROuPlaZM1cRT4Oqh8vIVAd1LDGCZCMIMEAx e2v52SnogDeVkBrZx0ZhqVYwxCf9EGf5U0gVwyoRzW/fFI3cMzrfmKyknqcAAwUE AIR6hpIM1E3Q6u1rQSOG71mQDE2zt91OId0Yrcyi9vsvu7SbLU3Ws2XR6fhBsI5j 33mi2rPybpDKp0213uW/s8h/2GT6LRfiy4aRthhE2TReKrAkc7bE+7ujx8KVxe6U m2XKZdkLAK/GQxah3zvl9h30KEyOL2Q73G2vyee2KhEz/gMDAhYa410fyj12YMeR kCWaAZhNrPRONa66Bx+oao9ZrbK90ZlEO0SelRRAhZYERUjCiqCf9/QXy1pQQf8G bwiRTngY445O+kHtiEkEGBECAAkFAkHEQjwCGwwACgkQlTpuRv1KRzk7aQCggTRJ qv98mr87CmfZUDMl/0QjLSUAniVhwcebkiQHTXUspFhlRMYkdIUEnQHWBEHERmsQ BeDdBRK0BVShMBADDkUXun8cJH14lJrvy8DOO15+jPBVvyJLBbPNmWnrW8veLfFw RXIhWfowaS0XCVGjT0Jv9IsoFuG4cnSj71bFS2BwY7Ct/WbBv5GzwMbyJ3Z2QNvn ADwKI0oKEMpL7jjcWsN7YnZhqECdV79rx31TiIJe6x6xUM3GyJpRPcAhuHCkLdN9 Qg7lMGz3EaHyO3U5kHi2D4k7dC2pH6bNQrCRi+aIa0gmVxUkNheUUvSnJpodWwAD BQXeJOxZUdKB1HX/hOo3RScI5qaXdGRvNKvsGn7dO9BNNgFGzsgj/fikrOgFslt+ n0utTdVFpi03EpF6x+g87Xmd+L4Dp8y29v49XYtRrK+TyylQ53012z8CW6atofeG KqWQKbmNAiI7b/TFZ/249jEiaSowDJB53m0KZyIpRh2XdUpdHjXiGOWvKcoWGWhj 7YBhgWCblN1oDIiYu01iBJlbvT4kVLldxSb1FLhBBoos2FOvZo9yNQo74VGFk8f+ AwMCXdwtNxKk+6NgSy67BmWFmEBUh8t37jDA1cS2M0I8E4XdpPvG3ppAq1TemYjq rzRVRddK0PWtLV85uZKGeFuavr0w+hlYtQyXTc1BG6qISQQYEQIACQUCQcRGawIb DAAKCRCVOm5G/UpHOU+MAKCFHYQ4RplYlFLuubtHTaQvtovWjwCgkPRCfm52EwLH dmvhDItZ9uyCIxWdAVgEQcXJcxAEAJ/NNIuhVSPO8yd6qSOSuo7NlrUTjnlEfike s4FmjOoGhYS12cjP637rFfa6yV8Q5WQQJ0khZeVJQYnDhA43VPgD4BPzM2b5NRWk qym/+uAxcz2fyNUtovgJzIOJ6aL6v0qoM+CdwD03kjQyUay6dWD22Vo659Im29iH x1MHUiMTAAMFA/4zxC6aN/ljcD+JoR2AwMx/8v8fEvxPOaPF+5tciwVGXh9YKk6s Bq+10Cp213Q5mCXVb+mDJNgzXOEhyTnzq5CIIhw9ixz0ltBzz8Ruuzjs0T/3tJ1A 6rmxnqIZubV13bI56xcBSMLmOW4vp3BsNLaj0/PkHaMQ12GEizUanjEsc/4DAwKd a2OlzKsqSWBGI1GF6NuHKZuPF/61g3ASZUSX89auAQ86wYi1Gu25E7yJfQlkt0pa NuPPaah7mZuCDHDrCZmIkeOgJIUww4hJBBgRAgAJBQJBxclzAhsMAAoJEJU6bkb9 Skc53uIAnRSScbmmbdX5DDD0oYNPSUhDAjXrAKCPY9nHpHYiXqqu0sYwYDlOFRD5 3p0B4QRBxd9uEQQA4kER5YUCOcJbq9fS7wex3eUM9pepxeiHKHyMX8Ynu+eOqBvW jtH/8FSSFj15i90bLfQz9imMOzWrsbTCmmm4bQdKqxSQSOMR7piC3Q65pN38+HlZ BfyHYgnDHaMi61hZ5tQDc/01uXHj7BQ8xuZZGHjnzOsIQEvlePdhINKb+bMAoJuP 6XaqtvtaSa8MMBGtpfN2Ogx/A/wNLIYiYI+o/ZgCiwKS19LAcqI8JMwapMIuJy1b 3r0GnWgKQk5Ar5Ksu43sXuuzaKIC8WfmIXD1Y96ZfMpRSDdG1Pz2+3pjWLvlaAJv yDnkEPiz9RabCVq+4r8NrFjkW79HqJMVykayVutkaTW/Nb99HPTsd6Zz34PNRize SfVonwQAqUnI29eiAxfhHgNASCA2gGb4hGioMrS74GmE27l2Q4D0FdKnYqxRhe29 7nFMfhOcRZ3TB8oxiXfsodvz7r8e6VRmPTeWVhLBVdxMy0jjjc9uQpbg92qGIJ8+ RcBlEytRxnRylKBVgaaebUwwUfP/rDa9/vUeQpJaG3ZZzDoD1BX+AwMC+ilr9fIF mFdgYh4IZA6uKhEUAj5XytFfPi0uuhsjZ6az1kz7EUNHPlrAmXtKALHxPBFwuHPV l4nXm2eISQQYEQIACQUCQcXfbwIbAgAKCRCVOm5G/UpHOUG2AKCOA+WIt7+i7mD3 CkVFYU6o6630GwCfcuyjih0+yA8dWff4K+QLBA8uod4= =F/f8 -----END PGP PRIVATE KEY BLOCK----- -------------- next part -------------- Der folgende Teil dieser Nachricht enth?lt einen Anhang im sogenannten Internet MIME Nachrichtenformat. Wenn Sie Pegasus Mail oder ein beliebiges anderes MIME-kompatibles Email-System verwenden, sollte Sie den Anhang mit Ihrem Email-System speichern oder anzeigen k?nnen. Anderenfalls fragen Sie Ihren Administrator. The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- Datei Information/File information ----------- Datei/File: xx-pub.asc Datum/Date: 19 Dec 2004, 21:10 Gr??e/Size: 4238 bytes. Typ/Type: PGP-Public-Key -------------- next part -------------- A non-text attachment was scrubbed... Name: xx-pub.asc Type: application/octet-stream Size: 4238 bytes Desc: not available Url : /pipermail/attachments/20041219/b0148308/xx-pub-0001.exe From dshaw at jabberwocky.com Mon Dec 20 15:21:06 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Mon Dec 20 15:18:11 2004 Subject: Revoked UID and subkey is shown when listing secret keyring In-Reply-To: <41C5FC92.20046.4BA993@localhost> References: <41C5FC92.20046.4BA993@localhost> Message-ID: <20041220142106.GF22290@jabberwocky.com> On Sun, Dec 19, 2004 at 10:11:30PM +0100, Dirk Traulsen wrote: > Hi! > > I tried gpg 1.4.0a for Windows on a german Windows95-Installation. > After generating a testkey, I found a bug. > > As you can see in the key info, there is a revoked subkey and a > revoked uid in the key. > > C:\Programme\GnuPG>gpg --list-keys --with-colons xx > tru::1:1103485092:1139767092:3:1:5 > pub:f:1024:17:953A6E46FD4A4739:2004-12-18:::-:xxxx5 ::scESC: > uid:f::::2004-12-19::8518392C677FE8D5E546F5CE32967DB951793C13::xx3x5 > : > uid:r::::::8226C3E7B1F72D39A449DC2C15718CC9A267A485::x2xx5 : > sub:r:1024:16:5356ECF361705F04:2004-12-18::::::e: > sub:f:1504:16:C9302575EF711C2A:2004-12-18::::::e: > sub:f:1024:16:087AA91389ECC00A:2004-12-19::::::e: > sub:f:1024:17:BAFAD77F2BEE00B9:2004-12-19::::::s: > > When I list the public key, it shows only the valid keys and UIDs: That is correct. > When I list the secret keys, it shows only the valid UIDs, but > additionally the revoked subkey (Is this intended or also a bug?): That's not correct. It should show the invalid UIDs in the secret keyring (same as if you list the whole secret keyring). I'll fix that. David -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 250 bytes Desc: not available Url : /pipermail/attachments/20041220/19adad33/attachment.bin From JPClizbe at comcast.net Mon Dec 20 23:06:09 2004 From: JPClizbe at comcast.net (John Clizbe) Date: Mon Dec 20 23:03:06 2004 Subject: Syntax error in 1.4.1-cvs-2004-12-20 Message-ID: <41C74CD1.3090301@comcast.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 $ diff -u g10/keygen.c~ g10/keygen.c - --- g10/keygen.c~ Mon Dec 20 15:42:04 2004 +++ g10/keygen.c Mon Dec 20 15:54:51 2004 @@ -1570,9 +1570,9 @@ } if( !valid_days ) { - - tty_printf((object==0) - - ? _("Key does not expire at all\n") : - - : _("Signature does not expire at all\n")); + tty_printf((object==0 + ? _("Key does not expire at all\n") + : _("Signature does not expire at all\n") ) ); interval = 0; } else { - -- John P. Clizbe Inet: JPClizbe(a)comcast DOT nyet Golden Bear Networks PGP/GPG KeyID: 0x608D2A10 "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0a (Windows 2000 SP4) Comment: When cryptography is outlawed, b25seSBvdXRsYXdzIHdpbGwgdXNlIG Comment: It's YOUR right - for the time being. Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBx0zHHQSsSmCNKhARAkdqAKDh6cVMdA70SOCgWwt8mMxkqmCz7gCfYVRF XbxZNIEuheq0fD98ak183dY= =8XkX -----END PGP SIGNATURE----- From nielsen at memberwebs.com Tue Dec 21 02:32:30 2004 From: nielsen at memberwebs.com (Nielsen) Date: Tue Dec 21 02:20:35 2004 Subject: (no subject) References: <3764.67.85.157.39.1103126458.squirrel@rhblade2.clemson.edu> <877jnjo2r5.fsf@wheatstone.g10code.de> <20041216001142.8A7FB840481@mail.npubs.com> <87r7lqlkby.fsf@wheatstone.g10code.de> Message-ID: <20041221013229.9DE3B8409B6@mail.npubs.com> Werner Koch wrote: > On Thu, 16 Dec 2004 00:11:43 +0000 (GMT), Nielsen said: >>I don't understand. How would a user move his long-time secret keys to >>another machine when he upgrades? Note I'm talking about a simple user >>here, 'use the command line' is not an option. > > Backup and restore ~/.gnupg of course. Right, and seahorse already has this functionality. Actually the users who requested this particular feature seem to be interested in moving keys and keyrings between GPG on Linux and PGP on Windows. But, as noted earlier, we'll probably eventually provide this option via a direct call to GPG. > Direct access to keyservers? gpg supports colon formatted output and > thus we are able to add this keyserver searches to gpgme. We ahve > already done this for gpgsm, so the infrastructure is more or less > available. > > Manipulation of options? gpgconf (from gnupg 1.9) does this job fine > for KDE and works with all current gpg versions. That's wonderful and great to hear. Thanks for the insight. As far as seahorse, it seems that for certain features, we may opt to wait for a stable GPG/GPGME release containing them. And for others which are more timely in nature, we may choose to implement them immediately using command line hacks until such a time as the features make their way into the stable GPG/GPGME code. Cheers, Nate From wk at gnupg.org Tue Dec 21 09:03:00 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Dec 21 09:04:47 2004 Subject: (no subject) In-Reply-To: <20041221013229.9DE3B8409B6@mail.npubs.com> (nielsen@memberwebs.com's message of "Tue, 21 Dec 2004 01:32:30 +0000 (GMT)") References: <3764.67.85.157.39.1103126458.squirrel@rhblade2.clemson.edu> <877jnjo2r5.fsf@wheatstone.g10code.de> <20041216001142.8A7FB840481@mail.npubs.com> <87r7lqlkby.fsf@wheatstone.g10code.de> <20041221013229.9DE3B8409B6@mail.npubs.com> Message-ID: <87u0qgt6x7.fsf@wheatstone.g10code.de> On Tue, 21 Dec 2004 01:32:30 +0000 (GMT), Nielsen said: > As far as seahorse, it seems that for certain features, we may opt to > wait for a stable GPG/GPGME release containing them. And for others gpgconf will not go into any gnupg < 1.9. It might be useful if Debian could separate gpgconf out. Werner From dshaw at jabberwocky.com Wed Dec 22 22:14:06 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Dec 22 22:11:11 2004 Subject: Help test new HTTP/FTP code Message-ID: <20041222211405.GA13662@jabberwocky.com> Hi folks, For various reasons, we are exploring using libcurl for HTTP and FTP access within GnuPG (specifically the gpgkeys_xxxx programs). This is still at the evaluation stage, and is not a done deal yet. For those people who are occasionally tracking CVS, I would very much appreciate it if you could sync up to today's checkins and give the new code a whirl. Note that using libcurl is not the default behavior, and requires a "--with-libcurl" argument to ./configure to turn it on. Note that when enabled, libcurl is only used for HTTP and FTP access, and not HKP. This pretty much restricts it to fetching a key from a http:// or ftp:// preferred keyserver URL on a key or in a signature. Things I'm looking for are: 1) Build problems. Does it not build on your platform (if so, what is the platform and what version of libcurl do you have?) 2) Functionality problems. Does it act funny or not do what you expect? 3) Other comments. Thanks! David From wk at gnupg.org Wed Dec 22 22:24:27 2004 From: wk at gnupg.org (Werner Koch) Date: Wed Dec 22 22:25:13 2004 Subject: GnuPG 1.9.14 released Message-ID: <87k6rani0k.fsf@wheatstone.g10code.de> Hi! We are pleased to announce the availability of GnuPG 1.9.14, the new development branch of GnuPG for use with S/MIME. GnuPG 1.9 is the development version of GnuPG; it is based on the GnuPG 1.3 code and the previous NewPG package. It will eventually lead to a GnuPG 2.0 release. Note that GnuPG 1.4 and 1.9 are not yet in sync and thus features and bug fixes done in 1.4 are not available in 1.9. Please keep on using 1.4 for OpenPGP. You should use GnuPG 1.9 if you want to use the gpg-agent or gpgsm (the S/MIME variant of gpg). Note that the gpg-agent is also helpful when using the stable gpg version 1.4 (as well as the old 1.2 series). This is mainly a bug fix release with a few new things: * [gpg-agent] New option --use-standard-socket to allow the use of a fixed socket. gpgsm falls back to this socket if GPG_AGENT_INFO has not been set. * Ported to MS Windows with some functional limitations. * New tool gpg-preset-passphrase. Please get it from the mirrors as listed at http://www.gnupg.org/download/mirrors.html or direct from ftp.gnupg.org: BZIP2 compressed: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.14.tar.bz (1593k) ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.14.tar.bz.sig or GZIP compressed: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.14.tar.gz (1880k) ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.14.tar.gz.sig or as a patch against the previous release (168k): ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.13-1.9.14.diff.gz You also need to get a new libassuan: ftp://ftp.gnupg.org/gcrypt/alpha/libassuan/libassuan-0.6.9.tar.gz (250k) ftp://ftp.gnupg.org/gcrypt/alpha/libassuan/libassuan-0.6.9.tar.gz.sig If you want to try out the yet very limited W32 version, you may get precompiled binaries at: ftp://ftp.gnupg.org/gcrypt/alpha/binary/gnupg-w32cli-1.9.14.zip (1427k) ftp://ftp.gnupg.org/gcrypt/alpha/binary/gnupg-w32cli-1.9.14.zip.sig SHA1 checksums for the above files are: 6e5a3b27a4eb6a781bc8d8ad9458ea3e99449b48 gnupg-1.9.14.tar.gz 056ba75f0361df26a9d39d4c4fe16c9541b03bd9 gnupg-1.9.14.tar.bz2 6b0d05a81b7fa9e2883ed9a2b5c36b78e48d632f gnupg-1.9.13-1.9.14.diff.gz 97bdb0c5b66d02bce22e55183c3b550542f19b46 libassuan-0.6.9.tar.gz 5a800a3ceb9fbbe11473a2fdec700c5b3c856ec4 libassuan-0.6.8-0.6.9.diff.gz 899dbffe90d071689ccdb422f11a6e34f18b89db gnupg-w32cli-1.9.14.zip Merry Christmas, The GnuPG hackers. -- Werner Koch The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.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/20041222/7718b83a/attachment.bin From michaelnottebrock at gmx.net Thu Dec 23 00:39:39 2004 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Thu Dec 23 11:30:22 2004 Subject: GnuPG 1.9.14 released In-Reply-To: <87k6rani0k.fsf@wheatstone.g10code.de> References: <87k6rani0k.fsf@wheatstone.g10code.de> Message-ID: <200412230039.43244.michaelnottebrock@gmx.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20041223/93e04bf5/attachment.bin From wk at gnupg.org Thu Dec 23 13:22:38 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Dec 23 13:24:55 2004 Subject: GnuPG 1.9.14 released In-Reply-To: <200412230039.43244.michaelnottebrock@gmx.net> (Michael Nottebrock's message of "Thu, 23 Dec 2004 00:39:39 +0100") References: <87k6rani0k.fsf@wheatstone.g10code.de> <200412230039.43244.michaelnottebrock@gmx.net> Message-ID: <878y7pkxv5.fsf@wheatstone.g10code.de> On Thu, 23 Dec 2004 00:39:39 +0100, Michael Nottebrock said: > Unfortunately it seems one of Santa's naughtier elves snuck in some new bugs > as well. Not to unlikely. Supporting SC's Winter OS required quite some tweaks to the build system. Thanks, Werner From jvender at owensboro.net Thu Dec 23 15:26:25 2004 From: jvender at owensboro.net (Joe Vender) Date: Thu Dec 23 15:24:02 2004 Subject: Help test new HTTP/FTP code In-Reply-To: <20041222211405.GA13662@jabberwocky.com> References: <20041222211405.GA13662@jabberwocky.com> Message-ID: <200412230826250660.0035BAA0@216.135.2.37> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >On 12/22/04 at 4:14 PM David Shaw wrote: >Hi folks, > >For various reasons, we are exploring using libcurl for HTTP and FTP >access within GnuPG (specifically the gpgkeys_xxxx programs). This is >still at the evaluation stage, and is not a done deal yet. > >For those people who are occasionally tracking CVS, I would very much >appreciate it if you could sync up to today's checkins and give the >new code a whirl. Note that using libcurl is not the default >behavior, and requires a "--with-libcurl" argument to ./configure to >turn it on. Could someone please tell me exactly what I need and how to set it up so I can use the --with-libcurl option in GnuPG 1.4.1-cvs. This would be on an MinGW32/MSYS system on Windows 98. I tried downloading curl-7.12.3-win32-ssl-devel-mingw32.zip and placing the header files in c:\mingw\include, the library file libcurl.a in c:\mingw\lib and the binary curl.exe in c:\mingw\bin, but when I run ./configure --with-libcurl, it reports that libcurl isn't available. Any help would be much appreciated. I even tried getting the source, curl-7.12.3.tar.bz2, building the libcurl.a and curl.exe myself and putting them in said locations, but configure still reported that libcurl isn't available. configure:6203: checking for libcurl configure:6216: result: no configure:6219: checking whether libcurl is modern enough configure:6254: gcc -o conftest.exe -O0 -mtune=i386 -march=i386 - -mfpmath=387 -mno-mmx -mno-sse -mno-3dnow -mno-sse2 conftest.c >&5 configure:6256:23: curl/curl.h: No such file or directory configure: In function `main': configure:6262: error: `CURL_ERROR_SIZE' undeclared (first use in this function) configure:6262: error: (Each undeclared identifier is reported only once configure:6262: error: for each function it appears in.) configure:6263: error: `NULL' undeclared (first use in this function) configure:6263: error: `CURLOPT_URL' undeclared (first use in this function) configure:6264: error: `CURLOPT_WRITEFUNCTION' undeclared (first use in this function) configure:6265: error: `CURLOPT_FILE' undeclared (first use in this function) configure:6267: error: `CURLOPT_ERRORBUFFER' undeclared (first use in this function) configure:6268: error: `CURLOPT_STDERR' undeclared (first use in this function) configure:6269: error: `CURLOPT_VERBOSE' undeclared (first use in this function) configure:6257: $? = 1 configure: failed program was: | #line 6227 "configure" | /* confdefs.h. */ | | #define PACKAGE_NAME "gnupg" | #define PACKAGE_TARNAME "gnupg" | #define PACKAGE_VERSION "1.4.1-cvs" | #define PACKAGE_STRING "gnupg 1.4.1-cvs" | #define PACKAGE_BUGREPORT "bug-gnupg@gnu.org" | #define PACKAGE "gnupg" | #define VERSION "1.4.1-cvs" | #define _GNU_SOURCE 1 | #define EGD_SOCKET_NAME "" | #define USE_RSA 1 | #define USE_IDEA 1 | #define USE_CAST5 1 | #define USE_BLOWFISH 1 | #define USE_AES 1 | #define USE_TWOFISH 1 | #define USE_SHA256 1 | #define PK_UID_CACHE_SIZE 4096 | #define USE_ONLY_8DOT3 1 | #define HAVE_DRIVE_LETTERS 1 | #define USE_SIMPLE_GETTEXT 1 | #define HAVE_DOSISH_SYSTEM 1 | #define WITH_SYMBOL_UNDERSCORE 1 | #define HTTP_SUPPORT 1 | #define FTP_SUPPORT 1 | #define HAVE_LDAP_GET_OPTION 1 | #define HAVE_LDAP_SET_OPTION 1 | /* end confdefs.h. */ | #include | int | main () | { | | int x; | x=CURL_ERROR_SIZE; | curl_easy_setopt(NULL,CURLOPT_URL,NULL); | x=CURLOPT_WRITEFUNCTION; | x=CURLOPT_FILE; | /* x=CURLOPT_WRITEDATA; */ | x=CURLOPT_ERRORBUFFER; | x=CURLOPT_STDERR; | x=CURLOPT_VERBOSE; | | ; | return 0; | } configure:6277: result: no Thanks, Joe Vender -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1-cvs (MingW32) - GPGshell v3.30 iQEVAwUBQcrVbSbIfMqPbtHmAQiTrgf+Ljg2ijkuuJ/qdtRYim9gR2CUXog8/i1O FRCBwANbieywKHrGL1tx00m+ugOM0IRNEBkdhzkvTirq7l9GPiRmxcW79/yGOavU Vgl461lyavJurod/ygFyfqTcUdxTkupEn/cJGh9YaaPuHQQrCq1fCU7+grOMvJv6 KSw79OqFBl8GokwKSweIRF4xrI/6S71hUEOc/WHNz5H2B/L2EzNNVQnw4gnuDZ3y Cx7hq/NCQQ8+6euxhzwS0ushYRSkoXH+eYAJOTs5NTPcPvxAV3xlNHXIJ2QageON 3PGUikTfIISQ5RllaelWpoCrpMKHNewnupEqgLwe1FZTlf/EYbx4Wg== =u8ir -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Thu Dec 23 15:37:11 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Dec 23 15:34:04 2004 Subject: Help test new HTTP/FTP code In-Reply-To: <200412230826250660.0035BAA0@216.135.2.37> References: <20041222211405.GA13662@jabberwocky.com> <200412230826250660.0035BAA0@216.135.2.37> Message-ID: <20041223143710.GH15426@jabberwocky.com> On Thu, Dec 23, 2004 at 08:26:25AM -0600, Joe Vender wrote: > Could someone please tell me exactly what I need and how to set it > up so I can use the --with-libcurl option in GnuPG 1.4.1-cvs. This > would be on an MinGW32/MSYS system on Windows 98. > > I tried downloading curl-7.12.3-win32-ssl-devel-mingw32.zip and > placing the header files in c:\mingw\include, the library file > libcurl.a in c:\mingw\lib and the binary curl.exe in c:\mingw\bin, > but when I run ./configure --with-libcurl, it reports that libcurl > isn't available. Any help would be much appreciated. configure looks for libcurl in two steps: first, it runs the 'curl-config' script to see if it exists. You're not getting past that stage. Doesn't the win32 version of curl have a curl-config script? David From dshaw at jabberwocky.com Fri Dec 24 20:55:31 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Dec 24 20:52:39 2004 Subject: Help test new HTTP/FTP code In-Reply-To: <20041223143710.GH15426@jabberwocky.com> References: <20041222211405.GA13662@jabberwocky.com> <200412230826250660.0035BAA0@216.135.2.37> <20041223143710.GH15426@jabberwocky.com> Message-ID: <20041224195531.GD26371@jabberwocky.com> On Thu, Dec 23, 2004 at 09:37:11AM -0500, David Shaw wrote: > On Thu, Dec 23, 2004 at 08:26:25AM -0600, Joe Vender wrote: > > > Could someone please tell me exactly what I need and how to set it > > up so I can use the --with-libcurl option in GnuPG 1.4.1-cvs. This > > would be on an MinGW32/MSYS system on Windows 98. > > > > I tried downloading curl-7.12.3-win32-ssl-devel-mingw32.zip and > > placing the header files in c:\mingw\include, the library file > > libcurl.a in c:\mingw\lib and the binary curl.exe in c:\mingw\bin, > > but when I run ./configure --with-libcurl, it reports that libcurl > > isn't available. Any help would be much appreciated. > > configure looks for libcurl in two steps: first, it runs the > 'curl-config' script to see if it exists. You're not getting past > that stage. Doesn't the win32 version of curl have a curl-config > script? It seems it doesn't, so I've revamped the configure check for libcurl to not require curl-config. Could you try again? Note that curl header files live in a subdirectory: it should be c:\mingw\include\curl\curl.h and not c:\mingw\include\curl.h David From jvender at owensboro.net Sat Dec 25 12:47:06 2004 From: jvender at owensboro.net (Joe Vender) Date: Sat Dec 25 12:44:28 2004 Subject: Help test new HTTP/FTP code In-Reply-To: <20041224195531.GD26371@jabberwocky.com> References: <20041222211405.GA13662@jabberwocky.com> <200412230826250660.0035BAA0@216.135.2.37> <20041223143710.GH15426@jabberwocky.com> <20041224195531.GD26371@jabberwocky.com> Message-ID: <200412250547060200.000A3AE7@216.135.2.37> Thanks for the info, David. Sorry that I didn't get back to you sooner. Christmas has me away from the computer. You're right. I don't see a curl-config file in the windows version. I've tried downloading the source and doing a ./configure to generate the file, but keep running into road blocks. First, I needed g++, g77 openssl (for ssl support), etc. Not enough time to work through the kinks right now. I'll grab the cvs source and try again. I figured out the subdir thing with the curl header files. I assume that the libcurl.a library and other library files goe into the normal path, c:\mingw\lib\libcurl.a, and the binary files go into c:\mingw\bin? That's what I'll try, anyway. Get back to you as soon as I can. Merry Christmas. Regards, Joe Vender *********** REPLY SEPARATOR *********** On 12/24/04 at 2:55 PM David Shaw wrote: >On Thu, Dec 23, 2004 at 09:37:11AM -0500, David Shaw wrote: >> On Thu, Dec 23, 2004 at 08:26:25AM -0600, Joe Vender wrote: >> >> > Could someone please tell me exactly what I need and how to set it >> > up so I can use the --with-libcurl option in GnuPG 1.4.1-cvs. This >> > would be on an MinGW32/MSYS system on Windows 98. >> > >> > I tried downloading curl-7.12.3-win32-ssl-devel-mingw32.zip and >> > placing the header files in c:\mingw\include, the library file >> > libcurl.a in c:\mingw\lib and the binary curl.exe in c:\mingw\bin, >> > but when I run ./configure --with-libcurl, it reports that libcurl >> > isn't available. Any help would be much appreciated. >> >> configure looks for libcurl in two steps: first, it runs the >> 'curl-config' script to see if it exists. You're not getting past >> that stage. Doesn't the win32 version of curl have a curl-config >> script? > >It seems it doesn't, so I've revamped the configure check for >libcurl to not require curl-config. Could you try again? Note that >curl header files live in a subdirectory: it should be >c:\mingw\include\curl\curl.h and not c:\mingw\include\curl.h > From jvender at owensboro.net Sat Dec 25 13:08:54 2004 From: jvender at owensboro.net (Joe Vender) Date: Sat Dec 25 13:06:09 2004 Subject: Help test new HTTP/FTP code In-Reply-To: <20041224195531.GD26371@jabberwocky.com> References: <20041222211405.GA13662@jabberwocky.com> <200412230826250660.0035BAA0@216.135.2.37> <20041223143710.GH15426@jabberwocky.com> <20041224195531.GD26371@jabberwocky.com> Message-ID: <200412250608540200.001E3114@216.135.2.37> I apologize for the word wrap problem when posting to this list. I've never been able to get Calypso to wrap the way I want it to. Qoutes get all messed up. I hope this works. If not, I'll just have to go to another emailer when posting to this list, since it doesn't understand qouted printable encoding. *********** REPLY SEPARATOR *********** On 12/24/04 at 2:55 PM David Shaw wrote: >On Thu, Dec 23, 2004 at 09:37:11AM -0500, David Shaw wrote: >> On Thu, Dec 23, 2004 at 08:26:25AM -0600, Joe Vender wrote: >> >> > Could someone please tell me exactly what I need and how to set it >> > up so I can use the --with-libcurl option in GnuPG 1.4.1-cvs. This >> > would be on an MinGW32/MSYS system on Windows 98. >> > >> > I tried downloading curl-7.12.3-win32-ssl-devel-mingw32.zip and >> > placing the header files in c:\mingw\include, the library file >> > libcurl.a in c:\mingw\lib and the binary curl.exe in c:\mingw\bin, >> > but when I run ./configure --with-libcurl, it reports that libcurl >> > isn't available. Any help would be much appreciated. >> >> configure looks for libcurl in two steps: first, it runs the >> 'curl-config' script to see if it exists. You're not getting past >> that stage. Doesn't the win32 version of curl have a curl-config >> script? > >It seems it doesn't, so I've revamped the configure check for >libcurl to not require curl-config. Could you try again? Note that >curl header files live in a subdirectory: it should be >c:\mingw\include\curl\curl.h and not c:\mingw\include\curl.h > From jvender at owensboro.net Sat Dec 25 17:45:02 2004 From: jvender at owensboro.net (Joe Vender) Date: Sat Dec 25 17:42:20 2004 Subject: Help test new HTTP/FTP code In-Reply-To: <20041224195531.GD26371@jabberwocky.com> References: <20041222211405.GA13662@jabberwocky.com> <200412230826250660.0035BAA0@216.135.2.37> <20041223143710.GH15426@jabberwocky.com> <20041224195531.GD26371@jabberwocky.com> Message-ID: <200412251045020310.0043077D@216.135.2.37> >On 12/24/04 at 2:55 PM David Shaw wrote: >> configure looks for libcurl in two steps: first, it runs the >> 'curl-config' script to see if it exists. You're not getting past >> that stage. Doesn't the win32 version of curl have a curl-config >> script? > >It seems it doesn't, so I've revamped the configure check for >libcurl to not require curl-config. Could you try again? Note that >curl header files live in a subdirectory: it should be >c:\mingw\include\curl\curl.h and not c:\mingw\include\curl.h > >David I'm not having much luck with this. I've tried using the libcurl.a that comes with curl-7.12.3-win32-ssl-devel-mingw32.zip and also tried generating my own from the source, but ./configure doesn't seem to like any of it. It keeps seeing libcurl as unusable. configure:6265: checking for curl-config configure:6298: result: no configure:6374: checking whether libcurl is usable configure:6413: gcc -o conftest.exe -O0 -mtune=i386 -march=i386 -mfpmath=387 -mno-mmx -mno-sse -mno-3dnow -mno-sse2 -static -lcurl conftest.c >&5 D:/TEMP/ccelrNfb.o(.text+0x37):conftest.c: undefined reference to `_imp__curl_easy_setopt' collect2: ld returned 1 exit status configure:6416: $? = 1 configure: failed program was: | #line 6385 "configure" | /* confdefs.h. */ | | #define PACKAGE_NAME "gnupg" | #define PACKAGE_TARNAME "gnupg" | #define PACKAGE_VERSION "1.4.1-cvs" | #define PACKAGE_STRING "gnupg 1.4.1-cvs" | #define PACKAGE_BUGREPORT "bug-gnupg@gnu.org" | #define PACKAGE "gnupg" | #define VERSION "1.4.1-cvs" | #define _GNU_SOURCE 1 | #define EGD_SOCKET_NAME "" | #define USE_RSA 1 | #define USE_IDEA 1 | #define USE_CAST5 1 | #define USE_BLOWFISH 1 | #define USE_AES 1 | #define USE_TWOFISH 1 | #define USE_SHA256 1 | #define PK_UID_CACHE_SIZE 4096 | #define USE_ONLY_8DOT3 1 | #define HAVE_DRIVE_LETTERS 1 | #define USE_SIMPLE_GETTEXT 1 | #define HAVE_DOSISH_SYSTEM 1 | #define WITH_SYMBOL_UNDERSCORE 1 | #define HAVE_LDAP_GET_OPTION 1 | #define HAVE_LDAP_SET_OPTION 1 | /* end confdefs.h. */ | #include | int | main () | { | | /* Try and use a few common options to force a failure if we are | missing symbols or can't link. */ | int x; | curl_easy_setopt(NULL,CURLOPT_URL,NULL); | x=CURL_ERROR_SIZE; | x=CURLOPT_WRITEFUNCTION; | x=CURLOPT_FILE; | x=CURLOPT_ERRORBUFFER; | x=CURLOPT_STDERR; | x=CURLOPT_VERBOSE; | | ; | return 0; | } configure:6439: result: no Oh, well... Regards, Joe From dshaw at jabberwocky.com Sat Dec 25 18:21:59 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Sat Dec 25 18:18:56 2004 Subject: Help test new HTTP/FTP code In-Reply-To: <200412251045020310.0043077D@216.135.2.37> References: <20041222211405.GA13662@jabberwocky.com> <200412230826250660.0035BAA0@216.135.2.37> <20041223143710.GH15426@jabberwocky.com> <20041224195531.GD26371@jabberwocky.com> <200412251045020310.0043077D@216.135.2.37> Message-ID: <20041225172159.GH26371@jabberwocky.com> On Sat, Dec 25, 2004 at 10:45:02AM -0600, Joe Vender wrote: > >On 12/24/04 at 2:55 PM David Shaw wrote: > > >> configure looks for libcurl in two steps: first, it runs the > >> 'curl-config' script to see if it exists. You're not getting past > >> that stage. Doesn't the win32 version of curl have a curl-config > >> script? > > > >It seems it doesn't, so I've revamped the configure check for > >libcurl to not require curl-config. Could you try again? Note that > >curl header files live in a subdirectory: it should be > >c:\mingw\include\curl\curl.h and not c:\mingw\include\curl.h > > > >David > > I'm not having much luck with this. I've tried using the libcurl.a that > comes with curl-7.12.3-win32-ssl-devel-mingw32.zip and also tried > generating my own from the source, but ./configure doesn't seem to like any > of it. It keeps seeing libcurl as unusable. Well, autoconf meets the most important test, which is that it detects that state properly and keeps going (and builds with the standard http code). That doesn't help you getting the curl stuff up though. I'm not actually sure why you're having problems. What error did you get when you tried to build and install your own curl rather than use the precompiled dll from the curl people? David From Sven.Hartrumpf at fernuni-hagen.de Mon Dec 27 09:06:25 2004 From: Sven.Hartrumpf at fernuni-hagen.de (Sven.Hartrumpf@fernuni-hagen.de) Date: Mon Dec 27 11:40:11 2004 Subject: Can gpg -e be fast enough for backup on DV tapes? Message-ID: <20041227.090625.74754124.Sven.Hartrumpf@fernuni-hagen.de> Hi all. I do backups along the following line: star ... | rsbep ... | dvbackup --prefix=125 |dvconnect -s (star is a better tar; rsbep adds redundancy to cope with tape errors; dvbackup allows to use digital video tapes (in your camcorder) as backup media). Very nice solution so far. But if I add "gpg -e" before rsbep pipes break probably because "gpg -e" is too slow to maintain the required speed (Firewire speed). How can I solve this problem? (I'm using gnupg 1.4.0 on a 1.6Mhz machine.) Greetings Sven -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20041227/c53f86dd/attachment.bin From D-Mail at gmx.net Sat Dec 25 20:50:30 2004 From: D-Mail at gmx.net (David Dahlberg) Date: Mon Dec 27 11:58:01 2004 Subject: Non-optimal program output on symm. decryption of old-style PGP data Message-ID: <1289367037.20041225205030@sub-etha.org> Hello *, Some time ago I tryed en- and decrypting some file symmetrically in the old PGP packet style (v3?) by using the following commands: |gpg -o --rfc1991 --cipher idea --symmetric |gpg -o --decrypt which I thougt should be okay, since the decrypt command uses to reply "gpg: assuming IDEA encrypted data" and this is indeed IDEA encrypted material. But for some reason it didn't work :-( Conclusion: The above encryption line uses the default hash algorithm (SHA), the decryption routine guesses CAST5 (but doesn't say it), while I thought plain symmetric encryption doesn't need any hashing. (See also et seqq. on /Z-NETZ/ALT/PGP/ALLGEMEIN, resp. (both German) ) My suggestion for improvement'd be to change that decryption cipher-guess line from "assuming IDEA encrypted data" to something like "assuming IDEA/CAST5": ,--------------[ mainproc.c ]--------- | static void | proc_encrypted( CTX c, PACKET *pkt ) | { [..] | write_status( STATUS_BEGIN_DECRYPTION ); | | /*log_debug("dat: %sencrypted data\n", c->dek?"":"conventional ");*/ | if( opt.list_only ) | result = -1; | else if( !c->dek && !c->last_was_session_key ) { | int algo; | STRING2KEY s2kbuf, *s2k = NULL; | | /* assume this is old style conventional encrypted data */ | if ( (algo = opt.def_cipher_algo)) | log_info (_("assuming %s encrypted data\n"), | cipher_algo_to_string(algo)); | else if ( check_cipher_algo(CIPHER_ALGO_IDEA) ) { | algo = opt.def_cipher_algo; | if (!algo) | algo = opt.s2k_cipher_algo; | idea_cipher_warn(1); | log_info (_("IDEA cipher unavailable, " | "optimistically attempting to use %s instead\n"), | cipher_algo_to_string(algo)); | } | else { | algo = CIPHER_ALGO_IDEA; | if (!opt.def_digest_algo) { | /* If no digest is given we assume MD5 */ | s2kbuf.mode = 0; | s2kbuf.hash_algo = DIGEST_ALGO_MD5; | s2k = &s2kbuf; | } | log_info (_("assuming %s encrypted data\n"), "IDEA"); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | } TIA and pardon my bad English David PS: http://bugs.gnupg.org/cgi-bin/gnatsweb.pl?debug=&database=default&cmd=create didn't work with Opera/7.54, WinXP; saying the following on "Submit": |Software error: |Malformed multipart POST |For help, please send mail to this site's webmaster, giving this error message |and the time and date of the error. :-( From fw at deneb.enyo.de Mon Dec 27 13:33:06 2004 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon Dec 27 13:29:28 2004 Subject: Can gpg -e be fast enough for backup on DV tapes? In-Reply-To: <20041227.090625.74754124.Sven.Hartrumpf@fernuni-hagen.de> (Sven Hartrumpf's message of "Mon, 27 Dec 2004 09:06:25 +0100 (CET)") References: <20041227.090625.74754124.Sven.Hartrumpf@fernuni-hagen.de> Message-ID: <87vfanhqf1.fsf@deneb.enyo.de> * Sven Hartrumpf: > Very nice solution so far. But if I add "gpg -e" before rsbep > pipes break probably because "gpg -e" is too slow to maintain the > required speed (Firewire speed). > > How can I solve this problem? Try to turn off compression. (It would be nice if GnuPG supported LZO compression, BTW. 8-) From wk at gnupg.org Tue Dec 28 11:54:32 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Dec 28 12:27:01 2004 Subject: [Announce] GnuPG 1.2.7 released Message-ID: <87wtv2g0bb.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From rjh at sixdemonbag.org Wed Dec 29 19:25:46 2004 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed Dec 29 19:21:59 2004 Subject: C#, GnuPG and /dev/tty Message-ID: <41D2F6AA.2010504@sixdemonbag.org> While hacking together a C# script to automate some key management tasks, I discovered some behavior which is radically different on Windows as opposed to UNIX. It appears to be a GnuPG difference, and not a CLR problem. Here's the essentials of it: A new ProcessStateInfo object is created which contains the necessary information about the GnuPG process--path, executable name, things like that, along with RedirectStandardOutput set to true. A new Process is created, passing our ProcessStateInfo object into its constructor, and a new StreamReader is hooked up to our process's StandardOutput accessor. So far, everything works great. I'm able to grab GnuPG's output, parse it, and do cool things. Where things break is when I set RedirectStandardInput to be true and hook a StreamWriter up to it. Then I get different behavior depending on which OS is in use. On UNIX I get an error message about how it can't open /dev/tty, and GnuPG aborts. On Windows, everything works fine. I've tried passing --no-tty, but that causes it to fail on both platforms. Can someone help me figure out precisely what I'm doing wrong here? It must be something simple. From npcole at yahoo.co.uk Thu Dec 30 15:29:04 2004 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Thu Dec 30 15:26:00 2004 Subject: Missing info in --with-colons Message-ID: <20041230142904.33122.qmail@web25408.mail.ukl.yahoo.com> (my apologies if this is a repost - I hope it isn't). Am I correct that there is information that it is not possible to extract from a --with-colons listing? For example, it does not appear to be possible to have the keyserver url of a key displayed in the --with-colons output. Best wishes, N. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com From npcole at yahoo.co.uk Thu Dec 30 15:55:43 2004 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Thu Dec 30 15:52:26 2004 Subject: key capabilities Message-ID: <20041230145543.14067.qmail@web25406.mail.ukl.yahoo.com> My old key (created originally with PGP) is marked as being capable of signing, certifying and authenticating (with the subkey for Encrypting). GPG only marks the keys it creates as suitable for signing and certifying. Is there a rationale for this minor incompatibility? I know that there are some authentication systems (a modified sshd, for example) that do use openpgp keys - presumably they should only use keys flagged as suitable for this use. Best, N. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com From dshaw at jabberwocky.com Thu Dec 30 16:17:42 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Dec 30 17:35:43 2004 Subject: Missing info in --with-colons In-Reply-To: <20041230142904.33122.qmail@web25408.mail.ukl.yahoo.com> References: <20041230142904.33122.qmail@web25408.mail.ukl.yahoo.com> Message-ID: <20041230151742.GZ30683@jabberwocky.com> On Thu, Dec 30, 2004 at 02:29:04PM +0000, Nicholas Cole wrote: > (my apologies if this is a repost - I hope it isn't). > > Am I correct that there is information that it is not > possible to extract from a --with-colons listing? For > example, it does not appear to be possible to have the > keyserver url of a key displayed in the --with-colons > output. All information can be gotten from --with-colons. Some pieces of information you need to ask for explicitly, though. Keyserver URLs can be very large, and there can be more than one of them which would make the regular --with-colons listing very large and be inconvenient for those people who didn't want them. To get keyserver URLs in the listing, add: --list-options show-sig-subpackets=24 to your list command. You'll also need to use --list-sigs instead of --list-keys since keyserver URLs live on signatures, not on keys. David From dshaw at jabberwocky.com Thu Dec 30 16:44:32 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Dec 30 17:35:49 2004 Subject: key capabilities In-Reply-To: <20041230145543.14067.qmail@web25406.mail.ukl.yahoo.com> References: <20041230145543.14067.qmail@web25406.mail.ukl.yahoo.com> Message-ID: <20041230154432.GA30683@jabberwocky.com> On Thu, Dec 30, 2004 at 02:55:43PM +0000, Nicholas Cole wrote: > My old key (created originally with PGP) is marked as > being capable of signing, certifying and > authenticating (with the subkey for Encrypting). GPG > only marks the keys it creates as suitable for signing > and certifying. > > Is there a rationale for this minor incompatibility? I > know that there are some authentication systems (a > modified sshd, for example) that do use openpgp keys - > presumably they should only use keys flagged as > suitable for this use. The difference is that PGP doesn't mark keys with capabilities at all. When reading these unmarked keys, GnuPG must resort to giving the key all capabilities for that key type since it cannot know what the intended use was for that key. If you want to make a key where you pick what flags are set, generate the key with --expert set. This enables an option where you can set any flags you like. David From alex at bofh.net.pl Thu Dec 30 17:29:46 2004 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Thu Dec 30 17:37:59 2004 Subject: key capabilities In-Reply-To: <20041230155726.85160.qmail@web25404.mail.ukl.yahoo.com> References: <20041230150614.GF25156@syjon.fantastyka.net> <20041230155726.85160.qmail@web25404.mail.ukl.yahoo.com> Message-ID: <20041230162946.GH25156@syjon.fantastyka.net> Nicholas Cole wrote: > > > My old key (created originally with PGP) is marked as being capable of > > > signing, certifying and authenticating (with the subkey for > > > Encrypting). GPG only marks the keys it creates as suitable for > > > signing and certifying. > > Is this a PGP 2.x key? > No - it's a DH/DSS one created with PGP 5.5 or 6 I guess this would be another PGP proprietary feature since there is no such thing as 'authenticating' OpenPGP key AFAIR. Encryption and signing are direct cryptographic operation while authentication is very environment- and protocol- dependent. It is X.509 certificates that have field that says if what you are allowed to do with them (supposedly to make it forbidden to use your cheap e-mail signing certificate instead of expensive authentication certificate or vice versa), but OpenPGP keys are just key material framed in some metadata. It is cryptography that makes a key (and algorithm) feasible for signing or encryption. And this 'authetication' is probably a combination of those. But there is no such thing as 'authenticating' OpenPGP key, if I rember correctly (correct this if I am wrong). Alex -- mors ab alto 0x46399138 From npcole at yahoo.co.uk Thu Dec 30 19:21:29 2004 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Thu Dec 30 21:45:46 2004 Subject: key capabilities In-Reply-To: <20041230154432.GA30683@jabberwocky.com> Message-ID: <20041230182129.6819.qmail@web25402.mail.ukl.yahoo.com> > The difference is that PGP doesn't mark keys with > capabilities at all. Why am I not surprised? :-) Thank you for the explanation, and thank you as ever for the --expert option! Best wishes, N. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com From alex at bofh.net.pl Thu Dec 30 16:06:15 2004 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Thu Dec 30 22:01:45 2004 Subject: key capabilities In-Reply-To: <20041230145543.14067.qmail@web25406.mail.ukl.yahoo.com> References: <20041230145543.14067.qmail@web25406.mail.ukl.yahoo.com> Message-ID: <20041230150614.GF25156@syjon.fantastyka.net> On Thu, Dec 30, 2004 at 02:55:43PM +0000, Nicholas Cole wrote: > My old key (created originally with PGP) is marked as > being capable of signing, certifying and > authenticating (with the subkey for Encrypting). GPG > only marks the keys it creates as suitable for signing > and certifying. Is this a PGP 2.x key? alex -- mors ab alto 0x46399138 From npcole at yahoo.co.uk Thu Dec 30 19:18:28 2004 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Fri Dec 31 00:14:27 2004 Subject: Missing info in --with-colons In-Reply-To: <20041230151742.GZ30683@jabberwocky.com> Message-ID: <20041230181828.12984.qmail@web25404.mail.ukl.yahoo.com> --- David Shaw wrote: > To get keyserver URLs in the listing, add: > > --list-options show-sig-subpackets=24 Thanks very much, David. I hadn't tried that - just the --list-options show-keyserver-urls option. Cheers, N. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com From Sven.Hartrumpf at fernuni-hagen.de Thu Dec 30 22:27:51 2004 From: Sven.Hartrumpf at fernuni-hagen.de (Sven.Hartrumpf@fernuni-hagen.de) Date: Fri Dec 31 12:01:16 2004 Subject: Can gpg -e be fast enough for backup on DV tapes? In-Reply-To: <87vfanhqf1.fsf@deneb.enyo.de> References: <20041227.090625.74754124.Sven.Hartrumpf@fernuni-hagen.de> <87vfanhqf1.fsf@deneb.enyo.de> Message-ID: <20041230.222751.74726065.Sven.Hartrumpf@fernuni-hagen.de> On 27 Dec 2004, Florian Weimer wrote: > > Very nice solution so far. But if I add "gpg -e" before rsbep > > pipes break probably because "gpg -e" is too slow to maintain the > > required speed (Firewire speed). > > > > How can I solve this problem? > > Try to turn off compression. This (adding -z 0 to the gpg call) solved my problem! Thanks a lot. > (It would be nice if GnuPG supported LZO compression, BTW. 8-) Seconded. Greetings Sven -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20041230/908c0c7d/attachment.bin