From mike at halcrow.us Wed Apr 6 21:11:59 2005 From: mike at halcrow.us (Michael Halcrow) Date: Wed Apr 6 21:09:31 2005 Subject: eCryptfs now in SF CVS; seeking advice on GnuPG integration Message-ID: <20050406191159.GA9373@halcrow.us> I am attempting to implement PGP-ish functionality at the VFS layer in the Linux kernel. My primary goal is to make the encryption and decryption as transparent as humanly possible to the end user. I have made an initial release of my prototype code to the SourceForge CVS repository: http://sourceforge.net/projects/ecryptfs I have passphrase and public-key based encryption working at this point, and I would now like to integrate eCryptfs with GnuPG keyrings. Specifically, I would like the ecryptfsd daemon to prompt the user with a dialog box menu of available public keys in the user's .gnupg/pubring.gpg file. The user would select the public keys from that list that he wishes to use for the file being created, and then those keys are used to encrypt the file's session key, and so on. Of course, this will be in addition to pre-set public keys, based on an .ecryptfsrc policy file at the target location (i.e., sets of key identifiers that describe which keys will be used to encrypt the session keys of the files written at any given location). By the way, if anyone has any cool ideas of how to better integrate eCryptfs with GnuPG, I'm all ears. And if anyone has any suggestions on making eCryptfs more secure, better performing, or more stable, feel free to chime in. Thanks, Mike .___________________________________________________________________. Michael A. Halcrow Security Software Engineer, IBM Linux Technology Center GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20050406/29048489/attachment.pgp From christianbiere at gmx.de Thu Apr 7 19:23:59 2005 From: christianbiere at gmx.de (Christian Biere) Date: Thu Apr 7 20:20:35 2005 Subject: GCC Compiler warnings with GnuPG 1.4.1 Message-ID: <20050407172359.GD23572@cyclonus> Hi, I get the following compiler warnings (using -W -Wall -Wformat=2) with GnuPG 1.4.1 (on NetBSD 2.99.11 FWIIW): g10.c:2269: warning: subscript has type `char' g10.c:3851: warning: subscript has type `char' g10.c:3851: warning: subscript has type `char' g10.c:3870: warning: subscript has type `char' g10.c:3899: warning: subscript has type `char' g10.c:3932: warning: subscript has type `char' keyserver.c:267: warning: subscript has type `char' The first and the last do not look completely harmless (i.e., could cause a crash) at a glance. The others are just "noise" and we had this topic before. In my humble opinion, the additional occurence of the first and the last warning since 1.2.hitme shows that it's a bad idea to keep this noise around. (Do you use GCC with the above options at all?) If you think that casting to unsigned char is evil, I suggest adding a function for this very purpose: unsigned char char_to_uchar(char *c) { return (unsigned char) *c; } This way you don't loose any compiler warnings an evil cast would hide. -- Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : /pipermail/attachments/20050407/ea282020/attachment.pgp From folkert at vanheusden.com Sun Apr 10 16:39:41 2005 From: folkert at vanheusden.com (folkert@vanheusden.com) Date: Sun Apr 10 17:27:11 2005 Subject: faster way of determing if the passphrase is correct or not Message-ID: <20050410143939.GF6561@vanheusden.com> Hi, For a program of mine I'd like to quickly verify if the entered passphrase is correct. Currently I'm calling "gpgme_op_sign" and check its return- value to see if the passphrase is correct or not (if it cannot sign, the passphrase is incorrect). This seems to be a slow method: my 2.8GHz P4 can only do it 220 times a second. So I was wondering: is there a faster method? Any api-call I don't know of? Or? Folkert van Heusden Auto te koop! Zie: http://www.vanheusden.com/daihatsu.php Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden! +------------------------------------------------------------------+ |UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)| |a try, it brings monitoring logfiles to a different level! See | |http://vanheusden.com/multitail/features.html for a feature list. | +------------------------------------------= www.unixsoftware.nl =-+ Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.com! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 282 bytes Desc: not available Url : /pipermail/attachments/20050410/993755bb/attachment.pgp From mike at halcrow.us Sun Apr 10 22:39:34 2005 From: mike at halcrow.us (Michael Halcrow) Date: Sun Apr 10 22:37:21 2005 Subject: faster way of determing if the passphrase is correct or not In-Reply-To: <20050410143939.GF6561@vanheusden.com> References: <20050410143939.GF6561@vanheusden.com> Message-ID: <20050410203934.GA4905@halcrow.us> On Sun, Apr 10, 2005 at 04:39:41PM +0200, folkert@vanheusden.com wrote: > For a program of mine I'd like to quickly verify if the entered > passphrase is correct. Currently I'm calling "gpgme_op_sign" and > check its return- value to see if the passphrase is correct or not > (if it cannot sign, the passphrase is incorrect). This seems to be a > slow method: my 2.8GHz P4 can only do it 220 times a second. So I > was wondering: is there a faster method? Any api-call I don't know > of? Or? That cannot really be made any faster without sacrificing security. In the string-to-key converstion process, the passphrase is concatenated with the salt, and then that chunk of data is iteratively hashed (i.e., 65,536 times). This makes it a little more difficult to do a dictionary attack on the passphrase. I'm not sure exactly what gpgme_op_sign is doing. In eCryptfs, I do the iterative hash thing, and then I hash the key one more time to generate a signature for the passphrase+salt combination. This signature is what is used to determine whether you have the right passphrase. You really can't tell whether or not you've go the right passphrase until you've done all the hashing. GPGME may actually go all the way through with a public key operation before it figures out that that the passphrase was incorrect. I'd have to look at the source to figure that out though... Mike .___________________________________________________________________. Michael A. Halcrow Security Software Engineer, IBM Linux Technology Center GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20050410/d849b452/attachment.pgp From gpgme at katehok.ac93.org Mon Apr 11 00:09:13 2005 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Mon Apr 11 00:05:16 2005 Subject: faster way of determing if the passphrase is correct or not In-Reply-To: <20050410203934.GA4905@halcrow.us> References: <20050410143939.GF6561@vanheusden.com> <20050410203934.GA4905@halcrow.us> Message-ID: <4259A409.8070906@katehok.ac93.org> Michael Halcrow wrote: >On Sun, Apr 10, 2005 at 04:39:41PM +0200, folkert@vanheusden.com wrote: > > >>For a program of mine I'd like to quickly verify if the entered >>passphrase is correct. Currently I'm calling "gpgme_op_sign" and >>check its return- value to see if the passphrase is correct or not >>(if it cannot sign, the passphrase is incorrect). This seems to be a >>slow method: my 2.8GHz P4 can only do it 220 times a second. So I >>was wondering: is there a faster method? Any api-call I don't know >>of? Or? >> >> > >That cannot really be made any faster without sacrificing security. In >the string-to-key converstion process, the passphrase is concatenated >with the salt, and then that chunk of data is iteratively hashed >(i.e., 65,536 times). This makes it a little more difficult to do a >dictionary attack on the passphrase. > > I don't know would it be faster but you can try a password change via gpgme_op_edit command. In its first phase it just verifies correctness of the password which should be faster than additionally signing something. Igor From wk at gnupg.org Mon Apr 11 15:55:42 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Apr 11 15:56:40 2005 Subject: faster way of determing if the passphrase is correct or not In-Reply-To: <20050410143939.GF6561@vanheusden.com> (folkert@vanheusden.com's message of "Sun, 10 Apr 2005 16:39:41 +0200") References: <20050410143939.GF6561@vanheusden.com> Message-ID: <87k6n9ct9d.fsf@wheatstone.g10code.de> On Sun, 10 Apr 2005 16:39:41 +0200, folkert said: > passphrase is incorrect). This seems to be a slow method: my 2.8GHz P4 > can only do it 220 times a second. So I was wondering: is there a faster I guess we can douple or triple the performance but not much more. The whole point of the algorithm is to slow things down. Things to do: Avoid the overhead of the cyptoframe work and thus write an optimized hash function. Avoid dynamic memory allocation and reuse buffers. And all the other usual micro optmimizations. It does not make much sense unless you want to write a passphrase cracker, though. Salam-Shalom, Werner From folkert at vanheusden.com Mon Apr 11 17:09:19 2005 From: folkert at vanheusden.com (folkert@vanheusden.com) Date: Mon Apr 11 17:05:13 2005 Subject: faster way of determing if the passphrase is correct or not In-Reply-To: <87k6n9ct9d.fsf@wheatstone.g10code.de> References: <20050410143939.GF6561@vanheusden.com> <87k6n9ct9d.fsf@wheatstone.g10code.de> Message-ID: <20050411150918.GE5610@vanheusden.com> > > passphrase is incorrect). This seems to be a slow method: my 2.8GHz P4 > > can only do it 220 times a second. So I was wondering: is there a faster > I guess we can douple or triple the performance but not much more. > The whole point of the algorithm is to slow things down. Ok/ > Things to do: Avoid the overhead of the cyptoframe work and thus write > an optimized hash function. Avoid dynamic memory allocation and reuse > buffers. And all the other usual micro optmimizations. Ah yes, and split the passphrase-callback function into two: one for asking and one for freeing up buffers that might have been created in the first one. > It does not make much sense unless you want to write a passphrase cracker, though. That's what it is for yes (http://www.vanheusden.com/nasty/) - altough I also create friendly programs (http://www.vanheusden.com/gpgstats/ - generate statistics for your keyring). Folkert van Heusden Auto te koop, zie: http://www.vanheusden.com/daihatsu.php Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden. -------------------------------------------------------------------- UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) a try, it brings monitoring logfiles to a different level! See http://vanheusden.com/multitail/features.html for a feature-list. -------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.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/20050411/971b8d09/attachment.pgp From wk at gnupg.org Mon Apr 11 19:59:13 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Apr 11 19:56:45 2005 Subject: faster way of determing if the passphrase is correct or not In-Reply-To: <20050411150918.GE5610@vanheusden.com> (folkert@vanheusden.com's message of "Mon, 11 Apr 2005 17:09:19 +0200") References: <20050410143939.GF6561@vanheusden.com> <87k6n9ct9d.fsf@wheatstone.g10code.de> <20050411150918.GE5610@vanheusden.com> Message-ID: <8764yt9oum.fsf@wheatstone.g10code.de> On Mon, 11 Apr 2005 17:09:19 +0200, folkert said: > That's what it is for yes (http://www.vanheusden.com/nasty/) - altough > I also create friendly programs (http://www.vanheusden.com/gpgstats/ - generate Passphrase crackers are in fact very useful tools to check for security problems. Salam-Shalom, Werner From folkert at vanheusden.com Mon Apr 11 20:11:15 2005 From: folkert at vanheusden.com (folkert@vanheusden.com) Date: Mon Apr 11 20:07:06 2005 Subject: faster way of determing if the passphrase is correct or not In-Reply-To: <8764yt9oum.fsf@wheatstone.g10code.de> References: <20050410143939.GF6561@vanheusden.com> <87k6n9ct9d.fsf@wheatstone.g10code.de> <20050411150918.GE5610@vanheusden.com> <8764yt9oum.fsf@wheatstone.g10code.de> Message-ID: <20050411181113.GB8178@vanheusden.com> > > That's what it is for yes (http://www.vanheusden.com/nasty/) - altough > > I also create friendly programs (http://www.vanheusden.com/gpgstats/ - generate > Passphrase crackers are in fact very useful tools to check for > security problems. True. Though: the current version needs 2 days (on a P4 2,8GHz) for a character set of 63 (a-z+A-Z+0-9+' '). I'll see if I can code a version doing the passphrase-change. Folkert van Heusden -------------------------------------------------------------------- UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) a try, it brings monitoring logfiles to a different level! See http://vanheusden.com/multitail/features.html for a feature-list. -------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.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/20050411/366ae9b5/attachment.pgp From wk at gnupg.org Mon Apr 11 20:23:10 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Apr 11 20:21:37 2005 Subject: GCC Compiler warnings with GnuPG 1.4.1 In-Reply-To: <20050407172359.GD23572@cyclonus> (Christian Biere's message of "Thu, 7 Apr 2005 19:23:59 +0200") References: <20050407172359.GD23572@cyclonus> Message-ID: <871x9h9nqp.fsf@wheatstone.g10code.de> On Thu, 7 Apr 2005 19:23:59 +0200, Christian Biere said: > The first and the last do not look completely harmless (i.e., could > cause a crash) at a glance. The others are just "noise" and we Right. I fixed them by adding an isascii() check. Also changed the other pales to use isascii() instead of testing the high bit directly. > a bad idea to keep this noise around. (Do you use GCC with the > above options at all?) No, because gcc seems not smart enough to detect the possible range of values. > This way you don't loose any compiler warnings an evil cast would > hide. alternativley I could use the simple digitp, hexdigitp and spacep macros I use at several other places. Further, I think that NetBSD should change their ctype.h implementation to provide values for negative offsets, like glibc does. The use of the isfoo macros is that widespreaded and I bet most of the hackers living in 7 bit countries are still not aware of the problems. I have fixed literally thousands of such bugs in my life but people are still getting it wrong (me too of course). Given that GNU/Linux doesn't care about it, they won't even notice it wehn porting software. Sure, it should be done right from the beginning but a safe fallback would be very appreciated. Shalom-Salam, Werner From dshaw at jabberwocky.com Tue Apr 12 05:58:31 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Apr 12 05:55:20 2005 Subject: faster way of determing if the passphrase is correct or not In-Reply-To: <20050411181113.GB8178@vanheusden.com> References: <20050410143939.GF6561@vanheusden.com> <87k6n9ct9d.fsf@wheatstone.g10code.de> <20050411150918.GE5610@vanheusden.com> <8764yt9oum.fsf@wheatstone.g10code.de> <20050411181113.GB8178@vanheusden.com> Message-ID: <20050412035831.GB8044@jabberwocky.com> On Mon, Apr 11, 2005 at 08:11:15PM +0200, folkert@vanheusden.com wrote: > > > That's what it is for yes (http://www.vanheusden.com/nasty/) - altough > > > I also create friendly programs (http://www.vanheusden.com/gpgstats/ - generate > > Passphrase crackers are in fact very useful tools to check for > > security problems. > > True. Though: the current version needs 2 days (on a P4 2,8GHz) for a character > set of 63 (a-z+A-Z+0-9+' '). > I'll see if I can code a version doing the passphrase-change. This method will work, but if you really want performance, you would do better by lifting the necessary code directly out of GnuPG. There is a lot of overhead that you could skip. David From folkert at vanheusden.com Tue Apr 12 16:21:03 2005 From: folkert at vanheusden.com (folkert@vanheusden.com) Date: Tue Apr 12 16:16:55 2005 Subject: tool for fixing corrupted key chains? Message-ID: <20050412142100.GF16454@vanheusden.com> Hi, Does anyone know a tool which fixes a corrupted key-ring? I have a keyring which gives me this when doing gpg --list-keys: gpg: Ohhhh jeeee: mpi crosses packet border secmem usage: 1408/1408 bytes in 2/2 blocks of pool 1408/32768 Aborted Folkert van Heusden Auto te koop, zie: http://www.vanheusden.com/daihatsu.php Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden. -------------------------------------------------------------------- UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) a try, it brings monitoring logfiles to a different level! See http://vanheusden.com/multitail/features.html for a feature-list. -------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.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/20050412/79e654f9/attachment.pgp From mconahan at zixtestott.com Tue Apr 12 16:12:03 2005 From: mconahan at zixtestott.com (mconahan@zixtestott.com) Date: Tue Apr 12 17:03:15 2005 Subject: Problems finding keyring with GnuPGME Message-ID: <425BD733.5040501@zixtestott.com> Hi everyone, I created a Linux application that uses GnuPGME. The app is started by a server process, and as a result is having troubles accessing PGP keyrings. This is probably a permissions thing, as I installed GnuPG as the root user; the API (GnuPGME) is probably looking for the keyring at /root/.gnupg/. FYI, if I run my app as root on the command line, everything works fine; however, I need to start this process with a server. I am currently looking at three options: 1) update the GnuPGME keyring functions that I use to allow me to specify arbitrary keyrings of my choice, 2) investigate what user process is running my app, and create a home directory for it with keyrings and all, or 3)investigate if there is some undocumented function in GnuPGME that I can use to help me specify the keyring of my choice. Any help/advice provided by anyone would be greatly appreciated. From gpgme at katehok.ac93.org Tue Apr 12 17:20:56 2005 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Tue Apr 12 17:17:14 2005 Subject: Problems finding keyring with GnuPGME In-Reply-To: <425BD733.5040501@zixtestott.com> References: <425BD733.5040501@zixtestott.com> Message-ID: <425BE758.8040601@katehok.ac93.org> mconahan@zixtestott.com wrote: > Hi everyone, > > I created a Linux application that uses GnuPGME. The app is started > by a server process, and as a result is having troubles accessing PGP > keyrings. This is probably a permissions thing, as I installed GnuPG > as the root user; the API (GnuPGME) is probably looking for the > keyring at /root/.gnupg/. GNUPGHOME env. var. can be used to point to the location of the kering. > > FYI, if I run my app as root on the command line, everything works > fine; however, I need to start this process with a server. > I am currently looking at three options: 1) update the GnuPGME keyring > functions that I use to allow me to specify arbitrary keyrings of my > choice, 2) investigate what user process is running my app, and create > a home directory for it with keyrings and all, or 3)investigate if > there is some undocumented function in GnuPGME that I can use to help > me specify the keyring of my choice. > > Any help/advice provided by anyone would be greatly appreciated. > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From folkert at vanheusden.com Tue Apr 12 17:33:21 2005 From: folkert at vanheusden.com (folkert@vanheusden.com) Date: Tue Apr 12 17:29:24 2005 Subject: gpg keyring fileformat? Message-ID: <20050412153318.GJ16454@vanheusden.com> Hi, Is there a document describing the gpg keyring fileformat? Or is a keyring just a bunch of 'packets' as described on page 12 and further of http://www.ietf.org/rfc/rfc2440.txt ? Folkert van Heusden Auto te koop, zie: http://www.vanheusden.com/daihatsu.php Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden. -------------------------------------------------------------------- UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) a try, it brings monitoring logfiles to a different level! See http://vanheusden.com/multitail/features.html for a feature-list. -------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.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/20050412/1df4d5b2/attachment.pgp From mconahan at zixtestott.com Tue Apr 12 19:32:04 2005 From: mconahan at zixtestott.com (mconahan@zixtestott.com) Date: Tue Apr 12 19:27:58 2005 Subject: Problems finding keyring with GnuPGME In-Reply-To: <05B51F05D8010B3A95DE1741@toughbook> References: <425BD363.1080101@zixtestott.com> <05B51F05D8010B3A95DE1741@toughbook> Message-ID: <425C0614.5030105@zixtestott.com> harry_b@mm.st wrote: > Hi, > > this should be quite easy - just set the environment variable > GNUPGHOME before you start your process and all should be fine. > > It defaults to '$HOME/.gnupg' I think but you can set it to whatever > you want. The directory should not be readable by anybody else than > the current user. > > HTH, Harry > > > --On Tuesday, April 12, 2005 09:55:47 -0400 mconahan@zixtestott.com > wrote: > >> Hi everyone, >> >> I created a Linux application that uses GnuPGME. The app is started >> by a server process, and as a result is having troubles accessing PGP >> keyrings. This is probably a permissions thing, as I installed GnuPG as >> the root user; the API (GnuPGME) is probably looking for the keyring at >> /root/.gnupg/. >> >> FYI, if I run my app as root on the command line, everything works fine; >> however, I need to start this process with a server. >> I am currently looking at three options: 1) update the GnuPGME keyring >> functions that I use to allow me to specify arbitrary keyrings of my >> choice, 2) investigate what user process is running my app, and create a >> home directory for it with keyrings and all, or 3)investigate if >> there is >> some undocumented function in GnuPGME that I can use to help me specify >> the keyring of my choice. >> >> Any help/advice provided by anyone would be greatly appreciated. > > > -- > > 1024D/40F14012 18F3 736A 4080 303C E61E 2E72 7E05 1F6E 40F1 4012 > > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GIT/S dx s: a C++ ULS++++$ P+++ L+++$ !E W++ N+ o? K? !w !O !M > V PS+ PE Y? PGP+++ t+ 5-- X+ R+ !tv b++ DI++ D+ G e* h r++ y++ > ------END GEEK CODE BLOCK----- > - Thanks! Your solution worked like magic. From mconahan at zixtestott.com Tue Apr 12 21:38:35 2005 From: mconahan at zixtestott.com (mconahan@zixtestott.com) Date: Tue Apr 12 21:34:30 2005 Subject: Setting the GnuPG binary path for GnuPGME Message-ID: <425C23BB.1030401@zixtestott.com> Hi everyone, I was wondering if any knows how to set the GnuPG binary path used by GnuPGME? Michael From gpgme at katehok.ac93.org Tue Apr 12 22:09:06 2005 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Tue Apr 12 22:05:21 2005 Subject: Setting the GnuPG binary path for GnuPGME In-Reply-To: <425C23BB.1030401@zixtestott.com> References: <425C23BB.1030401@zixtestott.com> Message-ID: <425C2AE2.3090903@katehok.ac93.org> mconahan@zixtestott.com wrote: > I was wondering if any knows how to set the GnuPG binary path used > by GnuPGME? On Windows gpg location is taken from Software\GNU\GnuPG\gpgProgram registry value or from the value specified during compilation of GPGME. On Unix it's just a compiled-in location. Igor From wk at gnupg.org Wed Apr 13 11:27:55 2005 From: wk at gnupg.org (Werner Koch) Date: Wed Apr 13 11:26:39 2005 Subject: Error at "bag.attributes" importing key from freemail cert into gpgsm In-Reply-To: <200504121122.09356.nsushkin@sushkins.net> (Nicholas Sushkin's message of "Tue, 12 Apr 2005 11:22:09 -0400") References: <200504071615.30963.nsushkin@sushkins.net> <87ll7o70lm.fsf@wheatstone.g10code.de> <200504121034.20015.nsushkin@sushkins.net> <200504121122.09356.nsushkin@sushkins.net> Message-ID: <878y3n3u1w.fsf@wheatstone.g10code.de> On Tue, 12 Apr 2005 11:22:09 -0400, Nicholas Sushkin said: > I think you forgot to commit common/sexputil.c to CVS Done. However, I doubt that the CVS version will really make a difference. Please send mey some test data. Salam-Shalom, Werner From wk at gnupg.org Wed Apr 13 12:02:50 2005 From: wk at gnupg.org (Werner Koch) Date: Wed Apr 13 12:01:38 2005 Subject: gpg keyring fileformat? In-Reply-To: <20050412153318.GJ16454@vanheusden.com> (folkert@vanheusden.com's message of "Tue, 12 Apr 2005 17:33:21 +0200") References: <20050412153318.GJ16454@vanheusden.com> Message-ID: <87u0mb2dv9.fsf@wheatstone.g10code.de> On Tue, 12 Apr 2005 17:33:21 +0200, folkert said: > Is there a document describing the gpg keyring fileformat? > Or is a keyring just a bunch of 'packets' as described on page 12 > and further of http://www.ietf.org/rfc/rfc2440.txt ? Yes, it is the same format as used for key exchange. One way to fix it is by using gpg-split to split the ring up and then trying to identify the key causing the corruption. Then remove all packets of this key and cat everything else together again. Shalom-Salam, Werner From rdieter at math.unl.edu Wed Apr 13 14:20:12 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed Apr 13 15:29:30 2005 Subject: Setting the GnuPG binary path for GnuPGME In-Reply-To: <425C2AE2.3090903@katehok.ac93.org> References: <425C23BB.1030401@zixtestott.com> <425C2AE2.3090903@katehok.ac93.org> Message-ID: <425D0E7C.2020000@math.unl.edu> Igor Belyi wrote: > mconahan@zixtestott.com wrote: > >> I was wondering if any knows how to set the GnuPG binary path used >> by GnuPGME? > > > On Windows gpg location is taken from Software\GNU\GnuPG\gpgProgram > registry value or from the value specified during compilation of GPGME. I'd suggest gpgme be updated to conform with the latest gnupg-1.4.1 to instead use the key "Install Directory" under Softare\GNU\GnuPG (per README-W32, appended) to determine the GnuPG binary location. -- Rex --------------------------------------- Installation directory: ======================= The installation directory of GnuPG is stored in the Registry under the key HKEY_LOCAL_MACHINE\Software\GNU\GnuPG with the name "Install Directory". The installer does not change the PATH environment variable to include this directory. You might want to do this manually. --------------------------------------- From wk at gnupg.org Wed Apr 13 16:31:45 2005 From: wk at gnupg.org (Werner Koch) Date: Wed Apr 13 16:31:41 2005 Subject: Setting the GnuPG binary path for GnuPGME In-Reply-To: <425D0E7C.2020000@math.unl.edu> (Rex Dieter's message of "Wed, 13 Apr 2005 07:20:12 -0500") References: <425C23BB.1030401@zixtestott.com> <425C2AE2.3090903@katehok.ac93.org> <425D0E7C.2020000@math.unl.edu> Message-ID: <878y3m3fzi.fsf@wheatstone.g10code.de> On Wed, 13 Apr 2005 07:20:12 -0500, Rex Dieter said: > I'd suggest gpgme be updated to conform with the latest gnupg-1.4.1 to > instead use the key "Install Directory" under Softare\GNU\GnuPG (per > README-W32, appended) to determine the GnuPG binary location. Correct, we will do that. However, we have not released a version of gpgme for W32. Some applications are partly using code of gpgme, though. Salam-Shalom, Werner From folkert at vanheusden.com Wed Apr 13 18:12:40 2005 From: folkert at vanheusden.com (folkert@vanheusden.com) Date: Wed Apr 13 18:08:39 2005 Subject: gpgme_op_sign failed: Unknown system error Message-ID: <20050413161238.GK30520@vanheusden.com> Hi, My program gives me when doing gpgme_op_sign: Unknown system error what could that be? Using library 1.0.2 Folkert van Heusden Auto te koop, zie: http://www.vanheusden.com/daihatsu.php Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden. -------------------------------------------------------------------- UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) a try, it brings monitoring logfiles to a different level! See http://vanheusden.com/multitail/features.html for a feature-list. -------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.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/20050413/a1be1bac/attachment.pgp From gpgme at katehok.ac93.org Wed Apr 13 18:43:19 2005 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Wed Apr 13 18:39:25 2005 Subject: gpgme_op_sign failed: Unknown system error In-Reply-To: <20050413161238.GK30520@vanheusden.com> References: <20050413161238.GK30520@vanheusden.com> Message-ID: <425D4C27.60800@katehok.ac93.org> folkert@vanheusden.com wrote: >My program gives me when doing gpgme_op_sign: Unknown system error >what could that be? >Using library 1.0.2 > > I think you need to be more specific. As far as I know this error message means that error code you feed into gpgme_strerror is either unknown or GPG_ERR_UNKNOWN_ERRNO. If it's the former one then there could be a incompatibility between GPGME and installed GPG - for example GPGME attempts to return a newer error code than GPG knows about. If the later - the error comes from GPG but I'm not that familiar with GPG internals. I would recomend to get the exact error code return from gpgme_op_sign and then manually feed it into gpg-error utility. Such error codes usually contain source of the error besides the error itself. Hope it helps, Igor From folkert at vanheusden.com Wed Apr 13 19:06:05 2005 From: folkert at vanheusden.com (folkert@vanheusden.com) Date: Wed Apr 13 19:01:56 2005 Subject: gpgme_op_sign failed: Unknown system error In-Reply-To: <425D4C27.60800@katehok.ac93.org> References: <20050413161238.GK30520@vanheusden.com> <425D4C27.60800@katehok.ac93.org> Message-ID: <20050413170603.GN30520@vanheusden.com> > >My program gives me when doing gpgme_op_sign: Unknown system error > >what could that be? > >Using library 1.0.2 > I think you need to be more specific. As far as I know this error > message means that error code you feed into gpgme_strerror is either > unknown or GPG_ERR_UNKNOWN_ERRNO. If it's the former one then there > could be a incompatibility between GPGME and installed GPG - for example > GPGME attempts to return a newer error code than GPG knows about. If the > later - the error comes from GPG but I'm not that familiar with GPG > internals. > I would recomend to get the exact error code return from gpgme_op_sign > and then manually feed it into gpg-error utility. Such error codes > usually contain source of the error besides the error itself. Found it: the passphrase callback routine was for the older version of gpgme. Folkert van Heusden Auto te koop, zie: http://www.vanheusden.com/daihatsu.php Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden. -------------------------------------------------------------------- UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) a try, it brings monitoring logfiles to a different level! See http://vanheusden.com/multitail/features.html for a feature-list. -------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.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/20050413/36c52ad5/attachment.pgp From folkert at vanheusden.com Thu Apr 14 09:23:12 2005 From: folkert at vanheusden.com (folkert@vanheusden.com) Date: Thu Apr 14 09:19:01 2005 Subject: gpgme_key_get_as_xml ? Message-ID: <20050414072310.GA30520@vanheusden.com> Hi, It seems in 1.0.2 the function gpgme_key_get_as_xml has disappeared. I wonder: with what has it been replaced? Folkert van Heusden Auto te koop, zie: http://www.vanheusden.com/daihatsu.php Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden. -------------------------------------------------------------------- UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) a try, it brings monitoring logfiles to a different level! See http://vanheusden.com/multitail/features.html for a feature-list. -------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.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/20050414/37fa8549/attachment.pgp From marcus.brinkmann at ruhr-uni-bochum.de Thu Apr 14 10:14:06 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Apr 14 10:11:05 2005 Subject: gpgme_cancel() does not stop gpg process from finishing asynchronous call In-Reply-To: <4249E9EF.8050504@katehok.ac93.org> References: <4249E9EF.8050504@katehok.ac93.org> Message-ID: <871x9dwzap.wl@ulysses.g10code.de> At Tue, 29 Mar 2005 18:51:11 -0500, Igor Belyi wrote: > > [1 ] > Starting asynchronouse call and then canceling it with gpgme_cancel do cause gpgme_wait() return Canceled error but leaves gpg process working and finishing the call. I have a slightly modified t-genkey test which shows that the key is generated after cancelation. I can send it if you want to. This is true. We use a double-fork technique to separate the child from the parent process and then just close all file descriptors. > I also have a patch (attached, since it's very small) fixing the problem in GPGME 1.0.2. :) The waitpid is wrong, because GPGME is not the parent of the process (due to the double-fork). FOr most operations, current behaviour should be OK. Even for genkey: GnuPG is supposed to send a heart-beat every second, so it should notice that the status FD is closed within the next second and then go away. Maybe the current GnuPG versions don't do this, but they should. Maybe you want to check that one out? Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Thu Apr 14 10:33:09 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Apr 14 10:30:55 2005 Subject: Incorrect gpgme_wait behavior In-Reply-To: <4249EBF9.2090006@katehok.ac93.org> References: <4249EBF9.2090006@katehok.ac93.org> Message-ID: <87zmw1vjui.wl@ulysses.g10code.de> At Tue, 29 Mar 2005 18:59:53 -0500, Igor Belyi wrote: > > [1 ] > Hello, > > gpgme_wait(ctx, &status, 0) on timeout returns ctx instead of NULL which > makes it difficult to distinguish from a program return when ctx in not NULL. > Plus, on timeout status is unchanged instead of being forced into 0. > As a work around I set status to 0xFFFF (an impossible error code) > and check if it got changed during the call. Good spot. I checked in a slightly different patch, which should do the same as yours (but doesn't modify ctx_wait and checks if status is not NULL). Thanks, Marcus 2005-04-14 Marcus Brinkmann * wait-global.c (gpgme_wait): If no context is found, and we should not hang, set *status to 0 and return NULL. Reported by Igor Belyi . diff -u -r1.12 wait-global.c --- wait-global.c 24 Mar 2005 13:05:12 -0000 1.12 +++ wait-global.c 14 Apr 2005 08:40:24 -0000 @@ -350,6 +350,12 @@ ctx = dctx; hang = 0; } + else if (!hang) + { + ctx = NULL; + if (status) + *status = 0; + } } } while (hang); From marcus.brinkmann at ruhr-uni-bochum.de Thu Apr 14 10:38:19 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Apr 14 10:35:52 2005 Subject: Typo causing segmentation fault for gpgme_wait(NULL, ..) In-Reply-To: <424A09D8.5030003@users.sourceforge.net> References: <424A09D8.5030003@users.sourceforge.net> Message-ID: <87y8blvjlw.wl@ulysses.g10code.de> At Tue, 29 Mar 2005 21:07:20 -0500, Igor Belyi wrote: > > [1 ] > Ok, here's the last patch in this short burst of a desire to help. :) > > When the first argument of the gpgme_wait is NULL it causes segmentation > fault due to a small typo in the code. The attached patch fixes the problem. Excellent! That was a cut&paste bug. I introduced a new temporary variable to the same effect. 2005-04-14 Marcus Brinkmann * wait-global.c (gpgme_wait): Use LI->ctx when checking a context in the list, not the user-provided CTX. Reported by Igor Belyi . Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Thu Apr 14 10:44:17 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Apr 14 10:40:54 2005 Subject: faster way of determing if the passphrase is correct or not In-Reply-To: <20050411150918.GE5610@vanheusden.com> References: <20050410143939.GF6561@vanheusden.com> <87k6n9ct9d.fsf@wheatstone.g10code.de> <20050411150918.GE5610@vanheusden.com> Message-ID: <87wtr5vjby.wl@ulysses.g10code.de> At Mon, 11 Apr 2005 17:09:19 +0200, folkert@vanheusden.com wrote: > Ah yes, and split the passphrase-callback function into two: one for asking > and one for freeing up buffers that might have been created in the first > one. That's very micro. Anyway, I won't go out of my way to optimize GPGME for a password cracker :) That's just not our target application. Just as the others said: Extract the relevant code out of GnuPG and put it into your application. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Thu Apr 14 10:46:25 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Apr 14 10:45:55 2005 Subject: Setting the GnuPG binary path for GnuPGME In-Reply-To: <425C23BB.1030401@zixtestott.com> References: <425C23BB.1030401@zixtestott.com> Message-ID: <87vf6pvj8e.wl@ulysses.g10code.de> At Tue, 12 Apr 2005 15:38:35 -0400, "mconahan@zixtestott.com" wrote: > > Hi everyone, > > I was wondering if any knows how to set the GnuPG binary path used > by GnuPGME? It's a new feature in CVS. also See the documentation (doc/gpgme.texi). It will be in the next release. Noteworthy changes in version 1.1.0 (unreleased) ------------------------------------------------ * You can now configure the backend engine file name and home directory to be used, as default and per context. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gpgme_set_engine_info NEW gpgme_ctx_get_engine_info NEW gpgme_ctx_set_engine_info NEW ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Thu Apr 14 10:50:24 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Apr 14 10:50:54 2005 Subject: gpgme_key_get_as_xml ? In-Reply-To: <20050414072310.GA30520@vanheusden.com> References: <20050414072310.GA30520@vanheusden.com> Message-ID: <87u0m9vj1r.wl@ulysses.g10code.de> At Thu, 14 Apr 2005 09:23:12 +0200, folkert@vanheusden.com wrote: > > [1 ] > [1.1 ] > Hi, > > It seems in 1.0.2 the function gpgme_key_get_as_xml has disappeared. > I wonder: with what has it been replaced? With nothing, it has been dropped. All the data is now directly available from the gpgme_key_t structure, which is so much more convenient for programmers. No more string parsing. If you really want the XML output, you will have to grab the function implementation from the 0.3 branch, port it to the new public interface and then put it into your application as a helper function. Thanks, Marcus From gpgme at katehok.ac93.org Thu Apr 14 13:51:14 2005 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Thu Apr 14 13:47:21 2005 Subject: gpgme_cancel() does not stop gpg process from finishing asynchronous call In-Reply-To: <871x9dwzap.wl@ulysses.g10code.de> References: <4249E9EF.8050504@katehok.ac93.org> <871x9dwzap.wl@ulysses.g10code.de> Message-ID: <425E5932.7080600@katehok.ac93.org> Marcus Brinkmann wrote: >At Tue, 29 Mar 2005 18:51:11 -0500, >Igor Belyi wrote: > > >>[1 ] >>Starting asynchronouse call and then canceling it with gpgme_cancel do cause gpgme_wait() return Canceled error but leaves gpg process working and finishing the call. I have a slightly modified t-genkey test which shows that the key is generated after cancelation. I can send it if you want to. >> >> > >This is true. We use a double-fork technique to separate the child >from the parent process and then just close all file descriptors. > > > >>I also have a patch (attached, since it's very small) fixing the problem in GPGME 1.0.2. :) >> >> > >The waitpid is wrong, because GPGME is not the parent of the process >(due to the double-fork). > > If you look at the patch - it gets pid from the child in the GPGME child process and then pass it back to GPGME using a pipe. This is the pid return from posix_io.c/_gpgme_io_spawn() and not the pid of the GPGME child. It does work for me and gives more control to GPGME over the process is spawn. >FOr most operations, current behaviour should be OK. Even for genkey: >GnuPG is supposed to send a heart-beat every second, so it should >notice that the status FD is closed within the next second and then go >away. Maybe the current GnuPG versions don't do this, but they should. >Maybe you want to check that one out? > > I've created the patch since I noticed the problem with GnuPG not canceling process when pipes are closed during gpgme_op_genkey. I still think that GPGME can handle such situation even if GnuPG behaving incorrectly in your opinion. But, it's your code and your decision - I'll just keep applying the patch on my box. >Thanks, >Marcus > > Cheers, Igor From gpgme at katehok.ac93.org Thu Apr 14 15:01:55 2005 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Thu Apr 14 14:58:06 2005 Subject: gpgme_cancel() does not stop gpg process from finishing asynchronous call In-Reply-To: <425E5932.7080600@katehok.ac93.org> References: <4249E9EF.8050504@katehok.ac93.org> <871x9dwzap.wl@ulysses.g10code.de> <425E5932.7080600@katehok.ac93.org> Message-ID: <425E69C3.90508@katehok.ac93.org> Igor Belyi wrote: > Marcus Brinkmann wrote: > >> The waitpid is wrong, because GPGME is not the parent of the process >> (due to the double-fork). > > If you look at the patch - it gets pid from the child in the GPGME > child process and then pass it back to GPGME using a pipe. This is the > pid return from posix_io.c/_gpgme_io_spawn() and not the pid of the > GPGME child. It does work for me and gives more control to GPGME over > the process is spawn. Marcus, Sorry, I haven't read your remark carefully enough... Yes, on UNIX this waitpid will return immediately with ECHILD errno, but it was added for Win32 benefit since it does not use double-fork. I know that Win32 does not have kill implemented yet but when it does this waitpid will come handy. :o) The patch intent is to send the spawn gpg process a signal which is a little bit more substantial than closed pipes. Cheers, Igor From marcus.brinkmann at ruhr-uni-bochum.de Thu Apr 14 15:56:06 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Apr 14 15:55:54 2005 Subject: gpgme_cancel() does not stop gpg process from finishing asynchronous call In-Reply-To: <425E69C3.90508@katehok.ac93.org> References: <4249E9EF.8050504@katehok.ac93.org> <871x9dwzap.wl@ulysses.g10code.de> <425E5932.7080600@katehok.ac93.org> <425E69C3.90508@katehok.ac93.org> Message-ID: <87r7hdv4w9.wl@ulysses.g10code.de> At Thu, 14 Apr 2005 09:01:55 -0400, Igor Belyi wrote: > Yes, on UNIX this waitpid will return immediately with ECHILD errno, but > it was added for Win32 benefit since it does not use double-fork. I know > that Win32 does not have kill implemented yet but when it does this > waitpid will come handy. :o) Then the W32 port needs to be changed :) Or the code must be conditionalized by putting helper functions in the *-io.c files. > The patch intent is to send the spawn gpg process a signal which is a > little bit more substantial than closed pipes. I understand that intention, and it's a good one. Let me first say that _if_ we go that route, then there is little sense in double-forking, but instead we should just fork once and then call waitpid always. This is what old versions of GPGME did, but then you need a SIGCHLD signal handler, too, and that's a bit of a mess in a library. I really like the beauty of double forking and not need to worry about what happens to GnuPG after closing the file descriptors, and just have GnuPG deal with it properly. This is useful in GnuPG anyway, so nothing is lost, and it makes GPGME simpler. This is why the code is like it is. Even better, but for future development, would be to have a special file descriptor or other communication channel by which we can send asynchronous events like cancelation to GnuPG. Then GnuPG could listen on that channel. Much more graceful than kill(), you wouldn't even need to exit if you are in server mode, and want to run many operations after another with the same instance of GnuPG. Thanks, Marcus From gpgme at katehok.ac93.org Thu Apr 14 16:49:07 2005 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Thu Apr 14 16:45:18 2005 Subject: gpgme_cancel() does not stop gpg process from finishing asynchronous call In-Reply-To: <87r7hdv4w9.wl@ulysses.g10code.de> References: <4249E9EF.8050504@katehok.ac93.org> <871x9dwzap.wl@ulysses.g10code.de> <425E5932.7080600@katehok.ac93.org> <425E69C3.90508@katehok.ac93.org> <87r7hdv4w9.wl@ulysses.g10code.de> Message-ID: <425E82E3.5040308@katehok.ac93.org> Marcus Brinkmann wrote: > I understand that intention, and it's a good one. Let me first say > >that _if_ we go that route, then there is little sense in >double-forking, but instead we should just fork once and then call >waitpid always. This is what old versions of GPGME did, but then you >need a SIGCHLD signal handler, too, and that's a bit of a mess in a >library. > >I really like the beauty of double forking and not need to worry about >what happens to GnuPG after closing the file descriptors, and just >have GnuPG deal with it properly. This is useful in GnuPG anyway, so >nothing is lost, and it makes GPGME simpler. This is why the code is >like it is. > >Even better, but for future development, would be to have a special >file descriptor or other communication channel by which we can send >asynchronous events like cancelation to GnuPG. Then GnuPG could >listen on that channel. Much more graceful than kill(), you wouldn't >even need to exit if you are in server mode, and want to run many >operations after another with the same instance of GnuPG. > > As much as I hate to admit it I think you are right - using kill() in gpgme does look more like a hack than a solution if you want to reuse GnuPG instance in a future. I'll try to look in GnuPG then to see why it doesn't stop or if it is fixed in CVS already. Thanks, Igor From gpgme at katehok.ac93.org Thu Apr 14 18:18:55 2005 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Thu Apr 14 18:15:13 2005 Subject: gpgme_cancel() does not stop gpg process from finishing asynchronous call In-Reply-To: <425E82E3.5040308@katehok.ac93.org> References: <4249E9EF.8050504@katehok.ac93.org> <871x9dwzap.wl@ulysses.g10code.de> <425E5932.7080600@katehok.ac93.org> <425E69C3.90508@katehok.ac93.org> <87r7hdv4w9.wl@ulysses.g10code.de> <425E82E3.5040308@katehok.ac93.org> Message-ID: <425E97EF.9020006@katehok.ac93.org> Igor Belyi wrote: > I'll try to look in GnuPG then to see why it doesn't stop or if it is > fixed in CVS already. And the sad story is that it will never be fixed in stable GnuPG... :o( All cipher generators use the following function to report their progress: static void progress( int c ) { if ( progress_cb ) progress_cb ( progress_cb_data, c ); else fputc( c, stderr ); } See the missing check for an error and no status return from the call? That means that there's a lot of places in need to be changed to let generation process notice that the output pipe is closed. I've tried to look through GnuPG Development branch but its switch to libgcrypt made it harder for me to see the impact of closed pipes. On the other hand, stable GnuPG code does have a handler for TERM signal and therefore soft kill used by GPGME should not cause keyring corruption at least. I don't know what to do... It looks like double-fork is a good way to avoid having SIGCHLD handler but seeing that there's too much changes are necessary in GnuPG itself to make it react promptly on closed pipe, I would think that sending a TERM signal is a good alternative for now. And probably waitpid can be removed since it doesn't work now anyway. Marcus, I'll let you decide what to do. ;o) But for now if somebody asks me why Cancel in my code doesn't work I'll refer them to my patch as a workaround. Cheers, Igor From mconahan at zixtestott.com Thu Apr 14 19:38:57 2005 From: mconahan at zixtestott.com (mconahan@zixtestott.com) Date: Thu Apr 14 19:34:52 2005 Subject: Setting the GnuPG binary path for GnuPGME In-Reply-To: <87vf6pvj8e.wl@ulysses.g10code.de> References: <425C23BB.1030401@zixtestott.com> <87vf6pvj8e.wl@ulysses.g10code.de> Message-ID: <425EAAB1.9060005@zixtestott.com> Marcus Brinkmann wrote: >At Tue, 12 Apr 2005 15:38:35 -0400, >"mconahan@zixtestott.com" wrote: > > >>Hi everyone, >> >> I was wondering if any knows how to set the GnuPG binary path used >>by GnuPGME? >> >> > >It's a new feature in CVS. also See the documentation (doc/gpgme.texi). >It will be in the next release. > >Noteworthy changes in version 1.1.0 (unreleased) >------------------------------------------------ > > * You can now configure the backend engine file name and home > directory to be used, as default and per context. > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >gpgme_set_engine_info NEW >gpgme_ctx_get_engine_info NEW >gpgme_ctx_set_engine_info NEW >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >Thanks, >Marcus > > > > Great! Thanks. From wk at gnupg.org Thu Apr 14 19:56:15 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Apr 14 19:56:43 2005 Subject: gpgme_cancel() does not stop gpg process from finishing asynchronous call In-Reply-To: <425E97EF.9020006@katehok.ac93.org> (Igor Belyi's message of "Thu, 14 Apr 2005 12:18:55 -0400") References: <4249E9EF.8050504@katehok.ac93.org> <871x9dwzap.wl@ulysses.g10code.de> <425E5932.7080600@katehok.ac93.org> <425E69C3.90508@katehok.ac93.org> <87r7hdv4w9.wl@ulysses.g10code.de> <425E82E3.5040308@katehok.ac93.org> <425E97EF.9020006@katehok.ac93.org> Message-ID: <877jj5xmww.fsf@wheatstone.g10code.de> On Thu, 14 Apr 2005 12:18:55 -0400, Igor Belyi said: > See the missing check for an error and no status return from the call? > That means that there's a lot of places in need to be changed to let generation > process notice that the output pipe is closed. We won't do that for 1.4. The plan for GnuPG 1.9 is to convert gpg to a multi session clean Assuan server. This will also include proper return code checking of status messages. Shalom-Salam, Werner From marcus.brinkmann at ruhr-uni-bochum.de Fri Apr 15 02:10:02 2005 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri Apr 15 02:05:57 2005 Subject: gpgme_cancel() does not stop gpg process from finishing asynchronous call In-Reply-To: <425E97EF.9020006@katehok.ac93.org> References: <4249E9EF.8050504@katehok.ac93.org> <871x9dwzap.wl@ulysses.g10code.de> <425E5932.7080600@katehok.ac93.org> <425E69C3.90508@katehok.ac93.org> <87r7hdv4w9.wl@ulysses.g10code.de> <425E82E3.5040308@katehok.ac93.org> <425E97EF.9020006@katehok.ac93.org> Message-ID: <87is2ovr1h.wl@ulysses.g10code.de> At Thu, 14 Apr 2005 12:18:55 -0400, Igor Belyi wrote: > > Igor Belyi wrote: > > > I'll try to look in GnuPG then to see why it doesn't stop or if it is > > fixed in CVS already. > > And the sad story is that it will never be fixed in stable GnuPG... :o( Yeah, that may be the case. Well, I could still apply your patch as a temporary work-around ;) I will consider it. That it doesn't touch any external interfaces etc makes it easier for me. > Marcus, I'll let you decide what to do. ;o) But for now if somebody asks me > why Cancel in my code doesn't work I'll refer them to my patch as a workaround. Just to be sure: cancel in GPGME does work, right? It's just that the gpg process keeps running until it completed its key generation, right? That's not too bad - key generation is not a common operation, and most users probably won't even notice that the computer keeps being busy for a couple of seconds draining the entropy pool after hitting that cancel button... So, the negative impact of this problem seems to be rather small to me. Thanks, Marcus From gpgme at katehok.ac93.org Sun Apr 17 00:03:40 2005 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Sat Apr 16 23:59:50 2005 Subject: gpgme_cancel() does not stop gpg process from finishing asynchronous call In-Reply-To: <87is2ovr1h.wl@ulysses.g10code.de> References: <4249E9EF.8050504@katehok.ac93.org> <871x9dwzap.wl@ulysses.g10code.de> <425E5932.7080600@katehok.ac93.org> <425E69C3.90508@katehok.ac93.org> <87r7hdv4w9.wl@ulysses.g10code.de> <425E82E3.5040308@katehok.ac93.org> <425E97EF.9020006@katehok.ac93.org> <87is2ovr1h.wl@ulysses.g10code.de> Message-ID: <42618BBC.8080300@katehok.ac93.org> Marcus Brinkmann wrote: >Well, I could still apply your patch as a temporary work-around ;) I >will consider it. That it doesn't touch any external interfaces etc >makes it easier for me. > > Additional thought - sending TERM signal should be no worse than a user hitting Control-C while working with gpg directly. >Just to be sure: cancel in GPGME does work, right? It's just that the >gpg process keeps running until it completed its key generation, >right? That's not too bad - key generation is not a common operation, >and most users probably won't even notice that the computer keeps >being busy for a couple of seconds draining the entropy pool after >hitting that cancel button... > >So, the negative impact of this problem seems to be rather small to me. > > Yes, cancel works with other functions. And yes, users won't notice the computer being busy for a couple of seconds after canceling key generation... until they look next time at their keyring and find their unwanted key. Plus, I've run into this problem while debuging my program and showing my computer to a croll with a banch of outstaning gpgs. Keep in mind that all other gpgme_*_start functions work with Data() objects - so you have control in your program to avoid writting this Data() to the disk if you know that user canceled the work. With key generate - the most you can do for a user - wait until this unwanted key is generated and then silently delete it (if you able to distinguish it from legitamate keys). Cheers, Igor From wk at gnupg.org Sun Apr 17 17:39:48 2005 From: wk at gnupg.org (Werner Koch) Date: Sun Apr 17 17:36:52 2005 Subject: gpgme_cancel() does not stop gpg process from finishing asynchronous call In-Reply-To: <42618BBC.8080300@katehok.ac93.org> (Igor Belyi's message of "Sat, 16 Apr 2005 18:03:40 -0400") References: <4249E9EF.8050504@katehok.ac93.org> <871x9dwzap.wl@ulysses.g10code.de> <425E5932.7080600@katehok.ac93.org> <425E69C3.90508@katehok.ac93.org> <87r7hdv4w9.wl@ulysses.g10code.de> <425E82E3.5040308@katehok.ac93.org> <425E97EF.9020006@katehok.ac93.org> <87is2ovr1h.wl@ulysses.g10code.de> <42618BBC.8080300@katehok.ac93.org> Message-ID: <87pswts98b.fsf@wheatstone.g10code.de> On Sat, 16 Apr 2005 18:03:40 -0400, Igor Belyi said: > Additional thought - sending TERM signal should be no worse than a > user hitting Control-C while working with gpg directly. BTW, there is an easy way to tell gpg to stop: Although the status functions won't return an error code, they may be changed to detect a write error and call exit() then. The problem here is that this slightly changes the semantics and some software may fail therefore. The only way to implement this in a safe way is by introducing a new option to gpg to do this. gpgme may then look at the gpg's versions and decide whether to use this option. Marcus, what do you think, shall I add such an option to gpg 1.4.2? Salam-Shalom, Werner From nsushkin at sushkins.net Tue Apr 12 17:22:09 2005 From: nsushkin at sushkins.net (Nicholas Sushkin) Date: Tue Apr 19 10:29:59 2005 Subject: Error at "bag.attributes" importing key from freemail cert into gpgsm In-Reply-To: <200504121034.20015.nsushkin@sushkins.net> References: <200504071615.30963.nsushkin@sushkins.net> <87ll7o70lm.fsf@wheatstone.g10code.de> <200504121034.20015.nsushkin@sushkins.net> Message-ID: <200504121122.09356.nsushkin@sushkins.net> On Tuesday 12 April 2005 10:34, Nicholas Sushkin wrote: > Werner, > > Thanks so much for your reply. I was using 1.9.15, gpgsm --import > failed with the same error. I'll try CVS next. > Werner, I think you forgot to commit common/sexputil.c to CVS Making all in common make[2]: Entering directory `/root/work/gnupg-1.9.cvs.20050412/gnupg/common' make[2]: *** No rule to make target `sexputil.c', needed by `sexputil.o'. Stop. make[2]: Leaving directory `/root/work/gnupg-1.9.cvs.20050412/gnupg/common' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/work/gnupg-1.9.cvs.20050412/gnupg' make: *** [all] Error 2 -- Nick From wk at g10code.com Thu Apr 21 17:23:26 2005 From: wk at g10code.com (Werner Koch) Date: Thu Apr 21 18:38:36 2005 Subject: [Announce] GnuPG 1.9.16 (S/MIME) released Message-ID: <87d5socfwx.fsf@wheatstone.g10code.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! We are pleased to announce the availability of GnuPG 1.9.16; the development branch of GnuPG featuring the S/MIME protocol. GnuPG 1.9 is the development version of GnuPG; it is based on some old GnuPG 1.3 code and the previous NewPG package. It will eventually lead to a GnuPG 2.0 release. Note that GnuPG 1.4 and 1.9 are not yet in sync and thus features and bug fixes done in 1.4 are not available in 1.9. *Please keep on using 1.4.x for OpenPGP*; 1.9.x and 1.4.x may be installed simultaneously. You should use GnuPG 1.9 if you want to use the gpg-agent or gpgsm (the S/MIME variant of gpg). The gpg-agent is also helpful when using the stable gpg version 1.4 (as well as the old 1.2 series). This is mainly a bug fix release but comes with some new features as well: * gpg-agent does now support the ssh-agent protocol and thus allows to use the pinentry as well as the OpenPGP smartcard with ssh. * New tool gpg-connect-agent as a general client for the gpg-agent. * New tool symcryptrun as a wrapper for certain encryption tools. * The gpg tool is not anymore build by default because those gpg versions available in the gnupg 1.4 series are far more matured. Please get it from the mirrors as listed at http://www.gnupg.org/download/mirrors.html or direct from ftp.gnupg.org: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.16.tar.bz2 (1667k) ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.16.tar.bz2.sig or as a patch against the previous release: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.15-1.9.16.diff.bz2 (108k) You will also need to get a new libksba (the X.509 and CMS parser): ftp://ftp.gnupg.org/gcrypt/alpha/libksba/libksba-0.9.11.tar.bz2 (443k) ftp://ftp.gnupg.org/gcrypt/alpha/libksba/libksba-0.9.11.tar.bz2.sig a patch is also available: ftp://ftp.gnupg.org/gcrypt/alpha/libksba/libksba-0.9.10-0.9.11.diff.bz2 (112k) GnuPG 1.9 makes use of a separate tool for CRL checking, this is called the Dirmngr. We have also released a new version of it and we suggest to update to that release: ftp://ftp.gnupg.org/gcrypt/alpha/dirmngr/dirmngr-0.9.2.tar.bz2 (463k) ftp://ftp.gnupg.org/gcrypt/alpha/dirmngr/dirmngr-0.9.2.tar.bz2.sig as usual we also provide a patch: ftp://ftp.gnupg.org/gcrypt/alpha/dirmngr/dirmngr-0.9.1-0.9.2.diff.bz2 (16k) SHA-1 checksums for the above files are: 7e470baf9a91221342af5aad57319329bf983a3a gnupg-1.9.16.tar.bz2 5a296cd8788f7fe2495bc014f8e19a4d2a000dc8 gnupg-1.9.15-1.9.16.diff.bz2 0dc8a41b3165404ccdb0e4a3701412f7cc625b11 libksba-0.9.11.tar.bz2 9805a08fd74b64c23262d31b741b12b0a59f04b2 libksba-0.9.10-0.9.11.diff.bz2 0e8377deb78408b9081681ea1437667cc3c5b77e dirmngr-0.9.2.tar.bz2 5f02bd2a9c5ac9214e0412d48d8d5342e230a2b0 dirmngr-0.9.1-0.9.2.diff.bz2 Happy hacking, Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iEYEARECAAYFAkJnxRgACgkQYHhOlAEKV+3RUgCeKeZvWsVNJDK5Mm5GKRmTzPjL /sMAoLmKF4+61cYHk/NxKUlmqUxSIq2T =yxLM -----END PGP SIGNATURE----- -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From Axel.Thimm at ATrpms.net Thu Apr 21 21:27:25 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu Apr 21 22:26:49 2005 Subject: opensc and pth in scd (was: GnuPG 1.9.16 (S/MIME) released) In-Reply-To: <87d5socfwx.fsf@wheatstone.g10code.de> References: <87d5socfwx.fsf@wheatstone.g10code.de> Message-ID: <20050421192725.GA25075@neu.nirvana> Hi, the scd Makefile will turn off pth libs if OpenSC is detected. But USE_GNU_PTH is still defined in command.c compiling in the pth_sleep function call. Which of course is not resolved in the link stage. What's the right thing to do? Thanks. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050421/5b345696/attachment.pgp From wk at gnupg.org Thu Apr 21 22:45:43 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Apr 21 22:46:53 2005 Subject: opensc and pth in scd In-Reply-To: <20050421192725.GA25075@neu.nirvana> (Axel Thimm's message of "Thu, 21 Apr 2005 21:27:25 +0200") References: <87d5socfwx.fsf@wheatstone.g10code.de> <20050421192725.GA25075@neu.nirvana> Message-ID: <87oec7c0zs.fsf@wheatstone.g10code.de> On Thu, 21 Apr 2005 21:27:25 +0200, Axel Thimm said: > the scd Makefile will turn off pth libs if OpenSC is detected. But > USE_GNU_PTH is still defined in command.c compiling in the pth_sleep Damned. I forgot about this. The solution is pretty easy: Delete or comment the whole block: if (rc && has_option (line, "--wait")) { pth_sleep (1); /* Better implement an event mechanism. However, for card operations this should be sufficient. */ goto retry; } It is not used yes. Time to move forward with app-p15.c to get rid of OpenSC. Shalom-Salam, Werner From peter.eberlein at ofd.verwalt-berlin.de Fri Apr 22 09:19:23 2005 From: peter.eberlein at ofd.verwalt-berlin.de (Peter Eberlein) Date: Fri Apr 22 10:07:12 2005 Subject: silent installation of gnupg-w32cli-1.4.1.exe Message-ID: <4268A57B.1020406@ofd.verwalt-berlin.de> Hi, I have to prepare the installation on a WindowsNT-Network in a silent way. I downloaded the gnupg-w32cli-1.4.1.exe and tried some parameter for installing. Any hints? Sincerely Peter From serdar at uludag.org.tr Fri Apr 22 14:06:53 2005 From: serdar at uludag.org.tr (Serdar KOYLU) Date: Fri Apr 22 14:54:36 2005 Subject: SmartCard usage Message-ID: <1114171613.5864.53.camel@serdar.uludag.org.tr> Hi, I have two blank smartcard (SC) and 3-4 reader device. All devices compatible with Linux, drivers available with binary or source format. PC/SC (pcsclite) work currently this readers. I don't know card brand or models. Card 1: GEMPLUS MPCOS-EMV Compatible card. No any information our hands.. ATR: 3B A7 00 40 18 80 65 A2 09 01 03 52 Card 2: Unknown, but TCOS card OS already. ATR: 3B BA 96 00 81 31 86 5D 00 64 05 60 02 03 31 80 90 00 66 With trying opensc-tool, many operations resulted correct values. Such as Card 2 accept DF/EF creation etc. I want use this cards with GnuPG. I research many tools from reader/card sites, pc-sc sites etc. And many times i try use gpg2 with --card* cmds. gpg2 --card-status scdaemon[pid]: no supported card application found: Invalid value with Card 2. And sleep, wait, wait and wait.... With Card 1 same result but error message is "No such file or directory". I try eject card with this wait phase, scdaemon show: reader-pcsc.c:433:pcsc_lock: SCardBeginTransaction failed: Card was removed. card-gpk.c:1709:gpk_get_info: sc_lock() failed: Card removed reader-pcsc.c:433:pcsc_lock: SCardBeginTransaction failed: Card was removed. scdaemon[26774]: can't lock card in reader 0: Card removed scdaemon: card.c:486: sc_unlock: Assertion `card->lock_count >= 1' failed. gpg-agent[26773]: command learn failed: Unknown system error gpg: OpenPGP card not available: Assuan server fault For --card-edit command, result don't change. But many time, i reach "Command>" prompt, but all commands resulted with error.. For use GnuPG with smartcard, i can what? Thanks.. From jan at gondor.com Fri Apr 22 15:43:58 2005 From: jan at gondor.com (Jan Niehusmann) Date: Fri Apr 22 15:39:46 2005 Subject: SmartCard usage In-Reply-To: <1114171613.5864.53.camel@serdar.uludag.org.tr> References: <1114171613.5864.53.camel@serdar.uludag.org.tr> Message-ID: <20050422134358.GA27109@gondor.com> On Fri, Apr 22, 2005 at 03:06:53PM +0300, Serdar KOYLU wrote: > For use GnuPG with smartcard, i can what? GnuPG only supports smart cards following the OpenPGP Card specification, as available from http://www.g10code.com/p-card.html The cards you can by from kernelconcepts (link on the mentioned page) are the only ones actually available, as far as I know. You may implement the OpenPGP specification on one of your cards, if it is programmable and sufficiently capable. But this would be very non-trivial, I don't think this is what you want to do. Jan From gpgme at katehok.ac93.org Sat Apr 23 19:25:55 2005 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Sat Apr 23 19:21:57 2005 Subject: Tricky gpgme_wait bug. Message-ID: <426A8523.50304@katehok.ac93.org> There's a strange gpgme bug hit by gpgme_wait when there's a sleep happen between calls and when the asynchronous command is 'gpgme_op_verify_start' resulting in an error. I've attached the program reproducing the problem. An input parameter should be a file with an attached signature. The problem can be seen when you feed to the program a file containing no signature. You can also see that problem does not happen if you comment out 'sleep(1)' in the while loop. I've run it in a debugger and found out that segmentation fault happens due to the fact that in the following line of the wait-global.c/gpgme_wait() function values of the opaque structure are bogus: item = (struct wait_item_s *) fdt.fds[i].opaque; I have hard time finding out where this opaque comes from and why would it be invalid sometimes, so I thought I will share what I already found. Hopefully, somebody will have better luck tracking this problem out. Cheers, Igor -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme_wait_bug.c Type: text/x-csrc Size: 1923 bytes Desc: not available Url : /pipermail/attachments/20050423/e8acd22c/gpgme_wait_bug.c From gpgme at katehok.ac93.org Sun Apr 24 05:43:53 2005 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Sun Apr 24 05:40:05 2005 Subject: Tricky gpgme_wait bug. In-Reply-To: <426A8523.50304@katehok.ac93.org> References: <426A8523.50304@katehok.ac93.org> Message-ID: <426B15F9.7010904@katehok.ac93.org> Igor Belyi wrote: > There's a strange gpgme bug hit by gpgme_wait when there's a sleep > happen between calls and when the asynchronous command is > 'gpgme_op_verify_start' resulting in an error. Ok, I think I know what causes this problem but I don't quite understand what is the best way to fix it. The extra sleep between gpgme_wait causes _gpgme_io_select to get signal on more than one file handler for the same context. As a result an error reported on the first handle causes all context handlers to be closed and the associated data released. When the second selected handle get processed it causes segmentation fault. Cheers, Igor From dshaw at jabberwocky.com Sun Apr 24 17:53:47 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Sun Apr 24 17:50:14 2005 Subject: small bugs and a small fix (1.4.1rc2 cvs) In-Reply-To: <20050227011622.GD5206@jabberwocky.com> References: <15783.1109046093@www13.gmx.net> <20050224211219.GB29001@jabberwocky.com> <20050226131741.GH4823@opium.palfrader.org> <20050227011622.GD5206@jabberwocky.com> Message-ID: <20050424155347.GM19713@jabberwocky.com> On Sat, Feb 26, 2005 at 08:16:22PM -0500, David Shaw wrote: > On Sat, Feb 26, 2005 at 02:17:41PM +0100, Peter Palfrader wrote: > > On Thu, 24 Feb 2005, David Shaw wrote: > > > > > On Tue, Feb 22, 2005 at 05:21:33AM +0100, Stephan Beyer wrote: > > > > > > > 1) --sign-key > > > > > > > > When signing a key with --sign-key, gpg asks `Really sign all user IDs? > > > > (y/N)'. Type `n' and 1.4.0 prints the hint to select the uids, but > > > > interprets `n' as a `No, I don't want to sign the key at all.' and exits. > > > > 1.2.x `returns' to the --edit-key-Command-prompt instead. > > > > > > This is actually a feature. The 1.2.x behavior is a little odd since > > > the user started from the command line, issued a command line command, > > > and then suddenly found themselves inside the --edit-key menu. I > > > agree the hint is not useful and confusing when the user gets there > > > via --sign-key, so I will remove it for --sign-key. > > > > This is very unfortunate as it breaks all scripts that call --sign-key > > and let the actual signing and uid selection to the user and gpg. > > I am revisiting this for 1.4.2 (well, maybe 1.4.1). Stephan's > suggestion of walking over each UID and asking the user seems good to > me. This is done for 1.4.2. > > On a related note, gpg now lists unique identifiers for each uid: > > > > | pub:u:1024:17:DE7AAF6E94C09C7F:942264711:::u:::scaESCA: > > | uid:u::::951840856::6DE2DB889258745FC0F19712AAD73DB1E1AF8E35::Peter Palfrader: > > | uid:u::::974848155::7846E1859AD46C860243B91589845BE87B584845::Peter Palfrader : > > > > Is there a way to use them in the edit dialog? I imagine something like > > > > | gpg --edit-key 12345678 > > | uid 7846E1859AD46C860243B91589845BE87B584845 <----- > > | sign > > > > would be handy. > > That's a good idea. It would be nice in scripts. So is this. David From harry_b at mm.st Mon Apr 25 10:27:49 2005 From: harry_b at mm.st (harry_b@mm.st) Date: Mon Apr 25 10:45:26 2005 Subject: gpg --list-only argument Message-ID: <315711438F5C41BC85487D11@toughbook> Hi everybody, sorry for the wrong subject before - I repost my message with the proper subject this time. I am trying to get around the lacking feature of gpgme to tell me for which keys a message has been encrypted for. I am running gpg 1.4.0 on Debian unstable. I thought, that 'gpg --list-only filename' should give me all keys, a message was encrypted for. Unfortunately, this seems not to include my own keys. If a message is encrypted for several recipients, it lists all except my own keys. If its encrypted for myself only, it doesn't list anything at all. Do I miss something here? Can I somehow get ALL keys? TIA, Harry -- 1024D/40F14012 18F3 736A 4080 303C E61E 2E72 7E05 1F6E 40F1 4012 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT/S dx s: a C++ ULS++++$ P+++ L+++$ !E W++ N+ o? K? !w !O !M V PS+ PE Y? PGP+++ t+ 5-- X+ R+ !tv b++ DI++ D+ G e* h r++ y++ ------END GEEK CODE BLOCK------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050425/f4539581/attachment.pgp From harry_b at mm.st Mon Apr 25 10:00:18 2005 From: harry_b at mm.st (harry_b@mm.st) Date: Mon Apr 25 11:02:06 2005 Subject: [Announce] German speaking mailing list In-Reply-To: <87acno89qm.fsf@wheatstone.g10code.de> References: <87acno89qm.fsf@wheatstone.g10code.de> Message-ID: <93F62CB3796987812ED6E5AD@toughbook> Hi everybody, I am trying to get around the lacking feature of gpgme to tell me for which keys a message has been encrypted for. I am running gpg 1.4.0 on Debian unstable. I thought, that 'gpg --list-only filename' should give me all keys, a message was encrypted for. Unfortunately, this seems not to include my own keys. If a message is encrypted for several recipients, it lists all except my own keys. If its encrypted for myself only, it doesn't list anything at all. Do I miss something here? Can I somehow get ALL keys? TIA, Harry -- 1024D/40F14012 18F3 736A 4080 303C E61E 2E72 7E05 1F6E 40F1 4012 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT/S dx s: a C++ ULS++++$ P+++ L+++$ !E W++ N+ o? K? !w !O !M V PS+ PE Y? PGP+++ t+ 5-- X+ R+ !tv b++ DI++ D+ G e* h r++ y++ ------END GEEK CODE BLOCK------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050425/1aa9e4a3/attachment.pgp From gpgme at katehok.ac93.org Mon Apr 25 19:51:58 2005 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Mon Apr 25 19:48:02 2005 Subject: Tricky gpgme_wait bug. In-Reply-To: <426B15F9.7010904@katehok.ac93.org> References: <426A8523.50304@katehok.ac93.org> <426B15F9.7010904@katehok.ac93.org> Message-ID: <426D2E3E.4050803@katehok.ac93.org> Igor Belyi wrote: > Igor Belyi wrote: > >> There's a strange gpgme bug hit by gpgme_wait when there's a sleep >> happen between calls and when the asynchronous command is >> 'gpgme_op_verify_start' resulting in an error. > > > Ok, I think I know what causes this problem but I don't quite > understand what is the best way to fix it. > > The extra sleep between gpgme_wait causes _gpgme_io_select to get > signal on more than one file handler for the same context. As a result > an error reported on the first handle causes all context handlers to > be closed and the associated data released. When the second selected > handle get processed it causes segmentation fault. And just to reply to myself, attached is a proposed patch fixing the problem. I do hope it helps, Igor -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme1.0-gpgme_signals_in_wait.patch Type: text/x-patch Size: 572 bytes Desc: not available Url : /pipermail/attachments/20050425/070fe896/gpgme1.0-gpgme_signals_in_wait.bin From jjperezmorales at gmail.com Tue Apr 26 11:50:03 2005 From: jjperezmorales at gmail.com (Juan Jose Perez) Date: Tue Apr 26 12:45:52 2005 Subject: gpg.conf Message-ID: Hi I'm trying to configure Gnupg for windows I've done all the steps for the installation but I don't get the gpg.conf in my home directory. Can I create this file by hand? what can I do to get such file? Thank you! From list at omicron-persei-8.net Wed Apr 27 10:03:26 2005 From: list at omicron-persei-8.net (Tyler Retzlaff) Date: Wed Apr 27 10:41:03 2005 Subject: doc/bug gpgme 1.0.1 Message-ID: <426F474E.7040102@omicron-persei-8.net> The info documentation for initialization of struct gpgme_data_cbs indicates that release is an optional. However, if it is initialized to NULL a gpgme_data_release still causes release to be called. It being initialized to NULL causes things to barf. The documentation should either be changed to say that gpgme_data_release should not be called if the release callback is not set. (Which may not be the right thing since we can't know allocations beyond user control haven't taken place internally). Or, check to make sure release is set before trying to call it. --- gpgme/data-user.c.orig 2005-04-27 11:06:34.000000000 +1000 +++ gpgme/data-user.c 2005-04-27 11:06:59.000000000 +1000 @@ -50,7 +50,8 @@ user_seek (gpgme_data_t dh, off_t offset static void user_release (gpgme_data_t dh) { - (*dh->data.user.cbs->release) (dh->data.user.handle); + if (*dh->data.user.cbs->release) + (*dh->data.user.cbs->release) (dh->data.user.handle); } Cheers From sadam at CLEMSON.EDU Fri Apr 29 06:08:37 2005 From: sadam at CLEMSON.EDU (Adam Schreiber) Date: Fri Apr 29 10:04:33 2005 Subject: Key Info Before Import Message-ID: <4271B345.6080102@clemson.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is it possible to extract data about a key (Name, Fingerprint, Signatures, Expiration Date, Email, etc) before the key is imported into the key ring? Adam Schreiber - -- Why isn't all of your email encrypted? http://gnupg.org http://enigmail.mozdev.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCcbNFjU1oaHEI4wgRAsaRAKDIl21b59PFckXkFvymQFxA50LIywCbBFOa hZfjkelPrD3pSVZCIeGWEn8= =NdI+ -----END PGP SIGNATURE----- From s-beyer at gmx.net Fri Apr 29 11:12:46 2005 From: s-beyer at gmx.net (Stephan Beyer) Date: Fri Apr 29 12:01:54 2005 Subject: Key Info Before Import In-Reply-To: <4271B345.6080102@clemson.edu> References: <4271B345.6080102@clemson.edu> Message-ID: <20050429091246.GA615@littlefarm> Hi, > Is it possible to extract data about a key (Name, Fingerprint, > Signatures, Expiration Date, Email, etc) before the key is imported into > the key ring? "gpg -v filename" or "gpg -vv filename" gives you information about the packets in the OpenPGP file (for example, a key or a keyring). Should tell you everything you want except the fingerprint. Btw: I guess, -devel isn't the right list for this question. Best regards, Stephan -- Stephan Beyer, PGP 0xFCC5040F, IRC sbeyer (seebyr, bseyer) From sadam at CLEMSON.EDU Fri Apr 29 17:21:59 2005 From: sadam at CLEMSON.EDU (Adam Schreiber) Date: Fri Apr 29 17:18:08 2005 Subject: Key Info Before Import In-Reply-To: <20050429091246.GA615@littlefarm> References: <4271B345.6080102@clemson.edu> <20050429091246.GA615@littlefarm> Message-ID: <42725117.5050308@clemson.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephan Beyer wrote: > "gpg -v filename" or "gpg -vv filename" gives you information about the > packets in the OpenPGP file (for example, a key or a keyring). Should > tell you everything you want except the fingerprint. I suppose I should have asked is there a way to do this using GPGME in such a fashion that the gpg executable doesn't need to be accessed directly? This information will be used for current Seahorse development (http://seahorse.sf.net). Adam Schreiber - -- Why isn't all of your email encrypted? http://gnupg.org http://enigmail.mozdev.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCclEWjU1oaHEI4wgRAkTrAKDc8XU5C23KNTowGyNJiPudOztKWwCeKgcJ XVnbtFSvtqtVmD1QObRVdQI= =V5uA -----END PGP SIGNATURE----- From mo at g10code.com Sat Apr 30 08:44:37 2005 From: mo at g10code.com (Moritz Schulte) Date: Sat Apr 30 09:40:23 2005 Subject: Key Info Before Import In-Reply-To: <42725117.5050308@clemson.edu> References: <4271B345.6080102@clemson.edu> <20050429091246.GA615@littlefarm> <42725117.5050308@clemson.edu> Message-ID: <20050430064437.GA13147@sarkutty> On Fri, Apr 29, 2005 at 11:21:59AM -0400, Adam Schreiber wrote: Hello, > I suppose I should have asked is there a way to do this using GPGME > in such a fashion that the gpg executable doesn't need to be > accessed directly? No, there is not. Please note that this is a design criteria: there is no reason why a public key should *not* be imported. What MUAs can do is displaying information about the key *after* it has been imported ("The following key has just been imported: ..."). Thanks, Moritz -- Moritz Schulte -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 193 bytes Desc: not available Url : /pipermail/attachments/20050430/4c6a0c0e/attachment.pgp From mutz at kde.org Thu Apr 28 15:06:31 2005 From: mutz at kde.org (Marc Mutz) Date: Wed May 4 15:25:48 2005 Subject: [libgcrypt] [PATCH] SHA-1 extracted for stand-alone use Message-ID: <200504281506.38562.mutz@kde.org> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20050428/0f72c494/attachment.pgp