From phil.pennock at globnix.org Tue Feb 1 16:22:37 2005 From: phil.pennock at globnix.org (Phil Pennock) Date: Tue Feb 1 16:53:54 2005 Subject: File-descriptor leak in 1.4.0 hkp retrieval Message-ID: <20050201152237.GA25332@parhelion.globnix.org> Hi, I think that I've found a file-descriptor leak in the retrieval of keys via hkp, in keyserver/gpgkeys_hkp.c and verified still present in the 1.4 code, at least as of revision 1.47 (latest in that branch via the CVSWeb interface, where I double-checked). I have a shell-script wrapper around a couple of invocations of gpg which attempts to retrieve all the keys which have signed some keys, where the keyid isn't already in my public key-ring. Basically, a gpg --list-sigs, extract the not-known ones, uniqueify and pass to --recv-key. I just used this to retrieve some sigs, which asked for an unexpectedly high number of keys. That's my silly fault, but this exposed a file-descriptor leak in the HKP handling. -----------------------------< cut here >------------------------------- gpg: key xxxxxxxx: public key "xxxxxxxxxxxx " imported ?: subkeys.pgp.net: Host not found gpgkeys: HKP fetch error: Too many open files ?: subkeys.pgp.net: Host not found gpgkeys: HKP fetch error: Too many open files ?: subkeys.pgp.net: Host not found gpgkeys: HKP fetch error: Too many open files ?: subkeys.pgp.net: Host not found gpgkeys: HKP fetch error: Too many open files -----------------------------< cut here >------------------------------- Looking at the code, it seems that in keyserver/gpgkeys_hkp.c in get_key(), there's a missing call to http_close(&hd) which appears to belong at the end of the function. But I'm not a gnupg developer and don't know if this is anywhere near right. I've only looked at the code enough to identify what appears to be a likely candidate (but it doesn't look as though the fd is kept for persistence ...); sorry if this is a bogus report. Thanks, -Phil From dshaw at jabberwocky.com Tue Feb 1 21:52:37 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Feb 1 21:49:26 2005 Subject: File-descriptor leak in 1.4.0 hkp retrieval In-Reply-To: <20050201152237.GA25332@parhelion.globnix.org> References: <20050201152237.GA25332@parhelion.globnix.org> Message-ID: <20050201205237.GD28650@jabberwocky.com> On Tue, Feb 01, 2005 at 04:22:37PM +0100, Phil Pennock wrote: > gpgkeys: HKP fetch error: Too many open files > -----------------------------< cut here >------------------------------- > > Looking at the code, it seems that in keyserver/gpgkeys_hkp.c in > get_key(), there's a missing call to http_close(&hd) which appears to > belong at the end of the function. The missing http_close is certainly wrong, though due to interesting circumstances that isn't the leak in this case. The http code is actually closing the socket automatically when we reach the end of the read. However, the http_close should still be there. The leak is in the new joined ipv4/ipv6 getaddrinfo code. Some of the addresses in the subkeys.pgp.net rotation are down, and we leak a fd each time we hit one. I've fixed this in CVS. Thanks for the report! David From wk at gnupg.org Thu Feb 3 12:48:26 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Feb 3 13:27:58 2005 Subject: [Announce] release candidate for 1.4.1 available Message-ID: <87fz0dhnjp.fsf@wheatstone.g10code.de> Hi! We are pleased to announce the availability of a release candidate for the forthcoming 1.4.1 version of gnupg: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.1rc1.tar.bz2 (2709k) ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.1rc1.tar.bz2.sig A binary for Windows is also available: ftp://ftp.gnupg.org/gcrypt/alpha/binary/gnupg-w32cli-1.4.1rc1.exe (1377k) ftp://ftp.gnupg.org/gcrypt/alpha/binary/gnupg-w32cli-1.4.1rc1.exe.sig Please try these versions out and report any problems. The installer used for the Windows binary package is pretty basic right now but nevertheless a first step. In particular, selecting the language to use still needs manual interaction. We hope to improve it over time. Checksums are: 323445ee8e0c1de97243c646538d9f5dae5567ff gnupg-1.4.1rc1.tar.bz2 cda3e84f89dd7a0fd7df59e4c142e7bbb9669cb2 gnupg-w32cli-1.4.1rc1.exe Noteworthy changes since 1.4.0: * New --rfc2440-text option which controls how text is handled in signatures. This is in response to some problems seen with certain PGP/MIME mail clients and GnuPG version 1.4.0. More details about this are available at * New "import-unusable-sigs" and "export-unusable-sigs" tags for --import-options and --export-options. These are on by default, and cause GnuPG to not import or export key signatures that are not usable (e.g. expired signatures). * New experimental HTTP, HTTPS, FTP, and FTPS keyserver helper that uses the cURL library to retrieve keys. This is disabled by default, but may be enabled with the configure option --with-libcurl. Without this option, the existing HTTP code is used for HTTP, and HTTPS, FTP, and FTPS are not supported. * When running a --card-status or --card-edit and a public key is available, missing secret key stubs will be created on the fly. Details of the key are listed too. * The implicit packet dumping in double verbose mode is now send to stderr and not to stdout. * [W32] The algorithm for the default home directory changed: First we look at the environment variable GNUPGHOME, if this one is not set, we check whether the registry entry {HKCU,HKLM}\Software\GNU\GnuPG:HomeDir has been set. If this fails we use a GnuPG directory below the standard application data directory (APPDATA) of the current user. Only in the case that this directory cannot be determined, the old default of c:\gnupg will be used. The option --homedir still overrides all of them. * [W32] The locale selection under Windows changed. You need to enter the locale in the registry at HKCU\Software\GNU\GnuPG:Lang. For German you would use "de". If it is not set, GnupG falls back to HKLM. The languages files "*.mo" are expected in a directory named "gnupg.nls" below the installation directory; that directory must be stored in the registry at the same key as above with the name "Install Directory". Happy Hacking, David, Timo, 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/20050203/005c5657/attachment.pgp From atom at smasher.org Thu Feb 3 17:34:49 2005 From: atom at smasher.org (Atom Smasher) Date: Thu Feb 3 17:30:42 2005 Subject: [Announce] release candidate for 1.4.1 available In-Reply-To: <87fz0dhnjp.fsf@wheatstone.g10code.de> References: <87fz0dhnjp.fsf@wheatstone.g10code.de> Message-ID: <20050203163436.83935.qmail@smasher.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thu, 3 Feb 2005, Werner Koch wrote: > * New "import-unusable-sigs" and "export-unusable-sigs" tags for > --import-options and --export-options. These are on by > default, and cause GnuPG to not import or export key signatures > that are not usable (e.g. expired signatures). ==================== is that a typo? they're on by default... this causes gpg to import/export...? also, it seems that the "historical feature" of sending some verbose output (with multiple "-v") to stdout has been changed (dare i say "fixed?"). woo-hoo! i don't see that mentioned in the change-log. - -- ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "Because, it isn't just a stupid little mistake, Ok? You have to understand Coke's business. How does Coke make money?" "They sell syrup to bottlers." "Right. And...." "And?" "And they license the rights to print their corporate art on the cans and bottles to those bottlers. So what are those bottlers going to say after finding out they've been paying twelve years worth of licensing fees for a fraudulent copyright?" -- Bob Kolody, explaining the implications of his suit against Coca-Cola http://www.guerrillanews.com/cocakarma/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJCAlKvAAoJEAx/d+cTpVciTc8H/A6UiVgujCI7qJ5GHnFWuHnH vwF1WnuXnUIPpdQ7l36AgYQgWtgzqjdMyfuIc28v666wqUvlLWLk2EQBMbWdXkuw 4qv2hp1z/DLtTEz4n/Z7JTqnFDts52esIen1FPijrckzoQPd2hQmKVjpJOfm7Ygp jWqQRkwJ6gWSMQE0KddJPtNKLghz3ufyG1RK49PhKFLFZN6/csGnckUcfOv5+8Hf 7+o8YzRuwnOdCVNFSgaGlFygfgdMCWaPL1PnVu77EFhxHiwCbuQig6GVP41uvviW Xo9g1RMijSz5Yqu+9nh1NjWNuSrBXp0VEW3x7xTwK0itA4vNvb+1RPA5jDYK4Y0= =uizh -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Thu Feb 3 17:41:36 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Feb 3 17:38:17 2005 Subject: [Announce] release candidate for 1.4.1 available In-Reply-To: <20050203163436.83935.qmail@smasher.org> References: <87fz0dhnjp.fsf@wheatstone.g10code.de> <20050203163436.83935.qmail@smasher.org> Message-ID: <20050203164136.GA12098@jabberwocky.com> On Thu, Feb 03, 2005 at 11:34:49AM -0500, Atom Smasher wrote: > On Thu, 3 Feb 2005, Werner Koch wrote: > > > * New "import-unusable-sigs" and "export-unusable-sigs" tags for > > --import-options and --export-options. These are on by > > default, and cause GnuPG to not import or export key signatures > > that are not usable (e.g. expired signatures). > ==================== > > is that a typo? they're on by default... this causes gpg to > import/export...? Oops - that is a typo. They're OFF by default. David From ask at skmp.net Thu Feb 3 10:18:58 2005 From: ask at skmp.net (Anton) Date: Thu Feb 3 20:56:43 2005 Subject: Gpg-agent is not working! Message-ID: <200502031118.59091.ask@skmp.net> My system is FreeBSD 5.2.1-RELEASE I have installed gpgme on it and pinentry from /usr/ports/security/pinentry with option PINENTRY-GTK2=yes. In ~/.gnupg/gpg.conf I have enabled string - "use-agent". In ~/.gnupg/gpg-agent.conf I wrote this: pinentry-program /usr/local/bin/pinentry-gtk-2 no-grab default-cache-ttl 1800 In my ~/.xinitrc file I wrote this: #!/bin/sh killall gpg-agent eval "$(/usr/local/bin/gpg-agent --daemon -s)" exec startkde When KDE starts Kgpg and KMail do not says anything about wrong gpg-agent. I have file "message". There is an encrypted by my key message - "Test of GPG" in it. In shell I print: gpg --use-agent -o "decrypt" --decrypt "message" After this I see pinentry-gtk-2 window, which ask my passphrase: "You need a passphrase to unlock the secret key for user:......." After entering a passphrase I can see file "decrypt", with phrase "Test of GPG" in it. But when I try to do: gpg --use-agent -o "decrypt1" --decrypt "message" I see pinentry-gtk-2 window again! Same situation happens, when I try send singed message to myself. What's wrong? Why gpg-agent didn't cache passphrase? From henkdebruijn at wanadoo.nl Thu Feb 3 15:07:30 2005 From: henkdebruijn at wanadoo.nl (Henk de Bruijn) Date: Thu Feb 3 20:56:46 2005 Subject: [Announce] release candidate for 1.4.1 available In-Reply-To: <87fz0dhnjp.fsf@wheatstone.g10code.de> References: <87fz0dhnjp.fsf@wheatstone.g10code.de> Message-ID: <5910418497.20050203150730@wanadoo.nl> On Thu, 03 Feb 2005 12:48:26 +0100GMT (3-2-2005, 12:48 +0100, where I live), Werner Koch wrote: > We are pleased to announce the availability of a release candidate for > the forthcoming 1.4.1 version of gnupg: > ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.1rc1.tar.bz2 (2709k) > ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.1rc1.tar.bz2.sig > A binary for Windows is also available: > > ftp://ftp.gnupg.org/gcrypt/alpha/binary/gnupg-w32cli-1.4.1rc1.exe > (1377k) > > ftp://ftp.gnupg.org/gcrypt/alpha/binary/gnupg-w32cli-1.4.1rc1.exe.sig > Please try these versions out and report any problems. The installer > used for the Windows binary package is pretty basic right now but > nevertheless a first step. In particular, selecting the language to > use still needs manual interaction. We hope to improve it over time. Thanks, up and running! -- Henk ______________________________________________________________________ The Bat!? Natural Email System v3.0.1.33nl Professional on Windows XP SP2 PGPkey available at http://www.biglumber.com/x/web?qs=0x12069B93DBE6E678 Gossamer Spider Web of Trust GSWoT http://www.gswot.org/ A Progressive and Innovative Web of Trust From skeleten at shillest.net Fri Feb 4 00:11:02 2005 From: skeleten at shillest.net (Norihiko Murase) Date: Fri Feb 4 00:08:26 2005 Subject: (1.4.0) configure: add_history in -lreadline In-Reply-To: (Your message of "Wed, 26 Jan 2005 17:00:15 -0500") <20050126220015.GA11478@jabberwocky.com> References: <20050127055346.bd0c7%skeleten@shillest.net> <20050126220015.GA11478@jabberwocky.com> Message-ID: <20050204081102.14496b%skeleten@shillest.net> |From: David Shaw |Subject: (1.4.0) configure: add_history in -lreadline |Message-ID: <20050126220015.GA11478@jabberwocky.com> |Date: Wed, 26 Jan 2005 17:00:15 -0500 | |>On Thu, Jan 27, 2005 at 05:53:46AM +0900, Norihiko Murase wrote: |>> Hi, |>> I tried building Ver.1.4.0, but the detection of add_history |>> in the readline library did NOT work correctly (did say "no".) |>> |>> # According to the ChangeLog file, you modified configure.ac |>> # in CVS on 2004-12-18, so this problem may have been |>> # already fixed. |>> # # Sorry, but I can't check it because I don't have |>> # # autoconf installed. X-) |> |>It should be fixed from that checkin. I've tested it on various |>machines and it correctly detects the readline dependency. |> |>We will be releasing a 1.4.1 release candidate soon, and perhaps you |>can give it a try then. Thanks, I've tested 1.4.1rc1, which was released yesterday. It does detect correctly. Thanks, --- Norihiko Murase From skeleten at shillest.net Fri Feb 4 00:19:05 2005 From: skeleten at shillest.net (Norihiko Murase) Date: Fri Feb 4 00:16:26 2005 Subject: REPORT(configure): Unnecessary warning about the make utility In-Reply-To: (Your message of "Mon, 17 Jan 2005 11:20:27 +0100") <87wtuc1hn8.fsf@wheatstone.g10code.de> References: <20050116035937.d1a6f5%skeleten@shillest.net> <87wtuc1hn8.fsf@wheatstone.g10code.de> Message-ID: <20050204081905.1ba65e%skeleten@shillest.net> |From: Werner Koch |Subject: REPORT(configure): Unnecessary warning about the make utility |Message-ID: <87wtuc1hn8.fsf@wheatstone.g10code.de> |Date: Mon, 17 Jan 2005 11:20:27 +0100 | |>On Sun, 16 Jan 2005 03:59:37 +0900, Norihiko Murase said: |> |>> The configure script seems to check the variable MAKE; |>> however, I think it is not necessary to print out this |>> warning after checking the variable --- only writing this in |>> the document clearly is ok. |> |>I'll remove the warning from 1.4. I'm afraid that 1.4.1rc1 does complain about it still now. X-( Thanks, --- Norihiko Murase From wk at gnupg.org Fri Feb 4 11:10:50 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Feb 4 11:10:48 2005 Subject: Gpg-agent is not working! In-Reply-To: <200502031118.59091.ask@skmp.net> (ask@skmp.net's message of "Thu, 3 Feb 2005 11:18:58 +0200") References: <200502031118.59091.ask@skmp.net> Message-ID: <87ekfwab4l.fsf@wheatstone.g10code.de> On Thu, 3 Feb 2005 11:18:58 +0200, Anton said: > eval "$(/usr/local/bin/gpg-agent --daemon -s)" What version of gpg-agent are you running? 1.9.14 has a bug leading not to cache the passphrase; fixed in 1.9.15. Salam-Shalom, Werner From wk at gnupg.org Fri Feb 4 11:13:14 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Feb 4 11:10:55 2005 Subject: REPORT(configure): Unnecessary warning about the make utility In-Reply-To: <20050204081905.1ba65e%skeleten@shillest.net> (Norihiko Murase's message of "Fri, 04 Feb 2005 08:19:05 +0900") References: <20050116035937.d1a6f5%skeleten@shillest.net> <87wtuc1hn8.fsf@wheatstone.g10code.de> <20050204081905.1ba65e%skeleten@shillest.net> Message-ID: <87acqkab0l.fsf@wheatstone.g10code.de> On Fri, 04 Feb 2005 08:19:05 +0900, Norihiko Murase said: > I'm afraid that 1.4.1rc1 does complain about it still now. Okay, now removed. Thanks, Werner From n-roeser at gmx.net Fri Feb 4 11:29:17 2005 From: n-roeser at gmx.net (Nico) Date: Fri Feb 4 11:54:44 2005 Subject: Update README file in alpha/gnupg on FTP server Message-ID: <42034E7D.5080100@gmx.net> Hi! says: > Development versions of GnuPG > > Note that GnuPG 1.9.x is quite different from the older versions and under > heavy development. Most likely you want the semi-stable 1.3 version or one > of the release candidates. As 1.4 is out, this should be updated. Thanks, -- Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050204/a17d677e/signature.pgp From galaxian67 at yahoo.com Fri Feb 4 05:26:28 2005 From: galaxian67 at yahoo.com (galaxian67) Date: Fri Feb 4 12:02:13 2005 Subject: Build problem: GnuPG 1.4.1rc1 on MinGW/MSYS /Windows 98 Message-ID: <20050204042628.23409.qmail@web51701.mail.yahoo.com> When attempting to build GnuPG 1.4.1rc1 on Windows 98 under MinGW/MSYS, make failed near the end (during the final dearmor stuff) with message :"The GPG.EXE file is linked to missing export SHELL32.dll:SHGetFolderPathA" The SHGetFolderPath call is made in g10/misc.c I've done some checking and found that SHGetFolderPath is found in shell32.dll under Windows 2000, but under Windows 98 its found in shfolder.dll After adding -lshfolder to the "LDADD =" line in g10/Makefile, GnuPG compiled without the fatal error and passed all 25 checks. Maybe a check should be done for the OS and the proper file linked accordingly. __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 From gnupg-devel=gnupg.org at lists.palfrader.org Mon Feb 7 07:28:14 2005 From: gnupg-devel=gnupg.org at lists.palfrader.org (Peter Palfrader) Date: Mon Feb 7 07:24:28 2005 Subject: min-cert-level and lsigs Message-ID: <20050207062814.GB9358@opium.palfrader.org> Hi, I have signed several keys locally with lsigs, usually at cert level 1 if I couldn't be bothered to do any checks other than having successfully used this key to communicate in the past. Is there a way to accept local signatures regardless of certlevel, while still ignoring 0x11 signatures by other people? Should there be? -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred. | : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `- http://www.debian.org/ From sylvain at 2001-space-odyssey.net Mon Feb 7 15:58:25 2005 From: sylvain at 2001-space-odyssey.net (Sylvain BERTRAND) Date: Mon Feb 7 16:57:01 2005 Subject: how to print calculated sha1 mac? Message-ID: <42078211.3030703@2001-space-odyssey.net> Hi, I've discovered today the great thing that is libgcrypt. I'm having troubles with displaying the calculated hash though. Below is the very simple program I wrote to calculate (and print) the SHA1 hash from a given file. Is this program correct? What can I do to make the hash printable to a file or to stdout? Thank for your help. Regards, Sylvain BERTRAND /* sha1-hash.c */ #include #include #include #define HASH_TYPE GCRY_MD_SHA1 int main (int argc, char ** argv) { char * filename = argv[1]; int c; unsigned char *hash; gcry_md_hd_t h; gcry_md_open(&h,HASH_TYPE,0); FILE * file = fopen(filename,"r"); do { c = fgetc(file); gcry_md_putc(h,c); } while (c != EOF); gcry_md_final(h); hash = gcry_md_read(h,HASH_TYPE); fclose(file); gcry_md_close(h); /* how to print? */ return 1; } From dshaw at jabberwocky.com Mon Feb 7 17:22:06 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Mon Feb 7 17:18:54 2005 Subject: min-cert-level and lsigs In-Reply-To: <20050207062814.GB9358@opium.palfrader.org> References: <20050207062814.GB9358@opium.palfrader.org> Message-ID: <20050207162206.GA30495@jabberwocky.com> On Mon, Feb 07, 2005 at 07:28:14AM +0100, Peter Palfrader wrote: > Hi, > > I have signed several keys locally with lsigs, usually at cert level 1 > if I couldn't be bothered to do any checks other than having > successfully used this key to communicate in the past. > > Is there a way to accept local signatures regardless of certlevel, while > still ignoring 0x11 signatures by other people? It's certainly easy to do. Something like this should do it (untested): Index: trustdb.c =================================================================== RCS file: /cvs/gnupg/gnupg/g10/trustdb.c,v retrieving revision 1.137 diff -u -r1.137 trustdb.c --- trustdb.c 6 Feb 2005 17:38:43 -0000 1.137 +++ trustdb.c 7 Feb 2005 16:06:59 -0000 @@ -1435,7 +1435,8 @@ continue; /* ignore self-signatures */ if (!IS_UID_SIG(sig) && !IS_UID_REV(sig)) continue; /* we only look at these signature classes */ - if(sig->sig_class>=0x11 && sig->sig_class<=0x13 && + if(sig->flags.exportable + && sig->sig_class>=0x11 && sig->sig_class<=0x13 && sig->sig_class-0x10 Should there be? That's a harder question. On the one hand, this change would make local sigs different trust-wise than exportable sigs, which is messier. On the other hand, the whole point of local sigs is that they are like a note from yourself, so they should be accepted regardless of their class. Then you get into questions about whether it violates expectations and so on. I'm rather sour on this whole 0x11 situation, and regret opening the door by adding the ability to make them in the first place. What do you think? David From gnupg-devel=gnupg.org at lists.palfrader.org Tue Feb 8 01:08:02 2005 From: gnupg-devel=gnupg.org at lists.palfrader.org (Peter Palfrader) Date: Tue Feb 8 01:04:08 2005 Subject: min-cert-level and lsigs In-Reply-To: <20050207162206.GA30495@jabberwocky.com> References: <20050207062814.GB9358@opium.palfrader.org> <20050207162206.GA30495@jabberwocky.com> Message-ID: <20050208000802.GF12664@opium.palfrader.org> On Mon, 07 Feb 2005, David Shaw wrote: > On Mon, Feb 07, 2005 at 07:28:14AM +0100, Peter Palfrader wrote: > > I have signed several keys locally with lsigs, usually at cert level 1 > > > > Is there a way to accept local signatures regardless of certlevel, while > > still ignoring 0x11 signatures by other people? > > > Should there be? > > That's a harder question. On the one hand, this change would make > local sigs different trust-wise than exportable sigs, which is > messier. On the other hand, the whole point of local sigs is that > they are like a note from yourself, so they should be accepted > regardless of their class. Then you get into questions about whether > it violates expectations and so on. > > What do you think? Hmm. I agree that handling lsigs differently from exportable sigs probably is not the right solution. It would very likely strike me as odd that GnuPG accepted my lsig x11 on key foo and make it valid, but when I sign key bar with an exportable sig x11 then it's like a no-op for the trust metrics. So maybe the solution is to accept signatures regardless of their class from implictly trusted keys? It might not be what users expect but it might just end up having the best behaviour. -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred. | : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `- http://www.debian.org/ From andrewbass at gmail.com Tue Feb 8 07:58:50 2005 From: andrewbass at gmail.com (Andrew Shcheglov) Date: Tue Feb 8 08:55:04 2005 Subject: Bugs in gnupg-1.4.0 and related packages Message-ID: <830142bd05020722585ffb6533@mail.gmail.com> When installed setuid root, gpg bails out with the error message: gpg: Ohhhh jeeee: ... this is a bug (g10.c:1758:main) secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 In file g10/g10.c, line 1758 there's a check whether real and effective uids are equal. This may be caused by grsecurity kernel patch. $ uname -a Linux bass.science.syrus.ru 2.4.25-grsec #2 Wed Mar 24 14:22:55 MSK 2004 i686 i686 i386 GNU/Linux $ grep 'GRKERNSEC' /usr/src/linux-2.4.25-grsec/.config CONFIG_GRKERNSEC=y # CONFIG_GRKERNSEC_LOW is not set # CONFIG_GRKERNSEC_MID is not set # CONFIG_GRKERNSEC_HI is not set CONFIG_GRKERNSEC_CUSTOM=y # CONFIG_GRKERNSEC_PAX_SOFTMODE is not set # CONFIG_GRKERNSEC_PAX_EI_PAX is not set # CONFIG_GRKERNSEC_PAX_PT_PAX_FLAGS is not set CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS=y # CONFIG_GRKERNSEC_PAX_HAVE_ACL_FLAGS is not set # CONFIG_GRKERNSEC_PAX_HOOK_ACL_FLAGS is not set # CONFIG_GRKERNSEC_KMEM is not set # CONFIG_GRKERNSEC_IO is not set CONFIG_GRKERNSEC_PROC_MEMMAP=y CONFIG_GRKERNSEC_HIDESYM=y CONFIG_GRKERNSEC_ACL_HIDEKERN=y CONFIG_GRKERNSEC_ACL_MAXTRIES=3 CONFIG_GRKERNSEC_ACL_TIMEOUT=30 CONFIG_GRKERNSEC_PROC=y CONFIG_GRKERNSEC_PROC_USER=y CONFIG_GRKERNSEC_PROC_ADD=y # CONFIG_GRKERNSEC_LINK is not set # CONFIG_GRKERNSEC_FIFO is not set # CONFIG_GRKERNSEC_CHROOT is not set # CONFIG_GRKERNSEC_AUDIT_GROUP is not set # CONFIG_GRKERNSEC_EXECLOG is not set # CONFIG_GRKERNSEC_RESLOG is not set # CONFIG_GRKERNSEC_CHROOT_EXECLOG is not set # CONFIG_GRKERNSEC_AUDIT_CHDIR is not set # CONFIG_GRKERNSEC_AUDIT_MOUNT is not set # CONFIG_GRKERNSEC_AUDIT_IPC is not set # CONFIG_GRKERNSEC_SIGNAL is not set # CONFIG_GRKERNSEC_FORKFAIL is not set # CONFIG_GRKERNSEC_TIME is not set CONFIG_GRKERNSEC_PROC_IPADDR=y # CONFIG_GRKERNSEC_EXECVE is not set CONFIG_GRKERNSEC_DMESG=y CONFIG_GRKERNSEC_RANDPID=y # CONFIG_GRKERNSEC_TPE is not set CONFIG_GRKERNSEC_RANDNET=y CONFIG_GRKERNSEC_RANDISN=y CONFIG_GRKERNSEC_RANDID=y CONFIG_GRKERNSEC_RANDSRC=y CONFIG_GRKERNSEC_RANDRPC=y # CONFIG_GRKERNSEC_SOCKET is not set # CONFIG_GRKERNSEC_SYSCTL is not set CONFIG_GRKERNSEC_FLOODTIME=10 CONFIG_GRKERNSEC_FLOODBURST=4 Also there're minor typos in texinfo documentation which make emacs info browser unable to display the corresponding info pages (packages affected are: libgcrypt-1.2.1 and libksba-0.9.10). See attachments for patches. -- Yours sincerely, Andrew ``Bass'' Shcheglov. -------------- next part -------------- A non-text attachment was scrubbed... Name: libgcrypt-1.2.1.patch Type: application/octet-stream Size: 332 bytes Desc: not available Url : /pipermail/attachments/20050208/6163b488/libgcrypt-1.2.1.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: libksba-0.9.10.patch Type: application/octet-stream Size: 335 bytes Desc: not available Url : /pipermail/attachments/20050208/6163b488/libksba-0.9.10.obj From wk at gnupg.org Tue Feb 8 10:11:05 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Feb 8 10:10:48 2005 Subject: Build problem: GnuPG 1.4.1rc1 on MinGW/MSYS /Windows 98 In-Reply-To: <20050204042628.23409.qmail@web51701.mail.yahoo.com> (galaxian67@yahoo.com's message of "Thu, 3 Feb 2005 20:26:28 -0800 (PST)") References: <20050204042628.23409.qmail@web51701.mail.yahoo.com> Message-ID: <877jlj76xi.fsf@wheatstone.g10code.de> On Thu, 3 Feb 2005 20:26:28 -0800 (PST), galaxian67 said: > I've done some checking and found that SHGetFolderPath > is found in shell32.dll under Windows 2000, but under > Windows 98 its found in shfolder.dll Thanks for testing. It seems that there is no wau around than to dlopen that function. Werner From wk at gnupg.org Tue Feb 8 11:02:54 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Feb 8 11:01:26 2005 Subject: Bugs in gnupg-1.4.0 and related packages In-Reply-To: <830142bd05020722585ffb6533@mail.gmail.com> (Andrew Shcheglov's message of "Tue, 8 Feb 2005 09:58:50 +0300") References: <830142bd05020722585ffb6533@mail.gmail.com> Message-ID: <87oeev5pyp.fsf@wheatstone.g10code.de> On Tue, 8 Feb 2005 09:58:50 +0300, Andrew Shcheglov said: > In file g10/g10.c, line 1758 there's a check whether real and > effective uids are equal. This may be caused by grsecurity kernel > patch. That is an extra check to make sure that privileges have been dropped at that point. > Also there're minor typos in texinfo documentation which make emacs > info browser unable to display the corresponding info pages (packages > affected are: libgcrypt-1.2.1 and libksba-0.9.10). See attachments for > patches. Thanks, Werner From andrewbass at gmail.com Tue Feb 8 13:05:57 2005 From: andrewbass at gmail.com (Andrew Shcheglov) Date: Tue Feb 8 13:02:07 2005 Subject: Bugs in gnupg-1.4.0 and related packages In-Reply-To: <87oeev5pyp.fsf@wheatstone.g10code.de> References: <830142bd05020722585ffb6533@mail.gmail.com> <87oeev5pyp.fsf@wheatstone.g10code.de> Message-ID: <830142bd050208040569e108d7@mail.gmail.com> Hello, everyone! On Tue, 08 Feb 2005 11:02:54 +0100, Werner Koch wrote: > On Tue, 8 Feb 2005 09:58:50 +0300, Andrew Shcheglov said: > > > In file g10/g10.c, line 1758 there's a check whether real and > > effective uids are equal. This may be caused by grsecurity kernel > > patch. > > That is an extra check to make sure that privileges have been dropped > at that point. Yes, I see, but isn't this check supposed to finish successfully? -- Yours sincerely, Andrew ``Bass'' Shcheglov. From wk at gnupg.org Tue Feb 8 14:58:10 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Feb 8 14:55:48 2005 Subject: Bugs in gnupg-1.4.0 and related packages In-Reply-To: <830142bd050208040569e108d7@mail.gmail.com> (Andrew Shcheglov's message of "Tue, 8 Feb 2005 15:05:57 +0300") References: <830142bd05020722585ffb6533@mail.gmail.com> <87oeev5pyp.fsf@wheatstone.g10code.de> <830142bd050208040569e108d7@mail.gmail.com> Message-ID: <87d5vb40i5.fsf@wheatstone.g10code.de> On Tue, 8 Feb 2005 15:05:57 +0300, Andrew Shcheglov said: > Yes, I see, but isn't this check supposed to finish successfully? Sure. It seems that grsecurity has properties which doesn't fit the assumptions made my GnuPG. After dropping the suid(root) privs, the effective and the real user id should be identical. Salam-Shalom, Werner From npcole at yahoo.co.uk Wed Feb 9 10:21:33 2005 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Wed Feb 9 10:18:12 2005 Subject: min-cert-level and lsigs In-Reply-To: <20050207162206.GA30495@jabberwocky.com> Message-ID: <20050209092133.88689.qmail@web25402.mail.ukl.yahoo.com> [snip] > I'm rather sour on this whole 0x11 situation, and > regret opening the > door by adding the ability to make them in the first > place. > > What do you think? Other than that the web of trust is broken (in part) because it tries to incorporate both human-readable data (about which subjective judgements should be made) and machine readable rules? That it would have been much nicer if at some point early on gpg/pgp had started asking "What checks did you make before signing this key?" and putting the user comments in a packet on the signature... Oh well. :-) I think that signatures made by ultimately trusted keys should always be accepted. I think the message "if you have signed a key with one of your own keys it will always be trusted. Everything else is extra." Is an easy one for users to understand. As you say, it is useful to have a note to yourself about the circumstances in which you signed a key. That way you could adopt a trust model for youself where you don't mark anyone else as "trusted" (so that all keys have to be signed by you to be used), but you can still say: "Ah, that key is signed by Bob and David, and they have said that they have made careful checks on this key, and I know I trust them and that they both know X, so I'll lsign this key 0x11 so that I can use it." Best, N. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com From daichi.k at aioros.ocn.ne.jp Wed Feb 9 10:23:54 2005 From: daichi.k at aioros.ocn.ne.jp (Daichi Kawahata) Date: Wed Feb 9 11:16:48 2005 Subject: [PATCH] Test process failed on IRIX Message-ID: <20050209182354.3090b982.daichi.k@aioros.ocn.ne.jp> Hi all, I've been using gpg since 1.2.6 on IRIX 6.5, recently I've upgraded 1.4.0. Build process was no problem, but some tests failed. So, I enabled some warning switch (-W -Wall -Wformat=2) with GCC 3.4.3, found there are some warnings (almost) concerned with signed vs. unsigned comparison though. This patch will fix these warnings, however I don't know the following: diff -ru gnupg-1.4.0.orig/mpi/mpi-scan.c gnupg-1.4.0/mpi/mpi-scan.c --- gnupg-1.4.0.orig/mpi/mpi-scan.c 2003-05-25 02:54:56.000000000 +0900 +++ gnupg-1.4.0/mpi/mpi-scan.c 2005-02-09 14:12:44.797195051 +0900 @@ -78,21 +78,21 @@ limb = (limb & 0x00ffffff) | (c<<24); #elif BYTES_PER_MPI_LIMB == 8 if( j == 0 ) - limb = (limb & 0xffffffffffffff00) | c; + limb = (limb & 0xffffffffffffff00ULL) | c; else if( j == 1 ) works on other platforms, seems 'ULL' is GCC extension. Anyway, 'make check' process succeeded on IRIX after modifying. PS. I've read past ML log, it seems there is announce of 1.4.1. If this patch is useless, I'll install 1.4.1. ...well any idea? Thank you. -- Daichi -------------- next part -------------- A non-text attachment was scrubbed... Name: warning_clean.diff.bz2 Type: application/octet-stream Size: 12797 bytes Desc: not available Url : /pipermail/attachments/20050209/02b7cb3f/warning_clean.diff-0001.obj From mark at stdnet.com Thu Feb 10 16:54:57 2005 From: mark at stdnet.com (Mark Riordan) Date: Thu Feb 10 17:56:06 2005 Subject: [gpgme] Windows DLL: 1.0.2 vs. 0.3.16 Message-ID: <004901c50f88$de6447d0$ad03a8c0@corp.stdnet.com> Hello. I have some questions about using GPGME in our commercial Windows application. I understand that recent versions of GPGME are released under the LGPL and hence would be allowed in a commercial app--but I have some questions anyway: 1. A few messages from October 2004 imply that the Windows version of GPGME cannot be commercially used because it uses the Qt library. I quote: "Unfortunately, we cannot use gpgme under Windows because Qt is non-GPL over there. This is why I opted to make my own code (this, and also because gpgme was not really supported on Windows anyway, but this may have changed). " http://listserver.dreamhost.com/pipermail/psi-devel-affinix.com/2004-October/000723.html "Psi cannot use gpgme on Windows due to legal reasons" http://listserver.dreamhost.com/pipermail/psi-devel-affinix.com/2004-October/000809.html Is this still true (or was it ever true)? 2. It appears that GPGME 1.0.2 is not available as a Windows DLL. However, an older version, 0.3.16, is. See: http://sylpheed-claws.sourceforge.net/win32/ The older version was released under the GPL, not the LGPL. Does the recent change in license terms from GPL to LGPL retroactively apply to this older version? I saw this note from July 2003: "We wrote GPGME from scratch; for LGPLing it we might need to replace some very small parts taken from other GNU software." http://marc.theaimsgroup.com/?l=gnupg-devel&m=105880397529494&w=2 implying that the older version might not be available under the LGPL. By the way, we would be willing to pay a fee to get a Win32 DLL version of GPGME 1.0.2. Regards, Mark Riordan Standard Networks ******************* PLEASE NOTE ******************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From wk at gnupg.org Thu Feb 10 19:27:16 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Feb 10 19:25:51 2005 Subject: [gpgme] Windows DLL: 1.0.2 vs. 0.3.16 In-Reply-To: <004901c50f88$de6447d0$ad03a8c0@corp.stdnet.com> (Mark Riordan's message of "Thu, 10 Feb 2005 09:54:57 -0600") References: <004901c50f88$de6447d0$ad03a8c0@corp.stdnet.com> Message-ID: <874qgkp8xn.fsf@wheatstone.g10code.de> On Thu, 10 Feb 2005 09:54:57 -0600, Mark Riordan said: > Hello. I have some questions about using GPGME in our > commercial Windows application. I understand that recent versions [Running a Free Software business, I have to mention that commercial is not the opposite of Free Software. In fact our software is commercial Free Software. I presume that you meant proprietary software.] > 1. A few messages from October 2004 imply that the Windows version > of GPGME cannot be commercially used because it uses the Qt library. gpgme itself is independent from Qt. > I quote: > "Unfortunately, we cannot use gpgme under Windows because Qt is non-GPL over > there. This is why I opted to make my own code (this, and also because A few days ago Trolltech announced that future Qt versions will be GPL on Windows too. > "Psi cannot use gpgme on Windows due to legal reasons" > http://listserver.dreamhost.com/pipermail/psi-devel-affinix.com/2004-October/000809.html That is not anymore true because GPGME is now available under the LGPL and thus compatible with QT and all other software. There is however the practical need to use gpgme as a DLL with non-GPL compatible software to satisfy the terms of LGPL. The other option would be to provide a way to relink the application statically (similar what Novell did with Netware before version 3). > The older version was released under the GPL, not the LGPL. > Does the recent change in license terms from GPL to LGPL > retroactively apply to this older version? I saw this note > from July 2003: No, it does not. We don't suggest the use of the old versions anymore and we don't want to spend time maintaining any version below 1.0. > By the way, we would be willing to pay a fee to get a > Win32 DLL version of GPGME 1.0.2. Please contact me at wk at g10code.com to talk about this. Hth, Werner From mike at halcrow.us Thu Feb 10 22:03:53 2005 From: mike at halcrow.us (Michael Halcrow) Date: Thu Feb 10 22:42:47 2005 Subject: Import/export of GnuPG keys w/ OpenSSL Message-ID: <20050210210353.GA23447@halcrow.us> I am writing a cryptographic filesystem that I would like to integrate with GnuPG keyrings. To start out, I would like to grab RSA keypairs from the GnuPG keyring, the private key via a PAM module (using the login credential to decrypt the private key in that keyring) and the public key via the request-key kernel callback function, store them in OpenSSL key_st structs, and import them into the kernel keyring in their PEM-encoded format (what you get from PEM_write_RSAPrivateKey). I am hoping that there is a utility out there that will take the .gpg key blocks and convert them into a set of RSA key blocks, each of which is importable with OpenSSL functions like PEM_read_RSAPrivateKey. Unless there is a more straightforward way to go about doing this (I am always open to suggestions). Thanks, Mike .___________________________________________________________________. Michael A. Halcrow Security Software Engineer, IBM Linux Technology Center GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20050210/519efb08/attachment.pgp From ms419 at freezone.co.uk Thu Feb 10 19:56:00 2005 From: ms419 at freezone.co.uk (ms419@freezone.co.uk) Date: Fri Feb 11 00:27:05 2005 Subject: [PATCH] hkp path Message-ID: <20050210185600.GB21347@fis.lat> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 242 bytes Desc: Digital signature Url : /pipermail/attachments/20050210/c5c308dd/attachment.pgp From dshaw at jabberwocky.com Fri Feb 11 02:11:15 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Feb 11 04:46:52 2005 Subject: [Announce] Attack against OpenPGP encryption Message-ID: <20050211011115.GD1476@jabberwocky.com> 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 dshaw at jabberwocky.com Fri Feb 11 02:00:17 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Feb 11 04:49:00 2005 Subject: [Announce] Attack against OpenPGP encryption Message-ID: <20050211010017.GC1476@jabberwocky.com> 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 Fri Feb 11 09:54:41 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Feb 11 09:50:56 2005 Subject: Import/export of GnuPG keys w/ OpenSSL In-Reply-To: <20050210210353.GA23447@halcrow.us> (Michael Halcrow's message of "Thu, 10 Feb 2005 15:03:53 -0600") References: <20050210210353.GA23447@halcrow.us> Message-ID: <87wttfmq7i.fsf@wheatstone.g10code.de> On Thu, 10 Feb 2005 15:03:53 -0600, Michael Halcrow said: > I am hoping that there is a utility out there that will take the .gpg > key blocks and convert them into a set of RSA key blocks, each of > which is importable with OpenSSL functions like You need to read the keyring and store the parameters into the secret key structure. Then use code like kparms[0] = sk.n; kparms[1] = sk.e; kparms[2] = sk.d; kparms[3] = sk.q; kparms[4] = sk.p; kparms[5] = gcry_mpi_snew (0); /* compute d mod (p-1) */ gcry_mpi_sub_ui (kparms[5], kparms[3], 1); gcry_mpi_mod (kparms[5], sk.d, kparms[5]); kparms[6] = gcry_mpi_snew (0); /* compute d mod (q-1) */ gcry_mpi_sub_ui (kparms[6], kparms[4], 1); gcry_mpi_mod (kparms[6], sk.d, kparms[6]); kparms[7] = sk.u; kparms[8] = NULL; to convert the representation to the OpenSSL one. The snippet above is for converting to a pkcs#12 thing which is IIRC the same as the one used by OpenSSL. You find in memory parsing code in gnupg-1.9/kbx/keybox-openpgp.c - however it does not yet handle secret keys. The full parsing code is in g10/parse-packet.c . Shalom-Salam, Werner From twhitehe at uwo.ca Thu Feb 10 18:49:57 2005 From: twhitehe at uwo.ca (Tyson Whitehead) Date: Fri Feb 11 10:09:58 2005 Subject: gpg-agent terminating on child termination Message-ID: <200502101250.02015.twhitehe@uwo.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I noticed that both gpg-agent and ssh-agent support forking off a command with the appropriate environment variables set. However, ssh-agent watches the child process and terminates itself after it quits, while gpg-agent does not seem to. I'm no expert on the issues here, but I think this would be a nice feature to have in gpg-agent as well. It ensures the user that gpg-agent will only run for the length of the child process (X session, mail program, whatever) -- even when things go wrong. Thanks! -T - -- Tyson Whitehead (-twhitehe@uwo.ca -- WSC-) Computer Engineer Dept. of Applied Mathematics, Graduate Student- Applied Mathematics University of Western Ontario, GnuPG Key ID# 0x8A2AB5D8 London, Ontario, Canada -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCC57JRXbLmIoqtdgRAmPDAJ9KSaDpnRikKYsgYq0HCaC7qr+p4QCg5wRZ RmwuE1BXk/6LW6WGPz03KYk= =xpA+ -----END PGP SIGNATURE----- From wk at gnupg.org Fri Feb 11 11:29:43 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Feb 11 11:25:50 2005 Subject: gpg-agent terminating on child termination In-Reply-To: <200502101250.02015.twhitehe@uwo.ca> (Tyson Whitehead's message of "Thu, 10 Feb 2005 12:49:57 -0500") References: <200502101250.02015.twhitehe@uwo.ca> Message-ID: <87is4zmlt4.fsf@wheatstone.g10code.de> On Thu, 10 Feb 2005 12:49:57 -0500, Tyson Whitehead said: > I noticed that both gpg-agent and ssh-agent support forking off a command > with the appropriate environment variables set. However, ssh-agent watches > the child process and terminates itself after it quits, while gpg-agent does > not seem to. You are right. I only use gpg-agent in the background so I forgot about this. Will put it ontop the TODO list. Thanks for remining me, Werner From james.fleming at electronic-quill.net Sat Feb 12 12:32:25 2005 From: james.fleming at electronic-quill.net (James Fleming) Date: Sat Feb 12 14:10:39 2005 Subject: Bug report Message-ID: <20050212113225.GA20571@electronic-quill.net> As I'm not subscribed, I'm not expecting much of a response. However, it seemed only reasonable to report this, in case it's of value. I've just installed gnupg-1.4.0 on a somewhat-modified Fedora 2 system, and it broke on the first key I tried: user$ /opt/pkgs/gnupg-1.2.6/bin/gpg --verify /opt/sourcery/crypto/gnupg-1.4.0.tar.bz2.sig gpg: Signature made Thu Dec 16 21:50:52 2004 EST using DSA key ID 57548DCD gpg: Good signature from "Werner Koch (gnupg sig) " gpg: Note: This key has expired! Primary key fingerprint: 6BD9 050F D8FC 941B 4341 2DCC 68B7 AB89 5754 8DCD Well? I am waiting! gpg --verify /opt/sourcery/crypto/gnupg-1.4.0.tar.bz2.sig gpg: Ohhhh jeeee: ... this is a bug (g10.c:1758:main) secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 Aborted The configure options used were: ./configure --prefix=/opt/pkgs/gnupg-1.4.0 --enable-m-guard --enable-selinux-support --with-capabilities The kernel is 2.6.8.1, in case that's a factor. This seems like a good opportunity also to thank the team for all your work. It's an excellent product that's been working nicely for me for quite some time now. Kind regards, James Fleming -- Stupidity killed the cat. Curiosity was framed. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050212/8f12552f/attachment.pgp From ajgpgml at tesla.inka.de Sat Feb 12 13:57:38 2005 From: ajgpgml at tesla.inka.de (Andreas John) Date: Sat Feb 12 14:27:35 2005 Subject: GnuPG1.4.1rc1 - Win98 Message-ID: <002d01c51102$7a1db060$7ad255d9@tesla> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Not sure if this is already known, but RC1 isn't starting on Win98 due to missing exports of SHGetFolderPathA from shell32.dll. The function is actually exported by SHFolders.dll as stated in MSDN: SHGetFolderPath [...] Remarks This function is a superset of SHGetSpecialFolderPath, included with earlier versions of the shell. It is implemented in a redistributable DLL, SHFolder.dll, that also simulates many of the new shell folders on older platforms such as Windows 95, Windows 98, and Windows NT 4.0. This DLL always calls the current platform's version of this function. If that fails, it will try to simulate the appropriate behavior. Bye! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) - GPGrelay v0.956 iD8DBQFCDf1ZnTiKrQObWqkRAt5AAJ4sgwIRh8JOOkZ5bpLRKxgmr6kajQCeMoqj lgNChFn1f6uB4aJZIvOKhso= =13tr -----END PGP SIGNATURE----- From wk at gnupg.org Sun Feb 13 17:37:43 2005 From: wk at gnupg.org (Werner Koch) Date: Sun Feb 13 17:35:57 2005 Subject: GnuPG1.4.1rc1 - Win98 In-Reply-To: <002d01c51102$7a1db060$7ad255d9@tesla> (Andreas John's message of "Sat, 12 Feb 2005 13:57:38 +0100") References: <002d01c51102$7a1db060$7ad255d9@tesla> Message-ID: <87y8dsh0vc.fsf@wheatstone.g10code.de> On Sat, 12 Feb 2005 13:57:38 +0100, Andreas John said: > Not sure if this is already known, but RC1 isn't starting on Win98 due to missing exports of SHGetFolderPathA from shell32.dll. > The function is actually exported by SHFolders.dll as stated in MSDN: Already fixed in CVS. We are now trying both; shell32.dll and shfolder.dll - this is the suggested way accoring to the MS info. Salam-Shalom, Werner From wk at gnupg.org Sun Feb 13 17:41:11 2005 From: wk at gnupg.org (Werner Koch) Date: Sun Feb 13 17:40:58 2005 Subject: Bug report In-Reply-To: <20050212113225.GA20571@electronic-quill.net> (James Fleming's message of "Sat, 12 Feb 2005 22:32:25 +1100") References: <20050212113225.GA20571@electronic-quill.net> Message-ID: <87u0ogh0pk.fsf@wheatstone.g10code.de> On Sat, 12 Feb 2005 22:32:25 +1100, James Fleming said: > gpg: Ohhhh jeeee: ... this is a bug (g10.c:1758:main) > secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 > Aborted Okay, that is due to: #if defined(HAVE_GETUID) && defined(HAVE_GETEUID) /* There should be no way to get to this spot while still carrying setuid privs. Just in case, bomb out if we are. */ if(getuid()!=geteuid()) BUG(); #endif > The configure options used were: > ./configure --prefix=/opt/pkgs/gnupg-1.4.0 --enable-m-guard > --enable-selinux-support --with-capabilities Seems that there are changes in the capability system of 2.6 compared to older kernels. Shalom-Salam, Werner From dshaw at jabberwocky.com Thu Feb 17 04:18:24 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Feb 17 04:15:13 2005 Subject: [Announce] Second release candidate for 1.4.1 available Message-ID: <20050217031824.GA24720@jabberwocky.com> Hi! We are pleased to announce the availability of a the second release candidate for the forthcoming 1.4.1 version of GnuPG: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.1rc2.tar.bz2 (2.7M) ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.1rc2.tar.bz2.sig ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.1rc1-1.4.1rc2.diff.bz2 (338K) An installer for Windows is also available: ftp://ftp.gnupg.org/gcrypt/alpha/binary/gnupg-w32cli-1.4.1rc2.exe (1.4M) ftp://ftp.gnupg.org/gcrypt/alpha/binary/gnupg-w32cli-1.4.1rc2.exe.sig SHA-1 checksums for the above files are: cfa9d6f4c7a0aa5b58df75e3b5480a8ccf223dea gnupg-1.4.1rc2.tar.bz2 21d4c2ef378e89b87123dc97c90989e8f1e09783 gnupg-1.4.1rc1-1.4.1rc2.diff.bz2 99f3bd0165cbfcbc2b562b42a3e0be64cec09b85 gnupg-w32cli-1.4.1rc2.exe Please try these versions out and report any problems. Noteworthy changes since 1.4.0: * New --rfc2440-text option which controls how text is handled in signatures. This is in response to some problems seen with certain PGP/MIME mail clients and GnuPG version 1.4.0. More details about this are available at . * New "import-unusable-sigs" and "export-unusable-sigs" tags for --import-options and --export-options. These are off by default, which causes GnuPG to not import or export key signatures that are not usable (e.g. expired signatures). * New experimental HTTP, HTTPS, FTP, and FTPS keyserver helper that uses the cURL library to retrieve keys. This is disabled by default, but may be enabled with the configure option --with-libcurl. Without this option, the existing HTTP code is used for HTTP, and HTTPS, FTP, and FTPS are not supported. * When running a --card-status or --card-edit and a public key is available, missing secret key stubs will be created on the fly. Details of the key are listed too. * The implicit packet dumping in double verbose mode is now sent to stderr and not to stdout. * Added countermeasures against the Mister/Zuccherato CFB attack . * [W32] The algorithm for the default home directory changed: First we look at the environment variable GNUPGHOME, if this one is not set, we check whether the registry entry {HKCU,HKLM}\Software\GNU\GnuPG:HomeDir has been set. If this fails we use a GnuPG directory below the standard application data directory (APPDATA) of the current user. Only in the case that this directory cannot be determined, the old default of c:\gnupg will be used. The option --homedir still overrides all of them. * [W32] The locale selection under Windows changed. You need to enter the locale in the registry at HKCU\Software\GNU\GnuPG:Lang. For German you would use "de". If it is not set, GnuPG falls back to HKLM. The languages files "*.mo" are expected in a directory named "gnupg.nls" below the installation directory; that directory must be stored in the registry at the same key as above with the name "Install Directory". * Add new --edit-key command "bkuptocard" to allow restoring a card key from a backup. * The "fetch" command of --card-edit now retrieves the key using the default keyserver if no URL has been stored on the card. Happy Hacking, David, Timo, Werner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 249 bytes Desc: not available Url : /pipermail/attachments/20050216/75b7c48e/attachment.pgp From dshaw at jabberwocky.com Thu Feb 17 14:30:19 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Feb 17 15:03:51 2005 Subject: New http code Message-ID: <20050217133019.GM24504@jabberwocky.com> Hi folks, Now that 1.4.1rc2 is out, can I get a few people to help exercise the new HTTP code? There are two main tests that would be very helpful: 1) Build with the configure option --with-libcurl. If you have libcurl installed, you should end up with a new program 'gpgkeys_curl', that supports HTTP, HTTPS, FTP, and FTPS. If you don't have libcurl installed, nothing should happen. 2) Build with the configure option --enable-fake-curl. This should also result in a 'gpgkeys_curl', but it only supports HTTP. Once built, if you could test the protocols by fetching some keys many times over, trying with different servers, etc, that would be very much appreciated. Note that this is for files via HTTP (or HTTPS or FTP or FTPS). It's not full keyserver support (with searching and so on). All you can do is fetch keys, genenerally from a preferred keyserver URL set on a key or signature. To make testing easier so you don't have to keep making preferred keyserver URLs all over the place, note you can test by doing something like this: gpg --keyserver http://www.example.com/a/key/is/stored/here.asc --recv-keys 99999999 or gpg --keyserver https://www.example.com/a/key/is/stored/here.asc --recv-keys 99999999 etc. The key stored in that file likely isn't key 99999999, but it'll work anyway to test. David From dshaw at jabberwocky.com Thu Feb 17 17:19:22 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Feb 17 17:50:42 2005 Subject: [Announce] Second release candidate for 1.4.1 available In-Reply-To: <20050217161148.GA13878@anl.gov> References: <20050217031824.GA24720@jabberwocky.com> <20050217161148.GA13878@anl.gov> Message-ID: <20050217161922.GB10243@jabberwocky.com> On Thu, Feb 17, 2005 at 10:11:48AM -0600, Stewart V. Wright wrote: > G'day David, > > * David Shaw [050216 21:24]: > > We are pleased to announce the availability of a the second release > > candidate for the forthcoming 1.4.1 version of GnuPG: > > Um... it appears that there was no update of the gnupg.spec file to > the one that we iterated to over the last week. No, the new spec is in CVS, but I checked it in just after Werner built 1.4.1rc2. No worries, it will be in 1.4.1. David From andrewbass at gmail.com Fri Feb 18 09:25:52 2005 From: andrewbass at gmail.com (Andrew Shcheglov) Date: Fri Feb 18 10:01:09 2005 Subject: Bugs in gnupg-1.4.0 and related packages In-Reply-To: <87d5vb40i5.fsf@wheatstone.g10code.de> References: <830142bd05020722585ffb6533@mail.gmail.com> <87oeev5pyp.fsf@wheatstone.g10code.de> <830142bd050208040569e108d7@mail.gmail.com> <87d5vb40i5.fsf@wheatstone.g10code.de> Message-ID: <830142bd05021800251970ae56@mail.gmail.com> There's the same bug on non-grsec'd kernel: > gpg: Ohhhh jeeee: ... this is a bug (g10.c:1758:main) > secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 $ uname -a Linux bass.science.syrus.ru 2.4.29 #4 Tue Feb 15 14:57:11 MSK 2005 i686 i686 i386 GNU/Linux $ /lib/libc.so.6 GNU C Library stable release version 2.3.4, by Roland McGrath et al. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.4.3. Compiled on a Linux 2.6.10 system on 2005-02-16. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk For bug reporting instructions, please see: . $ ld --version GNU ld version 2.15 $ gcc --version gcc (GCC) 3.4.3 -- Yours sincerely, Andrew ``Bass'' Shcheglov. From wk at gnupg.org Fri Feb 18 18:26:21 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Feb 18 18:26:07 2005 Subject: Bugs in gnupg-1.4.0 and related packages In-Reply-To: <830142bd05021800251970ae56@mail.gmail.com> (Andrew Shcheglov's message of "Fri, 18 Feb 2005 11:25:52 +0300") References: <830142bd05020722585ffb6533@mail.gmail.com> <87oeev5pyp.fsf@wheatstone.g10code.de> <830142bd050208040569e108d7@mail.gmail.com> <87d5vb40i5.fsf@wheatstone.g10code.de> <830142bd05021800251970ae56@mail.gmail.com> Message-ID: <871xbdbwzm.fsf@wheatstone.g10code.de> On Fri, 18 Feb 2005 11:25:52 +0300, Andrew Shcheglov said: >> gpg: Ohhhh jeeee: ... this is a bug (g10.c:1758:main) >> secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 Please tell us exactly on how you produced this error. You should also run gpg under gdb to get a stack dump: gdb gpg (gdb) run arguments to gpg (gdb) bt full Shalom-Salam, Werner From jvender at owensboro.net Fri Feb 18 18:07:15 2005 From: jvender at owensboro.net (Joe Vender) Date: Fri Feb 18 19:00:15 2005 Subject: keyserver verbosity Message-ID: <421620C3.2050408@owensboro.net> Is there a way to make gnupg display which keyserver it's connecting to when it attempts a connection for upload or download of keys? If not, it would be helpful if gnupg would display this information. The keyservers should display: 1) The URL of the keyserver which is being connected. 2) That it is a "Preferred Keyserver URL", if such is set in the signature. 3) That the connection and retrieval was successful or failed. 4) If failed, that the keyserver is trying the default server (if set) or next server in the list. All keyserver URLs should be shown at connection time. Joe From jvender at owensboro.net Fri Feb 18 20:08:58 2005 From: jvender at owensboro.net (Joe Vender) Date: Fri Feb 18 20:06:41 2005 Subject: keyserver verbosity Message-ID: <42163D4A.6000308@owensboro.net> Never mind my previous question. I see what the problem is, and it's not GnuPG, which IS doing what I though it wasn't doing. The issue is with the GUI's particular way of parsing the GnuPG output. Sorry. Joe From jvender at owensboro.net Sat Feb 19 00:01:04 2005 From: jvender at owensboro.net (Joe Vender) Date: Fri Feb 18 23:58:42 2005 Subject: GnuPG 1.4.1 & cURL Message-ID: <200502181701040820.006ADA1C@216.135.2.37> Hi, If anyone is able to successfully build GnuPG 1.4.x using the configure option "--with-libcurl" on Windows under MinGW/MSYS, please describe which packages(& version numbers) you have installed in MinGW/MSYS and what steps you took to build it, configure line, etc. From envite at rolamasao.org Sun Feb 20 12:17:37 2005 From: envite at rolamasao.org (Noel Torres) Date: Sun Feb 20 13:13:48 2005 Subject: Good messages showing as failed Message-ID: <421871D1.5080205@rolamasao.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm now using Enigmail regularly (as you can see), and I'm receiving my own messages with invalid signatures. Can it be a charset problem? How to solve it? Example: this message I sent shows as invalid signature: - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 F?lix J. Marcelo Wirnitzer escribi?: >> El d?a Saturday, 19 de February de 2005 23:53 Noel Torres (NT) dijo: >> > >>>> Mucha, mucha gente ech? de menos. No apareci? nadie m?s que yo :( > >> >> Siento no haber asistido, ya que yo estoy saliendo con gripe y no era cosa de >> recaer. A la pr?xima que convoques, ir?. Tienes mi palabra. Y si no puedo, >> avisar?. >> >> Mis disculpas por no haber podido. No pasa nada :) Es s?lo que esperaba ver al menos una cara er Envite - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFCGG9PcLQA8+7Hw3IRAlUDAJ9EEBzDfhwxhYD9CjEnKpRdcXrBdwCggemL 3G+gVRYNoEN87n1gWZsClwo= =NJCp - -----END PGP SIGNATURE----- Thanks in advance for any comment Noel Torres -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFCGHHKcLQA8+7Hw3IRAl0hAJ9q9aDWTWKTp+AmzPhII6IDGnT9fACeLNFE 6uArF/n9rMoW+ec3xb+UAoM= =Al4l -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Mon Feb 21 03:04:08 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Mon Feb 21 03:00:53 2005 Subject: Good messages showing as failed In-Reply-To: <421871D1.5080205@rolamasao.org> References: <421871D1.5080205@rolamasao.org> Message-ID: <20050221020408.GA27130@jabberwocky.com> On Sun, Feb 20, 2005 at 11:17:37AM +0000, Noel Torres wrote: > I'm now using Enigmail regularly (as you can see), and I'm receiving my > own messages with invalid signatures. Can it be a charset problem? How > to solve it? Since you're using Enigmail and GnuPG 1.4.0 together, one thing to try is to upgrade Enigmail. There was an early problem with that combination that was fixed in Enigmail. It might not be your problem, but it is where I would start. David From envite at rolamasao.org Mon Feb 21 21:53:01 2005 From: envite at rolamasao.org (Noel Torres) Date: Mon Feb 21 21:49:25 2005 Subject: Good messages showing as failed In-Reply-To: <20050221020408.GA27130@jabberwocky.com> References: <421871D1.5080205@rolamasao.org> <20050221020408.GA27130@jabberwocky.com> Message-ID: <421A4A2D.8000308@rolamasao.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw escribi?: | On Sun, Feb 20, 2005 at 11:17:37AM +0000, Noel Torres wrote: |> I'm now using Enigmail regularly (as you can see), and I'm receiving my |> own messages with invalid signatures. Can it be a charset problem? How |> to solve it? | | Since you're using Enigmail and GnuPG 1.4.0 together, one thing to try | is to upgrade Enigmail. There was an early problem with that | combination that was fixed in Enigmail. It might not be your problem, | but it is where I would start. | | David | | _______________________________________________ | Gnupg-devel mailing list | Gnupg-devel@gnupg.org | http://lists.gnupg.org/mailman/listinfo/gnupg-devel | | I've 0.90.0 and the latest is 0.90.1 so I'll try. Actually, it seems that deleting the option "--charset utf8" works fine. Thanks Noel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFCGkoqcLQA8+7Hw3IRAiArAJoDemuTtENvfrbnCq6d0seDn0YOIQCeOr/E 9Cs6NHl4+ioLt7mdDxaNBTg= =OoGC -----END PGP SIGNATURE----- From s-beyer at gmx.net Tue Feb 22 05:21:33 2005 From: s-beyer at gmx.net (Stephan Beyer) Date: Tue Feb 22 06:18:10 2005 Subject: small bugs and a small fix (1.4.1rc2 cvs) Message-ID: <15783.1109046093@www13.gmx.net> Hi, after switching to 1.4.0 I noticed some smaller bugs which have not been fixed yet. 1) --sign-key When signing a key with --sign-key, gpg asks `Really sign all user IDs? (y/N)'. Type `n' and 1.4.0 prints the hint to select the uids, but interprets `n' as a `No, I don't want to sign the key at all.' and exits. 1.2.x `returns' to the --edit-key-Command-prompt instead. I took a look over the source and *thought* about possible solutions: a) In 1.4.0 the `sign_mode' variable is replaced by a preselected commands-list (first sign, then save). We could remove the "save" command, but that would lead to a very unintuitive usage: the user has to save and exit _manually_. b) Add the `sign_mode' variable (see 1.2.x) and everything would be as nice as in good old times again... c) Remove --sign-key at all and tell the user to use something like --edit-key uid N sign save d) Add a function which iterates over the user IDs and asks whether the user wants to sign it. Well, I disliked a and c. And although d is less interactive than b, it's more intuitive. So I wrote a small patch for the current HEAD cvs(1.4.1rc2), downloadable at: http://noxa.de/~sbeyer/tmp/gnupg--sign-key.diff http://noxa.de/~sbeyer/tmp/gnupg--sign-key.diff.sig ( cd gnupgsourcedir && patch -p1 < ../gnupg--sign-key.diff ) What do you think about it? The patch introduces choose_uids() in keyedit.c. I disliked the `keyword' stuff, because I do not really know what it is used for, so I didn't test, whether I implemented it in a useful way. 2) --keyserver x-hkp://keyserver.kjsl.com:80 --search-key xxx This (see keyserver above) is the only patched PKS keyserver I know, which is running on port 80. That means, I can (and do) use it behind a firewall that dislikes accessing, for example, SKS servers on port 11371. --search on this server was no problem until I upgraded to GnuPG 1.4.0. `Funny' is, that I tried to fix the problem, but got banned from the keyserver after some trial&error. I mailed Jason Harris (the owner?) and explained what happened, but haven't got a reply yet. not real bugs: 3) --delete-key name(s) If is matching on more than one key, I am only asked if the first match should really be deleted. First, I didn't understand the `bug', because I thought gpg behaves in another way: 1. it expands the names list to all possible matches, removes duplicates, etc 2. it processes (--delete-key, --list-key) the expanded list, item by item This means, I thought that --delete-key and --list-key work in an equivalent way, except that the last operation is different (delete or list)... Then I took a look into the source / used the gdb debugger and was shocked, because do_delete_key() in delkey.c and list_one() in keylist.c are totally different. :\ I did not really try to fix it, because I could always use a name which produces an exact match (fingerprint) and so it isn't a real problem. 4) Be patient! My first experience with GnuPG 1.4.0 was this: nothing happens at all. So I kept my ~/.gnupg directory minimal: minimal secring, minimal pubring, no trustdb - and it worked! Soon I noticed that it's the trustdb, which makes gpg apparently do nothing (and according to `top' doing nothing eats almost 100% CPU). Of course, the same procedure as before: a look into the source and I saw that it really does something. keyring.c's keyring_rebuild_cache was the bad guy. I first thought that it loops infinitely on my 14MB pubring (or 6MB pubring on another machine) - maybe it generates a `ring list' and then iterates over it. But my first thoughts weren't true. It's a usual loop, just a bit inefficient. So I started gpg --check-trustdb and it finished after 19 minutes. Since then, it came always to a fast end, luckily. Why do I tell you that? It annoyed me... I thought that GnuPG 1.4. was broken and I was the only one noticing that. Maybe it should tell the people, that it rebuilds the cache / checks the trustdb and that this could take a while... It does, but not outside the source ;) Well, sorry for bad English. The only thing I did in the last 3 days was sleeping, eating and scrolling over GnuPG source code ;) I hope it wasn't worthless. best regards, Stephan Beyer -- Stephan Beyer, 0xFCC5040F Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail From ivg2 at cornell.edu Wed Feb 23 04:42:34 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed Feb 23 05:12:06 2005 Subject: gpg: PT_GNU_STACK RWE Message-ID: <1109130154.4359.1.camel@cobra.ivg2.net> Hi, I've subscribed to this list just to post this one question. The gpg binary is marked with PT_GNU_STACK RWE. This creates problems for the SELinux strict policy, and requires that special privileges be granted for gpg as a "legacy domain". The question is, does gpg really require an executable stack? I'm not a gcc expert of any kind, but from what I've read I understand that asm code causes gcc to mark the binary as requiring executable stack. I think it can be overridden with ld -z noexecstack. It would be a lot easier to write the gpg security policy if it didn't require executable stack. -- Ivan Gyurdiev Cornell University From wk at gnupg.org Wed Feb 23 11:29:06 2005 From: wk at gnupg.org (Werner Koch) Date: Wed Feb 23 11:26:04 2005 Subject: gpg: PT_GNU_STACK RWE In-Reply-To: <1109130154.4359.1.camel@cobra.ivg2.net> (Ivan Gyurdiev's message of "Tue, 22 Feb 2005 22:42:34 -0500") References: <1109130154.4359.1.camel@cobra.ivg2.net> Message-ID: <87acpv8t8t.fsf@wheatstone.g10code.de> On Tue, 22 Feb 2005 22:42:34 -0500, Ivan Gyurdiev said: > The question is, does gpg really require an executable stack? I don't think so. Some platforms might require it so; things to check are mpi/longlong.h as well as all the assembler code at mpi//. Might be easier to just check it out by running a key generation on all platforms. Salam-Shalom, Werner From harakiri_23 at yahoo.com Wed Feb 23 14:33:30 2005 From: harakiri_23 at yahoo.com (Harakiri) Date: Wed Feb 23 15:30:12 2005 Subject: Signing non self-signed key impossibile with GNUPG since > 1.2.x ? Message-ID: <20050223133331.14542.qmail@web53002.mail.yahoo.com> Why is it impossibile with GNUPG to sign old non self-signed keys ? Even with the allow-non-selfsigned-uid option it wont work, you can import, export etc those keys - but it is not possible to sign them - which makes it impossibile to use a certain rank of trust system. I have tested multiple versions of GNUPG, 1.2.0 Windows - the above example works 1.2.4 Unix - the above example does NOT work 1.4.0 Windows - the above example does NOT work The error is : User ID XXX is not self-signed. Unable to sign. So, what to do now ? I have to migrate back to a very old version to make gnupg work or sign those keys i really need to trust with PGP 8.x under windows... __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From dshaw at jabberwocky.com Wed Feb 23 16:05:52 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Feb 23 16:02:40 2005 Subject: Signing non self-signed key impossibile with GNUPG since > 1.2.x ? In-Reply-To: <20050223133331.14542.qmail@web53002.mail.yahoo.com> References: <20050223133331.14542.qmail@web53002.mail.yahoo.com> Message-ID: <20050223150552.GA26062@jabberwocky.com> On Wed, Feb 23, 2005 at 05:33:30AM -0800, Harakiri wrote: > Why is it impossibile with GNUPG to sign old non > self-signed keys ? The problem with signing a non-self signed key is that you're making a statement about a key that the *owner* of the key isn't making. For this reason, it is not usually allowed. > So, what to do now ? I have to migrate back to a very > old version to make gnupg work or sign those keys i > really need to trust with PGP 8.x under windows... Use the --expert option. David From alex at bofh.net.pl Thu Feb 24 12:17:06 2005 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Thu Feb 24 13:06:32 2005 Subject: a small feature request Message-ID: <20050224111706.GG25335@syjon.fantastyka.net> It would be useful to have GPG http keyserver helper to announce itself in HTTP transaction using "User-Agent" field in request. Now this field is not sent (as it is not obligatory). This results in the following being recorded on the server side: host81-134-162-60.in-addr.btopenworld.com - - [24/Feb/2005:04:30:06 +0100] "GET /crypto/0x46399138.asc HTTP/1.0" 200 23855 "-" "-" 7 quiston.tpsa.com "-" "-" Also, announcing GPG version would be useful for tracking of versions proliferation. Alex -- mors ab alto 0x46399138 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050224/533cb3f5/attachment.pgp From dshaw at jabberwocky.com Thu Feb 24 15:24:52 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Feb 24 15:21:46 2005 Subject: a small feature request In-Reply-To: <20050224111706.GG25335@syjon.fantastyka.net> References: <20050224111706.GG25335@syjon.fantastyka.net> Message-ID: <20050224142452.GC26818@jabberwocky.com> On Thu, Feb 24, 2005 at 12:17:06PM +0100, Janusz A. Urbanowicz wrote: > It would be useful to have GPG http keyserver helper to announce itself in > HTTP transaction using "User-Agent" field in request. Now this field is not > sent (as it is not obligatory). This results in the following being recorded > on the server side: > > host81-134-162-60.in-addr.btopenworld.com - - [24/Feb/2005:04:30:06 +0100] > "GET /crypto/0x46399138.asc HTTP/1.0" 200 23855 "-" "-" 7 quiston.tpsa.com > "-" "-" > > Also, announcing GPG version would be useful for tracking of versions > proliferation. I've always resisted this, using the logic that if a server operator doesn't actually *need* to know the GnuPG version, why give it to them? It's not a security-through-obscurity thing as the keyserver code needs to be safe no matter what, but more of a need-to-know thing. None of their business - if I wanted to have my version tracked, I'd announce the version myself. This is fine for HKP servers, none of which care if the User-Agent is there, but I've recently heard reports of some free web services that don't work with a blank User-Agent field. That would be a problem for keyserver URLs pointing to a file on those servers. This violates HTTP, of course, but good luck getting them to change. David From alex at bofh.net.pl Thu Feb 24 16:05:54 2005 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Thu Feb 24 16:04:06 2005 Subject: a small feature request In-Reply-To: <20050224142452.GC26818@jabberwocky.com> References: <20050224111706.GG25335@syjon.fantastyka.net> <20050224142452.GC26818@jabberwocky.com> Message-ID: <20050224150554.GH25335@syjon.fantastyka.net> On Thu, Feb 24, 2005 at 09:24:52AM -0500, David Shaw wrote: > On Thu, Feb 24, 2005 at 12:17:06PM +0100, Janusz A. Urbanowicz wrote: > > It would be useful to have GPG http keyserver helper to announce itself in > > HTTP transaction using "User-Agent" field in request. Now this field is not > > sent (as it is not obligatory). This results in the following being recorded > > on the server side: > > > > host81-134-162-60.in-addr.btopenworld.com - - [24/Feb/2005:04:30:06 +0100] > > "GET /crypto/0x46399138.asc HTTP/1.0" 200 23855 "-" "-" 7 quiston.tpsa.com > > "-" "-" > > > > Also, announcing GPG version would be useful for tracking of versions > > proliferation. > > I've always resisted this, using the logic that if a server operator > doesn't actually *need* to know the GnuPG version, why give it to > them? It's not a security-through-obscurity thing as the keyserver > code needs to be safe no matter what, but more of a need-to-know > thing. None of their business - if I wanted to have my version > tracked, I'd announce the version myself. If so, why announce PGP/GPG version in Version: field off ASCII armor, as it is done by default? Or, to further extend the logic, why include key IDs in encrypted mesages by default? As I not built gpg with libcurl yet, it is only a guess, but libcurl sometimes passes its own User-Agent string, and it is possible that libcurl http helper does so. From my POV sending User-Agent is a part of being good citizen of the net. I do not see a significant security gain in revealing the version in some channels and hiding it in the other. Of course, there is possibility of automated attacks against specific gpg versions done using this but it seems that probability is minimal. Maybe the best way is that it would be a option turned on by default. > This is fine for HKP servers, none of which care if the User-Agent is > there, but I've recently heard reports of some free web services that > don't work with a blank User-Agent field. That would be a problem for > keyserver URLs pointing to a file on those servers. This violates > HTTP, of course, but good luck getting them to change. I'm not saying it is a necessary feature. But as you say, lack of it could cause problems in some scenarios. Alex -- mors ab alto 0x46399138 From dshaw at jabberwocky.com Thu Feb 24 17:42:32 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Feb 24 17:39:26 2005 Subject: a small feature request In-Reply-To: <20050224150554.GH25335@syjon.fantastyka.net> References: <20050224111706.GG25335@syjon.fantastyka.net> <20050224142452.GC26818@jabberwocky.com> <20050224150554.GH25335@syjon.fantastyka.net> Message-ID: <20050224164232.GA28584@jabberwocky.com> On Thu, Feb 24, 2005 at 04:05:54PM +0100, Janusz A. Urbanowicz wrote: > > > Also, announcing GPG version would be useful for tracking of versions > > > proliferation. > > > > I've always resisted this, using the logic that if a server operator > > doesn't actually *need* to know the GnuPG version, why give it to > > them? It's not a security-through-obscurity thing as the keyserver > > code needs to be safe no matter what, but more of a need-to-know > > thing. None of their business - if I wanted to have my version > > tracked, I'd announce the version myself. > > If so, why announce PGP/GPG version in Version: field off ASCII armor, as it > is done by default? There is a switch to turn it off, which some people do. > Or, to further extend the logic, why include key IDs in encrypted mesages by > default? Because it's part of the protocol, and decryption doesn't work otherwise :) (yes, I know - speculative key IDs. It's not a required part of the protocol, and not all programs support them (i.e. PGP)). > As I not built gpg with libcurl yet, it is only a guess, but libcurl > sometimes passes its own User-Agent string, and it is possible that libcurl > http helper does so. Blank by default. > >From my POV sending User-Agent is a part of being good citizen of the net. > I do not see a significant security gain in revealing the version in some > channels and hiding it in the other. Of course, there is possibility of > automated attacks against specific gpg versions done using this but it seems > that probability is minimal. Maybe the best way is that it would be a option > turned on by default. I'm amused that it's always the server operators that want this so they can see who is using their server. It's never the users who ask for this ;) Understand that I'm not speaking about you specifically here, but this is not "please make a change to me so I will give out more information", but instead a "please make a change to other people so they will give me more information". > > This is fine for HKP servers, none of which care if the User-Agent is > > there, but I've recently heard reports of some free web services that > > don't work with a blank User-Agent field. That would be a problem for > > keyserver URLs pointing to a file on those servers. This violates > > HTTP, of course, but good luck getting them to change. > > I'm not saying it is a necessary feature. But as you say, lack of it could > cause problems in some scenarios. I may be forced to make the change for this reason, though I still think it's not necessary, or even a good idea. I'll probably extend --emit-version / --no-emit-version to apply to keyservers as well as the version string in armored messages. Not in 1.4.1, though. There are many changes in 1.4.1 already. David From md at Linux.IT Thu Feb 24 18:48:30 2005 From: md at Linux.IT (Marco d'Itri) Date: Thu Feb 24 21:49:14 2005 Subject: a small feature request In-Reply-To: <20050224142452.GC26818@jabberwocky.com> References: <20050224111706.GG25335@syjon.fantastyka.net> <20050224142452.GC26818@jabberwocky.com> Message-ID: <20050224174830.GA16833@wonderland.linux.it> On Feb 24, David Shaw wrote: > I've always resisted this, using the logic that if a server operator > doesn't actually *need* to know the GnuPG version, why give it to > them? This should be obvious: to help tracking misbehaving clients. -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20050224/62425ee0/attachment.pgp From dshaw at jabberwocky.com Thu Feb 24 21:56:44 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Feb 24 21:53:29 2005 Subject: a small feature request In-Reply-To: <20050224174830.GA16833@wonderland.linux.it> References: <20050224111706.GG25335@syjon.fantastyka.net> <20050224142452.GC26818@jabberwocky.com> <20050224174830.GA16833@wonderland.linux.it> Message-ID: <20050224205644.GA29001@jabberwocky.com> On Thu, Feb 24, 2005 at 06:48:30PM +0100, Marco d'Itri wrote: > On Feb 24, David Shaw wrote: > > > I've always resisted this, using the logic that if a server operator > > doesn't actually *need* to know the GnuPG version, why give it to > > them? > This should be obvious: to help tracking misbehaving clients. No question that version strings are a wonderful thing for the server operator to have. That doesn't answer the question why a user should choose to provide them. Who benefits here? Not the client. David From dshaw at jabberwocky.com Thu Feb 24 22:12:19 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Feb 24 22:08:55 2005 Subject: small bugs and a small fix (1.4.1rc2 cvs) In-Reply-To: <15783.1109046093@www13.gmx.net> References: <15783.1109046093@www13.gmx.net> Message-ID: <20050224211219.GB29001@jabberwocky.com> On Tue, Feb 22, 2005 at 05:21:33AM +0100, Stephan Beyer wrote: > 1) --sign-key > > When signing a key with --sign-key, gpg asks `Really sign all user IDs? > (y/N)'. Type `n' and 1.4.0 prints the hint to select the uids, but > interprets `n' as a `No, I don't want to sign the key at all.' and exits. > 1.2.x `returns' to the --edit-key-Command-prompt instead. This is actually a feature. The 1.2.x behavior is a little odd since the user started from the command line, issued a command line command, and then suddenly found themselves inside the --edit-key menu. I agree the hint is not useful and confusing when the user gets there via --sign-key, so I will remove it for --sign-key. Still, I rather like the general idea of an interactive walk through each user ID. I'll pick this up again for 1.4.2. > 2) --keyserver x-hkp://keyserver.kjsl.com:80 --search-key xxx > > This (see keyserver above) is the only patched PKS keyserver I know, which > is running on port 80. That means, I can (and do) use it behind a firewall > that dislikes accessing, for example, SKS servers on port 11371. > --search on this server was no problem until I upgraded to GnuPG 1.4.0. > > `Funny' is, that I tried to fix the problem, but got banned from the > keyserver after some trial&error. I mailed Jason Harris (the owner?) and > explained what happened, but haven't got a reply yet. The problem is that keyserver.kjsl.com returns an odd response when accessed over port 80 intead of 11371. Instead of just giving the answer, it gives three blank lines and then the answer. This breaks GnuPG's parser. Jason - what's the deal here? Can you easily remove the blank lines? Anyway, there is always pgp.srv.ualberta.ca on port 80. It's SKS, and supports multiple subkeys, photo IDs, etc. > If is matching on more than one key, I am only asked if the first > match should really be deleted. First, I didn't understand the `bug', > because I thought gpg behaves in another way: > 1. it expands the names list to all possible matches, removes duplicates, > etc > 2. it processes (--delete-key, --list-key) the expanded list, item by item > This means, I thought that --delete-key and --list-key work in an > equivalent way, except that the last operation is different (delete or > list)... It's not clear what the right thing to do here is. For example, --sign-key or --edit-key works like --delete-keys: it stops after the first match. It's certainly different than --list-keys, but they have different uses. At one point I considered a --delete-key that had the current behavior (first match), and a --delete-keys (with the 's') that acted like --list-keys (all matches), but I was afraid that would be confusing. > keyring.c's keyring_rebuild_cache was the bad guy. I first thought that it > loops infinitely on my 14MB pubring (or 6MB pubring on another machine) - > maybe it generates a `ring list' and then iterates over it. But my first > thoughts weren't true. It's a usual loop, just a bit inefficient. So I > started gpg --check-trustdb and it finished after 19 minutes. Since then, > it came always to a fast end, luckily. > > Why do I tell you that? It annoyed me... I thought that GnuPG 1.4. was > broken and I was the only one noticing that. Maybe it should tell the > people, that it rebuilds the cache / checks the trustdb and that this could > take a while... It does, but not outside the source ;) You're right. I'll add a release note about this. As you noted, it is only slow the first time, since after that the cache already exists. I'm actually a little surprised that someone didn't have a large cache built as the cache started being used in 1.0.7. David From jharris at widomaker.com Fri Feb 25 00:51:15 2005 From: jharris at widomaker.com (Jason Harris) Date: Fri Feb 25 00:47:29 2005 Subject: port 80 keyserver access (was Re: small bugs and a small fix (1.4.1rc2 cvs)) In-Reply-To: <20050224211219.GB29001@jabberwocky.com> References: <15783.1109046093@www13.gmx.net> <20050224211219.GB29001@jabberwocky.com> Message-ID: <20050224235115.GM1184@wilma.widomaker.com> > > --search on this server was no problem until I upgraded to GnuPG 1.4.0. > The problem is that keyserver.kjsl.com returns an odd response when > accessed over port 80 intead of 11371. Instead of just giving the > answer, it gives three blank lines and then the answer. This breaks > GnuPG's parser. Jason - what's the deal here? Can you easily remove > the blank lines? Removing whitespace in the .php page itself trims two of the unwanted newlines, as I've known about for ages, but since even a single empty line still confuses GPG, yes, it turns out there is an easy fix. Try it now (with GPG 1.4.0): %gpg --keyserver hkp://keyserver.kjsl.com:80 --search "jis mit" NB: Please access the keyserver directly (on port 11371) whenever possible. -- Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it? jharris@widomaker.com _|_ web: http://keyserver.kjsl.com/~jharris/ Got photons? (TM), (C) 2004 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: not available Url : /pipermail/attachments/20050224/9de86974/attachment.pgp From s-beyer at gmx.net Fri Feb 25 05:42:10 2005 From: s-beyer at gmx.net (Stephan Beyer) Date: Fri Feb 25 05:38:46 2005 Subject: small bugs and a small fix (1.4.1rc2 cvs) References: <20050224211219.GB29001@jabberwocky.com> Message-ID: <8769.1109306530@www35.gmx.net> Hi, (I hate writing via this WebMail thingie here again, but I'm not at home, so I must apologize for that advertisement at the end of the mail.) David Shaw wrote: > Still, I rather like the general idea of an interactive walk through > each user ID. I'll pick this up again for 1.4.2. Thank you. So my observations about it weren't worthless :) But I still have a question: What is that keyword stuff for? (I asked indirectly in my last mail.) It _sounds_ (I didn't look into the source about it.) that it's useful for batch mode, to exactly specify yes/no-answers for specific questions. [I've never used batch mode before, but it could be nice to sign many keys after the next bigger key signing party (next weekend).] > Anyway, there is always pgp.srv.ualberta.ca on port 80. It's SKS, and > supports multiple subkeys, photo IDs, etc. Big thanks! ;) I only found Jason's server (maybe because I like his keyanalyze reports). > It's not clear what the right thing to do here is. For example, > --sign-key or --edit-key works like --delete-keys: it stops after the > first match. They also could ask which key to choose, just an idea. Or - the lazy variant - everything stays the way it is ;) As I said, it is not *really* a problem to choose an exact match, but if it's only the fingerprint (of course, that's very rare), it will be a bit circumstantial to run 'gpg --fingerprint' and then retype/paste the fingerprint. :) > At one point I considered a --delete-key that had the current behavior > (first match), and a --delete-keys (with the 's') that acted like > --list-keys (all matches), but I was afraid that would be confusing. Just a little, because other commands make no difference between singular or plural. > You're right. I'll add a release note about this. As you noted, it > is only slow the first time, since after that the cache already > exists. Maybe I am only too impatient ;) Jason Harris wrote: > Try it now (with GPG 1.4.0): > > %gpg --keyserver hkp://keyserver.kjsl.com:80 --search "jis mit" Doesn't work for me, because I am still banned from the server. (403 Forbidden for /pks - of course, gpg just says, that there are no results, instead of telling me that status code 403 occured.) Best regards, Stephan Beyer -- Stephan Beyer, 0xFCC5040F, IRC: sbeyer DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen! AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl From wk at gnupg.org Fri Feb 25 10:30:24 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Feb 25 10:31:09 2005 Subject: a small feature request In-Reply-To: <20050224150554.GH25335@syjon.fantastyka.net> (Janusz A. Urbanowicz's message of "Thu, 24 Feb 2005 16:05:54 +0100") References: <20050224111706.GG25335@syjon.fantastyka.net> <20050224142452.GC26818@jabberwocky.com> <20050224150554.GH25335@syjon.fantastyka.net> Message-ID: <87bra92dhr.fsf@wheatstone.g10code.de> On Thu, 24 Feb 2005 16:05:54 +0100, Janusz A Urbanowicz said: > If so, why announce PGP/GPG version in Version: field off ASCII armor, as it > is done by default? That is different. You send that data on purpose to someone. Keyservers however are an anonymous resources and they should not track who is going to ask for what key using what software. It would indeed be nice to gather stats about GnuPG usage but it violates your privacy. Collect only what is absolutely needed for technical reasons is the maxim of data protection acts. Shalom-Salam, Werner From bms at zoominternet.net Sun Feb 27 01:56:24 2005 From: bms at zoominternet.net (Robert Spangler) Date: Fri Feb 25 11:06:27 2005 Subject: Error during compile Message-ID: <200502261956.37009.bms@zoominternet.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reporting error as asked to. Command Line: ./configure --enable-agent-only && make && make check && su root -c "make install" Received the following error during compile: /download/gpg/gnupg-1.9.15/tests/inittests: line 98: ../sm/gpgsm: No such file or directory /download/gpg/gnupg-1.9.15/tests/inittests: line 98: ../sm/gpgsm: No such file or directory /download/gpg/gnupg-1.9.15/tests/inittests: line 98: ../sm/gpgsm: No such file or directory echo timestamp >./inittests.stamp make[2]: Leaving directory `/download/gpg/gnupg-1.9.15/tests' make[2]: Entering directory `/download/gpg/gnupg-1.9.15' make[2]: Leaving directory `/download/gpg/gnupg-1.9.15' make[1]: Leaving directory `/download/gpg/gnupg-1.9.15' Making check in m4 make[1]: Entering directory `/download/gpg/gnupg-1.9.15/m4' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/download/gpg/gnupg-1.9.15/m4' Making check in intl make[1]: Entering directory `/download/gpg/gnupg-1.9.15/intl' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/download/gpg/gnupg-1.9.15/intl' Making check in jnlib make[1]: Entering directory `/download/gpg/gnupg-1.9.15/jnlib' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/download/gpg/gnupg-1.9.15/jnlib' Making check in common make[1]: Entering directory `/download/gpg/gnupg-1.9.15/common' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/download/gpg/gnupg-1.9.15/common' Making check in agent make[1]: Entering directory `/download/gpg/gnupg-1.9.15/agent' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/download/gpg/gnupg-1.9.15/agent' Making check in tools make[1]: Entering directory `/download/gpg/gnupg-1.9.15/tools' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/download/gpg/gnupg-1.9.15/tools' Making check in po make[1]: Entering directory `/download/gpg/gnupg-1.9.15/po' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/download/gpg/gnupg-1.9.15/po' Making check in doc make[1]: Entering directory `/download/gpg/gnupg-1.9.15/doc' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/download/gpg/gnupg-1.9.15/doc' Making check in tests make[1]: Entering directory `/download/gpg/gnupg-1.9.15/tests' make check-TESTS make[2]: Entering directory `/download/gpg/gnupg-1.9.15/tests' asschk: read_assuan: received incomplete line on fd 7 FAIL: sm-sign+verify asschk: read_assuan: received incomplete line on fd 5 FAIL: sm-verify ====================================== 2 of 2 tests failed Please report to gnupg-devel@gnupg.org ====================================== make[2]: *** [check-TESTS] Error 1 make[2]: Leaving directory `/download/gpg/gnupg-1.9.15/tests' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/download/gpg/gnupg-1.9.15/tests' make: *** [check-recursive] Error 1 - -- Regards Robert Smile... it increases your face value! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCIRrE0xJrO8dQYHgRAjiCAKCCQDPq/fZg8ZUqnBd5/oD3QcQ/LACfaHgr iFOaGqLvB0u8LLxlowJn2eM= =2717 -----END PGP SIGNATURE----- From md at Linux.IT Fri Feb 25 11:29:14 2005 From: md at Linux.IT (Marco d'Itri) Date: Fri Feb 25 11:30:01 2005 Subject: a small feature request In-Reply-To: <20050224205644.GA29001@jabberwocky.com> References: <20050224111706.GG25335@syjon.fantastyka.net> <20050224142452.GC26818@jabberwocky.com> <20050224174830.GA16833@wonderland.linux.it> <20050224205644.GA29001@jabberwocky.com> Message-ID: <20050225102914.GC8836@wonderland.linux.it> On Feb 24, David Shaw wrote: > No question that version strings are a wonderful thing for the server > operator to have. That doesn't answer the question why a user should > choose to provide them. Who benefits here? Not the client. And why do you consider this to be a problem? I still see no negative effects which justify not providing this useful information. I think it's in the interest of users that servers administrators have tools which help them keeping their servers running smoothly. -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20050225/18646ce1/attachment.pgp From gnupg-devel=gnupg.org at lists.palfrader.org Sat Feb 26 01:34:33 2005 From: gnupg-devel=gnupg.org at lists.palfrader.org (Peter Palfrader) Date: Sat Feb 26 01:30:49 2005 Subject: small bugs and a small fix (1.4.1rc2 cvs) In-Reply-To: <8769.1109306530@www35.gmx.net> References: <20050224211219.GB29001@jabberwocky.com> <8769.1109306530@www35.gmx.net> Message-ID: <20050226003433.GF4823@opium.palfrader.org> On Fri, 25 Feb 2005, Stephan Beyer wrote: > > Anyway, there is always pgp.srv.ualberta.ca on port 80. It's SKS, and > > supports multiple subkeys, photo IDs, etc. > > Big thanks! ;) I only found Jason's server (maybe because I like his > keyanalyze reports). keyserver.noreply.org should work too and has for a very long time. -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred. | : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `- http://www.debian.org/ From gnupg-devel=gnupg.org at lists.palfrader.org Sat Feb 26 14:17:41 2005 From: gnupg-devel=gnupg.org at lists.palfrader.org (Peter Palfrader) Date: Sat Feb 26 14:13:45 2005 Subject: small bugs and a small fix (1.4.1rc2 cvs) In-Reply-To: <20050224211219.GB29001@jabberwocky.com> References: <15783.1109046093@www13.gmx.net> <20050224211219.GB29001@jabberwocky.com> Message-ID: <20050226131741.GH4823@opium.palfrader.org> On Thu, 24 Feb 2005, David Shaw wrote: > On Tue, Feb 22, 2005 at 05:21:33AM +0100, Stephan Beyer wrote: > > > 1) --sign-key > > > > When signing a key with --sign-key, gpg asks `Really sign all user IDs? > > (y/N)'. Type `n' and 1.4.0 prints the hint to select the uids, but > > interprets `n' as a `No, I don't want to sign the key at all.' and exits. > > 1.2.x `returns' to the --edit-key-Command-prompt instead. > > This is actually a feature. The 1.2.x behavior is a little odd since > the user started from the command line, issued a command line command, > and then suddenly found themselves inside the --edit-key menu. I > agree the hint is not useful and confusing when the user gets there > via --sign-key, so I will remove it for --sign-key. This is very unfortunate as it breaks all scripts that call --sign-key and let the actual signing and uid selection to the user and gpg. On a related note, gpg now lists unique identifiers for each uid: | pub:u:1024:17:DE7AAF6E94C09C7F:942264711:::u:::scaESCA: | uid:u::::951840856::6DE2DB889258745FC0F19712AAD73DB1E1AF8E35::Peter Palfrader: | uid:u::::974848155::7846E1859AD46C860243B91589845BE87B584845::Peter Palfrader : Is there a way to use them in the edit dialog? I imagine something like | gpg --edit-key 12345678 | uid 7846E1859AD46C860243B91589845BE87B584845 <----- | sign would be handy. -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred. | : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `- http://www.debian.org/ From dshaw at jabberwocky.com Sun Feb 27 02:16:22 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Sun Feb 27 02:13:13 2005 Subject: small bugs and a small fix (1.4.1rc2 cvs) In-Reply-To: <20050226131741.GH4823@opium.palfrader.org> References: <15783.1109046093@www13.gmx.net> <20050224211219.GB29001@jabberwocky.com> <20050226131741.GH4823@opium.palfrader.org> Message-ID: <20050227011622.GD5206@jabberwocky.com> On Sat, Feb 26, 2005 at 02:17:41PM +0100, Peter Palfrader wrote: > On Thu, 24 Feb 2005, David Shaw wrote: > > > On Tue, Feb 22, 2005 at 05:21:33AM +0100, Stephan Beyer wrote: > > > > > 1) --sign-key > > > > > > When signing a key with --sign-key, gpg asks `Really sign all user IDs? > > > (y/N)'. Type `n' and 1.4.0 prints the hint to select the uids, but > > > interprets `n' as a `No, I don't want to sign the key at all.' and exits. > > > 1.2.x `returns' to the --edit-key-Command-prompt instead. > > > > This is actually a feature. The 1.2.x behavior is a little odd since > > the user started from the command line, issued a command line command, > > and then suddenly found themselves inside the --edit-key menu. I > > agree the hint is not useful and confusing when the user gets there > > via --sign-key, so I will remove it for --sign-key. > > This is very unfortunate as it breaks all scripts that call --sign-key > and let the actual signing and uid selection to the user and gpg. I am revisiting this for 1.4.2 (well, maybe 1.4.1). Stephan's suggestion of walking over each UID and asking the user seems good to me. > On a related note, gpg now lists unique identifiers for each uid: > > | pub:u:1024:17:DE7AAF6E94C09C7F:942264711:::u:::scaESCA: > | uid:u::::951840856::6DE2DB889258745FC0F19712AAD73DB1E1AF8E35::Peter Palfrader: > | uid:u::::974848155::7846E1859AD46C860243B91589845BE87B584845::Peter Palfrader : > > Is there a way to use them in the edit dialog? I imagine something like > > | gpg --edit-key 12345678 > | uid 7846E1859AD46C860243B91589845BE87B584845 <----- > | sign > > would be handy. That's a good idea. It would be nice in scripts. David From dshaw at jabberwocky.com Sun Feb 27 02:19:49 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Sun Feb 27 02:16:26 2005 Subject: small bugs and a small fix (1.4.1rc2 cvs) In-Reply-To: <8769.1109306530@www35.gmx.net> References: <20050224211219.GB29001@jabberwocky.com> <8769.1109306530@www35.gmx.net> Message-ID: <20050227011949.GE5206@jabberwocky.com> On Fri, Feb 25, 2005 at 05:42:10AM +0100, Stephan Beyer wrote: > Hi, > > (I hate writing via this WebMail thingie here again, but I'm not at home, > so I must apologize for that advertisement at the end of the mail.) > > David Shaw wrote: > > Still, I rather like the general idea of an interactive walk through > > each user ID. I'll pick this up again for 1.4.2. > > Thank you. So my observations about it weren't worthless :) > > But I still have a question: > What is that keyword stuff for? (I asked indirectly in my last mail.) > > It _sounds_ (I didn't look into the source about it.) that it's > useful for batch mode, to exactly specify yes/no-answers for specific > questions. > [I've never used batch mode before, but it could be nice to sign many > keys after the next bigger key signing party (next weekend).] It's actually part of two different things. First, it is used when using the --command-fd interface, so the program on the other side of the pipe knows what question is being asked. Second, it is used in the built-in help system so the right help message is displayed (see helptext.c). David From s-beyer at gmx.net Sun Feb 27 15:41:47 2005 From: s-beyer at gmx.net (Stephan Beyer) Date: Sun Feb 27 15:38:21 2005 Subject: small bugs and a small fix (1.4.1rc2 cvs) References: <20050227011949.GE5206@jabberwocky.com> Message-ID: <18979.1109515307@www29.gmx.net> Hi, > > But I still have a question: > > What is that keyword stuff for? (I asked indirectly in my last mail.) [...] > > It's actually part of two different things. First, it is used when > using the --command-fd interface, so the program on the other side of > the pipe knows what question is being asked. Second, it is used in > the built-in help system so the right help message is displayed (see > helptext.c). Ah, I see. So my patch is not really usable, because the keyword is generated dynamically depending on the uid. GnuPG is much more complex than I thought ;) best regards, Stephan -- Stephan Beyer, PGP 0xFCC5040F, IRC sbeyer Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail From patrick at mozilla-enigmail.org Mon Feb 28 11:23:44 2005 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Mon Feb 28 12:24:03 2005 Subject: File renaming bug still in gpg 1.4.1rc2 on Windows Message-ID: <4222F130.2050506@mozilla-enigmail.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just stumbled (again) across the file renaming bug on Windows XP with gpg 1.4.1 rc2. If my homedir is e.g. D:\patrick, then file renaming works fine. *But* if my homedir is: D:/Documents and Settings/patrick/Application Data/GnuPG then I still get the file renaming bug when trying to import a key: D:\gnupg\GnuPG\gpg.exe --charset utf8 --batch --no-tty --status-fd 2 - - -import gpg: key D18D9C18: public key "..." imported gpg: Total number processed: 1 gpg: imported: 1 gpg: public key 57BBB132 is 4104 seconds newer than the signature gpg: renaming `D:/Documents and Settings/patrick/Application Data/GnuPG\pubring.gpg' to `D:/Documents and Settings/patrick/Application Data/GnuPG\pubring.bak' failed: Permission denied gpg: failed to rebuild keyring cache: file rename error - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1rc2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCIvEv2KgHx8zsInsRAr0mAKDyCUGFSE0ShYrUAmG9onqwZLS+GwCg55g+ dGUgb75PqMf1LNDCLFPu3z4= =jnoR -----END PGP SIGNATURE-----