From schierlm at gmx.de Tue Aug 2 13:55:32 2005 From: schierlm at gmx.de (Michael Schierl) Date: Tue Aug 2 13:52:47 2005 Subject: Even more problems with revuid and --command-fd and --status-fd Message-ID: <42EF5F34.1050205@gmx.de> Hello, after writing my last mail yesterday (which is probably still pending moderator's approval) I got into even more trouble... Situation: GUI frontend wants to revoke a key's signature. How it is supposed to work: use --with-colons --batch --passphrase-fd 0 --command-fd 0 \ --status-fd 1 --edit-key and then send the revsig command. Then wait for the proper key id, confirm that one with "y", wait for "ask_revoke_sig.okay" and then dump out all the other things needed. When trying it in a "dry run" on the command line I noticed (as mentioned in my last mail) that the way gpg tells me the revocable key ids (which have to be confirmed one by one with y or n afterwards) is quite hard to parse. Even worse - it seems that these listings get sent directly to the terminal, so when reading stdout from a (Java) program these information is missing completely :( Any workarounds or should/can I wait for a fixed version? (I am using version 1.4.2 at the moment). BTW funny fact: I checked a few GPG frontends (enigmail keymanager, winpt, ...) but none of them supports to revoke a key's signature... Michael From dshaw at jabberwocky.com Wed Aug 3 06:24:25 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Aug 3 06:20:38 2005 Subject: Even more problems with revuid and --command-fd and --status-fd In-Reply-To: <42EF5F34.1050205@gmx.de> References: <42EF5F34.1050205@gmx.de> Message-ID: <20050803042425.GA7863@jabberwocky.com> On Tue, Aug 02, 2005 at 01:55:32PM +0200, Michael Schierl wrote: > Hello, > > after writing my last mail yesterday (which is probably still pending > moderator's approval) I got into even more trouble... > > Situation: GUI frontend wants to revoke a key's signature. > > How it is supposed to work: use > > --with-colons --batch --passphrase-fd 0 --command-fd 0 \ > --status-fd 1 --edit-key > > and then send the revsig command. Then wait for the proper key id, > confirm that one with "y", wait for "ask_revoke_sig.okay" and then dump > out all the other things needed. Just to clarify. You're trying to do revsig (like in this message), or revuid (like in the subject line) ? David From schierlm at gmx.de Wed Aug 3 16:40:14 2005 From: schierlm at gmx.de (Michael Schierl) Date: Wed Aug 3 16:37:27 2005 Subject: Even more problems with revuid and --command-fd and --status-fd In-Reply-To: <20050803042425.GA7863@jabberwocky.com> References: <42EF5F34.1050205@gmx.de> <20050803042425.GA7863@jabberwocky.com> Message-ID: <42F0D74E.5000601@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw schrieb: > On Tue, Aug 02, 2005 at 01:55:32PM +0200, Michael Schierl wrote: > >>after writing my last mail yesterday (which is probably still pending >>moderator's approval) I got into even more trouble... >> >>Situation: GUI frontend wants to revoke a key's signature. > > Just to clarify. You're trying to do revsig (like in this message), or > revuid (like in the subject line) ? Sorry. I meant revsig (to revoke a key's signature). revuid works fine. Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvDXTp2HdZ9YtIzdAQIVpAf/aII2LgH6bznjZHC40NhYx9GZJT1cXuCp 6lK4+RzniMBBpQ8iFYD8kX9bCRxYpjcwsQdgHPS5z1ooNFvuKo3dtZEX1UFJo+Lj sI0lmdfIkvhm6trVaLbcB5HeWVrvFC7tjlgv6kJ1uWW7nQ/FsPV259mge4Saof/S aXEaEf0S+eTSowe2URHahJGgflqGjunIJXq0+av5TzbPJP5wYP3htPAhDD8diRFo zy4IfKMs/mvZXJgC/odi04hp+LCrNnGAz72FjTzcFuMJ+hLRCzzsjTZZPpuZ7/yq m0b/4x4O8XEJiBoM2Itu424JTITUdjF8sCVNMGLE5of6JN69VzaIag== =BcUr -----END PGP SIGNATURE----- From schierlm at gmx.de Wed Aug 3 17:05:13 2005 From: schierlm at gmx.de (Michael Schierl) Date: Wed Aug 3 17:02:28 2005 Subject: Photo UIDs on --attribute-fd on Windows and strange LF->CRLF conversions Message-ID: <42F0DD29.8010001@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [this is a resend of a message from 2005-08-02 00:29 since that one apparently did not get through...] Hi, i have a "problem" with photo uids: ************* cut here ********* C:\temp>gpg --homedir \temp --edit-key JPEG gpg (GnuPG) 1.4.2; Copyright (C) 2005 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Secret key is available. pub 1024D/835DE7D3 created: 2005-08-01 expires: never usage: CS trust: ultimate validity: ultimate sub 1024g/023605A9 created: 2005-08-01 expires: never usage: E [ultimate] (1). JPEG Test Command> addphoto [...] Enter JPEG filename for photo ID: c:\temp\1px.jpg Is this photo correct (y/N/q)? y You need a passphrase to unlock the secret key for user: "JPEG Test " 1024-bit DSA key, ID 835DE7D3, created 2005-08-01 pub 1024D/835DE7D3 created: 2005-08-01 expires: never usage: CS trust: ultimate validity: ultimate sub 1024g/023605A9 created: 2005-08-01 expires: never usage: E [ultimate] (1). JPEG Test [ unknown] (2) [jpeg image of size 634] Command> q Save changes? (y/N) y C:\temp>gpg --homedir \temp --status-fd 1 --attribute-fd 1 --list-keys JPEG >new.dat ********** cut here ********** When trying to find the original image from the new.dat file, it seems that every 0x0a byte (line feed) inside the image is mangled to a 0x0d 0x0a. The length mentioned in the "ATTRIBUTES" line mentiones the decoded length. So decoding is a bit tricky, especially since when you read a 0x0d as last byte, you do not know whether to stop (i. e. it was a 0x0d byte) or not (if a 0x0a byte follows, it has been a 0x0a byte). If this is intentional, it should be documented somewhere, and there should be some way for the client program to detect this (so that the same program works on Windows and on other OSes). But IMHO it should be simply fixed (no LF->CRLF in binary data). (JFTR: The exactly same effect appears when I do this by creating a new process (from Java) and reading its stdout - so it is not some odd conversion done by the shell.) Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvDdKZ2HdZ9YtIzdAQLlJwgAj3a1KXPlr3Bs0+Jap7z+MlsPiv0z4u/d YbCZ0KDSeCNoSKEwTRhTcx2MAcoDIvFV+ZnBaLLSehhTOjRIjyL2ur/A5Smpd3if B0MRpNRfjXuiWzCUxpZEhcrAvTj32KmfuFiB1wHHeL8XJ7eqSFRAoEdDK0MiSUcl HBpb1nbXjpR5+yyvZfp3bZjAAY6DG1P4vxAsa9CUMN5iPGCc+5twXhK/sz4hKKca u+aa68xt/kTeh9QWzQDWz1bXEHME2ag7q7VDrwqdQ6gX4+dJJ2pA19kpeTIyFbQ8 lLRMK74tw89MOlOzuY7wasqAAhPfvR30a/wF4VP8cQDMKUrW92pMVg== =aqV4 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: new.dat Type: application/octet-stream Size: 906 bytes Desc: not available Url : /pipermail/attachments/20050803/77c78feb/new-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: 1px.jpg Type: image/jpeg Size: 634 bytes Desc: not available Url : /pipermail/attachments/20050803/77c78feb/1px-0001.jpg From dshaw at jabberwocky.com Wed Aug 3 17:33:24 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Aug 3 17:29:29 2005 Subject: Photo UIDs on --attribute-fd on Windows and strange LF->CRLF conversions In-Reply-To: <42F0DD29.8010001@gmx.de> References: <42F0DD29.8010001@gmx.de> Message-ID: <20050803153324.GA10395@jabberwocky.com> On Wed, Aug 03, 2005 at 05:05:13PM +0200, Michael Schierl wrote: > C:\temp>gpg --homedir \temp --status-fd 1 --attribute-fd 1 --list-keys > JPEG >new.dat > > ********** cut here ********** > > When trying to find the original image from the new.dat file, it seems > that every 0x0a byte (line feed) inside the image is mangled to a 0x0d > 0x0a. The length mentioned in the "ATTRIBUTES" line mentiones the > decoded length. So decoding is a bit tricky, especially since when you > read a 0x0d as last byte, you do not know whether to stop (i. e. it was > a 0x0d byte) or not (if a 0x0a byte follows, it has been a 0x0a byte). The problem here is twofold - first, you can't dump jpegs that way. You'll end up with garbage because it'll be mixed up with the key listings themselves. The second problem is related to the first - you're dumping to stdout, and stdout on windows does textmode conversion by default. To make this work, you need to use a fd that isn't stdout, or something like "--attribute-file new.dat" Note in any case that the attribute is not a raw JPEG. You'll get the attribute, which contains the JPEG. David From schierlm at gmx.de Wed Aug 3 18:39:39 2005 From: schierlm at gmx.de (Michael Schierl) Date: Wed Aug 3 18:36:56 2005 Subject: Photo UIDs on --attribute-fd on Windows and strange LF->CRLF conversions In-Reply-To: <20050803153324.GA10395@jabberwocky.com> References: <42F0DD29.8010001@gmx.de> <20050803153324.GA10395@jabberwocky.com> Message-ID: <42F0F34B.4010002@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (sorry for the private mail, David. I guess I have to read more mailing lists to remember clicking the "reply to all" button...) David Shaw schrieb: > The problem here is twofold - first, you can't dump jpegs that way. > You'll end up with garbage because it'll be mixed up with the key > listings themselves. The second problem is related to the first - > you're dumping to stdout, and stdout on windows does textmode > conversion by default. Hmm. For that "I can't do it that way" it works surprisingly well :) In all my tests it worked to read in "line-mode" and whenever there was an [GNUPG:] ATTRIBUTE ... line, switch to "byte-mode" and read that many bytes. Then check for CR-LFs, compensate by reading a few more bytes, and go on reading in "line-mode". That one worked well except in the case where the jpg ended with a LF byte. FWIW: I have that idea of "overloading stdout" from enigmail, which does it exactly that way (if the output in the debugging console is not "faked"). > To make this work, you need to use a fd that isn't stdout, or > something like "--attribute-file new.dat" Other fds (except stderr, which has the same problem I guess, and stdin, which is only writable) are not available from Java AFAIK (at least not platform-independently); and when using ?--attribute-file new2.dat? I got the same CRLF mangling :( And since one key can contain more than one JPEG image, the same problem with finding the beginning/end of those applies as well as when getting them out of stdout. BTW doc bug: I cannot find anything about --attribute-file neither in the manpage nor in src/doc/DETAILS > Note in any case that the attribute is not a raw JPEG. You'll get the > attribute, which contains the JPEG. Which is well-documented in src/doc/DETAILS. Yes, I know that, since it "basically" works here. Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvDzSp2HdZ9YtIzdAQJSqAf9HwCuCYa6HE5fXbeGAYPV+kjP4qpiOPe7 W7adGyBl2L7WTFNXkzpx6GRSPfmBQI+j+FZLgxYf8Q6ENT+r5TpH7KyE23niXvyI m5mHujPwUdZw4/ULbQHcbtMqYf4F5KeykJxnrY8a49tDJ4iBbBwoRBsxAm6WjN/Z UcXwymMmx90/8k/PK3pYqysCQDLosdGjVEbC3LC7rxPW9rxSNyFy9Fz3AJecUyG+ L3pppE2JFvTsZqs/jMW2sjA1m8kDqfHQmhtmmvTWsPbmOAo/ANGWQWMlB7NB1iCo lZ0Ps2nMGLA8ii5cf8OmO2yKs9vMmqYyT7NsBaFLyTUu2k2SabMZjA== =gKHa -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: new2.dat Type: application/octet-stream Size: 654 bytes Desc: not available Url : /pipermail/attachments/20050803/a83a8495/new2.obj From patrick at mozilla-enigmail.org Wed Aug 3 22:16:07 2005 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Wed Aug 3 22:14:33 2005 Subject: Photo UIDs on --attribute-fd on Windows and strange LF->CRLF conversions In-Reply-To: <42F0F34B.4010002__40811.8898085833$1123087408$gmane$org@gmx.de> References: <42F0DD29.8010001@gmx.de> <20050803153324.GA10395@jabberwocky.com> <42F0F34B.4010002__40811.8898085833$1123087408$gmane$org@gmx.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schierl wrote: > (sorry for the private mail, David. I guess I have to read more mailing > lists to remember clicking the "reply to all" button...) > > David Shaw schrieb: > > >>>The problem here is twofold - first, you can't dump jpegs that way. >>>You'll end up with garbage because it'll be mixed up with the key >>>listings themselves. The second problem is related to the first - >>>you're dumping to stdout, and stdout on windows does textmode >>>conversion by default. > > > Hmm. For that "I can't do it that way" it works surprisingly well :) > > In all my tests it worked to read in "line-mode" and whenever there was an > > [GNUPG:] ATTRIBUTE ... > > line, switch to "byte-mode" and read that many bytes. Then check for > CR-LFs, compensate by reading a few more bytes, and go on reading in > "line-mode". That one worked well except in the case where the jpg ended > with a LF byte. > > FWIW: I have that idea of "overloading stdout" from enigmail, which does > it exactly that way (if the output in the debugging console is not "faked"). The console is not "faked" but it doesn't care for CRLF conversion. If you look into the code of Enigmail, you'll notice that it actually does CRLF conversion on Windows systems to compensate the GnuPG/Windows output. But note that this is really a Windows-only issue (and probably GnuPG compiled with MinGW only?), so if you want to be platform independent you'll need to know the platform. - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC8SYD2KgHx8zsInsRApDIAKDZXVRDUHQcS8O18UYG4QxppaXSkACfWtvL rSmMPMSaaYF4h5dN7k05+VE= =3QH0 -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Wed Aug 3 22:19:25 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Aug 3 22:17:24 2005 Subject: Photo UIDs on --attribute-fd on Windows and strange LF->CRLF conversions In-Reply-To: <42F0F34B.4010002@gmx.de> References: <42F0DD29.8010001@gmx.de> <20050803153324.GA10395@jabberwocky.com> <42F0F34B.4010002@gmx.de> Message-ID: <20050803201925.GD10835@jabberwocky.com> On Wed, Aug 03, 2005 at 06:39:39PM +0200, Michael Schierl wrote: > (sorry for the private mail, David. I guess I have to read more mailing > lists to remember clicking the "reply to all" button...) > > David Shaw schrieb: > > > The problem here is twofold - first, you can't dump jpegs that way. > > You'll end up with garbage because it'll be mixed up with the key > > listings themselves. The second problem is related to the first - > > you're dumping to stdout, and stdout on windows does textmode > > conversion by default. > > Hmm. For that "I can't do it that way" it works surprisingly well :) It's a miracle... ;) Seriously, you're doing a lot of extra work to parse around the non-attribute data there. > > To make this work, you need to use a fd that isn't stdout, or > > something like "--attribute-file new.dat" > > Other fds (except stderr, which has the same problem I guess, and stdin, > which is only writable) are not available from Java AFAIK (at least not > platform-independently); and when using ?--attribute-file new2.dat? I > got the same CRLF mangling :( That should not happen. Try the attached patch. David -------------- next part -------------- Index: g10.c =================================================================== --- g10.c (revision 3847) +++ g10.c (working copy) @@ -937,7 +937,7 @@ might like it too. Prints an error message and returns -1 on error. On success the file descriptor is returned. */ static int -open_info_file (const char *fname, int for_write) +open_info_file (const char *fname, int for_write, int binary) { #ifdef __riscos__ return riscos_fdopenfile (fname, for_write); @@ -962,7 +962,8 @@ { if (for_write) fd = open (fname, O_CREAT | O_TRUNC | O_WRONLY, - S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP); + S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP + | (binary?MY_O_BINARY:0)); else fd = open (fname, O_RDONLY | MY_O_BINARY); } @@ -1996,20 +1997,20 @@ set_status_fd( iobuf_translate_file_handle (pargs.r.ret_int, 1) ); break; case oStatusFile: - set_status_fd ( open_info_file (pargs.r.ret_str, 1) ); + set_status_fd ( open_info_file (pargs.r.ret_str, 1, 0) ); break; case oAttributeFD: set_attrib_fd(iobuf_translate_file_handle (pargs.r.ret_int, 1)); break; case oAttributeFile: - set_attrib_fd ( open_info_file (pargs.r.ret_str, 1) ); + set_attrib_fd ( open_info_file (pargs.r.ret_str, 1, 1) ); break; case oLoggerFD: log_set_logfile( NULL, iobuf_translate_file_handle (pargs.r.ret_int, 1)); break; case oLoggerFile: - log_set_logfile( NULL, open_info_file (pargs.r.ret_str, 1) ); + log_set_logfile( NULL, open_info_file (pargs.r.ret_str, 1, 0) ); break; case oWithFingerprint: @@ -2275,13 +2276,13 @@ opt.use_agent = 0; break; case oPasswdFile: - pwfd = open_info_file (pargs.r.ret_str, 0); + pwfd = open_info_file (pargs.r.ret_str, 0, 0); break; case oCommandFD: opt.command_fd = iobuf_translate_file_handle (pargs.r.ret_int, 0); break; case oCommandFile: - opt.command_fd = open_info_file (pargs.r.ret_str, 0); + opt.command_fd = open_info_file (pargs.r.ret_str, 0, 0); break; case oCipherAlgo: def_cipher_string = xstrdup(pargs.r.ret_str); From dshaw at jabberwocky.com Wed Aug 3 22:54:55 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Aug 3 22:50:51 2005 Subject: Even more problems with revuid and --command-fd and --status-fd In-Reply-To: <42F0D74E.5000601@gmx.de> References: <42EF5F34.1050205@gmx.de> <20050803042425.GA7863@jabberwocky.com> <42F0D74E.5000601@gmx.de> Message-ID: <20050803205455.GA11204@jabberwocky.com> On Wed, Aug 03, 2005 at 04:40:14PM +0200, Michael Schierl wrote: > David Shaw schrieb: > > On Tue, Aug 02, 2005 at 01:55:32PM +0200, Michael Schierl wrote: > > > > >>after writing my last mail yesterday (which is probably still pending > >>moderator's approval) I got into even more trouble... > >> > >>Situation: GUI frontend wants to revoke a key's signature. > > > > Just to clarify. You're trying to do revsig (like in this message), or > > revuid (like in the subject line) ? > > Sorry. I meant revsig (to revoke a key's signature). revuid works fine. Try this patch. David -------------- next part -------------- Index: keyedit.c =================================================================== --- keyedit.c (revision 3847) +++ keyedit.c (working copy) @@ -2377,7 +2377,6 @@ } } - /* This is the version of show_key_with_all_names used when opt.with_colons is used. It prints all available data in a easy to parse format and does not translate utf8 */ @@ -4189,7 +4188,7 @@ ask_revoke_sig( KBNODE keyblock, KBNODE node ) { int doit=0; - char *p; + PKT_user_id *uid; PKT_signature *sig = node->pkt->pkt.signature; KBNODE unode = find_prev_kbnode( keyblock, node, PKT_USER_ID ); @@ -4198,15 +4197,33 @@ return; } - p=utf8_to_native(unode->pkt->pkt.user_id->name, - unode->pkt->pkt.user_id->len,0); - tty_printf(_("user ID: \"%s\"\n"),p); - xfree(p); + uid=unode->pkt->pkt.user_id; - tty_printf(_("signed by your key %s on %s%s%s\n"), - keystr(sig->keyid),datestr_from_sig(sig), - sig->flags.exportable?"":_(" (non-exportable)"),""); + if(opt.with_colons) + { + if(uid->attrib_data) + printf("uat:::::::::%u %lu",uid->numattribs,uid->attrib_len); + else + { + printf("uid:::::::::"); + print_string (stdout, uid->name, uid->len, ':'); + } + printf("\n"); + + print_and_check_one_sig_colon(keyblock,node,NULL,NULL,NULL,NULL,1); + } + else + { + char *p=utf8_to_native(unode->pkt->pkt.user_id->name, + unode->pkt->pkt.user_id->len,0); + tty_printf(_("user ID: \"%s\"\n"),p); + xfree(p); + + tty_printf(_("signed by your key %s on %s%s%s\n"), + keystr(sig->keyid),datestr_from_sig(sig), + sig->flags.exportable?"":_(" (non-exportable)"),""); + } if(sig->flags.expired) { tty_printf(_("This signature expired on %s.\n"), From schierlm at gmx.de Thu Aug 4 01:01:13 2005 From: schierlm at gmx.de (Michael Schierl) Date: Thu Aug 4 00:59:11 2005 Subject: Photo UIDs on --attribute-fd on Windows and strange LF->CRLF conversions In-Reply-To: <20050803201925.GD10835@jabberwocky.com> References: <42F0DD29.8010001@gmx.de> <20050803153324.GA10395@jabberwocky.com> <42F0F34B.4010002@gmx.de> <20050803201925.GD10835@jabberwocky.com> Message-ID: <42F14CB9.7050307@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw schrieb: > Seriously, you're doing a lot of extra work to parse around the > non-attribute data there. It depends. If i need quite a lot of the info anyway for building my "key preferences" dialog (and i even include sig subpackets for output to get things like preferred ciphers), it is easier to throw the rest of the information away than to ask Java for a temp file name and to ensure that this file will be deleted afterwards even if an error occurs. IOW: I hate using tempfiles if I can avoid it. >>when using ?--attribute-file new2.dat? I >>got the same CRLF mangling :( > > > That should not happen. Try the attached patch. patching file g10.c Hunk #1 succeeded at 930 (offset -7 lines). Hunk #2 succeeded at 955 (offset -7 lines). Hunk #3 succeeded at 1984 (offset -13 lines). Hunk #4 succeeded at 2245 with fuzz 1 (offset -31 lines). C:\progs\msys\1.0\home\mine\gnupg-1.4.1>.\g10\gpg --homedir \temp --attribute-file \temp\new4.dat --status-fd 1 --list-sigs "JPEG" C:\temp>fc new2.dat new4.dat Comparing files new2.dat and NEW4.DAT FC: no differences encountered (my hex editor thinks the same - i. e. that patch did not cure the problem) Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvFMuZ2HdZ9YtIzdAQJ99wf9Hxbam62K3UQpnNh5KxlpSZdeVm6OpwF+ 1mgT3D1RHXIMtwxTS1fu8c+WKYE2T30PlsY9bcz5eNgAVHytVMzvX01GXzzDPdUa 5dzCFrm7+9cSvdWKAZ0ouvcWbD1JBP2o1d7Q+vHBdLL4/460uatoSiPzULomborU XAcN+kBAYQDhOzbqmHXhF01muVlS5cR0YlF+qJaANh7kHjIGXLoRgN+GedV9dJ41 RXjZ6WGiud1LxlVbw7oV3p7g+SFoySZB8yFpKTQ47KQNeH969rHQvFAnoFfu6vd4 HIx/dbaLuFg1HLgd2KLxJmDW5gSHbLFfaO9buthZGyaxIAeeU/xDcw== =UCxG -----END PGP SIGNATURE----- From schierlm at gmx.de Thu Aug 4 01:29:16 2005 From: schierlm at gmx.de (Michael Schierl) Date: Thu Aug 4 01:27:22 2005 Subject: Even more problems with revuid and --command-fd and --status-fd In-Reply-To: <20050803205455.GA11204@jabberwocky.com> References: <42EF5F34.1050205@gmx.de> <20050803042425.GA7863@jabberwocky.com> <42F0D74E.5000601@gmx.de> <20050803205455.GA11204@jabberwocky.com> Message-ID: <42F1534C.8040002@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw schrieb: > On Wed, Aug 03, 2005 at 04:40:14PM +0200, Michael Schierl wrote: > >>Sorry. I meant revsig (to revoke a key's signature). revuid works fine. > > > Try this patch. Against what am I supposed to apply this? Does not apply cleanly against 1.4.1 source from the gnupg website. After replacing a ?m_free? by ?xfree? it did apply. But the result look usable (when I select the uid first, I could even live without that "uid/uat" line only with "sig"). thanks, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvFTTJ2HdZ9YtIzdAQJ39wgAlfz/8XgIA+0k4zD9S3uTGoGMeeSq5FF+ GUVZEZTWqTPyYfzj0QsDjF2hbHHEhCiGoJkizMUCrQ2V9UTWkV6+m5mnKQr/ZbRf JUlfV1loEV0aCi78Rmwj+jjbzbcdZaggsdf6ydQgILnPVRHqBUVjv1KYn515QxJx OchwYSdIO4WpXINU3qi2QSJLTnMP+28MZtqmE4l44Qw9NrEtmvCOPxfDiDZHOU5S vyv41IHRZLveNr+6LPJrY0CHhuwYcRxVAbkN69lrzfC91fScBXvdUFq0xb5Of1s4 LELA6pBj+5U+7iERfA0xheCZAf5/dHqErQZ7zjGiMJ3bp3p2bZ5LgA== =rd58 -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Thu Aug 4 02:45:26 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Aug 4 02:41:22 2005 Subject: Even more problems with revuid and --command-fd and --status-fd In-Reply-To: <42F1534C.8040002@gmx.de> References: <42EF5F34.1050205@gmx.de> <20050803042425.GA7863@jabberwocky.com> <42F0D74E.5000601@gmx.de> <20050803205455.GA11204@jabberwocky.com> <42F1534C.8040002@gmx.de> Message-ID: <20050804004526.GC11494@jabberwocky.com> On Thu, Aug 04, 2005 at 01:29:16AM +0200, Michael Schierl wrote: > David Shaw schrieb: > > On Wed, Aug 03, 2005 at 04:40:14PM +0200, Michael Schierl wrote: > > > >>Sorry. I meant revsig (to revoke a key's signature). revuid works fine. > > > > > > Try this patch. > > Against what am I supposed to apply this? Does not apply cleanly against > 1.4.1 source from the gnupg website. After replacing a ?m_free? by > ?xfree? it did apply. That's fine. > But the result look usable (when I select the uid first, I could even > live without that "uid/uat" line only with "sig"). You need the uid/uat line to tell which user ID the sig was on (say, if you signed more than one user ID on a key). David From wk at gnupg.org Thu Aug 4 09:40:26 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Aug 4 09:41:23 2005 Subject: Smart card interface, OpenSC and OpenCT In-Reply-To: <200507261338.25429.laurent.pinchart@skynet.be> (Laurent Pinchart's message of "Tue, 26 Jul 2005 13:38:25 +0200") References: <200507251710.42908.laurent.pinchart@skynet.be> <87k6jeyvh5.fsf@wheatstone.g10code.de> <200507261338.25429.laurent.pinchart@skynet.be> Message-ID: <87mzny880l.fsf@wheatstone.g10code.de> On Tue, 26 Jul 2005 13:38:25 +0200, Laurent Pinchart said: > Now, that's bad. How are applications/libraries supposed to cooperate when > different threading libraries are used ? That is actually a non-trivial problem and the only solution is to have callbacks for all basic threading functions. The actual application may then decide how to implement it. For some things a wrapper process works but this requires an easy interface and can't be done with a complex API like the one of OpenSC. > Right. libopensc only requires OpenSSL for the GPK-4000 and Oberthur cards. It > can be disabled at compile time, in which case sc_pkcs15_wrap_data and > sc_pkcs15_unwrap_data won't be available. The problem here is with the distributions: They would need to provide two different versions of the library. > OpenCT is (in my opinion) a cleaner API than PC/SC (which was designed for > Microsoft Windows). I'd rather see the CCID readers supported through OpenCT > and/or PC/SC than directly by GnuPG, as OpenCT and PC/SC can share a reader > between separate applications. Any opinion about that ? I also like OpenCT more than PC/SC but GnuPG smartcard support predates OpenCT. Another reason why PC/SC is a requirement is that GnuPG also runs on Windows and there we have no other choice. Of course OpenCT could be ported but the reader vendors distribute drivers for PC/SC. The way GnuPG currently works is that it requires exclusive access to the reader, thus PC/SC non-exclusive access feature doesn't matter. I have not yet come to a conclusion how to allow shared access to a reader. My current line of thinking is to provide this on an application level (i.e. trough the interface scdaemon provides). > * The SELECT FILE doesn't return any FCI, so the file size isn't know. This > doesn't seem to matter as GnuPG doesn't use the FCI. On a side note, > iso7816_read_binary doesn't handle status bytes 6Cxx (Wrong Le field). > Shouldn't it reissue the READ BINARY command with Le=xx ? I have not yet come across this error code; will implement it as required. > * The NonRep key needs a VERIFY PIN before each time it is used for a > signature. Zetes enforced that by popping a GUI window up every time a > signature was made. I don't like that solution, and it seems that GnuPG > performs the VERIFY command before every signature anyway. Could anyone > confirm that ? The new pkcs#15 code is very basic and definitely needs some polishing. For OpenPGP we keep track of sent VERIFY commands and also take care of the flag indicating that a PIN should not be cached. It's a matter of tests with a real card. BTW, the current versions of GnuPG 1.9.17 as well as 1.9.18 have some design problems with PIN caching. This is due to reset commands send at the end of each session; it is connected to the above mentioned question on exclusive access to smartcards. Needs more thinking. Shalom-Salam, Werner From wk at gnupg.org Thu Aug 4 09:46:43 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Aug 4 09:46:21 2005 Subject: Smart card interface, why so many daemons ? In-Reply-To: <200507271021.37723.laurent.pinchart@skynet.be> (Laurent Pinchart's message of "Wed, 27 Jul 2005 10:21:37 +0200") References: <200507271021.37723.laurent.pinchart@skynet.be> Message-ID: <87irym87q4.fsf@wheatstone.g10code.de> On Wed, 27 Jul 2005 10:21:37 +0200, Laurent Pinchart said: > - PC/SC Only required if you don't want to go with the internal CCID driver. > - pcsc-wrapper (not really a daemon here, but a separate process) This one is required to workaround the pthreads/pth conflicts. Having a libpsclite build without pthreads would make it needless. > - scdaemon Accesssing smartcards but due to the nature of smartcards, does not require to handle any sensitive (read private key) data. > - gpg-agent Manage private keys. Smartcards are different and thus gpg-agent will delegate operations to it. It is easier to have a single process to manage all sign and decrypt operations than to let the actual application decide whether to go to the gpg-agent or to the smartcard. > I understand the argument that, for security reasons, GnuPG can't be made a > library, but will stay a separate process (with gpgme helping to communicate > with that process). Are there security issues with scdaemon and > pcsc-wrapper ? Not for pcsc-wrapper. I don't want to have all that code for smartcards in the same process having access to private keys (gpg-agent). This is a general precaution and will urther help systems like SELinux to better protect private keys stored on disk. Salam-Shalom, Werner From sadam at CLEMSON.EDU Wed Aug 3 18:40:55 2005 From: sadam at CLEMSON.EDU (Adam Schreiber) Date: Thu Aug 4 12:50:20 2005 Subject: Photo UIDs on --attribute-fd on Windows and strange LF->CRLF conversions In-Reply-To: <20050803153324.GA10395@jabberwocky.com> References: <42F0DD29.8010001@gmx.de> <20050803153324.GA10395@jabberwocky.com> Message-ID: <42F0F397.40705@clemson.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw wrote: >>When trying to find the original image from the new.dat file, it seems >>that every 0x0a byte (line feed) inside the image is mangled to a 0x0d >>0x0a. The length mentioned in the "ATTRIBUTES" line mentiones the >>decoded length. So decoding is a bit tricky, especially since when you >>read a 0x0d as last byte, you do not know whether to stop (i. e. it was >>a 0x0d byte) or not (if a 0x0a byte follows, it has been a 0x0a byte). > > > The problem here is twofold - first, you can't dump jpegs that way. > You'll end up with garbage because it'll be mixed up with the key > listings themselves. The second problem is related to the first - > you're dumping to stdout, and stdout on windows does textmode > conversion by default. I've been working on Photo ID support for seahorse. We decided to attack the problem by using a helper program to output a jpg to a known location. Since gpg uses xloadimage on UNIX systems to display the photo ids, we created a program that dumps the intended output for xloadimage to a file specified by an environment variable. We're using gpgme_op_edit to trigger the output, but you could do a similar thing with the command: gpg --edit-key uid showphoto quit The helper program can be found in cvs at http://cvs.gnome.org/viewcvs/seahorse/src/seahorse-xloadimage.c The other glue can be found in the latest patch attached to GNOME bugzilla bug #160413 http://bugzilla.gnome.org/show_bug.cgi?id=160413 Specifically look at the changes in src/seahorse-key-op.c for the gpgme handling. Adam Schreiber - -- Why isn't all of your email protected? http://gnupg.org http://enigmail.mozdev.org http://seahorse.sourceforge.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC8POXjU1oaHEI4wgRAmTFAJ9VSju+OXc4rLgS/EDkB8D6q6ZE1ACg7sd7 XPQYcg0hrdPtIokrQyva570= =ZikJ -----END PGP SIGNATURE----- From randomiadgf at fsck.ch Thu Aug 4 12:15:43 2005 From: randomiadgf at fsck.ch (Tobias Roth) Date: Thu Aug 4 13:13:53 2005 Subject: possible bug with --batch and 1.4.2 Message-ID: <20050804121544.0ac5f9ec.randomiadgf@fsck.ch> Hi I tried out the --batch example from the DETAILS file (search for 'foo' in that file to find the example). This is what I got: Assertion failed: (pkt->pkt.generic), function build_packet, file build-packet.c , line 74. The same example seems to work with 1.4.1. The systems tested are FreeBSD 5.4-STABLE and 6.0-BETA1, I was not able to test on a different system, so I cannot say if this is OS specific. thabnks, t. From schierlm at gmx.de Thu Aug 4 13:18:14 2005 From: schierlm at gmx.de (Michael Schierl) Date: Thu Aug 4 13:15:32 2005 Subject: Photo UIDs on --attribute-fd on Windows and strange LF->CRLF conversions In-Reply-To: <42F0F397.40705@clemson.edu> References: <42F0DD29.8010001@gmx.de> <20050803153324.GA10395@jabberwocky.com> <42F0F397.40705@clemson.edu> Message-ID: <42F1F976.4030607@gmx.de> Adam Schreiber schrieb: > I've been working on Photo ID support for seahorse. We decided to > attack the problem by using a helper program to output a jpg to a known > location. Since gpg uses xloadimage on UNIX systems to display the > photo ids, we created a program that dumps the intended output for > xloadimage to a file specified by an environment variable. Thanks for your answer. I thought of this approach already, but that would break platform independence as well (since i had to compile that utility for each platform) or it would take ages (because starting a new java vm for each image is simply slow...). So this would be my last resort :) But I think I have a solution (at least a hack that is dirty enough so that I cannot think of any cases it does not handle): since there are always at least two text lines before the first attribute packet ("pub:..." and "[GNUPG:] ATTRIBUTE ..."), I'd just write a "filter stream" that looks at the first line ending. if it is exactly CRLF, do CRLF->LF conversion, if it is LF or CR only, do nothing. Michael From schierlm at gmx.de Thu Aug 4 13:18:32 2005 From: schierlm at gmx.de (Michael Schierl) Date: Thu Aug 4 13:15:44 2005 Subject: Even more problems with revuid and --command-fd and --status-fd In-Reply-To: <20050804004526.GC11494@jabberwocky.com> References: <42EF5F34.1050205@gmx.de> <20050803042425.GA7863@jabberwocky.com> <42F0D74E.5000601@gmx.de> <20050803205455.GA11204@jabberwocky.com> <42F1534C.8040002@gmx.de> <20050804004526.GC11494@jabberwocky.com> Message-ID: <42F1F988.4060100@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw schrieb: > On Thu, Aug 04, 2005 at 01:29:16AM +0200, Michael Schierl wrote: > > >>But the result look usable (when I select the uid first, I could even ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>live without that "uid/uat" line only with "sig"). > > > You need the uid/uat line to tell which user ID the sig was on (say, > if you signed more than one user ID on a key). I would need it if i did not say e. g. "uid 1" before "revsig". But better too much information than too less :-) Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvH5h52HdZ9YtIzdAQK/Ygf/QoRamSpDaMRKv/O+nFBjoAP9+MPU2Td7 iVVbjsISMETvvBdBkStaTcEQgssv/WL7AM5PWOJ3YObhplhbJOQ30Pyk6zScfTVi oLYEcSl+gEjHQnt2oJUKVDuFHq/YRQUDKntPitKNEu1uAgZ5lNuQe0JJ/yC4k7WH QD415vCUzoJVU9/0LkMX1VT40k2kAwKGfAqGucVNv/TkofGoCdeYW/Wi5e6UTOew 0kF0NzMF2ewa76Ta0lg5PdTz6Pfd2aZGezrDSn5xcTa7ZfZS9fL8BuXfdjA9sHe+ 9dq1Vp1yrXNgKo9cizuGoPfg2KG41jEEdiOLEw4oCniLHRG8udCk6w== =bKAo -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Thu Aug 4 15:07:24 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Aug 4 15:03:19 2005 Subject: possible bug with --batch and 1.4.2 In-Reply-To: <20050804121544.0ac5f9ec.randomiadgf@fsck.ch> References: <20050804121544.0ac5f9ec.randomiadgf@fsck.ch> Message-ID: <20050804130724.GA14992@jabberwocky.com> On Thu, Aug 04, 2005 at 12:15:43PM +0200, Tobias Roth wrote: > Hi > > I tried out the --batch example from the DETAILS file (search for 'foo' > in that file to find the example). This is what I got: > > Assertion failed: (pkt->pkt.generic), function build_packet, file > build-packet.c , line 74. > > The same example seems to work with 1.4.1. The systems tested are > FreeBSD 5.4-STABLE and 6.0-BETA1, I was not able to test on a different > system, so I cannot say if this is OS specific. Try this patch. David -------------- next part -------------- Index: keygen.c =================================================================== --- keygen.c (revision 3847) +++ keygen.c (working copy) @@ -2667,7 +2667,11 @@ PACKET *pkt; pkt=xmalloc_clear(sizeof(*pkt)); - pkt->pkttype=PKT_NONE; + + pkt->pkttype=PKT_USER_ID; + pkt->pkt.user_id=xmalloc_clear(sizeof *pkt->pkt.user_id); + pkt->pkt.user_id->ref=1; + *tree=new_kbnode(pkt); delete_kbnode(*tree); } From dshaw at jabberwocky.com Thu Aug 4 22:24:01 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Aug 4 22:19:59 2005 Subject: possible bug with --batch and 1.4.2 In-Reply-To: <20050804220152.49a5079b.randomiadgf@fsck.ch> References: <20050804121544.0ac5f9ec.randomiadgf@fsck.ch> <20050804130724.GA14992@jabberwocky.com> <20050804220152.49a5079b.randomiadgf@fsck.ch> Message-ID: <20050804202401.GA26520@jabberwocky.com> On Thu, Aug 04, 2005 at 10:01:52PM +0200, Tobias Roth wrote: > On Thu, 4 Aug 2005 09:07:24 -0400 > David Shaw wrote: > > > > I tried out the --batch example from the DETAILS file (search for > > > 'foo' in that file to find the example). This is what I got: > > > > > > Assertion failed: (pkt->pkt.generic), function build_packet, file > > > build-packet.c , line 74. > > > > > > The same example seems to work with 1.4.1. The systems tested are > > > FreeBSD 5.4-STABLE and 6.0-BETA1, I was not able to test on a > > > different system, so I cannot say if this is OS specific. > > > > Try this patch. > > The patch doesn't apply, it's off by too many lines. After fixing this > however, I can't link because xmalloc_clear is not known. After adding > a dummy #define for xmalloc_clear in include/memory.h, things work out > fine. Thanks! > > What's the next version that will include this fix? Should I notify the > FreeBSD GnuPG port maintainer so he can add this patch to the 1.4.2 > port until the next version will be released? This will be fixed in 1.4.3. Here is a patch against 1.4.2 without all the fuzz. David -------------- next part -------------- Index: keygen.c =================================================================== --- keygen.c (revision 3850) +++ keygen.c (working copy) @@ -2688,7 +2688,14 @@ PACKET *pkt; pkt=m_alloc_clear(sizeof(*pkt)); - pkt->pkttype=PKT_NONE; + + /* We're not acually using a user ID here - this is just an + arbitrary choice. We delete it anyway. */ + + pkt->pkttype=PKT_USER_ID; + pkt->pkt.user_id=m_alloc_clear(sizeof *pkt->pkt.user_id); + pkt->pkt.user_id->ref=1; + *tree=new_kbnode(pkt); delete_kbnode(*tree); } From schierlm at gmx.de Thu Aug 4 22:47:46 2005 From: schierlm at gmx.de (Michael Schierl) Date: Thu Aug 4 22:45:13 2005 Subject: possible bug with --batch and 1.4.2 In-Reply-To: <20050804121544.0ac5f9ec.randomiadgf@fsck.ch> References: <20050804121544.0ac5f9ec.randomiadgf@fsck.ch> Message-ID: <42F27EF2.2010707@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tobias Roth schrieb: > Hi > > I tried out the --batch example from the DETAILS file (search for 'foo' > in that file to find the example). This is what I got: Hmm. Some question. Is it a bug of my program (i.e. have not caught incorrect inputs) or a bug in GPG when I trigger a gpg: Ohhhh jeeee: ... this is a bug with --batch --gen-key? If the latter: - - "Subkey-Type: fuckme" (or anything which is no valid algorithm) - - two "%commit" in series (without a key in between) are two cases I can remember where I triggered an assertion. And another (unrelated) one: when trying to set the ownertrust to 0 via - --edit-key. All in GPG 1.4.2. Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvJ+8Z2HdZ9YtIzdAQLcogf+JsTx4q0UBkT9vrsJCI0r3yMXLybLaAJn x7ZXiMo+5YeSLIjecqe/1EkwCdcIV++bnGomJaHplU3boqbB1Vy2Tsrzy79JdPno RtJ6VfulOVuryBcnCnJsHSdrv6nqBaEL6dSiN/W7zJp73Q8RpcYeL5lCwuQiYo27 ouukEcyyy9kjNedui5GNLXRipRsncZzDM4Fz5Gt4o2QdtWqMLhf8qWYLMn2igUJl x+FQyyFGQY/y1pXPkfzUdsCiIFyryR1VT624aKyjhgiSZudL3h1kQAdwh8gwe5vG rBXKJpdolJxFZJY20J9m7YHrxRNdl6ZS3SdWmyyfwlMbL94AiUZ7nQ== =PpH6 -----END PGP SIGNATURE----- From randomiadgf at fsck.ch Thu Aug 4 23:08:35 2005 From: randomiadgf at fsck.ch (Tobias Roth) Date: Thu Aug 4 23:03:59 2005 Subject: possible bug with --batch and 1.4.2 In-Reply-To: <42F27EF2.2010707@gmx.de> References: <20050804121544.0ac5f9ec.randomiadgf@fsck.ch> <42F27EF2.2010707@gmx.de> Message-ID: <20050804230835.42b20f27.randomiadgf@fsck.ch> On Thu, 04 Aug 2005 22:47:46 +0200 Michael Schierl wrote: > Hmm. Some question. Is it a bug of my program (i.e. have not caught > incorrect inputs) or a bug in GPG when I trigger a > > gpg: Ohhhh jeeee: ... this is a bug > > with --batch --gen-key? > > If the latter: > > - - "Subkey-Type: fuckme" (or anything which is no valid algorithm) > > - - two "%commit" in series (without a key in between) > > are two cases I can remember where I triggered an assertion. > > And another (unrelated) one: when trying to set the ownertrust to 0 > via > - --edit-key. Good programming style assumed, it is always a bug when an assertion is triggered. So my answer would be (though I am not a GnuPG programmer), these are all bugs in GnuPG and not your program. From dshaw at jabberwocky.com Thu Aug 4 23:14:40 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Aug 4 23:10:34 2005 Subject: possible bug with --batch and 1.4.2 In-Reply-To: <20050804202401.GA26520@jabberwocky.com> References: <20050804121544.0ac5f9ec.randomiadgf@fsck.ch> <20050804130724.GA14992@jabberwocky.com> <20050804220152.49a5079b.randomiadgf@fsck.ch> <20050804202401.GA26520@jabberwocky.com> Message-ID: <20050804211440.GA26558@jabberwocky.com> On Thu, Aug 04, 2005 at 04:24:01PM -0400, David Shaw wrote: > > The patch doesn't apply, it's off by too many lines. After fixing this > > however, I can't link because xmalloc_clear is not known. After adding > > a dummy #define for xmalloc_clear in include/memory.h, things work out > > fine. Thanks! > > > > What's the next version that will include this fix? Should I notify the > > FreeBSD GnuPG port maintainer so he can add this patch to the 1.4.2 > > port until the next version will be released? > > This will be fixed in 1.4.3. Here is a patch against 1.4.2 without > all the fuzz. Sorry - wrong patch. Use this one instead. David -------------- next part -------------- Index: keygen.c =================================================================== --- keygen.c (revision 3850) +++ keygen.c (working copy) @@ -3243,15 +3243,21 @@ static int write_keyblock( IOBUF out, KBNODE node ) { - for( ; node ; node = node->next ) { - int rc = build_packet( out, node->pkt ); - if( rc ) { - log_error("build_packet(%d) failed: %s\n", + for( ; node ; node = node->next ) + { + if(!is_deleted_kbnode(node)) + { + int rc = build_packet( out, node->pkt ); + if( rc ) + { + log_error("build_packet(%d) failed: %s\n", node->pkt->pkttype, g10_errstr(rc) ); - return G10ERR_WRITE_FILE; + return G10ERR_WRITE_FILE; + } } } - return 0; + + return 0; } From randomiadgf at fsck.ch Thu Aug 4 22:01:52 2005 From: randomiadgf at fsck.ch (Tobias Roth) Date: Thu Aug 4 23:34:00 2005 Subject: possible bug with --batch and 1.4.2 In-Reply-To: <20050804130724.GA14992@jabberwocky.com> References: <20050804121544.0ac5f9ec.randomiadgf@fsck.ch> <20050804130724.GA14992@jabberwocky.com> Message-ID: <20050804220152.49a5079b.randomiadgf@fsck.ch> On Thu, 4 Aug 2005 09:07:24 -0400 David Shaw wrote: > > I tried out the --batch example from the DETAILS file (search for > > 'foo' in that file to find the example). This is what I got: > > > > Assertion failed: (pkt->pkt.generic), function build_packet, file > > build-packet.c , line 74. > > > > The same example seems to work with 1.4.1. The systems tested are > > FreeBSD 5.4-STABLE and 6.0-BETA1, I was not able to test on a > > different system, so I cannot say if this is OS specific. > > Try this patch. The patch doesn't apply, it's off by too many lines. After fixing this however, I can't link because xmalloc_clear is not known. After adding a dummy #define for xmalloc_clear in include/memory.h, things work out fine. Thanks! What's the next version that will include this fix? Should I notify the FreeBSD GnuPG port maintainer so he can add this patch to the 1.4.2 port until the next version will be released? thanks, t. From dshaw at jabberwocky.com Fri Aug 5 05:30:30 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Aug 5 05:26:28 2005 Subject: possible bug with --batch and 1.4.2 In-Reply-To: <42F27EF2.2010707@gmx.de> References: <20050804121544.0ac5f9ec.randomiadgf@fsck.ch> <42F27EF2.2010707@gmx.de> Message-ID: <20050805033030.GD26900@jabberwocky.com> On Thu, Aug 04, 2005 at 10:47:46PM +0200, Michael Schierl wrote: > Tobias Roth schrieb: > > Hi > > > > I tried out the --batch example from the DETAILS file (search for 'foo' > > in that file to find the example). This is what I got: > > Hmm. Some question. Is it a bug of my program (i.e. have not caught > incorrect inputs) or a bug in GPG when I trigger a > > gpg: Ohhhh jeeee: ... this is a bug > > with --batch --gen-key? > > If the latter: > > - "Subkey-Type: fuckme" (or anything which is no valid algorithm) > > - two "%commit" in series (without a key in between) > > are two cases I can remember where I triggered an assertion. > > And another (unrelated) one: when trying to set the ownertrust to 0 via > --edit-key. > > All in GPG 1.4.2. Fixed, thanks. David From wk at gnupg.org Fri Aug 5 09:47:31 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Aug 5 09:46:23 2005 Subject: possible bug with --batch and 1.4.2 In-Reply-To: <20050804220152.49a5079b.randomiadgf@fsck.ch> (Tobias Roth's message of "Thu, 4 Aug 2005 22:01:52 +0200") References: <20050804121544.0ac5f9ec.randomiadgf@fsck.ch> <20050804130724.GA14992@jabberwocky.com> <20050804220152.49a5079b.randomiadgf@fsck.ch> Message-ID: <871x586d0s.fsf@wheatstone.g10code.de> On Thu, 4 Aug 2005 22:01:52 +0200, Tobias Roth said: > The patch doesn't apply, it's off by too many lines. After fixing this > however, I can't link because xmalloc_clear is not known. After adding For testing latest thing, please use the Subversion repository. Note, that we recently switched from CVS to SVN. Checking out the 1.4 is as simple as: svn co svn://cvs.gnupg.org/gnupg/trunk gnupg14 (the CVS is still ojline but clearly marked as outdated). Salam-Shalom, Werner From withjr at yahoo.com Fri Aug 5 11:16:44 2005 From: withjr at yahoo.com (withjr) Date: Fri Aug 5 12:07:14 2005 Subject: Help: GPG.exe in batch mode on windows Message-ID: Respected all, I m using GPG 1.4.1 In my mutlithreaded application made in MS Visual C++ 6, i m using GPG.exe as command line to generate keys, encrypt file for rcpt and decrypt for rcpt. As my application is multithreaded sometimes GPG fails to generate keys and fails to decrypt message.. i come to know this because when i import pub/private key after gen-key it returns empty file with -- output. and same for encryption it doesnt generates output files. following are commands that i m useing ////////////////////////// // for geneating key szCommandLine = "C:\\GNUPG\\gpg.exe --ignore-valid-from --ignore-time- conflict --batch --gen-key C:\\def.inc"; def.inc contains: Key-Type: DSA Key-Length: 1024 Subkey-Type: ELG-E Subkey-Length: 1024 Name-Real: TEEST Name-Comment: This is automated key Name-Email: test@... Expire-Date: 0 Passphrase: 123456890 ////////////////////////// // for encryption // import public key sCmd = "C:\\Gnupg\\gpg.exe --import --ignore-valid-from --ignore-time- conflict C:\\hispubkey.txt"; hispubkey.txt contains publickey of somebody@... // encrypt szEncryptCmd = "C:\\gnupg\\gpg.exe --armor --ignore-valid-from -- ignore-time-conflict --always-trust --output C:\\enText.txt -r " + somebody@... --encrypt C:\\plText.txt"; here it is not generating enText.txt Any help and suggestions. Thanks In Advance Jetli Raghu From heathjs21 at yahoo.com Fri Aug 5 21:34:01 2005 From: heathjs21 at yahoo.com (Heather Shaw) Date: Fri Aug 5 22:29:54 2005 Subject: Need example of HMAC SHA Message-ID: <20050805193401.42549.qmail@web30015.mail.mud.yahoo.com> I am a newbie to the gnupg software and am needing to utilize the HMAC/SHA features of the libcrypt package. Does someone have a quick & dirty example of this. Most of the examples I have found use the AES cipher and in looking through the documentation, I have been confused on how to implement the HMAC/SHA. I am trying to just encrypt/decrypt a basic string. Thanks for the help ~heather From mcsmurf at mcsmurf.de Sat Aug 6 12:59:04 2005 From: mcsmurf at mcsmurf.de (Frank Wein) Date: Sat Aug 6 13:49:40 2005 Subject: Problems receiving a key Message-ID: <42F497F8.8000603@mcsmurf.de> Hi, i think i found a problem (or maybe a bug? not sure :) when i want to receive a key from a keyserver. I use GnuPG 1.4.2 on Windows, no firewall installed. I try to get a public key from a keyserver via "gpg.exe --keyserver random.sks.keyserver.penguin.de --recv-keys 0xA70E6FCB". Well i press enter and wait and wait and... :-). I started Ethereal and noticed this: First it makes this HTTP Request GET /pks/lookup?op=get&options=mr&search=0xA70E6FCB HTTP/1.0 Host: random.sks.keyserver.penguin.de:11371 Then it gets back the first packet (which is until "3HZST") and the "packet" following it comes up in Ethereal with the flags FIN,ACK, "[TCP Previous segment lost]" and "[A segment before this frame was lost]". Then my PC responds with some ACK again and that's it, gpg seems to be waiting forever for some further data? If i open the URL http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&options=mr&search=0xA70E6FCB via a webbrowser with HTTP 1.0, it works. It seems to me some flags of the TCP packets (the ACK one) might be wrong, but then i need to complain on the MinGW Mailinglist? Frank From wk at gnupg.org Sun Aug 7 14:07:02 2005 From: wk at gnupg.org (Werner Koch) Date: Sun Aug 7 14:06:30 2005 Subject: Need example of HMAC SHA In-Reply-To: <20050805193401.42549.qmail@web30015.mail.mud.yahoo.com> (Heather Shaw's message of "Fri, 5 Aug 2005 12:34:01 -0700 (PDT)") References: <20050805193401.42549.qmail@web30015.mail.mud.yahoo.com> Message-ID: <877jeyymqh.fsf@wheatstone.g10code.de> On Fri, 5 Aug 2005 12:34:01 -0700 (PDT), Heather Shaw said: > I am a newbie to the gnupg software and am needing to > utilize the HMAC/SHA features of the libcrypt package. > Does someone have a quick & dirty example of this. > Most of the examples I have found use the AES cipher > and in looking through the documentation, I have been > confused on how to implement the HMAC/SHA. I am > trying to just encrypt/decrypt a basic string. The HMAC construction requires a hash algorithnm and not a cipher algorithm. Some code snippets: Create a hash context: err = gcry_md_open (&ctx->send_mac, ctx->mac_algo, GCRY_MD_FLAG_HMAC); if (!err) err = gcry_md_setkey (ctx->send_mac, gsti_bstr_data (ctx->kex.mac_f), gsti_bstr_length (ctx->kex.mac_f)); mac_algo might be GCRY_MD_SHA1. Then hash the data and finally: static size_t generate_mac (gsti_ctx_t ctx, struct packet_buffer_s *pkt, u32 seqno) { gcry_md_hd_t md; byte buf[4]; byte *p = pkt->packet_buffer; size_t n = 5 + pkt->payload_len + pkt->padding_len; if (!ctx->send_mac) return 0; /* no MAC requested */ if (gcry_md_copy (&md, ctx->send_mac)) return 0; buf[0] = seqno >> 24; buf[1] = seqno >> 16; buf[2] = seqno >> 8; buf[3] = seqno; gcry_md_write (md, buf, 4); gcry_md_write (md, p, n); gcry_md_final (md); memcpy (p + n, gcry_md_read (md, 0), ctx->mac_len); gcry_md_close (md); return ctx->mac_len; } That example is from an Secure Shell library (GSTI). Salam-Shalom, Werner From wk at gnupg.org Sun Aug 7 14:48:56 2005 From: wk at gnupg.org (Werner Koch) Date: Sun Aug 7 14:46:29 2005 Subject: Proof of email ownership In-Reply-To: <42F3DBF1.7070701@post.cz> (David Srbecky's message of "Fri, 05 Aug 2005 23:36:49 +0200") References: <42F3DBF1.7070701@post.cz> Message-ID: <873bplzzd3.fsf@wheatstone.g10code.de> Hi! Let me note that I am currently working on a simplified key validation scheme. The basic idea is to connect a signature to an DNS entry. Our assumption is that DNS is secure and unforgeable - as of now it is not but eventually DNSSEC will get deployed to solve this and many other problems. Here is how it works: To create a signature on an email (or any other data) you would use: gpg -s -Npka-address@gnupg.org=werner@example.org foo (add other options as you see fit). Now when someone wants to verify the signature he does it using the usual gpg --verify foo.gpg gpg detects that foo.gpg has the notation key pka-address@gnupg.org and takes its value (werner@example.org) to run a DNS query like: $ host -t txt werner._pka.example.org werner._pka.example.org text "v=pka1\;fpr=A4D94E92B0986AB5EE9DC\ D755DE249965B0358A2\;uri=finger:wk@example.com" Now it compares the fingerprint given in that Text record against the one of the public key used to verify the signature. If they match, it has been proved that the mail address werner@example.org is a legitimate address in the domain example.org. If not, someone tried to use a faked key. As of now we use the outcome of this test to change the validity status of the key either to FULL or to NEVER (if they don't match). A MUA - or an MTA - may now display the verified address werner@example.org to the user and compare it to the From address. Will will likely add ptions to gpg to make this easier. As a bonus we also put the URI part into the TXT record to allow the specification of a keyserver or whatever to retrieve the public key. gpg uses this during signature verification as well when collecting the recipients of a message; i.e. if you use "-r joe@example.org" it would try to locate a PKA record for joe (joe._pka.example.org) and use this for key validation as well as to retrieve the key for joe. If you want to play with this feature, you need to build the latest Subversion of gpg and put keyserver-options auto-pka-retrieve into your gpg.conf. For real PKA records, replace example.org by fsfe.org. If this all works out well, we might want to apply for a dedicated DNS record type instead of using TXT. The scheme may also be used for S/MIME. Shalom-Salam, Werner From wk at gnupg.org Mon Aug 8 09:04:55 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 8 09:01:34 2005 Subject: Proof of email ownership In-Reply-To: <20050807141713.35742.qmail@web33904.mail.mud.yahoo.com> (S. K.'s message of "Sun, 7 Aug 2005 07:17:13 -0700 (PDT)") References: <20050807141713.35742.qmail@web33904.mail.mud.yahoo.com> Message-ID: <87br48ykmg.fsf@wheatstone.g10code.de> On Sun, 7 Aug 2005 07:17:13 -0700 (PDT), S K said: > How would this work out for people who do not have > control over the DNS record of domains? Best examples > are free email services like hotmail and gmail? Convince them to have a feature for upload a key or a key's fingerprint into the user settings. Then they can generate a zone file from it. Shalom-Salam, Werner From berndj at prism.co.za Mon Aug 8 09:37:10 2005 From: berndj at prism.co.za (Bernd Jendrissek) Date: Mon Aug 8 10:28:36 2005 Subject: Proof of email ownership In-Reply-To: <873bplzzd3.fsf@wheatstone.g10code.de> References: <42F3DBF1.7070701@post.cz> <873bplzzd3.fsf@wheatstone.g10code.de> Message-ID: <20050808073710.GA20235@prism.co.za> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Aug 07, 2005 at 02:48:56PM +0200, Werner Koch wrote: > gpg detects that foo.gpg has the notation key pka-address@gnupg.org > and takes its value (werner@example.org) to run a DNS query like: > > $ host -t txt werner._pka.example.org > werner._pka.example.org text "v=pka1\;fpr=A4D94E92B0986AB5EE9DC\ > D755DE249965B0358A2\;uri=finger:wk@example.com" > > Now it compares the fingerprint given in that Text record against the ^^^ ^^^^ Do these TXT records support having multiple keys associated with the same email address? For example, I use D7CBA633 for "everyday" signing and encryption, and 24EEB426 for tin foil hat applications. [Yes, I know I should start using a newer GnuPG.] - -- > BTW, sometimes the lack of a specific response indicates *agreement*. Just in case you thought I was agreeing with you. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFC9wuX/FmLrNfLpjMRAvYZAKCIb6kJOq45fSwHpR5DH11wQShG3ACfa+G7 GXE0m2WUf28NkcvUP1hlEUw= =51r3 -----END PGP SIGNATURE----- From schierlm at gmx.de Mon Aug 8 10:58:24 2005 From: schierlm at gmx.de (Michael Schierl) Date: Mon Aug 8 10:55:42 2005 Subject: How to list keys and revcerts in a file without doing anything with them? Message-ID: <42F71EB0.8020606@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Given is a text file (actually the clipboard contents) that may contain - - among other things that should be ignored - keys and revocation certificates. How do I list the contents of that file? I do not intend to import the contents directly into my primary keyring, so my current solution is to import everything into a new empty keyring and then list its contents. Problem: I do not get the revocation certificates since my empty keyring obviously does not contain their secret keys. They create a short notice on import to stdout, but that one is quite hard to parse from all the information "flying by". Alternative solution, just to use gpg without parameters. That one does not import anything, but it may start decrypting or verifying other stuff in that file (which I don't like since that may ask for passphrases, which is even more parsing...) - --list-packets is quite a lot of info and not really easier to parse. The only obvious option that is left for me is to add an "Edit->Paste directly" command that allows to import revocation certificates, but without any confirmation. Does anyone know any simple way or command line switch i missed? Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvcer52HdZ9YtIzdAQK4bgf9HJjieJA5KrMSaArDskbQU2teHUwkAHHm uXE/lPqwIX2K2cK3fs+m3vJkwqNa8WSZvlQtDTuGpBiDL4UUWvUC7xymqwwHW3i3 X6W/3vdleBTjV5b6FunqXjK6E7QEhFFai5/6c3BkqeCZzz1EinSHspr8mOHRPPOX WB0JAVK/Rs+IBpzPp8qyf0eyH6+JHhodIUrea5AK6aN9rmaZHiI3wRGAdvYg1ri8 clQwidO3rjozC6ZcSn2BYeYg5UnrbS/P7+DhI6iL3bIEM9gzvjK/99klr9M+rczp AaCtKxHtSsyU7ObVGSC72HOOglSQCarGvD8sm9+vNDmcfj/+kOVy0g== =4vH1 -----END PGP SIGNATURE----- From wk at gnupg.org Mon Aug 8 12:37:04 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 8 12:36:36 2005 Subject: Proof of email ownership In-Reply-To: <20050808073710.GA20235@prism.co.za> (Bernd Jendrissek's message of "Mon, 8 Aug 2005 09:37:10 +0200") References: <42F3DBF1.7070701@post.cz> <873bplzzd3.fsf@wheatstone.g10code.de> <20050808073710.GA20235@prism.co.za> Message-ID: <87ek94ww8f.fsf@wheatstone.g10code.de> On Mon, 8 Aug 2005 09:37:10 +0200, Bernd Jendrissek said: > Do these TXT records support having multiple keys associated with the > same email address? For example, I use D7CBA633 for "everyday" signing > and encryption, and 24EEB426 for tin foil hat applications. No. I can be extended to allow for this. The current implementation with TXT records should be considered experimental. Shalom-Salam, Werner From jas at extundo.com Mon Aug 8 14:26:47 2005 From: jas at extundo.com (Simon Josefsson) Date: Mon Aug 8 14:33:09 2005 Subject: Proof of email ownership In-Reply-To: <873bplzzd3.fsf__47521.913299761$1123419179$gmane$org@wheatstone.g10code.de> (Werner Koch's message of "Sun, 07 Aug 2005 14:48:56 +0200") References: <42F3DBF1.7070701@post.cz> <873bplzzd3.fsf__47521.913299761$1123419179$gmane$org@wheatstone.g10code.de> Message-ID: Werner Koch writes: > Let me note that I am currently working on a simplified key validation > scheme. The basic idea is to connect a signature to an DNS entry. Wonderful idea! > To create a signature on an email (or any other data) you would use: > > gpg -s -Npka-address@gnupg.org=werner@example.org foo I'm experimenting with making this easy to use in Gnus. Would it be possible to make it possible to specify the -N stuff through gpg.conf too? That may be simpler for users with old MUAs that hasn't been updated to support adding that parameter. Meanwhile, something like this seem to be what you need in Gnus: (setq pgg-gpg-extra-args '("-Npka-address@gnupg.org=jas@extundo.com")) Thanks, Simon From jas at extundo.com Mon Aug 8 14:03:07 2005 From: jas at extundo.com (Simon Josefsson) Date: Mon Aug 8 14:33:20 2005 Subject: Proof of email ownership In-Reply-To: <87ek94ww8f.fsf__24143.8634846874$1123497820$gmane$org@wheatstone.g10code.de> (Werner Koch's message of "Mon, 08 Aug 2005 12:37:04 +0200") References: <42F3DBF1.7070701@post.cz> <873bplzzd3.fsf@wheatstone.g10code.de> <20050808073710.GA20235@prism.co.za> <87ek94ww8f.fsf__24143.8634846874$1123497820$gmane$org@wheatstone.g10code.de> Message-ID: Werner Koch writes: > On Mon, 8 Aug 2005 09:37:10 +0200, Bernd Jendrissek said: > >> Do these TXT records support having multiple keys associated with the >> same email address? For example, I use D7CBA633 for "everyday" signing >> and encryption, and 24EEB426 for tin foil hat applications. > > No. I can be extended to allow for this. The current implementation > with TXT records should be considered experimental. You could have multiple TXT records, one for each key. Would that work? From wk at gnupg.org Mon Aug 8 15:29:51 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 8 15:26:27 2005 Subject: Proof of email ownership In-Reply-To: (Simon Josefsson's message of "Mon, 08 Aug 2005 14:26:47 +0200") References: <42F3DBF1.7070701@post.cz> <873bplzzd3.fsf__47521.913299761$1123419179$gmane$org@wheatstone.g10code.de> Message-ID: <87wtmwv9o0.fsf@wheatstone.g10code.de> On Mon, 08 Aug 2005 14:26:47 +0200, Simon Josefsson said: > I'm experimenting with making this easy to use in Gnus. Would it be > possible to make it possible to specify the -N stuff through gpg.conf Put sig-notation pka-address=foo@bar into your gpg.conf. This creates notation data for all data signatures. Shalom-Salam, Werner From jas at extundo.com Mon Aug 8 15:47:27 2005 From: jas at extundo.com (Simon Josefsson) Date: Mon Aug 8 15:43:06 2005 Subject: Proof of email ownership In-Reply-To: <87wtmwv9o0.fsf@wheatstone.g10code.de> (Werner Koch's message of "Mon, 08 Aug 2005 15:29:51 +0200") References: <42F3DBF1.7070701@post.cz> <873bplzzd3.fsf__47521.913299761$1123419179$gmane$org@wheatstone.g10code.de> <87wtmwv9o0.fsf@wheatstone.g10code.de> Message-ID: Werner Koch writes: > On Mon, 08 Aug 2005 14:26:47 +0200, Simon Josefsson said: > >> I'm experimenting with making this easy to use in Gnus. Would it be >> possible to make it possible to specify the -N stuff through gpg.conf > > Put > > sig-notation pka-address=foo@bar > > into your gpg.conf. This creates notation data for all data > signatures. I got: gpg: a user notation name must contain the ?@? character For reference, I assume that you meant: sig-notation pka-address@gnupg.org=foo@bar Experimenting more with it now... Thanks, Simon From rdieter at math.unl.edu Mon Aug 8 22:27:39 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon Aug 8 22:58:54 2005 Subject: gpgme-1.0.3: 'make check' fails Message-ID: <42F7C03B.4020803@math.unl.edu> I've tried building gpgme-1.0.3 on both Red Hat 9 (gcc-3.2.2) and Fedora Core 4 (gcc-4.0.1), and they both fail 1 test in 'make check': Making check in gpgsm make[3]: Entering directory `/usr/local/tmp/BUILD/gpgme-1.0.3/tests/gpgsm' make check-TESTS make[4]: Entering directory `/usr/local/tmp/BUILD/gpgme-1.0.3/tests/gpgsm' PASS: t-import Key has unexpected number of user IDs FAIL: t-keylist -----BEGIN ENCRYPTED MESSAGE----- MIAGCSqGSIb3DQEHA6CAMIACAQAxggEJMIIBBQIBADBwMGsxCzAJBgNVBAYTAkRF MRMwEQYDVQQHFApE/HNzZWxkb3JmMRYwFAYDVQQKEw1nMTAgQ29kZSBHbWJIMRkw FwYDVQQLExBBZWd5cHRlbiBQcm9qZWN0MRQwEgYDVQQDEwt0ZXN0IGNlcnQgMQIB ADALBgkqhkiG9w0BAQEEgYBVb6KmQtpWDi/YI7pE1i3XNd17WIix009hJw/Bx06p jil3/Sp20nGKs7k9IUMcHXgdYXSnvFU4Vypi9vjXjnmCtngE1h6ELTKdNBJ/W8zv fjvw21IkuF2pHlYqzyZbiVJZAoZ9AZS+WBst6QHPpsddNhhQk7jkAVHuUhvdUR4k GDCABgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECPk1RRWWDvKDoIAECH42hA4Ru/Fv BAiJy51oUK0BcgAAAAAAAAAAAAA= -----END ENCRYPTED MESSAGE----- From withjr at yahoo.com Fri Aug 5 07:32:03 2005 From: withjr at yahoo.com (withjr) Date: Tue Aug 9 13:26:31 2005 Subject: Help: GPG.exe in batch mode on windows Message-ID: Respected all, I m using GPG 1.4.1 In my mutlithreaded application made in MS Visual C++ 6, i m using GPG.exe as command line to generate keys, encrypt file for rcpt and decrypt for rcpt. As my application is multithreaded sometimes GPG fails to generate keys and fails to decrypt message.. i come to know this because when i import pub/private key after gen-key it returns empty file with -- output. and same for encryption it doesnt generates output files. following are commands that i m useing ////////////////////////// // for geneating key szCommandLine = "C:\\GNUPG\\gpg.exe --ignore-valid-from --ignore-time- conflict --batch --gen-key C:\\def.inc"; def.inc contains: Key-Type: DSA Key-Length: 1024 Subkey-Type: ELG-E Subkey-Length: 1024 Name-Real: TEEST Name-Comment: This is automated key Name-Email: test@test.com Expire-Date: 0 Passphrase: 123456890 ////////////////////////// // for encryption // import public key sCmd = "C:\\Gnupg\\gpg.exe --import --ignore-valid-from --ignore-time- conflict C:\\hispubkey.txt"; hispubkey.txt contains publickey of somebody@test.com // encrypt szEncryptCmd = "C:\\gnupg\\gpg.exe --armor --ignore-valid-from -- ignore-time-conflict --always-trust --output C:\\enText.txt -r " + somebody@test.com --encrypt C:\\plText.txt"; here it is not generating enText.txt Any help and suggestions. Thanks In Advance Jay Chadderwala From schierlm at gmx.de Tue Aug 2 00:29:53 2005 From: schierlm at gmx.de (Michael Schierl) Date: Tue Aug 9 13:26:36 2005 Subject: Photo UIDs on --attribute-fd on Windows and strange LF->CRLF conversions Message-ID: <42EEA261.5070904@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [please CC: me since I am not on the list] Hi, next "problem" with photo uids: ************* cut here ********* C:\temp>gpg --homedir \temp --edit-key JPEG gpg (GnuPG) 1.4.2; Copyright (C) 2005 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Secret key is available. pub 1024D/835DE7D3 created: 2005-08-01 expires: never usage: CS trust: ultimate validity: ultimate sub 1024g/023605A9 created: 2005-08-01 expires: never usage: E [ultimate] (1). JPEG Test Command> addphoto [...] Enter JPEG filename for photo ID: c:\temp\1px.jpg Is this photo correct (y/N/q)? y You need a passphrase to unlock the secret key for user: "JPEG Test " 1024-bit DSA key, ID 835DE7D3, created 2005-08-01 pub 1024D/835DE7D3 created: 2005-08-01 expires: never usage: CS trust: ultimate validity: ultimate sub 1024g/023605A9 created: 2005-08-01 expires: never usage: E [ultimate] (1). JPEG Test [ unknown] (2) [jpeg image of size 634] Command> q Save changes? (y/N) y C:\temp>gpg --homedir \temp --status-fd 1 --attribute-fd 1 --list-keys JPEG >new.dat ********** cut here ********** When trying to find the original image from the new.dat file, it seems that every 0x0a byte (line feed) inside the image is mangled to a 0x0d 0x0a. The length mentioned in the "ATTRIBUTES" line mentiones the decoded length. So decoding is a bit tricky, especially since when you read a 0x0d as last byte, you do not know whether to stop (i. e. it was a 0x0d byte) or not (if a 0x0a byte follows, it has been a 0x0a byte). If this is intentional, it should be documented somewhere, and there should be some way for the client program to detect this (so that the same program works on Windows and on other OSes). But IMHO it should be simply fixed (no LF->CRLF in binary data). (JFTR: The exactly same effect appears when I do this by creating a new process (from Java) and reading its stdout - so it is not some odd conversion done by the shell.) Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQu6iYJ2HdZ9YtIzdAQIo+Qf8DxO714puc3Kbrc2K7C0wNkGPpClQJfzo uNMc1WhDrLhyFESNgxRXAIEGLT2yr8dPfOOdpOcDw1Rz8EElUxMu6mA8o0St13QU pWiDMJlHy8Dl3rOc4YYvTCpVRRoVKq2HkSSvu98+Hj/+oflkiQmLE3GQZUoXoSL5 xvjLpRINkE+6BoULKhW41zqlsymtGouAvVE3yc434CeMaIem2Hm2on29RGNGmXHb 4vTe27Nwtti4n+8+GkKORHP3xCq5c/tC2vqcy2+4IEfpbput+aHogQVNJT3ENPML kORnZF5LzSg3F1KGDuYepPzicCOf0+Dmtqrfjf5k6OQZL9vYniAFJA== =BXB8 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: new.dat Type: application/octet-stream Size: 906 bytes Desc: not available Url : /pipermail/attachments/20050802/7737f411/new.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: 1px.jpg Type: image/jpeg Size: 634 bytes Desc: not available Url : /pipermail/attachments/20050802/7737f411/1px.jpg From schierlm at gmx.de Tue Aug 2 00:05:43 2005 From: schierlm at gmx.de (Michael Schierl) Date: Tue Aug 9 13:26:38 2005 Subject: Revoking key signatures via --command-fd and --status-fd problem Message-ID: <42EE9CB7.40504@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [please CC: me since I am not on the list] Hi, I am trying to write a "bug-for-bug-compliant" GUI (in Java) that resembles PGP 8's GPGkeys thing. But revoking signatures is somehow ugly: C:\Documents and Settings\Michi>gpg --batch --homedir \temp - --with-colons --comm and-fd 0 --status-fd 1 --edit-key aba Secret key is available. pub:u:1024:17:3A877DCDD01A78A2:1122902145:0::u: fpr:::::::::CBF8A910AB3565E33DB65EDA3A877DCDD01A78A2: sub:u:1024:16:04B0C17ED6D2BCE1:1122902151:0::: fpr:::::::::C6DBCAB72336CE5020641F3004B0C17ED6D2BCE1: uid:u::::::::aba:::S9 S8 S7 S3 S2 H2 H3 Z2 Z1,mdc,no-ks-modify:1,p: [GNUPG:] GET_LINE keyedit.prompt revsig [GNUPG:] GOT_IT You have signed these user IDs on key D01A78A2: aba revoked by your key F067E553 on 2005-08-01 signed by your key D01A78A2 on 2005-08-01 signed by your key F067E553 on 2005-08-01 signed by your key 6708FE7A on 2005-08-01 (non-exportable) user ID: "aba" signed by your key D01A78A2 on 2005-08-01 [GNUPG:] GET_BOOL ask_revoke_sig.one y [GNUPG:] GOT_IT user ID: "aba" signed by your key F067E553 on 2005-08-01 [GNUPG:] GET_BOOL ask_revoke_sig.one y [GNUPG:] GOT_IT user ID: "aba" signed by your key 6708FE7A on 2005-08-01 (non-exportable) [GNUPG:] GET_BOOL ask_revoke_sig.one y [GNUPG:] GOT_IT You are about to revoke these signatures: aba signed by your key D01A78A2 on 2005-08-01 signed by your key F067E553 on 2005-08-01 signed by your key 6708FE7A on 2005-08-01 (non-exportable) [GNUPG:] GET_BOOL ask_revoke_sig.okay y [GNUPG:] GOT_IT But: with-colons should make the output a bit more parsable, I guess? Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQu6ctp2HdZ9YtIzdAQKhNwf/YN6qJ+5TRczAC6ofG6oVdNKQ1LQRSMtJ kAvo6SrZheoIuT9Kk7o3d3As1S4ULPFKYK1B+fVhFP5NWcL4TUHUipKi7ZPvMVkN H/xqzJgIpZ3CWhDLfwC4s8DC3hf54Jz+97EBANK3sWOYVNeB3tCxFE4zHgO38+kF sT4tnoj9CzxHc5fNuNXLhXZ7fUa0J9tZiVNtzG1M3kTyFo7/vXs+OBZgRFAkJqti Quq5izHYtgSK+7tLgxaxx94+E+z82QWXOZFGlA0xzHjHz8w1KutB/sspH2RxhVv/ eylS03hlVjGgIw7Z9zyfdlsK+tcNHK7OQKEzU69ERGwXbjP5z/qy4w== =MEko -----END PGP SIGNATURE----- From amoselberg at myrealbox.com Sat Aug 6 22:07:18 2005 From: amoselberg at myrealbox.com (Amos B. Elberg) Date: Tue Aug 9 13:26:48 2005 Subject: Batch Key Generation Bug in 1.4.2 Message-ID: <48ph3g$23iln3@smtp05.mrf.mail.rcn.net> Hi. I get the following error when trying to batch generate keys in 1.4.2, which did not occur in 1.4.1: aelber@NetworkStore premail $ gpg --batch --gen-key Key-Type: DSA Key-Length: 1024 Subkey-Type: ELG-E Subkey-Length: 1024 Name-Email: test_of_batch@none Expire-Date: 0 %pubring /home/user/aelber/pubtest.gpg %secring /home/user/aelber/sectest.gpg %commit +++++++++++++++.++++++++++...+++++++++++++++.++++++++++.++++++++++..++++++++ ++++++++++++++++++++++.+++++.+++++.+++++++++++++++++++++++++..+++++>+++++..+ ++++>+++++<+++++..........+++++ +++++++++++++++++++++++++++++++++++++++++++++.+++++.++++++++++++++++++++++++ ++++++++++++++++.+++++++++++++++.++++++++++..+++++++++++++++...>.+++++...... ...+++++^^^ gpg: build-packet.c:74: build_packet: Assertion `pkt->pkt.generic' failed. Aborted If you need any info about this, or have any suggestions, please let me know. From sk4list at yahoo.com Sun Aug 7 16:17:13 2005 From: sk4list at yahoo.com (S K) Date: Tue Aug 9 13:26:51 2005 Subject: Proof of email ownership In-Reply-To: <873bplzzd3.fsf@wheatstone.g10code.de> Message-ID: <20050807141713.35742.qmail@web33904.mail.mud.yahoo.com> How would this work out for people who do not have control over the DNS record of domains? Best examples are free email services like hotmail and gmail? -SK --- Werner Koch wrote: > Hi! > > Let me note that I am currently working on a > simplified key validation > scheme. The basic idea is to connect a signature to > an DNS entry. > > Our assumption is that DNS is secure and unforgeable > - as of now it is > not but eventually DNSSEC will get deployed to solve > this and many other > problems. > > Here is how it works: > > To create a signature on an email (or any other > data) you would use: > > gpg -s -Npka-address@gnupg.org=werner@example.org > foo > > (add other options as you see fit). Now when someone > wants to verify > the signature he does it using the usual > > gpg --verify foo.gpg > > gpg detects that foo.gpg has the notation key > pka-address@gnupg.org > and takes its value (werner@example.org) to run a > DNS query like: > > $ host -t txt werner._pka.example.org > werner._pka.example.org text > "v=pka1\;fpr=A4D94E92B0986AB5EE9DC\ > D755DE249965B0358A2\;uri=finger:wk@example.com" > > Now it compares the fingerprint given in that Text > record against the > one of the public key used to verify the signature. > If they match, it > has been proved that the mail address > werner@example.org is a > legitimate address in the domain example.org. If > not, someone tried > to use a faked key. As of now we use the outcome of > this test to > change the validity status of the key either to FULL > or to NEVER (if > they don't match). > > A MUA - or an MTA - may now display the verified > address > werner@example.org to the user and compare it to the > From address. > Will will likely add ptions to gpg to make this > easier. > > As a bonus we also put the URI part into the TXT > record to allow the > specification of a keyserver or whatever to retrieve > the public key. > gpg uses this during signature verification as well > when collecting > the recipients of a message; i.e. if you use "-r > joe@example.org" it > would try to locate a PKA record for joe > (joe._pka.example.org) and > use this for key validation as well as to retrieve > the key for joe. > > If you want to play with this feature, you need to > build the latest > Subversion of gpg and put > > keyserver-options auto-pka-retrieve > > into your gpg.conf. For real PKA records, replace > example.org by > fsfe.org. If this all works out well, we might want > to apply for a > dedicated DNS record type instead of using TXT. The > scheme may also be > used for S/MIME. > > > Shalom-Salam, > > Werner > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From harry_b at mm.st Fri Aug 5 19:07:54 2005 From: harry_b at mm.st (harry_b@mm.st) Date: Tue Aug 9 13:26:56 2005 Subject: GPG/GPGME problem Message-ID: <1123261674.1504.240068676@webmail.messagingengine.com> Hi there, I am pretty confused about a problem with gpg and gpgme. I am working on an encryption program and for this I wrote some test sequences which now give me a hard time. Every 1000 runs or so, the following steps produce a weird error which even gpg itself messes up. :-/ I am on Debian unstable and use GPG 1.4.1 and gpgme 1.0.2. My test runs these steps: 1. Create some random XML data file 2. gzip this file (as my application does using zlib) $ gzip -9 FILE_A 3. encode it with a testkey $ echo "1234567890" | GNUPGHOME=./tests GPG_AGENT_INFO= gpg --no-tty --recipient="TESTKEY" --passphrase-fd 0 --armour --sign --encrypt --output="FILE_B" "FILE_A" 4. run my application and see if it can decrypt the file and write the same data again 5. compare the gpg file with my own file The problem now is, that even gpg can't decrypt it's own file FILE_B. I tried this with several keys and it happens with all of my keys. :-( I get these two errors: - gpg reports: gpg: [don't know]: invalid packet (ctb=14) - gpgme reports: Unexpected signature summary: 0x800 The weird thing is, that it seems to depend on the data which I create pretty randomly with a little perl script. Any ideas what I can do about this very weird thing? Harry PS: Some of these buggy files are in the attached tar.gz file. -------------- next part -------------- A non-text attachment was scrubbed... Name: buggy-files.tar.gz Type: application/x-gzip Size: 149333 bytes Desc: not available Url : /pipermail/attachments/20050805/c00bbff8/buggy-files.tar-0001.bin From md at Linux.IT Mon Aug 8 20:34:33 2005 From: md at Linux.IT (Marco d'Itri) Date: Tue Aug 9 13:26:59 2005 Subject: Proof of email ownership In-Reply-To: <87br48ykmg.fsf@wheatstone.g10code.de> References: <20050807141713.35742.qmail@web33904.mail.mud.yahoo.com> <87br48ykmg.fsf@wheatstone.g10code.de> Message-ID: <20050808183433.GB9880@wonderland.linux.it> How does this interact with DKIM? -- ciao, Marco From alex at bofh.net.pl Tue Aug 9 13:12:27 2005 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Tue Aug 9 13:59:04 2005 Subject: keyring thrashed Message-ID: <20050809111226.GA14687@syjon.fantastyka.net> I'm not sure if I should write here or to gnupg-users, but during migration to 1.4.2 on my main gnupg installation it has become unusable. Sidenote: various versions of gnupg has been used over this .gnupg directory (which is backed up) and that could lead to the corruption. Anyway. I migrated the installation to 1.4.2, did a few minor operations, then issued gpg -kvv |less to see contents of the keyring (which is quite big). Then it screamed about out of bounds MPI, started displaying lots of duplicate keys. Now it is unable to rebuild trustdb at all. The keyring in question is about 10 megabytes so I do not append it to this message. I also do not want to publish it since there is a quite a chunk of personal info in addressess, but I can put it online encrypted to someone of the team who would be interested in looking into the problem. I plan to split the keyring into individual keys, then rebuild it from scratch, but I'd lose local signatures this way. Is there a way to do not lose locasigs on import? Alex -- mors ab alto 0x46399138 From wk at gnupg.org Tue Aug 9 15:22:58 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Aug 9 15:21:28 2005 Subject: Proof of email ownership In-Reply-To: <20050808183433.GB9880@wonderland.linux.it> (Marco d'Itri's message of "Mon, 8 Aug 2005 20:34:33 +0200") References: <20050807141713.35742.qmail@web33904.mail.mud.yahoo.com> <87br48ykmg.fsf@wheatstone.g10code.de> <20050808183433.GB9880@wonderland.linux.it> Message-ID: <87acjrtfbh.fsf@wheatstone.g10code.de> On Mon, 8 Aug 2005 20:34:33 +0200, Marco d'Itri said: > How does this interact with DKIM? DKIM does not work. For example, their canonicalization is broken and one can easily fake a MIME message. Shalom-Salam, Werner From wk at gnupg.org Tue Aug 9 15:23:56 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Aug 9 15:21:52 2005 Subject: Batch Key Generation Bug in 1.4.2 In-Reply-To: <48ph3g$23iln3@smtp05.mrf.mail.rcn.net> (Amos B. Elberg's message of "Sat, 6 Aug 2005 16:07:18 -0400") References: <48ph3g$23iln3@smtp05.mrf.mail.rcn.net> Message-ID: <8764uftf9v.fsf@wheatstone.g10code.de> On Sat, 6 Aug 2005 16:07:18 -0400, Amos B Elberg said: > gpg: build-packet.c:74: build_packet: Assertion `pkt->pkt.generic' failed. Has already been fixed in CVS. David posted a patch a couple of days ago. Salam-Shalom, Werner From schierlm at gmx.de Tue Aug 9 16:37:57 2005 From: schierlm at gmx.de (Michael Schierl) Date: Tue Aug 9 16:35:16 2005 Subject: keyring thrashed In-Reply-To: <20050809111226.GA14687@syjon.fantastyka.net> References: <20050809111226.GA14687@syjon.fantastyka.net> Message-ID: <42F8BFC5.5070504@gmx.de> Janusz A. Urbanowicz schrieb: > I plan to split the keyring into individual keys, then rebuild it from > scratch, but I'd lose local signatures this way. Is there a way to do not > lose locasigs on import? from the man page: | --import-options parameters | This is a space or comma delimited string that gives options | for importing keys. Options can be prepended with a `no-' to | give the opposite meaning. The options are: | | import-local-sigs | Allow importing key signatures marked as "local". | This is not generally useful unless a shared | keyring scheme is being used. Defaults to no. | --export-options parameters | This is a space or comma delimited string that gives options | for exporting keys. Options can be prepended with a `no-' to | give the opposite meaning. The options are: | | export-local-sigs | Allow exporting key signatures marked as "local". | This is not generally useful unless a shared | keyring scheme is being used. Defaults to no. Michael From alex at bofh.net.pl Tue Aug 9 19:05:25 2005 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Tue Aug 9 19:01:07 2005 Subject: Proof of email ownership In-Reply-To: <873bplzzd3.fsf@wheatstone.g10code.de> References: <42F3DBF1.7070701@post.cz> <873bplzzd3.fsf@wheatstone.g10code.de> Message-ID: <20050809170525.GA21785@syjon.fantastyka.net> On Sun, Aug 07, 2005 at 02:48:56PM +0200, Werner Koch wrote: > Hi! > > Let me note that I am currently working on a simplified key validation > scheme. The basic idea is to connect a signature to an DNS entry. > > Our assumption is that DNS is secure and unforgeable - as of now it is > not but eventually DNSSEC will get deployed to solve this and many other > problems. This is the one assumption I can't accept. DNSSEC deployment is going slower than IPv6 adaptation, and for many years this is the tehcnology that will be adopted RSN. What is the exact purpose of the scheme, even assuming we have unforgeable DNS - it seems not very clear to me? Alex -- mors ab alto 0x46399138 From rdieter at math.unl.edu Tue Aug 9 19:35:24 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue Aug 9 19:30:51 2005 Subject: gnupg2-1.9.18: 'make check' fails on x86_64 Message-ID: <42F8E95C.6040606@math.unl.edu> Trying to build gnupg2-1.9.18 on Fedora Core 4/x86_64 (gcc-4.0.1) fails in 'make check': Any ideas? Full build log: http://buildsys.fedoraproject.org/logs//development/538-gnupg2-1.9.18-1.fc5/x86_64/build.log Relavent snippet: make check-TESTS make[2]: Entering directory `/builddir/build/BUILD/gnupg-1.9.18/tests' gpgsm: WARNING: running with faked system time: 2002-12-02 13:29:59 read_assuan: read "OK GNU Privacy Guard's S/M server 1.9.18 ready" read_assuan: read " " sending `INPUT FD=5' expecting OK read_assuan: read "OK" read_assuan: read " " sending `OUTPUT FD=6' expecting OK read_assuan: read "OK" read_assuan: read " " sending `SIGN' expecting OK gpgsm: can't connect to `/builddir/build/BUILD/gnupg-1.9.18/tests/S.gpg-agent': No such file or directory gpgsm: CRLs not checked due to --disable-crl-checks option gpgsm: DBG: adding certificates at level 1 gpgsm: signature created read_assuan: read "S PROGRESS starting_agent ? 0 0" read_assuan: read " " read_assuan: read "S SIG_CREATED S 1 2 00 20021202T132959 3CF405464F66ED4A7DF45BBDD1E4282E33BDB76E" read_assuan: read " " read_assuan: read "OK" read_assuan: read " " sending `RESET' expecting OK read_assuan: read "OK" read_assuan: read " " sending `INPUT FD=7' expecting OK read_assuan: read "OK" read_assuan: read " " sending `OUTPUT FD=8' expecting OK read_assuan: read "OK" read_assuan: read " " sending `VERIFY' expecting OK gpgsm: signal Segmentation fault caught ... exiting read_assuan: read "" asschk: read_assuan: received incomplete line on fd 9 FAIL: sm-sign+verify From jsogo at debian.org Tue Aug 9 23:52:24 2005 From: jsogo at debian.org (Jose Carlos Garcia Sogo) Date: Wed Aug 10 00:42:43 2005 Subject: Bug#322208: seahorse-agent: fails to be accessed from debuild In-Reply-To: References: Message-ID: <1123624344.16247.7.camel@gimli.tribulaciones.org> As reported in the bug below when using seahorse-agent and debuild it will always fail with the "problem with the agent - disabling agent use" error (it also happens to me). But if I use debsign after build process, I can sign the package using seahorse-agent fine. I am completely lost about where should I start looking for the bug/problem. This is why I am CCing both lists. Perhaps problem is in debuild itself, but any hint on how debugging this would be appreciated. Thanks El mar, 09-08-2005 a las 21:22 +0300, Martin-?ric Racine escribi?: > Package: seahorse > Version: 0.7.6-5 > Severity: important > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I launch searhorse-agent from my GNOME session startup files. This works well in GNOME applications such as Balsa or > when executing 'gpg' form the command line, such as with 'caff' from the "signing-party" package. However, it fails > whenever I build packages using debuild. What I get: > > 8X----- > Now signing changes and any dsc files... > signfile gaim-irchelper_0.12-1.dsc Martin-?ric Racine > > You need a passphrase to unlock the secret key for > user: "Martin-?ric Racine " > 1024-bit DSA key, ID 1E0CB9CD, created 2003-10-26 > > gpg: problem with the agent - disabling agent use > Enter passphrase: > 8X----- > > I then enter my passphrase, which gives me this: > > 8X----- > debsign: gpg error occurred! Aborting.... > debuild: fatal error at line 788: > running debsign failed > 8X----- > > Note: this bug might actually be caused by 'debuild' but I'm not sure how I would verify this. If you feel that this > bug belongs to the "devscripts" package, you are welcome to reasign it to that. > > - -- System Information: > Debian Release: testing/unstable > Architecture: powerpc (ppc) > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.6.11-imac > Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) > > Versions of packages seahorse depends on: > ii debconf [debconf-2.0] 1.4.52 Debian configuration management sy > ii gconf2 2.10.1-1 GNOME configuration database syste > ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi > ii libatk1.0-0 1.10.1-2 The ATK accessibility toolkit > ii libbonobo2-0 2.10.0-1 Bonobo CORBA interfaces library > ii libbonoboui2-0 2.8.1-2 The Bonobo UI library > ii libc6 2.3.5-3 GNU C Library: Shared libraries an > ii libeel2-2 2.8.2-1 Eazel Extensions Library (for GNOM > ii libgail-common 1.8.4-1 GNOME Accessibility Implementation > ii libgail17 1.8.4-1 GNOME Accessibility Implementation > ii libgconf2-4 2.10.1-1 GNOME configuration database syste > ii libglade2-0 1:2.5.1-2 library to load .glade files at ru > ii libglib2.0-0 2.6.5-1 The GLib library of C routines > ii libgnome2-0 2.8.1-2 The GNOME 2 library - runtime file > ii libgnomecanvas2-0 2.10.2-2 A powerful object-oriented display > ii libgnomeui-0 2.8.1-3 The GNOME 2 libraries (User Interf > ii libgnomevfs2-0 2.8.4-4 The GNOME virtual file-system libr > ii libgpg-error0 1.1-4 library for common error values an > ii libgpgme11 1.0.2-1 GPGME - GnuPG Made Easy > ii libgtk2.0-0 2.6.8-1 The GTK+ graphical user interface > ii libice6 4.3.0.dfsg.1-14 Inter-Client Exchange library > ii liborbit2 1:2.12.2-1 libraries for ORBit2 - a CORBA ORB > ii libpango1.0-0 1.8.2-1 Layout and rendering of internatio > ii libpopt0 1.7-5 lib for parsing cmdline parameters > ii libsm6 4.3.0.dfsg.1-14 X Window System Session Management > ii libx11-6 4.3.0.dfsg.1-14 X Window System protocol client li > ii libxml2 2.6.20-1 GNOME XML library > ii xlibs 4.3.0.dfsg.1-14 X Keyboard Extension (XKB) configu > ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime > > seahorse recommends no packages. > > - -- debconf information: > * seahorse/SUID: true > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFC+PRdeXr56x4Muc0RAng6AJsEsrGtPmnL8/hr0xt+VC8bQAlusACfbMYk > 2UcF1yccUCicBNmT6mx0Aws= > =KdBQ > -----END PGP SIGNATURE----- > -- Jose Carlos Garcia Sogo jsogo@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/attachments/20050809/af668e80/attachment.pgp From JPClizbe at comcast.net Wed Aug 10 05:11:00 2005 From: JPClizbe at comcast.net (John Clizbe) Date: Wed Aug 10 05:50:47 2005 Subject: mpi error with check-trustdb in 1.4.2 Message-ID: <42F97044.9050603@comcast.net> Hi Werner, Dave, and everyone else. This error started showing up when I switched to 1.4.2. It does not occur in 1.4.1. A similar mpi error occurs with --rebuild-keydb-cache. It's not dangerous like some of the 1.4.0 rename errors, just a nuisance. Probably just key cruft, but I thought you might want to look at it since it wasn't a problem in prior versions. gpg: key 7B27F15C: accepted as trusted key gpg: key 18BB373A: accepted as trusted key gpg: key 89387612: no subkey for subkey revocation signature gpg: NOTE: signature key FC731D63 expired 07/15/04 00:01:06 gpg: NOTE: signature key FC731D63 expired 07/15/04 00:01:06 gpg: NOTE: signature key FC731D63 expired 07/15/04 00:01:06 gpg: mpi larger than indicated length (2 bytes) gpg: keyring_get_keyblock: read error: invalid packet gpg: keyring_get_keyblock failed: invalid keyring gpg: failed to rebuild keyring cache: invalid keyring gpg: 921 keys processed (1585 validity counts cleared) gpg: Invalid key 6D49B725 made valid by --allow-non-selfsigned-uid gpg: Invalid key 162E93A8 made valid by --allow-non-selfsigned-uid gpg: Invalid key A3124966 made valid by --allow-non-selfsigned-uid gpg: Invalid key 9F6535A4 made valid by --allow-non-selfsigned-uid gpg: Invalid key 6E386101 made valid by --allow-non-selfsigned-uid gpg: Invalid key AD76F7BF made valid by --allow-non-selfsigned-uid gpg: Invalid key 9921A703 made valid by --allow-non-selfsigned-uid gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: NOTE: signature key F4634E45 expired 01/02/04 02:01:17 gpg: key 89387612: no subkey for subkey revocation signature gpg: NOTE: signature key 7391F44F expired 01/31/02 16:27:18 gpg: NOTE: signature key 7391F44F expired 01/31/02 16:27:18 gpg: NOTE: signature key 9B766424 expired 07/01/02 17:41:03 gpg: NOTE: signature key 3EBF10A7 expired 01/26/05 14:32:50 gpg: NOTE: signature key 5B3F6A19 expired 07/14/03 03:32:02 gpg: NOTE: signature key 67F81171 expired 01/01/02 20:57:46 gpg: NOTE: signature key 5E4B731F expired 02/25/04 07:18:59 gpg: NOTE: signature key DBFB99ED expired 12/25/04 08:14:36 gpg: Invalid key 7A299B59 made valid by --allow-non-selfsigned-uid gpg: NOTE: signature key FC731D63 expired 07/15/04 00:01:06 gpg: NOTE: signature key 434798B9 expired 12/30/03 19:04:00 gpg: mpi larger than indicated length (2 bytes) gpg: keyring_get_keyblock: read error: invalid packet gpg: keydb_get_keyblock failed: invalid keyring gpg: validate_key_list failed -- John P. Clizbe Inet: JPClizbe(a)comcast DOT nyet Golden Bear Networks PGP/GPG KeyID: 0x608D2A10 "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 435 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050809/82ee48ef/signature.pgp From alex at bofh.net.pl Wed Aug 10 11:33:41 2005 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Wed Aug 10 11:29:27 2005 Subject: mpi error with check-trustdb in 1.4.2 In-Reply-To: <42F97044.9050603@comcast.net> References: <42F97044.9050603@comcast.net> Message-ID: <20050810093341.GB21785@syjon.fantastyka.net> On Tue, Aug 09, 2005 at 10:11:00PM -0500, John Clizbe wrote: > Hi Werner, Dave, and everyone else. > > This error started showing up when I switched to 1.4.2. It does not occur in > 1.4.1. A similar mpi error occurs with --rebuild-keydb-cache. > > It's not dangerous like some of the 1.4.0 rename errors, just a nuisance. I have similar problem and for me it is more than nuisance since my gpg installation has been unable to make key-change (import, signaure etc) related operations since the error appeared first. Alex PS> John, your signature didn't verify for me, something on the way thrashed it. -- mors ab alto 0x46399138 From teun.nijssen at uvt.nl Tue Aug 9 12:27:21 2005 From: teun.nijssen at uvt.nl (Teun Nijssen) Date: Wed Aug 10 13:11:29 2005 Subject: Traditional LDAP keyserver going off line Message-ID: <42F88509.2080601@uvt.nl> Hi, for a very, very long time (even when a keyserver was a Perl script), SURFnet has been funding PGP keyservers. In august 2004, SURFnet installed a new dedicated SKS keyserver hkp://pgp.surfnet.nl:11371 which is also known as minsky.surfnet.nl The previous machine, horowitz.surfnet.nl is currently still operational; it handles between 1M and 2M *LDAP* keyserver requests per month. Nevertheless, at the end of this month good old horowitz (a Solaris Enterprise 1 box of previous century quality) will go off-line. Its problem is not the age of the hardware but the fading away of Solaris at Tilburg University. (We're a Debian site now.) I have requested PGP.com to point the europe.keys.pgp.com cname alias to one of their own servers. cheers, teun -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050809/b3317c7f/signature.pgp From rdieter1 at unl.edu Tue Aug 9 18:59:05 2005 From: rdieter1 at unl.edu (Rex Dieter) Date: Wed Aug 10 13:11:32 2005 Subject: gnupg2-1.9.18: 'make check' fails on x86_64 Message-ID: <42F8E0D9.4090401@unl.edu> Trying to build gnupg2-1.9.18 on Fedora Core 4/x86_64 (gcc-4.0.1) fails in 'make check': Any ideas? Full build log: http://buildsys.fedoraproject.org/logs//development/538-gnupg2-1.9.18-1.fc5/x86_64/build.log Relavent snippet: make check-TESTS make[2]: Entering directory `/builddir/build/BUILD/gnupg-1.9.18/tests' gpgsm: WARNING: running with faked system time: 2002-12-02 13:29:59 read_assuan: read "OK GNU Privacy Guard's S/M server 1.9.18 ready" read_assuan: read " " sending `INPUT FD=5' expecting OK read_assuan: read "OK" read_assuan: read " " sending `OUTPUT FD=6' expecting OK read_assuan: read "OK" read_assuan: read " " sending `SIGN' expecting OK gpgsm: can't connect to `/builddir/build/BUILD/gnupg-1.9.18/tests/S.gpg-agent': No such file or directory gpgsm: CRLs not checked due to --disable-crl-checks option gpgsm: DBG: adding certificates at level 1 gpgsm: signature created read_assuan: read "S PROGRESS starting_agent ? 0 0" read_assuan: read " " read_assuan: read "S SIG_CREATED S 1 2 00 20021202T132959 3CF405464F66ED4A7DF45BBDD1E4282E33BDB76E" read_assuan: read " " read_assuan: read "OK" read_assuan: read " " sending `RESET' expecting OK read_assuan: read "OK" read_assuan: read " " sending `INPUT FD=7' expecting OK read_assuan: read "OK" read_assuan: read " " sending `OUTPUT FD=8' expecting OK read_assuan: read "OK" read_assuan: read " " sending `VERIFY' expecting OK gpgsm: signal Segmentation fault caught ... exiting read_assuan: read "" asschk: read_assuan: received incomplete line on fd 9 FAIL: sm-sign+verify From md+g10 at linux.it Wed Aug 10 15:46:14 2005 From: md+g10 at linux.it (Marco d'Itri) Date: Wed Aug 10 15:41:44 2005 Subject: Proof of email ownership In-Reply-To: <20050809170525.GA21785@syjon.fantastyka.net> References: <42F3DBF1.7070701@post.cz> <873bplzzd3.fsf@wheatstone.g10code.de> <20050809170525.GA21785@syjon.fantastyka.net> Message-ID: <20050810134614.GA8938@wonderland.linux.it> On Aug 09, "Janusz A. Urbanowicz" wrote: > This is the one assumption I can't accept. DNSSEC deployment is going slower > than IPv6 adaptation, and for many years this is the tehcnology that will be > adopted RSN. DNSSEC is going to be deployed for in-addr.arpa in a few months, at least in RIPE-land. A few TLDs will hopefully follow next year. -- 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/20050810/5b1703ce/attachment.pgp From npcole at yahoo.co.uk Wed Aug 10 17:17:49 2005 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Wed Aug 10 17:59:44 2005 Subject: --status-fd pipe and select Message-ID: <20050810151749.92582.qmail@web25408.mail.ukl.yahoo.com> I realise that similar questions have been asked before, but after much googling I can't work out the answer. If using --status-fd 1, --command-fd 0 and calling gpg using popen (I'm doing this from python, but AFAIKS it's only a thin wrapper around the library), select correctly reports that the stdout pipe is ready for reading once gpg has terminated. In other words, if using the edit key functions, it is not possible to use select to be sure that a read will not block. Is this inevitable, or could gpg become more 'select' friendly? Best wishes, N. ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com From gnupg-devel=gnupg.org at lists.palfrader.org Wed Aug 10 16:57:32 2005 From: gnupg-devel=gnupg.org at lists.palfrader.org (Peter Palfrader) Date: Wed Aug 10 19:04:17 2005 Subject: keys that GnuPG doesn't like with --recv/--refresh Message-ID: <20050810145732.GA32477@opium.palfrader.org> Hi, key 0x39CC8CED3D79EDCA as found on keyserver.noreply.org (or any other server of the SKS network) makes GnuPG 1.4.2 fall over itself on --recv/--refresh: weasel@asteria:~/gnupg$ gpg --keyserver localhost --recv 94c09c7f gpg: keyring `/home/weasel/gnupg/gpghome/secring.gpg' created gpg: keyring `/home/weasel/gnupg/gpghome/pubring.gpg' created [..] weasel@asteria:~/gnupg$ gpg --keyserver localhost --recv 39CC8CED3D79EDCA gpg: requesting key 3D79EDCA from hkp server localhost gpg: key 3D79EDCA: public key "Marc SCHAEFER (CRIL) " imported gpg: [don't know]: invalid packet (ctb=2d) gpg: read_block: read error: invalid packet gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 weasel@asteria:~/gnupg$ gpg --keyserver localhost --recv c82e0039 [..] gpg: imported: 1 (RSA: 1) gpg --list-key then properly shows all 3 keys, however: weasel@asteria:~/gnupg$ gpg --keyserver localhost --refresh-keys gpg: refreshing 3 keys from localhost gpg: requesting key 94C09C7F from hkp server localhost gpg: requesting key 3D79EDCA from hkp server localhost gpg: requesting key C82E0039 from hkp server localhost gpg: key 94C09C7F: "Peter Palfrader" not changed gpg: key 3D79EDCA: "Marc SCHAEFER (CRIL) " not changed gpg: [don't know]: invalid packet (ctb=2d) gpg: read_block: read error: invalid packet gpg: Total number processed: 2 gpg: unchanged: 2 That is, it stops refreshing keys after 3D79EDCA. So it seems that it imported parts of the key that it could understand, however when refreshing keys (or receiving them) it stops the process after this key. -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred. | : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `- http://www.debian.org/ From jharris at widomaker.com Wed Aug 10 21:29:25 2005 From: jharris at widomaker.com (Jason Harris) Date: Wed Aug 10 21:59:41 2005 Subject: keys that GnuPG doesn't like with --recv/--refresh In-Reply-To: <20050810145732.GA32477@opium.palfrader.org> References: <20050810145732.GA32477@opium.palfrader.org> Message-ID: <20050810192925.GZ358@wilma.widomaker.com> On Wed, Aug 10, 2005 at 04:57:32PM +0200, Peter Palfrader wrote: > key 0x39CC8CED3D79EDCA as found on keyserver.noreply.org (or any other > server of the SKS network) makes GnuPG 1.4.2 fall over itself on --recv/--refresh: Interestingly (albeit with the key fetched from keyserver.kjsl.com), GPG only does this when importing an armored version of the key: %esha1sum lookup fb196917496fbb5d533cf5a6a402a887cdf6a680 11364 lookup Importing a dearmored ("gpg --dearmor lookup") version of the key: %esha1sum lookup.gpg 235c953f05bd2334c7c74cbb60c44233bc2c0824 8192 lookup.gpg produces no errors. Also, importing the key with others (in one armored keyblock): %curl 'http://keyserver.kjsl.com:11371/pks/lookup?op=get&search=Marc%20SCHAEFER' | gpg --import produces no errors. GPG gets multiple armored keyblocks from gpgkeys_hkp during the --refresh you mentioned, Peter, and is choking on the end of the second keyblock, apparently, so the third keyblock doesn't get processed. During a "--recv 0x3D79EDCA," it only gets one keyblock, which doesn't cause an error until _after_ 0x3D79EDCA is already imported. NB: Fetching the key from pgp.mit.edu doesn't cause this error. The kjsl and MIT query outputs (respectively) end with: %tail -5 lookup lookup.1 ==> lookup <== 7I6jM8w/O6mIRgQYEQIABgUCPQIoMAAKCRA5zIztPXntynFGAJ9sPZd9EGprjp1z 2J4/+PMVXnntuACfR8ZsukCCfDUeU7Qgfz+X5BMoM94= =yz3b -----END PGP PUBLIC KEY BLOCK----- ==> lookup.1 <== 8ZoZnplT7I6jM8w/O6mIRgQYEQIABgUCPQIoMAAKCRA5zIztPXntynFGAJ9sPZd9 EGprjp1z2J4/+PMVXnntuACfR8ZsukCCfDUeU7Qgfz+X5BMoM94= =Bva6 -----END PGP PUBLIC KEY BLOCK----- and end with the same subkey sig. packet (when dearmored and gpgsplit): 2406ea5bb3544178efabfe4ec85b33c6f7361d90 72 000040-002.sig 2406ea5bb3544178efabfe4ec85b33c6f7361d90 72 000041-002.sig So, there seems to be some difference between "gpg --dearmor" and "gpgkeys_hkp | gpg ..." when interpreting armored data. -- 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: 313 bytes Desc: not available Url : /pipermail/attachments/20050810/2d2bf919/attachment.pgp From jharris at widomaker.com Thu Aug 11 00:07:20 2005 From: jharris at widomaker.com (Jason Harris) Date: Thu Aug 11 00:02:46 2005 Subject: keys that GnuPG doesn't like with --recv/--refresh In-Reply-To: <20050810192925.GZ358@wilma.widomaker.com> References: <20050810145732.GA32477@opium.palfrader.org> <20050810192925.GZ358@wilma.widomaker.com> Message-ID: <20050810220720.GA358@wilma.widomaker.com> On Wed, Aug 10, 2005 at 03:29:25PM -0400, Jason Harris wrote: > On Wed, Aug 10, 2005 at 04:57:32PM +0200, Peter Palfrader wrote: > > key 0x39CC8CED3D79EDCA as found on keyserver.noreply.org (or any other > > server of the SKS network) makes GnuPG 1.4.2 fall over itself on --recv/--refresh: > > Interestingly (albeit with the key fetched from keyserver.kjsl.com), > GPG only does this when importing an armored version of the key: Even better, remove the keyservers' armoring as a variable and simply compare GPG's armored import/export: %gpg --export -a 0x3D79EDCA | gpg --import gpg: key 3D79EDCA: "Marc SCHAEFER (CRIL) " not changed gpg: [don't know]: invalid packet (ctb=2d) gpg: read_block: read error: invalid packet gpg: import from `[stdin]' failed: invalid keyring gpg: Total number processed: 1 gpg: unchanged: 1 with its binary import/export: %gpg --export 0x3D79EDCA | gpg --import gpg: key 3D79EDCA: "Marc SCHAEFER (CRIL) " not changed gpg: Total number processed: 1 gpg: unchanged: 1 for this particular key. > NB: Fetching the key from pgp.mit.edu doesn't cause this error. NB: When this key is fetched from MIT, the trick above doesn't work. -- 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: 313 bytes Desc: not available Url : /pipermail/attachments/20050810/111b1262/attachment.pgp From JPClizbe at comcast.net Thu Aug 11 05:30:09 2005 From: JPClizbe at comcast.net (John Clizbe) Date: Thu Aug 11 06:11:53 2005 Subject: mpi error with check-trustdb in 1.4.2 - resolved In-Reply-To: <42F97044.9050603@comcast.net> References: <42F97044.9050603@comcast.net> Message-ID: <42FAC641.9040507@comcast.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Clizbe wrote: > Hi Werner, Dave, and everyone else. > > This error started showing up when I switched to 1.4.2. It does not occur in > 1.4.1. A similar mpi error occurs with --rebuild-keydb-cache. > > It's not dangerous like some of the 1.4.0 rename errors, just a nuisance. > > Probably just key cruft, but I thought you might want to look at it since it > wasn't a problem in prior versions. Tracked down the two offending keys and deleted them with 1.4.1. They both failed to import from a keyserver with 1.4.2 with the same mpi error, so I'm marking it off to key cruft. The keys were: pub 1024R/FC05DA69 1997-05-12 Anand Kumria pub 1024D/A0B3E88B 2000-07-24 Martin Pool - -- John P. Clizbe Inet: JPClizbe(a)comcast DOT nyet Golden Bear Networks PGP/GPG KeyID: 0x608D2A10 "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: When cryptography is outlawed, b25seSBvdXRsYXdzIHdpbGwgdXNlIG Comment: Be part of the ?33t ECHELON -- Use Strong Encryption. Comment: It's YOUR right - for the time being. Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+sZBHQSsSmCNKhARAvAIAKDMNYnzFhcbjL8+Wt58SOfbpOVjcgCgiCnv /X23Es3Fwc/vbnLkDAsEszU= =Uhd9 -----END PGP SIGNATURE----- From jharris at widomaker.com Thu Aug 11 18:02:17 2005 From: jharris at widomaker.com (Jason Harris) Date: Thu Aug 11 17:57:49 2005 Subject: mpi error with check-trustdb in 1.4.2 - resolved In-Reply-To: <42FAC641.9040507@comcast.net> References: <42F97044.9050603@comcast.net> <42FAC641.9040507@comcast.net> Message-ID: <20050811160217.GC358@wilma.widomaker.com> On Wed, Aug 10, 2005 at 10:30:09PM -0500, John Clizbe wrote: > Tracked down the two offending keys and deleted them with 1.4.1. They both > failed to import from a keyserver with 1.4.2 with the same mpi error, so I'm > marking it off to key cruft. > > The keys were: > > pub 1024R/FC05DA69 1997-05-12 Anand Kumria [snip] > pub 1024D/A0B3E88B 2000-07-24 Martin Pool [snip] Turning up the debugging level: %gpg -vvv --recv A0B3E88B shows the first offending packet: :user ID packet: "Martin Pool " :signature packet: algo 17, keyid 2EDDBB0000000000 version 4, created 1043327185, md5len 0, sigclass 12 digest algo 2, begin of digest 00 00 hashed subpkt 2 len 4 (sig created 2003-01-23) subpkt 16 len 8 (issuer key ID 2EDDBB0000000000) data: [0 bits] gpg: mpi larger than indicated length (2 bytes) data: [MPI_NULL] gpg: read_block: read error: invalid packet pgpdump has this to add: DSA r(0 bits) - DSA s(0 bits) - NB: The truncated issuer looks like a real issuer: Key ID - 0x2EDDBB0000000000 Key ID - 0x2EDDBB4F51916CDA pks decodes MPIs and can discard any packets with zero-length MPIs if necessary. GPG used to ignore them, and I think it still could since the packets seem to be of their indicated overall size. Also, GPG states: gpg: mpi larger than indicated length (2 bytes) data: [MPI_NULL] which seems self-contradictory. pgpdump says the MPIs are both zero-length as well, so is GPG's claim: "mpi larger than indicated length (2 bytes)" actually erroneous? -- 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: 313 bytes Desc: not available Url : /pipermail/attachments/20050811/d1c5602e/attachment-0001.pgp From jharris at widomaker.com Thu Aug 11 20:21:44 2005 From: jharris at widomaker.com (Jason Harris) Date: Thu Aug 11 20:17:14 2005 Subject: zero-length MPIs (was: Re: mpi error with check-trustdb in 1.4.2 - resolved) In-Reply-To: <20050811160217.GC358@wilma.widomaker.com> References: <42F97044.9050603@comcast.net> <42FAC641.9040507@comcast.net> <20050811160217.GC358@wilma.widomaker.com> Message-ID: <20050811182144.GA33562@wilma.widomaker.com> On Thu, Aug 11, 2005 at 12:02:17PM -0400, Jason Harris wrote: > On Wed, Aug 10, 2005 at 10:30:09PM -0500, John Clizbe wrote: > > Tracked down the two offending keys and deleted them with 1.4.1. They both > > failed to import from a keyserver with 1.4.2 with the same mpi error, so I'm > > marking it off to key cruft. Here are some more offending keys: 0xA0B3E88B 0xFC05DA69 0x0FCF6738 0xCC78C893 0x98FDE37C 0x74C9DE33 0x57023F00 - corrupt subkey Fetching them from keyserver.kjsl.com is now possible with gnupg-1.4.2. To patch pks, add this to the middle of decode_mpi() (in pgputil.c): /* skip packets with 0-length MPIs for GPG's benefit (gnupg-1.4.2) */ if (mpi->nbits == 0) { return (0); } -- 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: 313 bytes Desc: not available Url : /pipermail/attachments/20050811/5039bd58/attachment.pgp From marcus.brinkmann at ruhr-uni-bochum.de Thu Aug 11 23:41:05 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Aug 11 23:38:50 2005 Subject: GPG/GPGME problem In-Reply-To: <1123261674.1504.240068676@webmail.messagingengine.com> References: <1123261674.1504.240068676@webmail.messagingengine.com> Message-ID: <87k6isf8y6.wl@ulysses.g10code.de> At Fri, 05 Aug 2005 19:07:54 +0200, harry_b@mm.st wrote: > I am pretty confused about a problem with gpg and gpgme. I am working on > an encryption program and for this I wrote some test sequences which now > give me a hard time. Every 1000 runs or so, the following steps produce > a weird error which even gpg itself messes up. :-/ > > I am on Debian unstable and use GPG 1.4.1 and gpgme 1.0.2. > > My test runs these steps: > 1. Create some random XML data file > 2. gzip this file (as my application does using zlib) > $ gzip -9 FILE_A > 3. encode it with a testkey > $ echo "1234567890" | GNUPGHOME=./tests GPG_AGENT_INFO= gpg > --no-tty --recipient="TESTKEY" --passphrase-fd 0 --armour --sign > --encrypt --output="FILE_B" "FILE_A" > 4. run my application and see if it can decrypt the file and write > the same data again > 5. compare the gpg file with my own file > > The problem now is, that even gpg can't decrypt it's own file FILE_B. I > tried this with several keys and it happens with all of my keys. :-( You may try to keep debug logs of the gpg runs in step 3, so that you can catch the failing case and at least have some information about it. Then check if it is reproducible with the same data set (ie, run only step 3 on the same data a couple thousand times). > I get these two errors: > - gpg reports: gpg: [don't know]: invalid packet (ctb=14) > - gpgme reports: Unexpected signature summary: 0x800 The GPGME output may itself be a bit problematic if GPGME doesn't cope with the error output of gpg very well (that may be the case, we can look at this individually, for example if you send me the broken file so I can reproduce it). But of course if your step 3 above creates an invalid file, then the problem must be GPG or the way you are using it (although the command line looks basically OK to me). > The weird thing is, that it seems to depend on the data which I create > pretty randomly with a little perl script. If it depends on the data, that would be good, because then step 3 would be reproducible. If it fails sometimes and works some other times on the same data set, then this points to a completely different class of bugs, which can be harder to track down. > Any ideas what I can do about this very weird thing? A better (ie more isolated, more specific) test case would be good. > PS: Some of these buggy files are in the attached tar.gz file. > [2 buggy-files.tar.gz ] I get EOF on all of them, not even invalid packet... Thanks, Marcus From jharris at widomaker.com Fri Aug 12 02:22:43 2005 From: jharris at widomaker.com (Jason Harris) Date: Fri Aug 12 02:18:38 2005 Subject: [Sks-devel] Re: zero-length MPIs (was: Re: mpi error with check-trustdb in 1.4.2 - resolved) In-Reply-To: <20050811195459.GB12783@opium.palfrader.org> References: <42F97044.9050603@comcast.net> <42FAC641.9040507@comcast.net> <20050811160217.GC358@wilma.widomaker.com> <20050811182144.GA33562@wilma.widomaker.com> <20050811195459.GB12783@opium.palfrader.org> Message-ID: <20050812002243.GD358@wilma.widomaker.com> On Thu, Aug 11, 2005 at 09:54:59PM +0200, Peter Palfrader wrote: > On Thu, 11 Aug 2005, Jason Harris wrote: > > Fetching them from keyserver.kjsl.com is now possible with gnupg-1.4.2. > > To patch pks, add this to the middle of decode_mpi() (in pgputil.c): > > > > /* skip packets with 0-length MPIs for GPG's benefit (gnupg-1.4.2) */ > > if (mpi->nbits == 0) { > > return (0); > > } > > can we do that in SKS too? please! Try the patch below. 0x1A9537E7 is another offending key, and all eight work now: %gpg --recv 0xA0B3E88B 0xFC05DA69 0x0FCF6738 0xCC78C893 0x98FDE37C 0x74C9DE33 0x57023F00 0x1A9537E7 ... gpg: Total number processed: 8 gpg: unchanged: 8 =================================================================== RCS file: parsePGP.ml,v retrieving revision 1.1 diff -u -r1.1 parsePGP.ml --- parsePGP.ml 2005/08/12 00:03:16 1.1 +++ parsePGP.ml 2005/08/12 00:03:54 @@ -23,6 +23,7 @@ open Printf exception Overlong_mpi +exception Zerolen_mpi exception Partial_body_length of int (********************************************************) @@ -109,6 +110,7 @@ try let byte2 = cin#read_byte in let length = (byte1 lsl 8) + byte2 in + if length <= 0 then raise Zerolen_mpi; let data = cin#read_string ((length + 7)/8) in -- 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: 313 bytes Desc: not available Url : /pipermail/attachments/20050811/22dc97df/attachment.pgp From wk at gnupg.org Fri Aug 12 14:15:02 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Aug 12 14:11:33 2005 Subject: gpg-agent env-vars In-Reply-To: <200507231337.43529.zander@kde.org> (Thomas Zander's message of "Sat, 23 Jul 2005 13:37:38 +0200") References: <200507231337.43529.zander@kde.org> Message-ID: <871x4znygp.fsf@wheatstone.g10code.de> On Sat, 23 Jul 2005 13:37:38 +0200, Thomas Zander said: > I was thinking that if ssh-agent would write a standardised file with the > env-variables it now prints on stdout; the various clients could read > that file. What about: @item --write-env-file @var{file} @opindex write-env-file Often it is required to connect to the agent from a process not being an inferior of @command{gpg-agent} and thus the environment variable with the socket name is not available. To help setting up those variables in other sessions, this option may be used to write the information into @var{file}. The format is suitable to be evaluated by a Bourne shell like in this simple example: @example eval `cat @var{file}` eval `cut -d= -f 1 < @var{file} | xargs echo export` @end example I use ~/.gpg-agent-info as file name. Its there since 1.9.17. Salam-Shalom, Werner From heathjs21 at yahoo.com Fri Aug 12 16:50:18 2005 From: heathjs21 at yahoo.com (Heather Shaw) Date: Fri Aug 12 17:46:08 2005 Subject: Creating a key without using a random key generator. Message-ID: <20050812145019.19322.qmail@web30006.mail.mud.yahoo.com> If I am given a key to use for generating a message digest of a buffer, how do I create a key manually to pass into the gcry_md_setkey() without using the routines to randomly generate a key and then pass it in. Right now for my test example, I am using gcry_sexp_new(&key_spec, "(genkey (rsa (nbits 4:1028)))", 0 ,1) and calling the gcry_pk_genkey. I am then stripping out the public and private key and using the public key as my key. *I know there probably was an easier way, but I just found this example and it was faster for me.* My test code to create the message digest is calling gcry_md_open() with all the necessary params and then calling gcry_md_setkey () with the key I found above. Thanks for your help! I am sure it is something pretty trivial.... From michaeln at twentyten.org Sun Aug 14 01:53:05 2005 From: michaeln at twentyten.org (Michael Nguyen) Date: Sun Aug 14 02:23:09 2005 Subject: gpgme: encrypt/decrypt Message-ID: <05f501c5a062$29508870$800101df@oldeenglish> I'd normally post this to gnupg-users, but they don't seem to be much help right now... So, I've been going through the samples, and I'm still sort of unclear about how to get the right public key read in so I can do an encryption. I'm looking at the following function: gpgme_error_t gpgme_op_encrypt (gpgme_ctx_t ctx, gpgme_key_t recp[], gpgme_encrypt_flags_t flags, gpgme_data_t plain, gpgme_data_t cipher) The question is, how do I build these recipients? I have a bunch of public keys in a MySQL database keyed by email address. I want to populate recp[] with these public keys and encrypt, but I'm not sure how to go about doing that. Could someone give me a quick tutorial on how to get this going? You know, something like: - Take your text keys from MySQL and read it into a char string - Run gpgme_blah_blah with blah and blah to turn the public keys into the recp array - Pass that value to gpgme_op_encrypt and away you go Thanks in advance. Michael From zander at kde.org Mon Aug 15 15:46:42 2005 From: zander at kde.org (Thomas Zander) Date: Mon Aug 15 16:43:46 2005 Subject: gpg-agent env-vars In-Reply-To: <871x4znygp.fsf@wheatstone.g10code.de> References: <200507231337.43529.zander@kde.org> <871x4znygp.fsf@wheatstone.g10code.de> Message-ID: <200508151546.43249.zander@kde.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 12 August 2005 14:15, Werner Koch wrote: > On Sat, 23 Jul 2005 13:37:38 +0200, Thomas Zander said: > > I was thinking that if ssh-agent would write a standardised file with > > the env-variables it now prints on stdout; the various clients could > > read that file. > > What about: > > @item --write-env-file @var{file} [snip] Ahh; cool :) Am I correct in understanding the help message that this does not actually standardise the argument filename? If so; please consider making the argument optional (with a good default value). This is needed since otherwise the original problem is still unsolved. (different software tools writing different env-files, and effectively not seeing the agent that another tool started) If the argument is already optional; then this is exactly what I was thinking about. > I use ~/.gpg-agent-info as file name. Its there since 1.9.17. So the feature was added a month before I asked for it :) You guys are amazing! Thanks. ps. I'm not subscribed to the list anymore. I hope this post comes through.. - -- Thomas Zander -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFDAJzDCojCW6H2z/QRAkKpAJ0fXnfRv8rN1z/HtXA+rXKiSxT7eACfWP8G PfWu5X7DTvyorj6scn5aJDM= =E8VY -----END PGP SIGNATURE----- From hawke at hawkesnest.net Sun Aug 14 18:06:49 2005 From: hawke at hawkesnest.net (Alex L. Mauer) Date: Mon Aug 15 22:01:34 2005 Subject: Revokation of keys from smart card In-Reply-To: References: Message-ID: Alex L. Mauer wrote: > Is it possible to revoke keys that have been stored on a smart card? It > seems to me that it is not. Am I correct, or do I just need to do > something other than "revkey"? Oh right ... my bad on that one (it helps to have the secret key for the primary key on the keyring that's being edited. But perhaps GnuPG should give an error of some kind indicating that it didn't work and why. -- Bad - You get pulled over for doing 90 in a school zone and you're drunk off your ass again at three in the afternoon. Worse - The cop is drunk too, and he's a mean drunk. FUCK! - A mean drunk that's actually a swarm of semi-sentient flesh-eating beetles. OpenPGP key id: 51192FF2 @ subkeys.pgp.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050814/ccdcf9f4/signature.pgp From michaeln at twentyten.org Tue Aug 16 08:12:12 2005 From: michaeln at twentyten.org (Michael Nguyen) Date: Tue Aug 16 09:08:26 2005 Subject: gpgme: encrypt/decrypt References: <05f501c5a062$29508870$800101df@oldeenglish> Message-ID: <08ff01c5a229$713c4020$800101df@oldeenglish> From: "Michael Nguyen" [snip] Ok... I'm willing to PayPal $50 to whoever shows me how to do this. I'm not a developer by trade, but I'm actually ok at it. I just need some help in getting this down. Yeah it's only $50, but if you guys know what you're doing (and I assume every other subscriber to this list does), it should be painless. Michael From wk at gnupg.org Tue Aug 16 10:28:48 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Aug 16 10:26:02 2005 Subject: gpg-agent env-vars In-Reply-To: <200508151546.43249.zander@kde.org> (Thomas Zander's message of "Mon, 15 Aug 2005 15:46:42 +0200") References: <200507231337.43529.zander@kde.org> <871x4znygp.fsf@wheatstone.g10code.de> <200508151546.43249.zander@kde.org> Message-ID: <87pssel1z3.fsf@wheatstone.g10code.de> On Mon, 15 Aug 2005 15:46:42 +0200, Thomas Zander said: > Am I correct in understanding the help message that this does not actually > standardise the argument filename? Correct. > If so; please consider making the argument optional (with a good default > value). This is needed since otherwise the original problem is still > unsolved. (different software tools writing different env-files, and I hesitate to do this because I consider this to be a matter of the actual distribution to decide on a filename. Hwoever I can add a suggestion to the documentation. Salam-Shalom, Werner From wk at gnupg.org Tue Aug 16 18:57:36 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Aug 16 18:56:03 2005 Subject: gpg-agent env-vars In-Reply-To: <200508151546.43249.zander@kde.org> (Thomas Zander's message of "Mon, 15 Aug 2005 15:46:42 +0200") References: <200507231337.43529.zander@kde.org> <871x4znygp.fsf@wheatstone.g10code.de> <200508151546.43249.zander@kde.org> Message-ID: <87ll31hla7.fsf@wheatstone.g10code.de> On Mon, 15 Aug 2005 15:46:42 +0200, Thomas Zander said: > If so; please consider making the argument optional (with a good default > value). This is needed since otherwise the original problem is still Done in SVN. The filename for --write-env-file is now optional and defaults to ~/.gpg-agent-info. Salam-Shalom, Werner From wk at gnupg.org Tue Aug 16 19:00:19 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Aug 16 19:01:03 2005 Subject: gpgme: encrypt/decrypt In-Reply-To: <05f501c5a062$29508870$800101df@oldeenglish> (Michael Nguyen's message of "Sat, 13 Aug 2005 16:53:05 -0700") References: <05f501c5a062$29508870$800101df@oldeenglish> Message-ID: <87hddphl5o.fsf@wheatstone.g10code.de> On Sat, 13 Aug 2005 16:53:05 -0700, Michael Nguyen said: > - Take your text keys from MySQL and read it into a char string 1. import the keys into gpg's keyring; use gpgme_op_import. > - Run gpgme_blah_blah with blah and blah to turn the public keys into the > recp array 2. Do nothing > - Pass that value to gpgme_op_encrypt and away you go 3. Use the fingerprint or the user ID or the keyID of the key and put it into the recipients array. Shalom-Salam, Werner From albrecht.dress at arcor.de Tue Aug 16 09:36:39 2005 From: albrecht.dress at arcor.de (Albrecht Dreß) Date: Tue Aug 16 19:23:13 2005 Subject: Aw: Re: gpgme: encrypt/decrypt In-Reply-To: <08ff01c5a229$713c4020$800101df@oldeenglish> References: <08ff01c5a229$713c4020$800101df@oldeenglish> <05f501c5a062$29508870$800101df@oldeenglish> Message-ID: <29268133.1124177799334.JavaMail.ngmail@webmail-03.arcor-online.net> Open http://cvs.gnome.org/viewcvs/balsa/libbalsa/gmime-gpgme-context.c?rev=1.13&view=markup and search for function gpgme_build_recipients() which is basically called with a gpgme context and a GPtrArray of recipient email addresses. Or, of course, load the whole balsa code from http://balsa.gnome.org... Hth, Albrecht. Machen Sie aus 14 Cent spielend bis zu 100 Euro! Die neue Gaming-Area von Arcor - ?ber 50 Onlinespiele im Angebot. http://www.arcor.de/rd/emf-gaming-1 From michaeln at twentyten.org Tue Aug 16 20:22:19 2005 From: michaeln at twentyten.org (Michael Nguyen) Date: Tue Aug 16 20:17:10 2005 Subject: gpgme: encrypt/decrypt References: <05f501c5a062$29508870$800101df@oldeenglish> <87hddphl5o.fsf@wheatstone.g10code.de> Message-ID: <0a1301c5a28f$70dd9500$800101df@oldeenglish> From: "Werner Koch" > On Sat, 13 Aug 2005 16:53:05 -0700, Michael Nguyen said: > > > - Take your text keys from MySQL and read it into a char string > > 1. import the keys into gpg's keyring; use gpgme_op_import. > 2. Do nothing > 3. Use the fingerprint or the user ID or the keyID of the key and put > it into the recipients array. Hi Werner... I guess this is more of a program design question. Should I be able to do what I want to do here? I'm creating a Postfix content filter for the company that automatically does GPG encryption/decryption on incoming and outgoing corporate mail. What I wanted to do is have the user's private and public key stored as a TEXT type in MySQL. I've been told that I would likely need to store the keyring file as a binary BLOB instead, write it to a temp file, do my work with it, and then remove the temp file. Is this correct? The overall idea of the program is this: - Email gets delivered to SMTP server - Content filter knows who's sending the email and who the recipients are - Filter uses this user information to encrypt the message - Filter returns the email to SMTP I do something similar for incoming delivery (except that it's even easier because I don't have to search for recipients). If I can just take that PGP key and slap it into gpgme_op_import then that'd be even better, but from what I've heard, I can't do that. Michael From wk at gnupg.org Tue Aug 16 20:49:28 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Aug 16 20:46:05 2005 Subject: gpgme: encrypt/decrypt In-Reply-To: <0a1301c5a28f$70dd9500$800101df@oldeenglish> (Michael Nguyen's message of "Tue, 16 Aug 2005 11:22:19 -0700") References: <05f501c5a062$29508870$800101df@oldeenglish> <87hddphl5o.fsf@wheatstone.g10code.de> <0a1301c5a28f$70dd9500$800101df@oldeenglish> Message-ID: <87slx9g1jb.fsf@wheatstone.g10code.de> On Tue, 16 Aug 2005 11:22:19 -0700, Michael Nguyen said: > I guess this is more of a program design question. Should I be able to do > what I want to do here? I'm creating a Postfix content filter for the > company that automatically does GPG encryption/decryption on incoming and Everyone seems to write this kind of software tehse days ;-) For various reasons, GnuPG requires access to the full keyring. Just import everything once and you are basically set. No deen t duplicate the data. Shalom-Salam, Werner From wk at gnupg.org Tue Aug 16 20:50:12 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Aug 16 20:51:04 2005 Subject: Aw: Re: gpgme: encrypt/decrypt In-Reply-To: <29268133.1124177799334.JavaMail.ngmail@webmail-03.arcor-online.net> ( =?utf-8?q?Albrecht_Dre=C3=9F's_message_of?= "Tue, 16 Aug 2005 09:36:39 +0200 (CEST)") References: <08ff01c5a229$713c4020$800101df@oldeenglish> <05f501c5a062$29508870$800101df@oldeenglish> <29268133.1124177799334.JavaMail.ngmail@webmail-03.arcor-online.net> Message-ID: <87oe7xg1i3.fsf@wheatstone.g10code.de> On Tue, 16 Aug 2005 09:36:39 +0200 (CEST), Albrecht Dre? said: > Open http://cvs.gnome.org/viewcvs/balsa/libbalsa/gmime-gpgme-context.c?rev=1.13&view=markup and search for function gpgme_build_recipients() which is basically called with a gpgme context and a GPtrArray of recipient email addresses. Or, of course, load the whole balsa code from http://balsa.gnome.org... Or have a look at the latest mutt releases, file crypt-gpgme.c. Salam-Shalom, Werner From michaeln at twentyten.org Tue Aug 16 21:44:17 2005 From: michaeln at twentyten.org (Michael Nguyen) Date: Tue Aug 16 21:39:11 2005 Subject: **WARNING**Re: gpgme: encrypt/decrypt References: <14794035.1124219317079.JavaMail.root@m32> Message-ID: <0a3b01c5a29a$e4341910$800101df@oldeenglish> From: "Albrecht Dre?" >Am 16.08.05 20:22 schrieb(en) Michael Nguyen: >> I'm creating a Postfix content filter for the company that automatically >> does GPG encryption/decryption on incoming and outgoing corporate mail. > > This sounds like an ineresting idea! First, I want to thank you for the response. >However, are you sure you want to do this on the *mta* level? Most mua's The CEO has requested this because he wants GPG to be standard at the company and doesn't want to have any spin up time for any of the employees. He feels that it has to be as transparent as possible. If this is implemented right, no one will never know it's happening. >(balsa, evolution, kmail, thunderbird, ...) support encryption, which >seems to be the more logical approach to me. Apart from that, it offers >more security for the user, as incoming messages are decrypted only on the >user's machine and using a (hopefully really secure) passphrase only known >by the user. Yes, the security is certainly not as good. We'll be storing private keys, public keys, and passphrases in our database so I can see how a GPG/PGP purist would recoil at the thought of what I'm implementing, but it allows us to do two things: - Force GPG on our user base without generating any resistance - Allows our user base to converse with other GPG/PGP users without having to be technically savvy >> What I wanted to do is have the user's private and public key stored as >> a TEXT type in MySQL. > >Why don't you use the usual gpg key ring for that, maybe with automatic >retreival of missing keys from a key server? You could store the >fingerprint as TEXT, but gpg(me) can use email addresses to fetch keys. Storing these things in SQL allows us to be far more flexible regarding the management tools that we can write. Perhaps a normal key ring could be just as good, but I don't feel it would be. >> - Content filter knows who's sending the email and who the recipients >> are > >Not sure if Postfix offers all recipients to the filter. But remember that >the bcc recipients *must* be treated separately, i.e. they must receive a >different message as the key id's of all "recipients" can be extracted >from the crypto envelope. Yeah, there's definitely a lot more I need to think about. >> - Filter uses this user information to encrypt the message > >So the whole content is put into a rfc3156 multipart/encrypted container, >maybe signed by a "company key"? Yes, but signed by the individual's key. >If you are concerned about security and want to force the users to encrypt >messages, another approach might be to reject (bounce) unencrypted >messages (i.e. with a top-level MIME content type other than >multipart/encrypted) to certain recipients and/or incoming ones from >certain senders. I can tell you right now, that this would not go over well. ;-) >> I do something similar for incoming delivery (except that it's even >> easier because I don't have to search for recipients). > >I wonder if this is a good idea... If I send someone an encrypted message, >I would assume that this is a "for her/his eyes only" one. IMHO some kind >of company-wide automatic decryption breaks privacy (and may even be >forbidden by law, at least in Europe). Yeah, I don't know if it's illegal or not in the US, but this is only for company-related email. Most users will never know that their emails are being encrypted or decrypted. Part of the new employee account creation process will be to go to some Java Servlet page and hit the "generate new key" button which will insert a new private/public key into the database for NewEmployee1@domain.com. >Just my ? 0.01... A very much appreciated 0.01... I'll let you guys know how it goes. If I feel it's of good enough quality and ends up being a decent implementation, I'll release it as a Postfix module so others can use it. Michael From albrecht.dress at arcor.de Tue Aug 16 21:07:16 2005 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Tue Aug 16 22:01:23 2005 Subject: gpgme: encrypt/decrypt In-Reply-To: <0a1301c5a28f$70dd9500$800101df@oldeenglish> (from michaeln@twentyten.org on Tue Aug 16 20:22:19 2005) References: <05f501c5a062$29508870$800101df@oldeenglish> <87hddphl5o.fsf@wheatstone.g10code.de> <0a1301c5a28f$70dd9500$800101df@oldeenglish> Message-ID: <1124219246l.2891l.0l@antares.localdomain> Am 16.08.05 20:22 schrieb(en) Michael Nguyen: > I'm creating a Postfix content filter for the company that automatically > does GPG encryption/decryption on incoming and outgoing corporate mail. This sounds like an ineresting idea! However, are you sure you want to do this on the *mta* level? Most mua's (balsa, evolution, kmail, thunderbird, ...) support encryption, which seems to be the more logical approach to me. Apart from that, it offers more security for the user, as incoming messages are decrypted only on the user's machine and using a (hopefully really secure) passphrase only known by the user. > What I wanted to do is have the user's private and public key stored as > a TEXT type in MySQL. Why don't you use the usual gpg key ring for that, maybe with automatic retreival of missing keys from a key server? You could store the fingerprint as TEXT, but gpg(me) can use email addresses to fetch keys. > - Content filter knows who's sending the email and who the recipients > are Not sure if Postfix offers all recipients to the filter. But remember that the bcc recipients *must* be treated separately, i.e. they must receive a different message as the key id's of all "recipients" can be extracted from the crypto envelope. > - Filter uses this user information to encrypt the message So the whole content is put into a rfc3156 multipart/encrypted container, maybe signed by a "company key"? If you are concerned about security and want to force the users to encrypt messages, another approach might be to reject (bounce) unencrypted messages (i.e. with a top-level MIME content type other than multipart/encrypted) to certain recipients and/or incoming ones from certain senders. > I do something similar for incoming delivery (except that it's even > easier because I don't have to search for recipients). I wonder if this is a good idea... If I send someone an encrypted message, I would assume that this is a "for her/his eyes only" one. IMHO some kind of company-wide automatic decryption breaks privacy (and may even be forbidden by law, at least in Europe). Just my ? 0.01... Cheers, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de GnuPG public key: http://home.arcor.de/dralbrecht.dress/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050816/cbe5a3b8/attachment.pgp From jam at jamux.com Tue Aug 16 22:51:19 2005 From: jam at jamux.com (John A. Martin) Date: Tue Aug 16 23:16:33 2005 Subject: **WARNING**Re: gpgme: encrypt/decrypt References: <14794035.1124219317079.JavaMail.root@m32> <0a3b01c5a29a$e4341910$800101df__14810.4051164866$1124221660$gmane$org@oldeenglish> Message-ID: <87pssdip14.fsf@athene.jamux.com> >>>>> "Michael" == Michael Nguyen >>>>> "Re: **WARNING**Re: gpgme: encrypt/decrypt" >>>>> Tue, 16 Aug 2005 12:44:17 -0700 Michael> From: "Albrecht Dre?" >> Am 16.08.05 20:22 schrieb(en) Michael Nguyen: >>> I'm creating a Postfix content filter for the company that >>> automatically does GPG encryption/decryption on incoming and >>> outgoing corporate mail. >> >> This sounds like an ineresting idea! Michael> First, I want to thank you for the response. >> However, are you sure you want to do this on the *mta* level? >> Most mua's Michael> The CEO has requested this because he wants GPG to be Michael> standard at the company and doesn't want to have any spin Michael> up time for any of the employees. He feels that it has Michael> to be as transparent as possible. If this is implemented Michael> right, no one will never know it's happening. How about just turning on Postfix's TLS support? Maybe with SMTP-AUTH as well? Then perhaps gpg for end-to-end privacy? Use the tool that fits the job. Avoid a lot of problems. jam -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 154 bytes Desc: not available Url : /pipermail/attachments/20050816/a35fa23e/attachment-0001.pgp From michaeln at twentyten.org Wed Aug 17 01:49:15 2005 From: michaeln at twentyten.org (Michael Nguyen) Date: Wed Aug 17 01:44:07 2005 Subject: gpgme: encrypt/decrypt References: <05f501c5a062$29508870$800101df@oldeenglish><87hddphl5o.fsf@wheatstone.g10code.de><0a1301c5a28f$70dd9500$800101df@oldeenglish> <87slx9g1jb.fsf@wheatstone.g10code.de> Message-ID: <0a9e01c5a2bd$1c700830$800101df@oldeenglish> From: "Werner Koch" > On Tue, 16 Aug 2005 11:22:19 -0700, Michael Nguyen said: > > > I guess this is more of a program design question. Should I be able to do > > what I want to do here? I'm creating a Postfix content filter for the > > company that automatically does GPG encryption/decryption on incoming and > > Everyone seems to write this kind of software tehse days ;-) > > For various reasons, GnuPG requires access to the full keyring. > Just import everything once and you are basically set. No deen t > duplicate the data. Hmm...so... are you saying I can't do it this way? Ok, bear with me here...this is what I've done so far: So, I've read my test public key into a string that's a member of a user struct called z.gpgPublic [sample of public key so that we're very clear on the format here] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.2 (GNU/Linux) mQGiBEMBnIcRBACbXdplRQM9iXWf30OQZqWSfT69+t5lflpvLnKehQt4FaSrxJj/ EwmsTtf7PiOm2Cjp727HUlr12gSkVWwwBT+mnUD+oqpM6Gzl6pcolzoEWHzCMwFH TTMvdnUzYTI81aY2wMTHx016IbdTeO3qZ4nQGxz95IyH1Lx+6kkinK//zwCg2Q5U [...] I then do the following: err = gpgme_data_new_from_mem (&pubKey, z.gpgPublic, strlen(z.gpgPublic), 1); err = gpgme_op_import (ctx, pubKey); So, will this really import the key? It seems to because I can find my email address: while (!(err = gpgme_op_keylist_next (ctx, &key))) { if(strcmp(z.primaryEmail, key->uids->email) == 0) { printf ("%s\n", key->uids->email); } } Basically I take this loop and I say "If you see the email address of the user, print it". It always comes up so it seems to work. So, am I going about this the right way so far? If so, how do I correctly call gpgme_op_encrypt() at this point? Michael From nielsen at memberwebs.com Sun Aug 14 02:33:54 2005 From: nielsen at memberwebs.com (Nielsen) Date: Wed Aug 17 16:43:59 2005 Subject: Listing credentials ids in gpg-agent Message-ID: <20050814003353.D022B70DB63@mail.npubs.com> Hi all. I'm wondering if there's an assuan command in the gpg-agent protocol that lists the keyids for cached credentials. I'm the author of seahorse-agent. It would be nice when gnupg2 comes out it could integrate with gpg-agent rather than trying to take the place of gpg-agent. To implement the seahorse-agent functionality of listing cached credentials and allowing the user to clear them, I'd need to be able to ask gpg-agent to list the ids for it's cache. Any ideas? Or is this somehow a bad idea? Cheers, Nate Nielsen From heathjs21 at yahoo.com Wed Aug 17 19:57:35 2005 From: heathjs21 at yahoo.com (Heather Shaw) Date: Wed Aug 17 19:58:14 2005 Subject: Creating a MAC Message-ID: <20050817175735.43599.qmail@web30014.mail.mud.yahoo.com> Hello, I am a newbie so please forgive stupid questions but, I am trying to create a message digest using the gcry_md_open (&md, GCRY_MD_SHA1, GCRY_MD_FLAG_HMAC). In the documentation it states that you must call the gcry_md_setkey to be used to set the MAC key. How do I calculate this MAC key? What is the MAC key...does it get generated from the message itself in combination with another key of some sort. Thanks Heather From stephane at sente.ch Wed Aug 17 20:37:42 2005 From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Wed Aug 17 21:38:58 2005 Subject: Bug in gpg 1.4.1/gpgme 1.0.2 - blocked while encrypting signed data with untrusted key Message-ID: <4B2D374C-E5D8-4D6B-AF55-FEE777BF179C@sente.ch> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Here's a bug I thought it had been fixed in gpg 1.4.1 (or is it gpgme 1.0.2?), but, alas, it's still present (no, I haven't tested yet the upcoming 1.4.2 release). Using gpgme 1.0.2, I encrypt and sign some data; keys used for encryption are not trusted, and I don't want them to be trusted blindly. Here's the command issued by gpgme: gpg --no-sk-comment --status-fd 26 --no-tty --charset utf8 --enable- progress-filter --command-fd 27 --encrypt --sign --armor -r SOME_UNTRUSTED_KEY_ID -r MY_KEY_ID -u MY_KEY_ID --output - -- If I perform the operation on the command line, here's what's happening: $ gpg --no-sk-comment --status-fd 1 --no-tty --charset utf8 --enable- progress-filter --command-fd 0 --encrypt --sign --armor -r SOME_UNTRUSTED_KEY_ID -r A5BAB3D84F6CAE038B2276F25467B616992020D4 -u 5467B616992020D4 --output - -- [GNUPG:] USERID_HINT 5467B616992020D4 St?phane Corth?sy (Sen:te) [GNUPG:] NEED_PASSPHRASE 5467B616992020D4 5467B616992020D4 17 0 [GNUPG:] GET_HIDDEN passphrase.enter XXX [GNUPG:] GOT_IT [GNUPG:] GOOD_PASSPHRASE gpg: XXXXXXXX: There is no assurance this key belongs to the named user [GNUPG:] GET_BOOL untrusted_key.override Process is then blocked, because it expects a 'true' or 'false' reply to the last question. I hope it's been fixed in gpg 1.4.2/gpgme 1.1 (when will they be released?), as it prevents the use of gpgme with the 'trust all keys' option. Cheers, St?phane P.-S. $ gpg --version gpg (GnuPG) 1.4.1 Copyright (C) 2005 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512 Compression: Uncompressed, ZIP, ZLIB, BZIP2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDA4P3VGe2FpkgINQRAhPbAJ4uj/u6HuBl6e5NN/mheh2LLmVbIwCgihB/ yiGEncybm0NA3Bh+I9ipyjg= =59lw -----END PGP SIGNATURE----- From folkert at vanheusden.com Wed Aug 17 22:14:34 2005 From: folkert at vanheusden.com (Folkert van Heusden) Date: Wed Aug 17 22:58:33 2005 Subject: Creating a MAC In-Reply-To: <20050817175735.43599.qmail@web30014.mail.mud.yahoo.com> References: <20050817175735.43599.qmail@web30014.mail.mud.yahoo.com> Message-ID: <20050817201433.GA5359@vanheusden.com> Isn't it easier (and faster perhaps?) to use the openssl library? #include int SHA_Init(SHA_CTX *c); int SHA_Update(SHA_CTX *c, const void *data, unsigned long len); int SHA_Final(unsigned char *md, SHA_CTX *c); easy as pie On Wed, Aug 17, 2005 at 10:57:35AM -0700, Heather Shaw wrote: > Hello, > I am a newbie so please forgive stupid questions > but, I am trying to create a message digest using the > gcry_md_open (&md, GCRY_MD_SHA1, GCRY_MD_FLAG_HMAC). > In the documentation it states that you must call the > gcry_md_setkey to be used to set the MAC key. How do > I calculate this MAC key? What is the MAC key...does > it get generated from the message itself in > combination with another key of some sort. > > Thanks > Heather > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel Folkert van Heusden -- Auto te koop, zie: http://www.vanheusden.com/daihatsu.php ---------------------------------------------------------------------- Get your PGP/GPG key signed at www.biglumber.com! ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 282 bytes Desc: Digital signature Url : /pipermail/attachments/20050817/980e3492/attachment.pgp From michaeln at twentyten.org Thu Aug 18 08:03:42 2005 From: michaeln at twentyten.org (Michael Nguyen) Date: Thu Aug 18 08:03:58 2005 Subject: gpgme: encrypt/decrypt References: <05f501c5a062$29508870$800101df@oldeenglish><87hddphl5o.fsf@wheatstone.g10code.de><0a1301c5a28f$70dd9500$800101df@oldeenglish><87slx9g1jb.fsf@wheatstone.g10code.de> <0a9e01c5a2bd$1c700830$800101df@oldeenglish> Message-ID: <018b01c5a3ba$968d62e0$800101df@oldeenglish> From: "Michael Nguyen" [snip] Umm...my umm...$50 offer still stands. If it's too low, let me know. The recipient will have the option of taking whatever the offer is or having me donate twice the offer to the Free Software Foundation. Just thought I'd mention it. ;-) Michael From wk at gnupg.org Thu Aug 18 11:18:14 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Aug 18 11:21:31 2005 Subject: Creating a MAC In-Reply-To: <20050817201433.GA5359@vanheusden.com> (Folkert van Heusden's message of "Wed, 17 Aug 2005 22:14:34 +0200") References: <20050817175735.43599.qmail@web30014.mail.mud.yahoo.com> <20050817201433.GA5359@vanheusden.com> Message-ID: <87r7crd2nd.fsf@wheatstone.g10code.de> On Wed, 17 Aug 2005 22:14:34 +0200, Folkert van Heusden said: > int SHA_Init(SHA_CTX *c); > int SHA_Update(SHA_CTX *c, const void *data, unsigned long len); > int SHA_Final(unsigned char *md, SHA_CTX *c); That does not produce a MAC. BTW, with Libgcrypt you can do the above even in one step: gcry_md_hash_buffer (GCRY_MD_SHA1, void *digest, const void *buffer, size_t length); Please let me remark again that basic cryptographic knowledge is required to develop application with Libgcrypt. Schneier's "Practical Cryptography" seems to be a very good resource. An example on how to implement MACing may be found in ftp://ftp.gnupg.org/gcrypt/alpha/gsti/gsti-0.3.0.tar.bz2 which implements the Secure Shell (ssh) protocol. Shalom-Salam, Werner From wk at gnupg.org Thu Aug 18 11:39:17 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Aug 18 11:41:30 2005 Subject: gpgme: encrypt/decrypt In-Reply-To: <0a9e01c5a2bd$1c700830$800101df@oldeenglish> (Michael Nguyen's message of "Tue, 16 Aug 2005 16:49:15 -0700") References: <05f501c5a062$29508870$800101df@oldeenglish> <87hddphl5o.fsf@wheatstone.g10code.de> <0a1301c5a28f$70dd9500$800101df@oldeenglish> <87slx9g1jb.fsf@wheatstone.g10code.de> <0a9e01c5a2bd$1c700830$800101df@oldeenglish> Message-ID: <87mznfd1oa.fsf@wheatstone.g10code.de> On Tue, 16 Aug 2005 16:49:15 -0700, Michael Nguyen said: > So, I've read my test public key into a string that's a member of a user > struct called z.gpgPublic Okay. > err = gpgme_data_new_from_mem (&pubKey, z.gpgPublic, strlen(z.gpgPublic), > 1); > err = gpgme_op_import (ctx, pubKey); > So, will this really import the key? It seems to because I can find my > email address: Yes. If you need to know what keys are actually imported, you may want to call /* Retrieve a pointer to the result of the import operation. */ gpgme_import_result_t gpgme_op_import_result (gpgme_ctx_t ctx); which returns a structure with the stats similar to the one seen when running gpg on the command line. Further result->imports ist the head of a linked list describing each imported key. struct _gpgme_import_status { struct _gpgme_import_status *next; /* Fingerprint. */ char *fpr; /* If a problem occured, the reason why the key could not be imported. Otherwise GPGME_No_Error. */ gpgme_error_t result; /* The result of the import, the GPGME_IMPORT_* values bit-wise ORed. 0 means the key was already known and no new components have been added. */ unsigned int status; }; > while (!(err = gpgme_op_keylist_next (ctx, &key))) > { > if(strcmp(z.primaryEmail, key->uids->email) == 0) > { > printf ("%s\n", key->uids->email); > } > } Well this would work too but is slower. > Basically I take this loop and I say "If you see the email address of the > user, print it". It always comes up so it seems to work. So, am I going > about this the right way so far? If so, how do I correctly call > gpgme_op_encrypt() at this point? If you already know the fingerprint of the key (from the import stats) you may use the convenience function /* Get the key with the fingerprint FPR from the crypto backend. If SECRET is true, get the secret key. */ gpgme_error_t gpgme_get_key (gpgme_ctx_t ctx, const char *fpr, gpgme_key_t *r_key, int secret) Using your search by email works too, however this might return several keys if it happens that there are several keys with the same email address. In genereal, using the fingerprint is the best way. Encryption (from tests/gpg/t-encrypt.c): int main (int argc, char *argv[]) { gpgme_ctx_t ctx; gpgme_error_t err; gpgme_data_t in, out; gpgme_key_t key[3] = { NULL, NULL, NULL }; gpgme_encrypt_result_t result; init_gpgme (GPGME_PROTOCOL_OpenPGP); err = gpgme_new (&ctx); fail_if_err (err); gpgme_set_armor (ctx, 1); err = gpgme_data_new_from_mem (&in, "Hallo Leute\n", 12, 0); fail_if_err (err); err = gpgme_data_new (&out); fail_if_err (err); /* Put the keys into the array. Two keys in this example. Make sure that the last entry in the array is NULL (done by the intialization above). */ err = gpgme_get_key (ctx, "A0FF4590BB6122EDEF6E3C542D727CC768697734", &key[0], 0); fail_if_err (err); err = gpgme_get_key (ctx, "D695676BDCEDCC2CDD6152BCFE180B1DA9E3B0B2", &key[1], 0); fail_if_err (err); err = gpgme_op_encrypt (ctx, key, GPGME_ENCRYPT_ALWAYS_TRUST, in, out); fail_if_err (err); result = gpgme_op_encrypt_result (ctx); if (result->invalid_recipients) { fprintf (stderr, "Invalid recipient encountered: %s\n", result->invalid_recipients->fpr); exit (1); } print_data (out); gpgme_key_unref (key[0]); gpgme_key_unref (key[1]); gpgme_data_release (in); gpgme_data_release (out); gpgme_release (ctx); return 0; } Salam-Shalom, Werner From wk at gnupg.org Thu Aug 18 11:42:22 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Aug 18 11:46:29 2005 Subject: Listing credentials ids in gpg-agent In-Reply-To: <20050814003353.D022B70DB63@mail.npubs.com> (nielsen@memberwebs.com's message of "Sun, 14 Aug 2005 00:33:54 +0000 (GMT)") References: <20050814003353.D022B70DB63@mail.npubs.com> Message-ID: <87iry3d1j5.fsf@wheatstone.g10code.de> On Sun, 14 Aug 2005 00:33:54 +0000 (GMT), Nielsen said: > I'm wondering if there's an assuan command in the gpg-agent protocol > that lists the keyids for cached credentials. Not yet. However I have seen a need for this myself. Will be implemented as time permits. > I'm the author of seahorse-agent. It would be nice when gnupg2 comes out > it could integrate with gpg-agent rather than trying to take the place > of gpg-agent. I am not sure whether I understood it. gpg-agent will be part of gnupg2 as it is now part of gnupg-1.9.x. Shalom-Salam, Werner From heathjs21 at yahoo.com Thu Aug 18 15:10:48 2005 From: heathjs21 at yahoo.com (Heather Shaw) Date: Thu Aug 18 15:11:33 2005 Subject: Creating a MAC Message-ID: <20050818131048.38022.qmail@web30003.mail.mud.yahoo.com> Thank you for the help. Let me tell you what I am trying to do. I found some test examples in the document located at: http://csrc.nist.gov/publications/fips/fips198/fips-198a.pdf for Appendix A: Sample #1. I am trying to verify my logic by using their key and text to compare results to ensure I am correctly utilizing the libraries in libcrypt. From bogus@does.not.exist.com Mon Aug 15 10:25:50 2005 From: bogus@does.not.exist.com () Date: Thu Aug 18 15:11:34 2005 Subject: No subject Message-ID: to install on our solaris machines so I can't view the TAR) I can't really determine what the difference is other than maybe the way I using the key??. I am also not real sure what the u32 seqno represents...maybe it is specific to ssl, I don't know. All I am doing is setting an unsigned char* equal to the key as given in the example from the document. I call gcry_md_open with the SHA1, HMAC. I pass the key from above into the gcry_md_setkey function. Then I am taking my text buffer "Sample #1" and calling the gcry_md_write with the text and size. When I call gcry_md_read and print it, I don't get the same result as expected in the document. I thought it was pretty straight-forward, but I don't understand I am not processing the examples in the document to produce the same result. From the ssl example, it appears I am following the same logic. Any help would be appreciated. From jharris at widomaker.com Thu Aug 18 23:17:05 2005 From: jharris at widomaker.com (Jason Harris) Date: Thu Aug 18 23:17:42 2005 Subject: [svn] GnuPG - r3867 - trunk/keyserver In-Reply-To: References: Message-ID: <20050818211705.GA90346@wilma.widomaker.com> On Thu, Aug 18, 2005 at 11:14:17PM +0200, svn author dshaw wrote: > Author: dshaw > Date: 2005-08-18 23:14:16 +0200 (Thu, 18 Aug 2005) > New Revision: 3867 > > Modified: > trunk/keyserver/ChangeLog > trunk/keyserver/gpgkeys_hkp.c > trunk/keyserver/gpgkeys_ldap.c > trunk/keyserver/ksutil.c > trunk/keyserver/ksutil.h > Log: > * ksutil.h, ksutil.c (parse_ks_options): New keyserver-option exact-name. > The last of exact-name and exact-email overrides the earlier. It works better without the <, so remove it: Index: keyserver/gpgkeys_hkp.c =================================================================== --- keyserver/gpgkeys_hkp.c (revision 3867) +++ keyserver/gpgkeys_hkp.c (working copy) @@ -304,7 +304,6 @@ } strcpy(bracketed,searchkey); - strcat(bracketed," <"); searchkey_encoded=curl_escape(bracketed,0); free(bracketed); -- 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: 313 bytes Desc: not available Url : /pipermail/attachments/20050818/c46368eb/attachment.pgp From dshaw at jabberwocky.com Thu Aug 18 23:34:58 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Aug 18 23:35:50 2005 Subject: [svn] GnuPG - r3867 - trunk/keyserver In-Reply-To: <20050818211705.GA90346@wilma.widomaker.com> References: <20050818211705.GA90346@wilma.widomaker.com> Message-ID: <20050818213458.GA1501@jabberwocky.com> On Thu, Aug 18, 2005 at 05:17:05PM -0400, Jason Harris wrote: > On Thu, Aug 18, 2005 at 11:14:17PM +0200, svn author dshaw wrote: > > > Author: dshaw > > Date: 2005-08-18 23:14:16 +0200 (Thu, 18 Aug 2005) > > New Revision: 3867 > > > > Modified: > > trunk/keyserver/ChangeLog > > trunk/keyserver/gpgkeys_hkp.c > > trunk/keyserver/gpgkeys_ldap.c > > trunk/keyserver/ksutil.c > > trunk/keyserver/ksutil.h > > Log: > > * ksutil.h, ksutil.c (parse_ks_options): New keyserver-option exact-name. > > The last of exact-name and exact-email overrides the earlier. > > It works better without the <, so remove it: Except, of course, that doesn't do what I want. David From jharris at widomaker.com Fri Aug 19 00:33:31 2005 From: jharris at widomaker.com (Jason Harris) Date: Fri Aug 19 00:33:52 2005 Subject: [svn] GnuPG - r3867 - trunk/keyserver In-Reply-To: <20050818213458.GA1501@jabberwocky.com> References: <20050818211705.GA90346@wilma.widomaker.com> <20050818213458.GA1501@jabberwocky.com> Message-ID: <20050818223330.GI358@wilma.widomaker.com> On Thu, Aug 18, 2005 at 05:34:58PM -0400, David Shaw wrote: > On Thu, Aug 18, 2005 at 05:17:05PM -0400, Jason Harris wrote: > > It works better without the <, so remove it: > > Except, of course, that doesn't do what I want. I see. So you'll be adding "--keyserver-options exact-full-userid" and "exact-partial-userid" next, then? Wouldn't it be easier just to apply the notation that GPG already understands/documents for --list-keys et. al. to --search (from gpg.1): =Heinrich Heine Using an exact to match string. The equal sign indicates this. Using the email address part which must match exactly. The left angle bracket indicates this email address mode. +Heinrich Heine duesseldorf All words must match exactly (not case sensi- tive) but can appear in any order in the user ID. Words are any sequences of letters, digits, the underscore and all characters with bit 7 set. Heine *Heine By case insensitive substring matching. This is the default mode but applications may want to explicitly indicate this by putting the asterisk in front. NB: Although + seems redundant, it also doesn't work yet (GPG v1.4.2): %gpg -k "+David M. Shaw" gpg: DBG: word search mode does not yet work gpg: DBG: word search mode does not yet work gpg: DBG: word search mode does not yet work gpg: DBG: word search mode does not yet work gpg: DBG: word search mode does not yet work gpg: error reading key: public key not found v.: %gpg -k "*David M. shaw" pub 4096R/99242560 2002-01-28 ... and: %gpg -k "David M. shaw" pub 4096R/99242560 2002-01-28 ... -- 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: 313 bytes Desc: not available Url : /pipermail/attachments/20050818/b2550d23/attachment.pgp From dshaw at jabberwocky.com Fri Aug 19 02:47:07 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Aug 19 02:47:51 2005 Subject: [svn] GnuPG - r3867 - trunk/keyserver In-Reply-To: <20050818223330.GI358@wilma.widomaker.com> References: <20050818211705.GA90346@wilma.widomaker.com> <20050818213458.GA1501@jabberwocky.com> <20050818223330.GI358@wilma.widomaker.com> Message-ID: <20050819004707.GA1722@jabberwocky.com> On Thu, Aug 18, 2005 at 06:33:31PM -0400, Jason Harris wrote: > On Thu, Aug 18, 2005 at 05:34:58PM -0400, David Shaw wrote: > > On Thu, Aug 18, 2005 at 05:17:05PM -0400, Jason Harris wrote: > > > > It works better without the <, so remove it: > > > > Except, of course, that doesn't do what I want. > > I see. So you'll be adding "--keyserver-options exact-full-userid" > and "exact-partial-userid" next, then? No. I don't think they're useful, and keyservers don't support them uniformly anyway, so the point is moot. > Wouldn't it be easier just to apply the notation that GPG already > understands/documents for --list-keys et. al. to --search > (from gpg.1): Not a bad idea, though keyservers can't all handle this fully. Jason, it would be really helpful if we could dispense with the traditional suggestion method you use. This isn't the first time, and it's wasting both our time. Generally, they go like this (pardon the paraphrase): Jason: This sucks. Change it. (Without saying what, exactly, is bothering you.) David: No. (Irritated because he's again replying to noise without an actual suggestion). Jason: Sarcastic comment. (Pause) Useful suggestion. Can we cut straight to the "Useful suggestion" part? David From mschwendt at gmail.com Fri Aug 19 01:50:42 2005 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri Aug 19 02:55:12 2005 Subject: gnupg2-1.9.18: 'make check' fails on x86_64 In-Reply-To: <42F8E0D9.4090401@unl.edu> References: <42F8E0D9.4090401@unl.edu> Message-ID: <440f31f6050818165039dcedc@mail.gmail.com> On 09/08/05, Rex Dieter wrote: > > Trying to build gnupg2-1.9.18 on Fedora Core 4/x86_64 (gcc-4.0.1) fails > in 'make check': > > Any ideas? As the previous 1.9.17 version of gnupg2 built fine and passed the tests, too, that raises the question whether it would still build fine with the updated libksba/libassuan? Shouldn't hurt to request a build for an old tag. From jharris at widomaker.com Fri Aug 19 03:32:23 2005 From: jharris at widomaker.com (Jason Harris) Date: Fri Aug 19 03:48:15 2005 Subject: [svn] GnuPG - r3867 - trunk/keyserver In-Reply-To: <20050819004707.GA1722@jabberwocky.com> References: <20050818211705.GA90346@wilma.widomaker.com> <20050818213458.GA1501@jabberwocky.com> <20050818223330.GI358@wilma.widomaker.com> <20050819004707.GA1722@jabberwocky.com> Message-ID: <20050819013223.GJ358@wilma.widomaker.com> On Thu, Aug 18, 2005 at 08:47:07PM -0400, David Shaw wrote: > On Thu, Aug 18, 2005 at 06:33:31PM -0400, Jason Harris wrote: > > I see. So you'll be adding "--keyserver-options exact-full-userid" > > and "exact-partial-userid" next, then? > > No. I don't think they're useful, and keyservers don't support them > uniformly anyway, so the point is moot. Keyservers (HKP) only support exact and not exact, it is only when one adds " <" and/or ">" to a search that it is "limited" to outside and/or a full match of the email address. > > Wouldn't it be easier just to apply the notation that GPG already > > understands/documents for --list-keys et. al. to --search > > (from gpg.1): > > Not a bad idea, though keyservers can't all handle this fully. LDAP? (pks and SKS can, AFAIK.) > Jason, it would be really helpful if we could dispense with the > traditional suggestion method you use. This isn't the first time, and > it's wasting both our time. Generally, they go like this (pardon the > paraphrase): > > Jason: This sucks. Change it. (Without saying what, exactly, is > bothering you.) > > David: No. (Irritated because he's again replying to noise without an > actual suggestion). > > Jason: Sarcastic comment. (Pause) Useful suggestion. No sarcasm was intended. Really, you've already got two of the four ways (HKP) keyservers can be asked to do exact searches; I'm just advocating that all four be supported. > Can we cut straight to the "Useful suggestion" part? I thought initially that the " <" was wrong. Nothing more, nothing less. Not allowing spaces in email addresses already seems to preclude finding exact matches for "David M. Shaw" inside email addresses, TTBOMK, hence my initial reaction. Again, no sarcasm was (or is) intended. -- 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: 313 bytes Desc: not available Url : /pipermail/attachments/20050818/6432dbfe/attachment.pgp From dshaw at jabberwocky.com Fri Aug 19 04:48:54 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Aug 19 04:49:52 2005 Subject: [svn] GnuPG - r3867 - trunk/keyserver In-Reply-To: <20050819013223.GJ358@wilma.widomaker.com> References: <20050818211705.GA90346@wilma.widomaker.com> <20050818213458.GA1501@jabberwocky.com> <20050818223330.GI358@wilma.widomaker.com> <20050819004707.GA1722@jabberwocky.com> <20050819013223.GJ358@wilma.widomaker.com> Message-ID: <20050819024854.GA1748@jabberwocky.com> On Thu, Aug 18, 2005 at 09:32:23PM -0400, Jason Harris wrote: > On Thu, Aug 18, 2005 at 08:47:07PM -0400, David Shaw wrote: > > On Thu, Aug 18, 2005 at 06:33:31PM -0400, Jason Harris wrote: > > > > I see. So you'll be adding "--keyserver-options exact-full-userid" > > > and "exact-partial-userid" next, then? > > > > No. I don't think they're useful, and keyservers don't support them > > uniformly anyway, so the point is moot. > > Keyservers (HKP) only support exact and not exact, it is only when > one adds " <" and/or ">" to a search that it is "limited" to outside > and/or a full match of the email address. " <" and ">" are pretty good, but not perfect methods. For example, take this user ID (I've actually seen one like this): Joe Smith (old email address is ) It will incorrectly match a search of . Fussy example, to be sure, but it's inconsistent with LDAP which can do true exact matches: a LDAP search for "pgpuserid=*" correctly won't match because of the right anchor. The reason for the " <" is so that a HKP search for "Joe Smith <" *won't* match the above. It really shouldn't since it's not an exact match of the not-email-address part of the uid. Even so, take this: Joe Smith A HKP " <" search for that using "Smith <" will match and should not since again it's not exact. A LDAP search for "pgpuserid=Smith <*" will correctly not match because of the left anchor. So... like I said: pretty good, but not perfect. Probably good enough for the majority of cases. > > > Wouldn't it be easier just to apply the notation that GPG already > > > understands/documents for --list-keys et. al. to --search > > > (from gpg.1): > > > > Not a bad idea, though keyservers can't all handle this fully. > > LDAP? (pks and SKS can, AFAIK.) No, the other way around. LDAP actually supports everything here and more since it has an actual search syntax with wildcards. Both pks and SKS searches are much more limited and inherently substring. In pks, "exact" means "exact substring with whole words" and "not exact" means "whole word match". Not quite sure exactly what SKS does, but I know the search facility there is being tinkered with as we speak. David From jharris at widomaker.com Fri Aug 19 06:24:05 2005 From: jharris at widomaker.com (Jason Harris) Date: Fri Aug 19 06:24:22 2005 Subject: full-text v. regular expression userid searches (was: Re: [svn] GnuPG - r3867 - trunk/keyserver) In-Reply-To: <20050819024854.GA1748@jabberwocky.com> References: <20050818211705.GA90346@wilma.widomaker.com> <20050818213458.GA1501@jabberwocky.com> <20050818223330.GI358@wilma.widomaker.com> <20050819004707.GA1722@jabberwocky.com> <20050819013223.GJ358@wilma.widomaker.com> <20050819024854.GA1748@jabberwocky.com> Message-ID: <20050819042404.GA92174@wilma.widomaker.com> On Thu, Aug 18, 2005 at 10:48:54PM -0400, David Shaw wrote: > On Thu, Aug 18, 2005 at 09:32:23PM -0400, Jason Harris wrote: > > LDAP? (pks and SKS can, AFAIK.) > > No, the other way around. LDAP actually supports everything here and > more since it has an actual search syntax with wildcards. Both pks > and SKS searches are much more limited and inherently substring. In > pks, "exact" means "exact substring with whole words" and "not exact" > means "whole word match". Not quite sure exactly what SKS does, but I > know the search facility there is being tinkered with as we speak. pks considers "words" to be 2 or more chars long, SKS allow single- character "words." Neither currently stores the full userid strings in a separate db (table), so both match whole words, fetch the candidate keys, and check for exact substring matches in the candidate keys. Supporting (e.g., POSIX) Regular Expression searches would be interesting, both in GPG and (HKP) keyserver keyrings, but searching the 2545113+ userids (on 2209793+ keys) on (well-synchronized) keyservers could be unacceptably slow. The raw text is 99425942+ bytes (94.8+MB). NB: The legacy LDAP server fails this search: gpgkeys: LDAP search for: (&(pgpuserid=3D*jaso*harr*)(pgpdisabled=3D0)) although the GD (LDAP) server quickly returns (always only one match) 0x341A91C4. But, I don't consider the GD a good benchmark since it has so few keys, can (and does?) stop looking after the first match, etc. -- 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: 313 bytes Desc: not available Url : /pipermail/attachments/20050819/e46c3f60/attachment.pgp From dshaw at jabberwocky.com Fri Aug 19 06:35:22 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Aug 19 06:36:20 2005 Subject: full-text v. regular expression userid searches (was: Re: [svn] GnuPG - r3867 - trunk/keyserver) In-Reply-To: <20050819042404.GA92174@wilma.widomaker.com> References: <20050818211705.GA90346@wilma.widomaker.com> <20050818213458.GA1501@jabberwocky.com> <20050818223330.GI358@wilma.widomaker.com> <20050819004707.GA1722@jabberwocky.com> <20050819013223.GJ358@wilma.widomaker.com> <20050819024854.GA1748@jabberwocky.com> <20050819042404.GA92174@wilma.widomaker.com> Message-ID: <20050819043522.GA3468@jabberwocky.com> On Fri, Aug 19, 2005 at 12:24:05AM -0400, Jason Harris wrote: > On Thu, Aug 18, 2005 at 10:48:54PM -0400, David Shaw wrote: > > On Thu, Aug 18, 2005 at 09:32:23PM -0400, Jason Harris wrote: > > > > LDAP? (pks and SKS can, AFAIK.) > > > > No, the other way around. LDAP actually supports everything here and > > more since it has an actual search syntax with wildcards. Both pks > > and SKS searches are much more limited and inherently substring. In > > pks, "exact" means "exact substring with whole words" and "not exact" > > means "whole word match". Not quite sure exactly what SKS does, but I > > know the search facility there is being tinkered with as we speak. > > pks considers "words" to be 2 or more chars long, SKS allow single- > character "words." Neither currently stores the full userid strings > in a separate db (table), so both match whole words, fetch the candidate > keys, and check for exact substring matches in the candidate keys. > > Supporting (e.g., POSIX) Regular Expression searches would be interesting, > both in GPG and (HKP) keyserver keyrings, but searching the 2545113+ > userids (on 2209793+ keys) on (well-synchronized) keyservers could be > unacceptably slow. The raw text is 99425942+ bytes (94.8+MB). I don't know that it would be unusably slow: searching in a database is a very well researched problem and there are ways to speed things up. I seem to recall the old PGP LDAP server did quite well in searching, and it had quite a large number of keys to search through. Even though it wasn't synchronized with the HKP world, it was pretty up to date (being the default server for PGP). Not that I'm suggesting regex searches. I think they're overkill for the problem at hand. Even LDAP doesn't do full regex. > NB: The legacy LDAP server fails this search: > > gpgkeys: LDAP search for: (&(pgpuserid=3D*jaso*harr*)(pgpdisabled=3D0)) > > although the GD (LDAP) server quickly returns (always only one match) > 0x341A91C4. But, I don't consider the GD a good benchmark since it has > so few keys, can (and does?) stop looking after the first match, etc. Which legacy LDAP server are you testing with? PGP.com's old server is gone, and I think horowitz is currently broken: any search returns no responses. David From jharris at widomaker.com Fri Aug 19 15:49:19 2005 From: jharris at widomaker.com (Jason Harris) Date: Fri Aug 19 15:49:50 2005 Subject: full-text v. regular expression userid searches (was: Re: [svn] GnuPG - r3867 - trunk/keyserver) In-Reply-To: <20050819043522.GA3468@jabberwocky.com> References: <20050818211705.GA90346@wilma.widomaker.com> <20050818213458.GA1501@jabberwocky.com> <20050818223330.GI358@wilma.widomaker.com> <20050819004707.GA1722@jabberwocky.com> <20050819013223.GJ358@wilma.widomaker.com> <20050819024854.GA1748@jabberwocky.com> <20050819042404.GA92174@wilma.widomaker.com> <20050819043522.GA3468@jabberwocky.com> Message-ID: <20050819134919.GL358@wilma.widomaker.com> On Fri, Aug 19, 2005 at 12:35:22AM -0400, David Shaw wrote: > On Fri, Aug 19, 2005 at 12:24:05AM -0400, Jason Harris wrote: > > Supporting (e.g., POSIX) Regular Expression searches would be interesting, > > both in GPG and (HKP) keyserver keyrings, but searching the 2545113+ > > userids (on 2209793+ keys) on (well-synchronized) keyservers could be > > unacceptably slow. The raw text is 99425942+ bytes (94.8+MB). > > I don't know that it would be unusably slow: searching in a database > is a very well researched problem and there are ways to speed things > up. I seem to recall the old PGP LDAP server did quite well in > searching, and it had quite a large number of keys to search through. > Even though it wasn't synchronized with the HKP world, it was pretty > up to date (being the default server for PGP). It may have, but I just mentioned it (keyserver-legacy.pgp.com) failing a partial-word search when it should have matched several keys, so it might only be doing such searches from the beginning of words now. Anyway, pks and SKS use Berkeley DB, which only allows partial matching or range searching in sorted (Btree) dbs/tables from the beginning of words/keys (via DBcursor->c_get (..., DB_SET_RANGE), in case anyone wants to try it). This is good for finding "david" as the first available word after the (currently) non-existent "davic," for example, but can't be used for other types of partial-word searches. If you're thinking of a particular SQL feature, fine, but you'd have to run CKS, onak, or OpenPKSD to get SQL. (Also, please provide URLs for any SQL/database feature(s) you are referring to.) > Not that I'm suggesting regex searches. I think they're overkill for > the problem at hand. Even LDAP doesn't do full regex. Well, allowing "anchoring" of the (full-word) searches with ^ and $ sounds like it would be a good start, > Which legacy LDAP server are you testing with? PGP.com's old server > is gone, and I think horowitz is currently broken: any search returns > no responses. keyserver-legacy.pgp.com. -- 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: 313 bytes Desc: not available Url : /pipermail/attachments/20050819/8ef1e961/attachment.pgp From dshaw at jabberwocky.com Fri Aug 19 16:55:06 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Aug 19 16:55:50 2005 Subject: full-text v. regular expression userid searches (was: Re: [svn] GnuPG - r3867 - trunk/keyserver) In-Reply-To: <20050819134919.GL358@wilma.widomaker.com> References: <20050818211705.GA90346@wilma.widomaker.com> <20050818213458.GA1501@jabberwocky.com> <20050818223330.GI358@wilma.widomaker.com> <20050819004707.GA1722@jabberwocky.com> <20050819013223.GJ358@wilma.widomaker.com> <20050819024854.GA1748@jabberwocky.com> <20050819042404.GA92174@wilma.widomaker.com> <20050819043522.GA3468@jabberwocky.com> <20050819134919.GL358@wilma.widomaker.com> Message-ID: <20050819145506.GA5731@jabberwocky.com> On Fri, Aug 19, 2005 at 09:49:19AM -0400, Jason Harris wrote: > Anyway, pks and SKS use Berkeley DB, which only allows partial matching > or range searching in sorted (Btree) dbs/tables from the beginning of > words/keys (via DBcursor->c_get (..., DB_SET_RANGE), in case anyone > wants to try it). This is good for finding "david" as the first > available word after the (currently) non-existent "davic," for > example, but can't be used for other types of partial-word searches. > > If you're thinking of a particular SQL feature, fine, but you'd have > to run CKS, onak, or OpenPKSD to get SQL. (Also, please provide URLs > for any SQL/database feature(s) you are referring to.) I'm not thinking of SQL or any particular technology. Just pointing out the same thing you are: pks and SKS use a backend storage system that doesn't allow for searching in all the ways that some people want. If these people really want more searchability, it may well mean significant changes in SKS and/or pks. Which, I should caution, I'm not arguing for. I think the current system is a pretty decent compromise. I'd leave it alone. > > Not that I'm suggesting regex searches. I think they're overkill for > > the problem at hand. Even LDAP doesn't do full regex. > > Well, allowing "anchoring" of the (full-word) searches with ^ and $ > sounds like it would be a good start, Hard to do in a backwards compatible way, but at least it's not likely that people use ^ and $ at the beginning and end of their real user IDs. Anyway, I can't say I think it's really necessary, but if SKS starts to support it, I'll add support for it in gpgkeys_hkp. David From jharris at widomaker.com Sat Aug 20 14:13:32 2005 From: jharris at widomaker.com (Jason Harris) Date: Sat Aug 20 14:16:36 2005 Subject: full-text v. regular expression userid searches (was: Re: [svn] GnuPG - r3867 - trunk/keyserver) In-Reply-To: <20050819145506.GA5731@jabberwocky.com> References: <20050818211705.GA90346@wilma.widomaker.com> <20050818213458.GA1501@jabberwocky.com> <20050818223330.GI358@wilma.widomaker.com> <20050819004707.GA1722@jabberwocky.com> <20050819013223.GJ358@wilma.widomaker.com> <20050819024854.GA1748@jabberwocky.com> <20050819042404.GA92174@wilma.widomaker.com> <20050819043522.GA3468@jabberwocky.com> <20050819134919.GL358@wilma.widomaker.com> <20050819145506.GA5731@jabberwocky.com> Message-ID: <20050820121332.GM358@wilma.widomaker.com> On Fri, Aug 19, 2005 at 10:55:06AM -0400, David Shaw wrote: > On Fri, Aug 19, 2005 at 09:49:19AM -0400, Jason Harris wrote: > > > Not that I'm suggesting regex searches. I think they're overkill for > > > the problem at hand. Even LDAP doesn't do full regex. > > > > Well, allowing "anchoring" of the (full-word) searches with ^ and $ > > sounds like it would be a good start, > > Hard to do in a backwards compatible way, but at least it's not likely > that people use ^ and $ at the beginning and end of their real user > IDs. Anyway, I can't say I think it's really necessary, but if SKS > starts to support it, I'll add support for it in gpgkeys_hkp. This applies after yminsky@cs.cornell.edu--2004/sks--mainline--1.0--patch-44, Enjoy: --- orig/utils.ml +++ mod/utils.ml @@ -327,16 +327,13 @@ let substring_find ~sub string = try - for i = 0 to String.length string - String.length sub do - try - for j = 0 to String.length sub - 1 do - if string.[i+j] <> sub.[j] then raise Exit - done; - raise (Found i) - with - Exit -> () - done; - -1 + let string = String.lowercase string in + let sub = String.lowercase sub in + let re = Str.regexp sub in + try + let pos = Str.search_forward re string 0 in + raise (Found pos) + with Not_found -> raise (Found (-1)) + -1 with - Found i -> i - + Found pos -> pos -- 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: 313 bytes Desc: not available Url : /pipermail/attachments/20050820/024b8636/attachment.pgp From nielsen at memberwebs.com Sun Aug 21 03:54:52 2005 From: nielsen at memberwebs.com (Nielsen) Date: Sun Aug 21 03:52:11 2005 Subject: Listing credentials ids in gpg-agent References: <20050814003353.D022B70DB63@mail.npubs.com> <87iry3d1j5.fsf@wheatstone.g10code.de> Message-ID: <20050821015452.11CCF70DBD2@mail.npubs.com> Werner Koch wrote: > On Sun, 14 Aug 2005 00:33:54 +0000 (GMT), Nielsen said: >>I'm wondering if there's an assuan command in the gpg-agent protocol >>that lists the keyids for cached credentials. > > Not yet. However I have seen a need for this myself. Will be > implemented as time permits. Wonderful. >>I'm the author of seahorse-agent. It would be nice when gnupg2 comes out >> it could integrate with gpg-agent rather than trying to take the place >>of gpg-agent. > > I am not sure whether I understood it. gpg-agent will be part of > gnupg2 as it is now part of gnupg-1.9.x. Yup. Currently seahorse-agent performs passphrase caching for GNOME users of Seahorse. Once gnupg2 is stable, then it won't need to anymore. However to continue with functionality like listing cached secrets in the notification area, it'll need to be able to poll gpg-agent for the key ids of the secrets it has cached. Cheers, Nate From kssingvo at suse.de Wed Aug 24 15:07:17 2005 From: kssingvo at suse.de (Klaus Singvogel) Date: Wed Aug 24 15:44:54 2005 Subject: [Sks-devel] Re: zero-length MPIs (was: Re: mpi error with check-trustdb in 1.4.2 - resolved) In-Reply-To: <20050812002243.GD358@wilma.widomaker.com> References: <42F97044.9050603@comcast.net> <42FAC641.9040507@comcast.net> <20050811160217.GC358@wilma.widomaker.com> <20050811182144.GA33562@wilma.widomaker.com> <20050811195459.GB12783@opium.palfrader.org> <20050812002243.GD358@wilma.widomaker.com> Message-ID: <20050824130716.GA4211@suse.de> Hi. Jason Harris wrote: > On Thu, Aug 11, 2005 at 09:54:59PM +0200, Peter Palfrader wrote: > > On Thu, 11 Aug 2005, Jason Harris wrote: > > > > Fetching them from keyserver.kjsl.com is now possible with gnupg-1.4.2. > > > To patch pks, add this to the middle of decode_mpi() (in pgputil.c): > > > > > > /* skip packets with 0-length MPIs for GPG's benefit (gnupg-1.4.2) */ > > > if (mpi->nbits == 0) { > > > return (0); > > > } > > > > can we do that in SKS too? please! > > Try the patch below. 0x1A9537E7 is another offending key, and all eight > work now: > [...] I don't see those files in my copy of gnupg-1.4.2. where your patch applies. Therefore I looked myself closer at the code, as this problem araises unter "gpg --trustdb" at some of our users. I noticed that these messages are coming from mpi/mpicoder.c:mpi_read() and had a closer look at it. :-) The second if check, for "goto overflow;" seems a bit doubtful (maybe a copy&paste without to much thinking whats coming next ? :-) As there are no mandatory reads from the iobuf coming, only optional reads, I changed the code to "if (++nread > nmax)" and the problem was gone (see attached patch). Please confirm me, that my thinking is correct here. Thanks in advance. Regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: Klaus.Singvogel@SuSE.de 90409 Nuernberg Phone: +49 (0) 911 740530 Germany GnuPG-Key-ID: 1024R/5068792D 1994-06-27 -------------- next part -------------- --- gnupg-1.4.2/mpi/mpicoder.c.orig 2005-05-31 08:30:05.000000000 +0200 +++ gnupg-1.4.2/mpi/mpicoder.c 2005-08-24 14:51:07.000000000 +0200 @@ -87,7 +87,7 @@ nbits = c << 8; if( (c = iobuf_get(inp)) == -1 ) goto leave; - if (++nread >= nmax) + if (++nread > nmax) goto overflow; nbits |= c; if( nbits > MAX_EXTERN_MPI_BITS ) { From rdieter at math.unl.edu Fri Aug 26 14:50:09 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri Aug 26 14:50:38 2005 Subject: gnupg2-1.9.18: gpgkey2ssh: gpgkey2ssh.c:255: main: Assertion `argc == 2' failed. Message-ID: <430F1001.8090809@math.unl.edu> Anyone else seeing this with gnupg2-1.9.18: $gpgkey2ssh gpgkey2ssh: gpgkey2ssh.c:255: main: Assertion `argc == 2' failed. Does the same on all platforms I've built for, including RedHat 9, Fedora Core 4, RedHat Enterprise 4. -- Rex From wk at gnupg.org Fri Aug 26 16:20:36 2005 From: wk at gnupg.org (Werner Koch) Date: Fri Aug 26 16:26:37 2005 Subject: gnupg2-1.9.18: gpgkey2ssh: gpgkey2ssh.c:255: main: Assertion `argc == 2' failed. In-Reply-To: <430F1001.8090809@math.unl.edu> (Rex Dieter's message of "Fri, 26 Aug 2005 07:50:09 -0500") References: <430F1001.8090809@math.unl.edu> Message-ID: <874q9c230r.fsf@wheatstone.g10code.de> On Fri, 26 Aug 2005 07:50:09 -0500, Rex Dieter said: > $gpgkey2ssh > gpgkey2ssh: gpgkey2ssh.c:255: main: Assertion `argc == 2' failed. Its a q+d hack without any option parsing or help output. Run it as: gpgkey2ssh keyid Salam-Shalom, Werner From rdieter1 at unl.edu Fri Aug 26 17:54:14 2005 From: rdieter1 at unl.edu (Rex Dieter) Date: Fri Aug 26 17:55:49 2005 Subject: gnupg2-1.9.18: 'make check' fails on x86_64 In-Reply-To: <440f31f6050818165039dcedc@mail.gmail.com> References: <42F8E0D9.4090401@unl.edu> <440f31f6050818165039dcedc@mail.gmail.com> Message-ID: <430F3B26.1040606@unl.edu> Michael Schwendt wrote: > On 09/08/05, Rex Dieter wrote: > >>Trying to build gnupg2-1.9.18 on Fedora Core 4/x86_64 (gcc-4.0.1) fails >>in 'make check': >> >>Any ideas? > > > As the previous 1.9.17 version of gnupg2 built fine and passed the > tests, too, that raises the question whether it would still build fine > with the updated libksba/libassuan? Shouldn't hurt to request a build > for an old tag. Good idea. I found that gnupg2-1.9.18 (and 1.9.17) fails tests when built against libksba-0.9.12, but passes when built against libksba-0.9.11 -- Rex From benjamin at pythagoras.no-ip.org Sat Aug 27 11:17:44 2005 From: benjamin at pythagoras.no-ip.org (Benjamin Donnachie) Date: Sat Aug 27 13:15:37 2005 Subject: OpenPGG Card Message-ID: <84ee92c719bd8f3b10caaec695f20cc2@www.pythagoras.no-ip.org> Is it possible to obtain further details on the OpenPGP card? I have such a card and a working smartcard reader but, ideally, I'd like to obtain copies of the sourcecode and program my own cards. However, it's extremely difficult to track down any specific information! Many thanks, -- Benjamin benjamin@pythagoras.no-ip.org From unknown_kev_cat at hotmail.com Sun Aug 28 06:48:17 2005 From: unknown_kev_cat at hotmail.com (Joe Smith) Date: Sun Aug 28 17:22:05 2005 Subject: OpenPGG Card References: <84ee92c719bd8f3b10caaec695f20cc2__25836.3736131743$1125141464$gmane$org@www.pythagoras.no-ip.org> Message-ID: There is no need to post a message to the list three times. >Is it possible to obtain further details on the OpenPGP card? > >I have such a card and a working smartcard reader but, ideally, I'd like to >obtain copies of the sourcecode and program my own cards. However, it's >extremely difficult to track down any specific information! You can get aditional information, but unfortunately the information available is not to particularly satisfying. That said these are the details I know: The openPGP cards are manufactured by PPC Card Systems using a chip created by Atmel, running BasicCard OS, and code written presumably by Werner Koch. The cards are non-reprogrammable, they are set to state 'RUN'. The last I asked there were no other manufactures of OpenPGP Card complient smartcards. ----- Ideally one should be able to just buy a smart card with rsa support, download OpenPGP card source, and compile it. Then flash it and any other things you wish to have on the card. However it sadly does not work that way. Source code is not available. Here is a quote from an email Werner sent me: >> Is the source for the program on the card available? > >No, this is not possible because the chip vendors supply chips only to >large card vendors due to fear of litigation through Pay TV channels. >They had pretty bad experience with that in recent years. Same goes >with the firmare supplied with the chip which is the base of the >(actual very small) application we did. Atmel will even stop the >production of the chip we are currently using due to force by Pay TV >lawyers (the same chip is used in many Pay TV scrambling systems; and >they all use security by litigation). Its all a very sad and >ridiculous situation. If you can somehow manage to get ahold of a BasicCard OS-based smartcard that has support for RSA, it would not be too difficult to program it. Most of the crypto stuff is handled by the chip, so the code needed to be written is mainly interface code. From sadam at CLEMSON.EDU Sun Aug 28 23:06:49 2005 From: sadam at CLEMSON.EDU (Adam Schreiber) Date: Sun Aug 28 23:06:53 2005 Subject: Primary Photo ID Question Message-ID: <43122769.4090005@clemson.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there a reason why when a photo ID is made primary it isn't made the first photo ID on the key like regular uids are? i.e., 5 is the primary photo ID but it wasn't moved up to 3. [ultimate] (3) [jpeg image of size 334] [ultimate] (4) [jpeg image of size 334] [ultimate] (5). [jpeg image of size 4827] [ultimate] (6) [jpeg image of size 3873] Adam Schreiber - -- Why isn't all of your email protected? http://gnupg.org http://enigmail.mozdev.org http://seahorse.sourceforge.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDEidpjU1oaHEI4wgRAgQmAKCC2dwn20tf256acZxIrls3vQGK+QCfWEgp pxQmSdqN8ar+x3U1v/buS7w= =LPaz -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Mon Aug 29 02:12:45 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Mon Aug 29 02:14:07 2005 Subject: Primary Photo ID Question In-Reply-To: <43122769.4090005@clemson.edu> References: <43122769.4090005@clemson.edu> Message-ID: <20050829001245.GA19152@jabberwocky.com> On Sun, Aug 28, 2005 at 05:06:49PM -0400, Adam Schreiber wrote: > Is there a reason why when a photo ID is made primary it isn't made the > first photo ID on the key like regular uids are? i.e., 5 is the primary > photo ID but it wasn't moved up to 3. > > [ultimate] (3) [jpeg image of size 334] > [ultimate] (4) [jpeg image of size 334] > [ultimate] (5). [jpeg image of size 4827] > [ultimate] (6) [jpeg image of size 3873] No real reason, just never got around to it. Try the attached patch. David -------------- next part -------------- Index: keylist.c =================================================================== --- keylist.c (revision 3875) +++ keylist.c (working copy) @@ -1379,15 +1379,16 @@ * Reorder the keyblock so that the primary user ID (and not attribute * packet) comes first. Fixme: Replace this by a generic sort * function. */ -void -reorder_keyblock (KBNODE keyblock) +static void +do_reorder_keyblock (KBNODE keyblock,int attr) { KBNODE primary = NULL, primary0 = NULL, primary2 = NULL; KBNODE last, node; for (node=keyblock; node; primary0=node, node = node->next) { if( node->pkt->pkttype == PKT_USER_ID && - !node->pkt->pkt.user_id->attrib_data && + ((attr && node->pkt->pkt.user_id->attrib_data) || + (!attr && !node->pkt->pkt.user_id->attrib_data)) && node->pkt->pkt.user_id->is_primary ) { primary = primary2 = node; for (node=node->next; node; primary2=node, node = node->next ) { @@ -1419,6 +1420,13 @@ } void +reorder_keyblock (KBNODE keyblock) +{ + do_reorder_keyblock(keyblock,1); + do_reorder_keyblock(keyblock,0); +} + +void list_keyblock( KBNODE keyblock, int secret, int fpr, void *opaque ) { reorder_keyblock (keyblock); From sadam at CLEMSON.EDU Mon Aug 29 03:02:13 2005 From: sadam at CLEMSON.EDU (Adam Schreiber) Date: Mon Aug 29 03:02:03 2005 Subject: Primary Photo ID Question In-Reply-To: <20050829001245.GA19152@jabberwocky.com> References: <43122769.4090005@clemson.edu> <20050829001245.GA19152@jabberwocky.com> Message-ID: <43125E95.30609@clemson.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw wrote: > No real reason, just never got around to it. Try the attached patch. That works great. Adam - -- Why isn't all of your email protected? http://gnupg.org http://enigmail.mozdev.org http://seahorse.sourceforge.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDEl6VjU1oaHEI4wgRAsZdAKCv0LlOr1iI/0Jt6IMK0LwJx2R9AwCgz8Sx Y7jEHi4PTygzonZRBCRi0QA= =dUEY -----END PGP SIGNATURE----- From marcus.brinkmann at ruhr-uni-bochum.de Mon Aug 29 14:10:50 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Aug 29 14:13:15 2005 Subject: Bug in gpg 1.4.1/gpgme 1.0.2 - blocked while encrypting signed data with untrusted key In-Reply-To: <4B2D374C-E5D8-4D6B-AF55-FEE777BF179C@sente.ch> References: <4B2D374C-E5D8-4D6B-AF55-FEE777BF179C@sente.ch> Message-ID: <87vf1p2bat.wl@ulysses.g10code.de> At Wed, 17 Aug 2005 20:37:42 +0200, St?phane Corth?sy wrote: > [GNUPG:] GET_BOOL untrusted_key.override GPGME was not prepared to deal with such unexpected questions on the command fd. This was hopefully fixed a couple of days ago in the HEAD: 2005-08-26 Marcus Brinkmann * rungpg.c (command_handler): Use _gpgme_io_write instead of write. * edit.c (command_handler): Do not depend on PROCESSED being available. * engine.h (engine_command_handler_t): Add new argument processed. * ops.h (_gpgme_passphrase_command_handler_internal): Rename prototype to ... (_gpgme_passphrase_command_handler): ... this one. * passphrase.c (_gpgme_passphrase_command_handler_internal): Rename to ... (_gpgme_passphrase_command_handler): ... this one. * edit.c (command_handler): Add new argument processed. Remove local variable with the same name. Always return processed as true. * rungpg.c (command_handler): Send a newline character if the handler did not. If you can confirm that it works, I can push the fix to the 1.0 branch. > I hope it's been fixed in gpg 1.4.2/gpgme 1.1 (when will they be > released?), as it prevents the use of gpgme with the 'trust all keys' > option. GPGME 1.1 will be released "soonish". Thanks, Marcus From benjamin at pythagoras.no-ip.org Mon Aug 29 16:38:37 2005 From: benjamin at pythagoras.no-ip.org (Benjamin Donnachie) Date: Mon Aug 29 17:19:13 2005 Subject: OpenPGP Card In-Reply-To: References: <84ee92c719bd8f3b10caaec695f20cc2__25836.3736131743$1125141464$gmane$org@www.pythagoras.no-ip.org> Message-ID: <43131DED.6080909@pythagoras.no-ip.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Smith wrote: > There is no need to post a message to the list three times. I didn't. I posted it to gnupg-users and -devel as I felt my enquiry was equally suited to both lists. > You can get aditional information, but unfortunately the information > available is not to particularly satisfying. Yup - that's exactly what I've discovered! > Source code is not available. Here is a quote from an email Werner sent me: [...] >> No, this is not possible because the chip vendors supply chips only to >> large card vendors due to fear of litigation through Pay TV channels. >> They had pretty bad experience with that in recent years. Same goes >> with the firmare supplied with the chip which is the base of the >> (actual very small) application we did. Atmel will even stop the >> production of the chip we are currently using due to force by Pay TV >> lawyers (the same chip is used in many Pay TV scrambling systems; and >> they all use security by litigation). Its all a very sad and >> ridiculous situation. I agree with Werner - it is a very sad and ridiculous situation! > If you can somehow manage to get ahold of a BasicCard OS-based smartcard > that has support for RSA, it would not be too difficult to program it. > Most of the crypto stuff is handled by the chip, so the code needed to > be written is mainly interface code. I shall stop being so lazy, and shall see what can be done! Take care, Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQxMd6+gNmph0Y1E2AQKMvBAAha+pv/VTAQNNSSP+SMqa0dcj2+FYk02B 4emiuFQKGGU4MREfxO5yjaQ+Ly6nF+zOkF1ukK9noDBum7NtWH32Pg5s7oT80b2i JZP0F+8WD1sMemKWxpmuIV6fFhyATUefGTxJ7l7cL1MlmuS0WNYJwkVfyM2jHVQI CLraSzvc/GsObNpXlExlq13WJviUBrGxjnXncXfAdey3/vstTV4xXijo8d3fHrS0 aDP9zEx8FIkx/UcL8G3ME5LB0PkEkgNA0Juzn5nI3EEL2JcjTc6TeXTsR83K1mHO c8TCeiOVEVZQoz1uiKUqyRXoJS4Ugv727ZaSpPOJDEeyJuQlvDyZMB8H8rLpKOyH 5Z027Jvy89gDJkTJX8tOJw6P7q/1USgdDhsO5KX2Wwbu7QK8u8gLVy59FBXkS/vo EOouG/nq/oiSg280CehsywmTCAOaFuYazEwdyxIRzqtpdaFYkpR+LGmBifyQ+64/ RF8hpRzFvY7xkUeOUOHJO1Clv0yrRbCag7qY2h0bmhJ0y5ExgpOP7+hSQlhOvsIz 2KAmkVWMfagstTaqreuetkvLGssdKoLBoO87ufOrSmllge+P0y7Lg4h9sTZrmq9t QtblvPAFFGTdqCscuNBlJ90ict7ScIBUsUZ/PWGTrv1TQaLo5wKvJAt1chUHrhdk 1aFjc+GZXY0= =5vX+ -----END PGP SIGNATURE----- From harakiri_23 at yahoo.com Tue Aug 30 13:00:17 2005 From: harakiri_23 at yahoo.com (Harakiri) Date: Tue Aug 30 14:00:52 2005 Subject: Bug in GPG for Windows - gpg: invalid key resource URL for keyrings In-Reply-To: <87vf1p2bat.wl@ulysses.g10code.de> Message-ID: <20050830110017.86567.qmail@web53008.mail.yahoo.com> I have an asc file which includes a public and secret key. Using this key i want to create a public and secret keyring. Under windows i use (this example works perfectly under any *nix btw) gpg --homedir c:\keys\tmp --batch --yes --verbose --status-fd 2 --no-default-keyring --keyring c:\keys\tmp\pubring.gpg --secret-keyring c:\keys\tmp\secring.gpg --import c:\keys\mykey.asc output : gpg: invalid key resource URL `c:\keys\tmp\secring.gpg' gpg: keyblock resource `(null)': general error gpg: invalid key resource URL `c:\keys\tmp\pubring.gpg' gpg: keyblock resource `(null)': general error (you can copy and paste this and verify it for yourself - you dont even need to have these directories or a key) The only workaround currently is, to use the homedir param together with the --keyring arguments - so i remove the absolute path and use the following command : gpg --homedir c:\keys\tmp --batch --yes --verbose --status-fd 2 --no-default-keyring --keyring pubring.gpg --secret-keyring secring.gpg --import c:\keys\mykey.asc It is not possible under windows to specify a complete file path to a key ressource - the above workaround does only work if the key rings are within the same directory - what do you do if they would be on another drive ? BTW : I also replaced "\" with "/" to be sure but then gpg would think it should add the homedir param so it would be like c:\keys\tmp\c:\keys\tmp\pubring.gpg __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From schierlm at gmx.de Tue Aug 30 17:57:08 2005 From: schierlm at gmx.de (Michael Schierl) Date: Tue Aug 30 17:58:17 2005 Subject: Bug in GPG for Windows - gpg: invalid key resource URL for keyrings In-Reply-To: <20050830110017.86567.qmail@web53008.mail.yahoo.com> References: <20050830110017.86567.qmail@web53008.mail.yahoo.com> Message-ID: <431481D4.5050005@gmx.de> Harakiri schrieb: > gpg --homedir c:\keys\tmp --batch --yes --verbose > --status-fd 2 --no-default-keyring --keyring > c:\keys\tmp\pubring.gpg --secret-keyring > c:\keys\tmp\secring.gpg --import c:\keys\mykey.asc > > output : > > gpg: invalid key resource URL > `c:\keys\tmp\secring.gpg' > gpg: keyblock resource `(null)': general error > gpg: invalid key resource URL > `c:\keys\tmp\pubring.gpg' > gpg: keyblock resource `(null)': general error > > (you can copy and paste this and verify it for > yourself - you dont even need to have these > directories or a key) Hmm: C:\>gpg --homedir c:\keys\tmp --batch --yes --verbose --status-fd 2 --no-default-keyring --keyring c:\keys\tmp\pubring.gpg --secret-keyring c:\keys\tmp\secring.gpg --import c:\keys\mykey.asc gpg: keyblock resource `c:\keys\tmp\secring.gpg': file open error gpg: keyblock resource `c:\keys\tmp\pubring.gpg': file open error gpg: can't open `c:\keys\mykey.asc': No such file or directory gpg: Total number processed: 0 [GNUPG:] IMPORT_RES 0 0 0 0 0 0 0 0 0 0 0 0 0 0 After creating c:\keys\tmp it works as expected. C:\>gpg --version gpg (GnuPG) 1.4.2 C:\>ver Microsoft Windows 2000 [Version 5.00.2195] Please supply more information. Michael From sadam at CLEMSON.EDU Wed Aug 31 21:09:56 2005 From: sadam at CLEMSON.EDU (Adam Schreiber) Date: Wed Aug 31 21:10:58 2005 Subject: [Sks-devel] Re: zero-length MPIs In-Reply-To: <20050824130716.GA4211@suse.de> References: <42F97044.9050603@comcast.net> <42FAC641.9040507@comcast.net> <20050811160217.GC358@wilma.widomaker.com> <20050811182144.GA33562@wilma.widomaker.com> <20050811195459.GB12783@opium.palfrader.org> <20050812002243.GD358@wilma.widomaker.com> <20050824130716.GA4211@suse.de> Message-ID: <43160084.4000209@clemson.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Klaus Singvogel wrote: > Please confirm me, that my thinking is correct here. I'm not sure if Klaus' thinking is correct, but his patch clears up the MPI errors I was receiving. Adam Schreiber - -- Why isn't all of your email protected? http://gnupg.org http://enigmail.mozdev.org http://seahorse.sourceforge.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDFgCEjU1oaHEI4wgRAnQdAKDJfzhnHslrWKd7CCz0j2NiA1TM8QCglrwF S4UcEMVOzn+TRmQvHkh25Ks= =f736 -----END PGP SIGNATURE----- From misch at multinet.de Wed Aug 24 15:51:30 2005 From: misch at multinet.de (Michael Schwartzkopff) Date: Fri Sep 2 15:54:43 2005 Subject: gpgme: encrypt/decrypt Message-ID: <200508241551.34444.misch@multinet.de> Hi, I read your thread about gpg integration into postfix as a content filter. Did you find any good solution? How did you realize it finally? Thanks for your feedback. -- Dr. Michael Schwartzkopff MultiNET Services GmbH Bretonischer Ring 7 85630 Grasbrunn Tel: (+49 89) 456 911 - 0 Fax: (+49 89) 456 911 - 21 mob: (+49 174) 343 28 75 PGP Fingerprint: F919 3919 FF12 ED5A 2801 DEA6 AA77 57A4 EDD8 979B Skype: misch42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050824/cdaa5f57/attachment.pgp From martin.traviolia at mci.com Wed Aug 31 23:19:56 2005 From: martin.traviolia at mci.com (Martin Traviolia) Date: Fri Sep 2 15:54:51 2005 Subject: msg__control, msg_controllen, and msg_flags in assuan-domain-connect.c Message-ID: <0IM300JB0V986O@pmismtp06.mcilink.com> I am building libassuan-0.6.10 on Solaris 9 using Sun's 5.6 C compiler. In the file "assuan-domain-connect.c" the fields "msg_control", "msg_controllen" and "msg_flags" are used from "struct msghdr". These fields are only defined on Solaris if "_XOPEN_SOURCE" and _XOPEN_SOURCE_EXTENDED" are defined, or if "_XOPEN_SOURCE" = 500 From martin.traviolia at mci.com Wed Aug 31 22:59:31 2005 From: martin.traviolia at mci.com (Martin Traviolia) Date: Fri Sep 2 15:54:54 2005 Subject: setenv in assuan-pipe-connect.c Message-ID: <0IM300B0LUB782@pmismtp01.mcilink.com> I am building libassuan-0.6.10 on Solaris 9 using Sun's 5.6 C compiler. In the file "assuan-pipe-connect.c" is a call to "setenv" which is not available on Solaris 9. The section of code in question is --------------------------------------------------------- /* We store our parents pid in the environment so that the execed assuan server is able to read the actual pid of the client. The server can't use getppid becuase it might have been double forked before the assuan server has been initialized. */ setenv ("_assuan_pipe_connect_pid", mypidstr, 1); execv (name, argv); ----------------------------------------------------------- Looking at the Single UNXI Specification Version 2 the portable, but non-reentrant, call is "putenv". Otherwise, one would need to copy from "extern char** environ;" and use "execve". Since Solaris is not a supported platform this may not be worth changing. I think I can safely comment it out as I just need gpg-agent.