From bjk at luxsci.net Sun Dec 2 18:47:45 2007 From: bjk at luxsci.net (Ben Kibbey) Date: Sun, 2 Dec 2007 12:47:45 -0500 Subject: assuan external loop over socket In-Reply-To: <87myu6xap6.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200710251400.l9PE05WX010150@rs19.luxsci.com> <87myu6xap6.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200712021750.lB2Ho2Wg013657@rs41.luxsci.com> On Fri, Oct 26, 2007 at 03:33:09PM +0200, Marcus Brinkmann wrote: > At Thu, 25 Oct 2007 09:59:20 -0400, > Ben Kibbey wrote: > > > > The assuan info docs say connecting to a socket with the external IO > > loop isn't supported. Are there any plans to do this in the near future? > > If you need to do asynchronous assuan communication in the client, > then yes, there is a small function missing, which I can add easily. [...] I have a need for this now. I have a client that sends an inquire command to the server, but the data needs to be sent ASSUAN_LINELENGTH bytes at a time (memory restrictions). assuan_transact() can't do this with it's inquire callback and keep parsing status messages from the server at the same time, which I also need. I can't call assuan_read_line() to do the status line parsing in the inquire callback because assuan_read_line() blocks? I'm guessing how the asynchronous client works: If I were to call assuan_transact() which would setup the callbacks, then call assuan_process_next() until the inquire callback returns EOF, or an error, to finish the command. Then call assuan_process_done() to get the command result from the server. Is this right? -- Benjamin J. Kibbey bjk at luxsci.net/jabber/freenode 3019 F5FC AA33 5BC7 BE9F 09D2 393E DBD2 40D5 FA7E From bjk at luxsci.net Sun Dec 2 19:04:22 2007 From: bjk at luxsci.net (Ben Kibbey) Date: Sun, 2 Dec 2007 13:04:22 -0500 Subject: assuan_read_from_server() and return value In-Reply-To: <200711231902.lANJ22OU007693@rs41.luxsci.com> References: <200711231902.lANJ22OU007693@rs41.luxsci.com> Message-ID: <200712021805.lB2I51KI003982@rs41.luxsci.com> On Fri, Nov 23, 2007 at 02:01:04PM -0500, Ben Kibbey wrote: > I'm using assuan_transact() to process an inquire command. After the > command is finished, assuan_transact() sends "END" then reads the next > line from the server via assuan_read_from_server(). > assuan_read_from_server() will parse an ERR line, but won't do anything > with the error code. Attached is a patch that'll return the server error > code. Doesn't seem to break anything. Oops. The patch does break things. The server isn't guaranteed to return a ASSUAN_N or GPG_ERR_N code. And there isn't a way to tell which type of error it is. So would it be better to patch the server (pinentry in this case) to return gpg-error codes, or do something different with my return codes from the server (which does use gpg-error codes)? It does make sense to me to consider the ERR response code from a server command. Any reason not to? Thanks, -- Benjamin J. Kibbey bjk at luxsci.net/jabber/freenode 3019 F5FC AA33 5BC7 BE9F 09D2 393E DBD2 40D5 FA7E From wk at gnupg.org Mon Dec 3 11:34:03 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Dec 2007 11:34:03 +0100 Subject: [Announce] Libgcrypt 1.3.2 (devel) released Message-ID: <87wsrwt6ck.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of Libgcrypt 1.3.2. This version should be considered a release candidate for 1.4.0. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementaion of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use libgcrypt. Changes compared to 1.3.2 are: * The visibility attribute is now used if supported by the toolchain. * The ACE engine of VIA processors is now used for AES-128. * The ASN.1 DER template for SHA-224 has been fixed. Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source file and its digital signature is: ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.3.2.tar.bz2 (941k) ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.3.2.tar.bz2.sig This file is bzip2 compressed. The SHA-1 checksum is: a6d7cf7d717edf10718d9200ab7ee11296f984ee libgcrypt-1.3.2.tar.bz2 For help on developing with Libgcrypt you should send mail to the grcypt-devel mailing list [1]. Improving Libgcrypt is costly, but you can help! We are looking for organizations that find Libgcrypt useful and wish to contribute back. You can contribute by reporting bugs, improve the software [2], or by donating money. Commercial support contracts for Libgcrypt are available [3], and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company, is currently funding Libgcrypt development. We are always looking for interesting development projects. Happy hacking, Werner [1] See http://www.gnupg.org/documentation/mailing-lists.html . [2] Note that copyright assignments to the FSF are required. [3] See the service directory at http://www.gnupg.org/service.html . -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available Url : /pipermail/attachments/20071203/af4f475f/attachment.pgp -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From marcus.brinkmann at ruhr-uni-bochum.de Mon Dec 3 15:56:53 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 03 Dec 2007 15:56:53 +0100 Subject: assuan_read_from_server() and return value In-Reply-To: <200711231902.lANJ22OU007693@rs41.luxsci.com> <200712021805.lB2I51KI003982@rs41.luxsci.com> References: <200711231902.lANJ22OU007693@rs41.luxsci.com> Message-ID: <87fxyjaksq.wl%marcus.brinkmann@ruhr-uni-bochum.de> Hi Ben, there seem to be separate issues here: 1) It seems to me that the case you describe can only happen if you have no inquire callback set, right? In this case, the error code is going to be overwritten by assuan_transact anyway. Frankly, I do not understand why there is a dummy read in that place anyway. Comparing this with the code in assuan-buffer.c, where there is no dummy read after sending the END command (this is the code path taken if there is an inquire callback), the dummy read does not seem to be necessary, in fact, in my opinion it could be downright harmful. OTOH, as there is an error code returned by assuan_transact, one could argue that the connection is in a messed up state anyway at that point due to the missing inquire callback. The code may be designed to salvage from the connection whatever is possible. But, this fails if for example after sending END and doing a dummy read the server command is still not yet finished. It seems to me the right way to fix this is to send a CANCEL instead or following the END. 2) However, the function _assuan_read_from_server is also used in two other places in libassuan, where an error could also be returned due to a missing handshake. In this case, the return code could be useful. I think it is reasonable to assume that it is a gpg error or assuan error code at that point, because the low-level handshake protocol is defined by assuan and we control the sender and receiver side for this. In fact, we can always just return whatever ERR number is provided by the server: assuan_error_t is defined in that way (some values are reserved for the assuan protocol, the rest is free. We recently introduced support for gpg-error numbers, which makes things a bit more delicate, but I am willing to ignore this complication for the sake of discussion :). So, I think I would still like to apply your patch, although it should not make any difference in the scenario you describe. Plus, I would like to replace the dummy read and possibly (if it works) the sending of END by a sending of CANCEL. Does this make sense? I might be missing something here. Thanks, Marcus At Fri, 23 Nov 2007 14:01:04 -0500, Ben Kibbey wrote: > > I'm using assuan_transact() to process an inquire command. After the > command is finished, assuan_transact() sends "END" then reads the next > line from the server via assuan_read_from_server(). > assuan_read_from_server() will parse an ERR line, but won't do anything > with the error code. Attached is a patch that'll return the server error > code. Doesn't seem to break anything. > > Index: assuan-client.c > =================================================================== > --- assuan-client.c (revision 278) > +++ assuan-client.c (working copy) > @@ -86,6 +86,7 @@ > *off = 3; > while (line[*off] == ' ') > ++*off; > + rc = atoi(line+ (*off)); > } > else if (linelen >= 7 > && line[0] == 'I' && line[1] == 'N' && line[2] == 'Q' > > -- > Benjamin J. Kibbey bjk at luxsci.net/jabber/freenode > 3019 F5FC AA33 5BC7 BE9F 09D2 393E DBD2 40D5 FA7E > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > At Sun, 2 Dec 2007 13:04:22 -0500, Ben Kibbey wrote: > > On Fri, Nov 23, 2007 at 02:01:04PM -0500, Ben Kibbey wrote: > > I'm using assuan_transact() to process an inquire command. After the > > command is finished, assuan_transact() sends "END" then reads the next > > line from the server via assuan_read_from_server(). > > assuan_read_from_server() will parse an ERR line, but won't do anything > > with the error code. Attached is a patch that'll return the server error > > code. Doesn't seem to break anything. > > Oops. The patch does break things. The server isn't guaranteed to return > a ASSUAN_N or GPG_ERR_N code. And there isn't a way to tell which type > of error it is. So would it be better to patch the server (pinentry in > this case) to return gpg-error codes, or do something different with my > return codes from the server (which does use gpg-error codes)? > > It does make sense to me to consider the ERR response code from a server > command. Any reason not to? > > Thanks, > > -- > Benjamin J. Kibbey bjk at luxsci.net/jabber/freenode > 3019 F5FC AA33 5BC7 BE9F 09D2 393E DBD2 40D5 FA7E > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From marcus.brinkmann at ruhr-uni-bochum.de Mon Dec 3 16:08:05 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 03 Dec 2007 16:08:05 +0100 Subject: assuan external loop over socket In-Reply-To: <200712021750.lB2Ho2Wg013657@rs41.luxsci.com> References: <200710251400.l9PE05WX010150@rs19.luxsci.com> <87myu6xap6.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200712021750.lB2Ho2Wg013657@rs41.luxsci.com> Message-ID: <87eje3aka2.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sun, 2 Dec 2007 12:47:45 -0500, Ben Kibbey wrote: > > On Fri, Oct 26, 2007 at 03:33:09PM +0200, Marcus Brinkmann wrote: > > At Thu, 25 Oct 2007 09:59:20 -0400, > > Ben Kibbey wrote: > > > > > > The assuan info docs say connecting to a socket with the external IO > > > loop isn't supported. Are there any plans to do this in the near future? > > > > If you need to do asynchronous assuan communication in the client, > > then yes, there is a small function missing, which I can add easily. > > [...] > > I have a need for this now. I have a client that sends an inquire > command to the server, but the data needs to be sent ASSUAN_LINELENGTH > bytes at a time (memory restrictions). assuan_transact() can't do this > with it's inquire callback and keep parsing status messages from the > server at the same time, which I also need. I can't call > assuan_read_line() to do the status line parsing in the inquire callback > because assuan_read_line() blocks? Allow me to ask for a clarification: You want to read status messages *while* you have an inquire operation ongoing? Normally, assuan servers do not send status messages while they are receiving inquire data. I have never considered this possibility. It seems overly complex. The current asynchronous interfaces assume that both client and server read promptly whenever the other end may send something. So, you should be able to write all inquire data in a busy loop without blocking. > I'm guessing how the asynchronous client works: If I were to call > assuan_transact() which would setup the callbacks, then call > assuan_process_next() until the inquire callback returns EOF, or an > error, to finish the command. Then call assuan_process_done() to get the > command result from the server. Is this right? Well, the assuan_transact function would need to be split up into a send request phase and a receive reply phase. I don't think inquire data should be handled asynchronously. This would only make sense if you have a lot of inquire data, and then it makes sense to just use an input fd for your data. I don't remember anymore exactly what plans I had for the client side and asynchronous interfaces. Probably not much beyond what I wrote above. In fact, if you look at GPGME, it uses assuan_transact only for simple "synchrnous" commands which we know return promptly. For the main functions it uses its own implementation of "assuan_transact". One might wish for more support from libassuan, but assuan_transact is so simple, and asynchronous interfaces are so complex, that shifting that little of the client side which is in libassuan to the application does not seem overly burdensome. BUT: I do not use the inquire feature in GPGME at all, which may make me biased. I suggest we first clarify which data gets send asynchronously in which direction under which circumstances first, and then take another look at the interfaces we might need to touch to make this easier/possible. Thanks, Marcus From m_pupil at yahoo.com.cn Mon Dec 3 17:28:44 2007 From: m_pupil at yahoo.com.cn (It's me FKtPp ;)) Date: Tue, 04 Dec 2007 00:28:44 +0800 Subject: gnupg 1.4.7 build system bug: gpgkeys_ldap compile error while libcurl in non-standard path In-Reply-To: <20071129003939.GA6508@jabberwocky.com> References: <684194.27183.qm@web15008.mail.cnb.yahoo.com> <20071129003939.GA6508@jabberwocky.com> Message-ID: <47542EBC.3090306@yahoo.com.cn> David Shaw ????: > On Tue, Nov 27, 2007 at 11:17:46PM +0800, FKtPp wrote: >> Dear developers, >> >> I find this bug while compiling gnupg 1.4.7 on solaris 10/8 x86 edition on my machine. >> >> PRE-REQUIREMENTS: >> >> 1) if you have curl/libcurl installed in non-standard place(which was true for solaris in /opt/sfw subdirectory) >> >> 2) you chose to compile in curl support. >> >> 3) your configure decide to compile in ldap support. >> >> RESULT: >> >> Compile error while compile gpgkeys_ldap things. gpgkeys_ldap_* need libcurl header/libs path to be correct compiled/linked. > > Can you show me the error you get? It would be helpful. Sorry, for the late reply. I was previously not on list... 1) my configuration commandline is: ./configure --prefix=/opt/sfw --with-libcurl=/opt/sfw 2) error output is: gcc -g -O2 -Wall -o gpgv gpgv.o build-packet.o compress.o compress-bz2.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-packet.o status.o plaintext.o sig-check.o keylist.o signal.o verify.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -lresolv ../intl/libintl.a -lz -lbz2 gmake[2]: Leaving directory `/home/fktpp/downloads/gnupg-1.4.7/g10' Making all in keyserver gmake[2]: Entering directory `/home/fktpp/downloads/gnupg-1.4.7/keyserver' if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../intl -g -O2 -Wall -MT gpgkeys_ldap-gpgkeys_ldap.o -MD -MP -MF ".deps/gpgkeys_ldap-gpgkeys_ldap.Tpo" -c -o gpgkeys_ldap-gpgkeys_ldap.o `test -f 'gpgkeys_ldap.c' || echo './'`gpgkeys_ldap.c; \ then mv -f ".deps/gpgkeys_ldap-gpgkeys_ldap.Tpo" ".deps/gpgkeys_ldap-gpgkeys_ldap.Po"; else rm -f ".deps/gpgkeys_ldap-gpgkeys_ldap.Tpo"; exit 1; fi In file included from gpgkeys_ldap.c:59: ksutil.h:37:23: curl/curl.h: ?????????????? In file included from gpgkeys_ldap.c:59: ksutil.h:119: error: syntax error before "error" gmake[2]: *** [gpgkeys_ldap-gpgkeys_ldap.o] Error 1 gmake[2]: Leaving directory `/home/fktpp/downloads/gnupg-1.4.7/keyserver' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/fktpp/downloads/gnupg-1.4.7' gmake: *** [all] Error 2 From bjk at luxsci.net Sat Dec 8 18:44:21 2007 From: bjk at luxsci.net (Ben Kibbey) Date: Sat, 8 Dec 2007 12:44:21 -0500 Subject: assuan_read_from_server() and return value In-Reply-To: <87fxyjaksq.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200711231902.lANJ22OU007693@rs41.luxsci.com> <87fxyjaksq.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200712081745.lB8Hj2rF001140@rs41.luxsci.com> On Mon, Dec 03, 2007 at 03:56:53PM +0100, Marcus Brinkmann wrote: > Hi Ben, > > there seem to be separate issues here: > > 1) It seems to me that the case you describe can only happen if you > have no inquire callback set, right? In this case, the error code is > going to be overwritten by assuan_transact anyway. After the inquire callback is finished, assuan_transact() sends END to terminate the inquire then calls _assuan_read_from_server() again. On the server end, an error may have occured while processing the inquired data which may return an error code which is not guaranteed to be an ASSUAN_ error code. Without the patch, _assuan_read_from_server() returns the value returned from _assuan_read_line() (zero). I use GPG_ERR codes on the server. Pinentry uses ASSUAN_ errors and there is no way to tell if the error is an GPG_ERR_ or an ASSUAN_ error. So I guess pinentry has to migrate to use GPG_ERR_ codes, which may break clients, or I have to wait until libassuan removes ASSUAN_ codes completely forcing libassuan users to use GPG_ERR_ codes, which seems unlikely to happen any time soon? > Frankly, I do not understand why there is a dummy read in that place > anyway. Comparing this with the code in assuan-buffer.c, where there Maybe to flush the input? > is no dummy read after sending the END command (this is the code path > taken if there is an inquire callback), the dummy read does not seem > to be necessary, in fact, in my opinion it could be downright harmful. > OTOH, as there is an error code returned by assuan_transact, one could > argue that the connection is in a messed up state anyway at that point > due to the missing inquire callback. The code may be designed to > salvage from the connection whatever is possible. But, this fails if > for example after sending END and doing a dummy read the server > command is still not yet finished. > > It seems to me the right way to fix this is to send a CANCEL instead > or following the END. > > 2) However, the function _assuan_read_from_server is also used in two > other places in libassuan, where an error could also be returned due > to a missing handshake. In this case, the return code could be > useful. I think it is reasonable to assume that it is a gpg error or > assuan error code at that point, because the low-level handshake > protocol is defined by assuan and we control the sender and receiver > side for this. In fact, we can always just return whatever ERR number > is provided by the server: assuan_error_t is defined in that way (some > values are reserved for the assuan protocol, the rest is free. We > recently introduced support for gpg-error numbers, which makes things > a bit more delicate, but I am willing to ignore this complication for > the sake of discussion :). Heh. This is the main problem I've having. The ERR returned from the server isn't known to be ASSUAN_ or GPG_ERR_. If all servers used GPG_ERR, it'd fix things for me. Or maybe just all clients that use pinentry after patching it. > So, I think I would still like to apply your patch, although it should > not make any difference in the scenario you describe. Plus, I would > like to replace the dummy read and possibly (if it works) the sending > of END by a sending of CANCEL. If CANCEL is used, wouldn't the INQUIRE on the server end not succeed (OK response) if all went well? -- Benjamin J. Kibbey bjk at luxsci.net/jabber/freenode 3019 F5FC AA33 5BC7 BE9F 09D2 393E DBD2 40D5 FA7E From rwillmer at gmail.com Mon Dec 10 15:50:15 2007 From: rwillmer at gmail.com (Rachel Willmer) Date: Mon, 10 Dec 2007 14:50:15 +0000 Subject: Clearsigned text / OpenPGP interop Message-ID: <5cd112870712100650qc93f73doa4ae1fef771556d1@mail.gmail.com> Hi I wonder if someone could point me in the right direction. I'm using GPG to generate a clearsigned text message (V4 sig, SHA1 hash) which I'd like to validate using OpenPGP::SDK. The test is currently failing, and I'm a bit confused about what GPG is actually hashing. In the GPG function hash_sigversion_to_magic(), it's hashing the signature sub-packet as I'd expect, but then at the end of the function, there's this: /* add some magic */ buf[0] = sig->version; buf[1] = 0xff; buf[2] = n >> 24; /* hmmm, n is only 16 bit, so this is always 0 */ buf[3] = n >> 16; buf[4] = n >> 8; buf[5] = n; md_write (md, buf, 6); I can't figure how this matches up to the OpenPGP spec. So if anyone can help with the following questions, I'd appreciate it: a) Am I just missing something obvious in the RFC? If so, please point me at it! b) Or, do I need to do something special to make gpg generate OpenPGP-compliant packets? (I'm using --openpgp but is there something else?) c) or is gpg just not intended to be openpgp-compliant for V4 sigs? thanks for any light you can shed, Rachel From dshaw at jabberwocky.com Mon Dec 10 16:01:36 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 10 Dec 2007 10:01:36 -0500 Subject: Clearsigned text / OpenPGP interop In-Reply-To: <5cd112870712100650qc93f73doa4ae1fef771556d1@mail.gmail.com> References: <5cd112870712100650qc93f73doa4ae1fef771556d1@mail.gmail.com> Message-ID: <20071210150135.GA6769@jabberwocky.com> On Mon, Dec 10, 2007 at 02:50:15PM +0000, Rachel Willmer wrote: > Hi > > I wonder if someone could point me in the right direction. > > I'm using GPG to generate a clearsigned text message (V4 sig, SHA1 > hash) which I'd like to validate using OpenPGP::SDK. The test is > currently failing, and I'm a bit confused about what GPG is actually > hashing. > > In the GPG function hash_sigversion_to_magic(), it's hashing the > signature sub-packet as I'd expect, but then at the end of the > function, there's this: > > > /* add some magic */ > buf[0] = sig->version; > buf[1] = 0xff; > buf[2] = n >> 24; /* hmmm, n is only 16 bit, so this is always 0 */ > buf[3] = n >> 16; > buf[4] = n >> 8; > buf[5] = n; > md_write (md, buf, 6); > > > I can't figure how this matches up to the OpenPGP spec. > > So if anyone can help with the following questions, I'd appreciate it: > > a) Am I just missing something obvious in the RFC? If so, please > point me at it! The above magic comes from section 5.2.4 in RFC-4880. Specifically: V4 signatures also hash in a final trailer of six octets: the version of the Signature packet, i.e., 0x04; 0xFF; and a four-octet, big-endian number that is the length of the hashed data from the Signature packet (note that this number does not include these final six octets). > b) Or, do I need to do something special to make gpg generate > OpenPGP-compliant packets? (I'm using --openpgp but is there something > else?) Nothing special. You have to go pretty far out of your way to make GPG violate OpenPGP, and it usually complains about doing it. David From rwillmer at gmail.com Mon Dec 10 13:50:11 2007 From: rwillmer at gmail.com (Rachel Willmer) Date: Mon, 10 Dec 2007 12:50:11 +0000 Subject: Clearsigned text / OpenPGP interop Message-ID: <5cd112870712100450v189b5eceib0811a117c28b400@mail.gmail.com> Hi I wonder if someone could point me in the right direction. I'm using GPG to generate a clearsigned text message (V4 sig, SHA1 hash) which I'd like to validate using OpenPGP::SDK. The test is currently failing, and I'm a bit confused about what GPG is actually hashing. In the GPG function hash_sigversion_to_magic(), it's hashing the signature sub-packet as I'd expect, but then at the end of the function, there's this: /* add some magic */ buf[0] = sig->version; buf[1] = 0xff; buf[2] = n >> 24; /* hmmm, n is only 16 bit, so this is always 0 */ buf[3] = n >> 16; buf[4] = n >> 8; buf[5] = n; md_write (md, buf, 6); I can't figure how this matches up to the OpenPGP spec. So if anyone can help with the following questions, I'd appreciate it: a) Am I just missing something obvious in the RFC? If so, please point me at it! b) Or, do I need to do something special to make gpg generate OpenPGP-compliant packets? (I'm using --openpgp but is there something else?) c) or is gpg just not intended to be openpgp-compliant for V4 sigs? thanks for any light you can shed, Rachel From rwillmer at gmail.com Mon Dec 10 16:10:55 2007 From: rwillmer at gmail.com (Rachel Willmer) Date: Mon, 10 Dec 2007 15:10:55 +0000 Subject: Clearsigned text / OpenPGP interop In-Reply-To: <20071210150135.GA6769@jabberwocky.com> References: <5cd112870712100650qc93f73doa4ae1fef771556d1@mail.gmail.com> <20071210150135.GA6769@jabberwocky.com> Message-ID: <5cd112870712100710u3536efd4ob9abbab413d634b@mail.gmail.com> On 10/12/2007, David Shaw wrote: > > a) Am I just missing something obvious in the RFC? If so, please > > point me at it! > > The above magic comes from section 5.2.4 in RFC-4880. Specifically: Thanks! I have read that section over and over again, how did I come to miss that!! > Nothing special. You have to go pretty far out of your way to make > GPG violate OpenPGP, and it usually complains about doing it. Yes, that's what I thought. Thanks again for your quick reply Rachel From wk at gnupg.org Mon Dec 10 20:01:06 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 10 Dec 2007 20:01:06 +0100 Subject: [Announce] Libgcrypt 1.4.0 (stable) released Message-ID: <87y7c2ml1p.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of Libgcrypt 1.4.0. This is the new stable version of Libgcrypt and upward compatible with the 1.2 series. The 1.2 series will enter end of life state in 2 years on 2009-12-31. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes between 1.2.x and 1.4.0 are: * Support for SHA-224 and HMAC using SHA-384 and SHA-512. * Support for the SEED cipher. * Support for the Camellia cipher. * Support for OFB encryption mode. * Support for DSA2. * Support for Microsoft Windows. * The entire library is now under the LGPLv2+. The helper programs and the manual are under the GPLv2+. Kudos to Peter Gutmann for giving permissions to relicense the rndw32 and rndunix modules. * The visibility attribute is now used if supported by the toolchain. * The ACE engine of VIA processors is now used for AES-128. * Changed the way the RNG gets initialized. This allows to keep it uninitialized as long as no random numbers are used. * Updated the entropy gatherer for W32. * Made the RNG immune against fork without exec. * Reading and writing the random seed file is now protected by a fcntl style file lock on systems that provide this function. * gcry_mpi_rshift does not anymore truncate the shift count. * Reserved algorithm ranges for use by applications. * The new function gcry_md_debug should be used instead of the gcry_md_start_debug and gcry_md_stop_debug macros. * Non executable stack support is now used by default on systems supporting it. * Assembler support for the AMD64 architecture. * New configure option --enable-mpi-path for optimized builds. * Fixed a bug in the detection of symbol prefixes which inhibited the build of optimized assembler code on certain systems. * New control code GCRYCTL_PRINT_CONFIG to print the build configuration. * Experimental support for ECDSA; should only be used for testing. * New configure option --enable-random-daemon to support a system wide random daemon. The daemon code is experimental and not yet very well working. It will eventually allow to keep a global random pool for the sake of short living processes. * Minor changes to some function declarations. Buffer arguments are now typed as void pointer. This should not affect any compilation. Fixed two bugs in return values and clarified documentation. * Interface changes relative to the 1.2.0 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gcry_fast_random_pol NEW. gcry_md_debug NEW. gcry_sexp_nth_string NEW. GCRY_MD_SHA224 NEW. GCRY_PK_USAGE_CERT NEW. GCRY_PK_USAGE_AUTH NEW. GCRY_PK_USAGE_UNKN NEW. GCRY_PK_ECDSA NEW. GCRY_CIPHER_SEED NEW. GCRY_CIPHER_CAMELLIA128 NEW. GCRY_CIPHER_CAMELLIA192 NEW. GCRY_CIPHER_CAMELLIA256 NEW. GCRYCTL_FAKED_RANDOM_P NEW. GCRYCTL_PRINT_CONFIG NEW. GCRYCTL_SET_RNDEGD_SOCKET NEW. gcry_mpi_scan CHANGED: Argument BUFFER is now void*. gcry_pk_algo_name CHANGED: Returns "?" instead of NULL. gcry_cipher_algo_name CHANGED: Returns "?" instead of "". gcry_pk_spec_t CHANGED: Element ALIASES is now const ptr. gcry_md_write_t CHANGED: Argument BUF is now a const void*. gcry_md_ctl CHANGED: Argument BUFFER is now void*. gcry_cipher_encrypt CHANGED: Arguments IN and OUT are now void*. gcry_cipher_decrypt CHANGED: Arguments IN and OUT are now void*. gcry_sexp_sprint CHANGED: Argument BUFFER is now void*. gcry_create_nonce CHANGED: Argument BUFFER is now void*. gcry_randomize CHANGED: Argument BUFFER is now void*. gcry_cipher_register CHANGED: Argument ALGORITHM_ID is now int*. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source file and its digital signatures is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.0.tar.bz2 (942k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.0.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.0.tar.gz (1176k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.0.tar.gz.sig The SHA-1 checksums are: cd1b52e8ecfa361737c6f130ed2f1d850e312c16 libgcrypt-1.4.0.tar.bz2 69183b7100b60da8eb1648f49836a611454541bb libgcrypt-1.4.0.tar.gz For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. Improving Libgcrypt is costly, but you can help! We are looking for organizations that find Libgcrypt useful and wish to contribute back. You can contribute by reporting bugs, improve the software [2], or by donating money. Commercial support contracts for Libgcrypt are available [3], and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company, is currently funding Libgcrypt development. We are always looking for interesting development projects. Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] See http://www.gnupg.org/documentation/mailing-lists.html . [2] Note that copyright assignments to the FSF are required. [3] See the service directory at http://www.gnupg.org/service.html . -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available Url : /pipermail/attachments/20071210/e4ccd64b/attachment-0001.pgp -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From rjh at sixdemonbag.org Tue Dec 11 13:59:59 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 11 Dec 2007 06:59:59 -0600 Subject: libgpg-error and gpgme: GPLed or LGPLed? Message-ID: <475E89CF.8030606@sixdemonbag.org> libgpg-error and gpgme appear to be ambiguously licensed. The COPYING file in the source tree is the GPL, but the comments at the top of, e.g., src/mkerrorcodes.c suggest that libgpg-error is meant to be distributed under terms of the LGPL. It would probably be a good idea to bring the COPYING file(s) in sync with the license information in the source code. From wk at gnupg.org Tue Dec 11 14:22:55 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Dec 2007 14:22:55 +0100 Subject: libgpg-error and gpgme: GPLed or LGPLed? In-Reply-To: <475E89CF.8030606@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 11 Dec 2007 06:59:59 -0600") References: <475E89CF.8030606@sixdemonbag.org> Message-ID: <87r6htgyc0.fsf@wheatstone.g10code.de> On Tue, 11 Dec 2007 13:59, rjh at sixdemonbag.org said: > libgpg-error and gpgme appear to be ambiguously licensed. The COPYING > file in the source tree is the GPL, but the comments at the top of, > e.g., src/mkerrorcodes.c suggest that libgpg-error is meant to be > distributed under terms of the LGPL. Libgpg-error is under trhe LGPLv2.1+ but some internal build tools are under the GPL. From the README: libgpg-error is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. See the file COPYING.LIB for copyright and warranty information. However, some files (for example src/mkerrnos.awk) used in the build process of the library are covered by a different license. Please see the header of these files and the file COPYING for copyright and warranty information on these files. A special exception in the copyright license of these files makes sure that the output in the build process, which is used in libgpg-error, is not affected by the GPL. I have made sure that COPYING.LIB and COPYING are both distributed. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Tue Dec 11 14:34:26 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue, 11 Dec 2007 14:34:26 +0100 Subject: libgpg-error and gpgme: GPLed or LGPLed? In-Reply-To: <475E89CF.8030606@sixdemonbag.org> References: <475E89CF.8030606@sixdemonbag.org> Message-ID: <87d4td8ie5.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 11 Dec 2007 06:59:59 -0600, "Robert J. Hansen" wrote: > > libgpg-error and gpgme appear to be ambiguously licensed. The COPYING > file in the source tree is the GPL, but the comments at the top of, > e.g., src/mkerrorcodes.c suggest that libgpg-error is meant to be > distributed under terms of the LGPL. > > It would probably be a good idea to bring the COPYING file(s) in sync > with the license information in the source code. The COPYING file always contains the GPL. The LGPL is always contained in the COPYING.LESSER (aka COPYING.LIB) file. These are license texts, but they are not(!) copyright notices. The copyright notices for libgpg-error and gpgme are in the README file and, more importantly, in each individual file. We use many licenses in our packages: The GPL for build tools (in libgpg-error), with a "output is not restricted" exception a la autoconf. The LGPL for the main code that ends up in the binaries. A very liberal "attribution only" license for some text files like changelogs. The README gives a summary of the situation for the whole package, but it is to be read as a statement of intent and overview. I checked the READMEs of GPGME and libgpg-error and though they are different in style and extent, they seem to be accurate. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Wed Dec 12 15:47:18 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed, 12 Dec 2007 15:47:18 +0100 Subject: assuan_read_from_server() and return value In-Reply-To: <200712081745.lB8Hj2rF001140@rs41.luxsci.com> References: <200711231902.lANJ22OU007693@rs41.luxsci.com> <87fxyjaksq.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200712081745.lB8Hj2rF001140@rs41.luxsci.com> Message-ID: <87mysgug09.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sat, 8 Dec 2007 12:44:21 -0500, Ben Kibbey wrote: > > On Mon, Dec 03, 2007 at 03:56:53PM +0100, Marcus Brinkmann wrote: > > Hi Ben, > > > > there seem to be separate issues here: > > > > 1) It seems to me that the case you describe can only happen if you > > have no inquire callback set, right? In this case, the error code is > > going to be overwritten by assuan_transact anyway. > > After the inquire callback is finished, assuan_transact() sends END to > terminate the inquire then calls _assuan_read_from_server() again. Are you sure? That's not my reading of the code: assuan-client.c::assuan_transact() [...] if (!inquire_cb) { assuan_write_line (ctx, "END"); /* get out of inquire mode */ _assuan_read_from_server (ctx, &okay, &off); /* dummy read */ rc = _assuan_error (ASSUAN_No_Inquire_Callback); } else { rc = inquire_cb (inquire_cb_arg, line); if (!rc) rc = assuan_send_data (ctx, NULL, 0); /* flush and send END */ if (!rc) goto again; } The code path "END" followed by _assuan_read_from_server is only invoked if "!inquire_cb" that means "inquire_cb == NULL". Otherwise, the inquire_cb is invoked. Are you sure you have a callback function set up? > On the server end, an error may have occured while processing the inquired > data which may return an error code which is not guaranteed to be an > ASSUAN_ error code. Right. > Without the patch, _assuan_read_from_server() > returns the value returned from _assuan_read_line() (zero). I use > GPG_ERR codes on the server. Pinentry uses ASSUAN_ errors and there is > no way to tell if the error is an GPG_ERR_ or an ASSUAN_ error. Not quite correct. We have a heuristic to differentiate: Values that have the high bits set indicate a gpg error with a source set. All our servers set a gpg error source. On the other hand, low values indicate an assuan based error code. This is not failure proof, but covers current and expected usage. By the way: It is currently undefined how assuan error codes can be extended by user defined error codes. In gpg-error, there are reserved values for that. > So I > guess pinentry has to migrate to use GPG_ERR_ codes, which may break > clients, or I have to wait until libassuan removes ASSUAN_ codes > completely forcing libassuan users to use GPG_ERR_ codes, which seems > unlikely to happen any time soon? We can map assuan error codes to gpg error codes (see the function _assuan_error in mkerrors). However, I want to clear up the following issues: Why you actually encounter this code path (it seems you should have an inquire cb but don't), and if sending END and reading from the server is the right thing to do anyway. > > Frankly, I do not understand why there is a dummy read in that place > > anyway. Comparing this with the code in assuan-buffer.c, where there > > Maybe to flush the input? Nah, that function doesn't flush. I think it is simply to receive the status code of the command which caused the inquire, to try to push the server into a state where it will receive a new command. But that is not a failsafe way to do that. > > So, I think I would still like to apply your patch, although it should > > not make any difference in the scenario you describe. Plus, I would > > like to replace the dummy read and possibly (if it works) the sending > > of END by a sending of CANCEL. > > If CANCEL is used, wouldn't the INQUIRE on the server end not succeed > (OK response) if all went well? At that point in the code path, the client already will get an error because of a missing inquire callback function. It seems to me that canceling the pending operation is then the right response. Thanks, Marcus From wk at gnupg.org Wed Dec 12 17:27:16 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 12 Dec 2007 17:27:16 +0100 Subject: libassuan 1.0.4 released Message-ID: <87k5nj515n.fsf@wheatstone.g10code.de> Hi, for those of you who tried to build the current GnuPG-2 SVN versions, life is mow a little bit easier because there is no more need to also build libassuan from SVN ;-) I have just released version 1.0.4: ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-1.0.4.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-1.0.4.tar.bz2.sig The primary reason why we need this version for GnuPG-2 are the new socket wrapper fucntions: It is sometimes useful to support Unix domain sockets on Windows. To do this in a portable way, Assuan provides a set of wrapper functions which may be used on any system but will enhance Windows to support these socket types. The actual implementation is based on local TCP sockets and fully transparent for the client. Server code needs to utilize two extra functions to check the permissions. -- Function: int assuan_sock_close (assuan_fd_t FD) Wrapper for close which does a closesocket on Windows if needed. -- Function: assuan_fd_t assuan_sock_new (int DOMAIN, int TYPE, int PROTO); Wrapper around socket. -- Function: int assuan_sock_connect (assuan_fd_t SOCKFD, struct sockaddr *ADDR, int ADDRLEN) Wrapper around connect. For Unix domain sockets under Windows this function also does a write immediatley after the the connect to send the nonce as read from the socket's file. -- Function: int assuan_sock_bind ( assuan_fd_t SOCKFD, struct sockaddr *ADDR, int ADDRLEN) Wrapper around bind. Under Windows this creates a file and writes the port number and a random nonce to this file. -- Function: int assuan_sock_get_nonce ( struct sockaddr *ADDR, int ADDRLEN, assuan_sock_nonce_t *NONCE) This is used by the server after a bind to return the random nonce. To keep the code readable this may also be used on POSIX system. -- Function: int assuan_sock_check_nonce ( assuan_fd_t FD, assuan_sock_nonce_t *NONCE) On Windows this is used by the server after an accept to read the nonce from the client and compare it with the saved NONCE. If this function fails the server should immediatly drop the connection. To keep the code readable this may also be used on POSIX system; it is a dummy function then. See also `assuan_set_sock_nonce'. BTW, the release of 2.0.8 is scheduled for Friday. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Thu Dec 13 19:54:23 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu, 13 Dec 2007 19:54:23 +0100 Subject: assuan_read_from_server() and return value In-Reply-To: <87mysgug09.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200711231902.lANJ22OU007693@rs41.luxsci.com> <87fxyjaksq.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200712081745.lB8Hj2rF001140@rs41.luxsci.com> <87mysgug09.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <87ejdqv31c.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Wed, 12 Dec 2007 15:47:18 +0100, Marcus Brinkmann wrote: > However, I want to clear up the following issues: Why you actually > encounter this code path (it seems you should have an inquire cb but > don't), and if sending END and reading from the server is the right > thing to do anyway. Werner points out that gpg-connect-agent sends CANCEL when an inquire without a handler is encountered. This seems to support my idea to do the same in libassuan if no callback handler is registered. But there is a related issue documented in the source code, see dirmngr-client.c and the TODO item in libassuan. Dirmngr client returns an error instead of sending CANCEL upon seeing an unknown inquire, causing assuan_transact to send END. We need to properly specify what should happen and make sure that we don't break anything. I'll see what I can come up with. Thanks, Marcus From wk at gnupg.org Fri Dec 14 14:35:45 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 14 Dec 2007 14:35:45 +0100 Subject: [Announce] GnuPG: second release candidate for 1.4.8 Message-ID: <87wsrhtn4e.fsf@wheatstone.g10code.de> Hi, I just uploaded a second release candidate for GnuPG 1.4.8: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.8rc2.tar.bz2 ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.8rc2.tar.bz2.sig If you have problems with 1.4.7, you may want to give it a try. Those who reported build problems should also try to build that one and report if the problems persist (to the gnupg-users ML). Note that the language files are not all updated and our translators may want to check whether they find time to send an update in. There are certainly a couple of bugs not yet fixed as we had not the time to work through all bug reports, please complain if there are important things still not resolved. The actual release of 1.4.8 is planned for December 20. Noteworthy changes since the last release candidate --------------------------------------------------- * Allow encryption using legacy Elgamal sign+encrypt keys if option --rfc2440 is used. * Fixed the auto creation of the key stub for smartcards. * Fixed a rare bug in decryption using the OpenPGP card. * Fix RFC-4880 typo in the SHA-224 hash prefix. Old SHA-224 signatures will continue to work. Happy hacking, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available Url : /pipermail/attachments/20071214/5e5e14f9/attachment.pgp -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Fri Dec 14 17:26:04 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 14 Dec 2007 17:26:04 +0100 Subject: [Announce] Here comes the release candidate for GnuPG 2.0.8 Message-ID: <87tzmls0o3.fsf@wheatstone.g10code.de> Hi, I just uploaded a release candidate for GnuPG 2.0.8: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-2.0.8rc1.tar.bz2 ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-2.0.8rc1.tar.bz2.sig Note that the language files are not all updated and our translators may want to check whether they find time to send an update in. There are certainly a couple of bugs not yet fixed as we had not the time to work through all bug reports, please complain if there are important things still not resolved. The actual release of 2.0.8 is also planned for December 20. Noteworthy changes since 2.0.7 ------------------------------ * Make sure that under Windows the file permissions of the socket are taken into account. This required a change of our socket emulation code; thus old GnuPG modules can't be used anymore. * Fixed a crash in gpgconf. * Enhanced gpg-connect-agent with a small scripting language. * New option --list-config for gpgconf. * The envvars XAUTHORITY and PINENTRY_USER_DATA are now passed to the pinentry. * Allow encryption with legacy Elgamal sign+encrypt keys with option --rfc2440. * Fixed the auto creation of the key stub for smartcards. * Fixed a rare bug in decryption using the OpenPGP card. * Creating DSA2 keys is now possible. * New option --extra-digest-algo for gpgsm to allow verification of broken signatures. Note: You need the current version of libassuan (1.0.4) to build this. Happy hacking, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available Url : /pipermail/attachments/20071214/7e220758/attachment-0001.pgp -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From brad at 16systems.com Wed Dec 12 01:23:03 2007 From: brad at 16systems.com (Brad Tilley) Date: Tue, 11 Dec 2007 19:23:03 -0500 Subject: Frontend for GPG Message-ID: <3ac86fa70712111623wd83e701vd07440a6966dde65@mail.gmail.com> I'm writing a quick frontend to gpg (cross-platform... Win, Lin, Unix & Mac in Python) just for the --symmetric function, but may some day grow to do more. Are there any docs that describe a programmatic interface to gpg or how to go about this sort of thing with a os.system and/or os.popen library? Thanks for any advice, Brad From rjh at sixdemonbag.org Sat Dec 15 16:14:01 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 15 Dec 2007 09:14:01 -0600 Subject: Frontend for GPG In-Reply-To: <3ac86fa70712111623wd83e701vd07440a6966dde65@mail.gmail.com> References: <3ac86fa70712111623wd83e701vd07440a6966dde65@mail.gmail.com> Message-ID: <4763EF39.2000900@sixdemonbag.org> Brad Tilley wrote: > I'm writing a quick frontend to gpg (cross-platform... Win, Lin, Unix > & Mac in Python) just for the --symmetric function, but may some day > grow to do more. Are there any docs that describe a programmatic > interface to gpg or how to go about this sort of thing with a > os.system and/or os.popen library? As a word of warning, do not expect it to work reliably under Windows. There appears to be a bug with I/O redirection--or, at least, there was; I haven't tested with 1.4.7 or 1.4.8 to see if it's still there. See: http://lists.gnupg.org/pipermail/gnupg-devel/2006-April/022832.html I have run into this problem with Python, Java and C#, so I doubt that it's a bug in either my code or my virtual machine implementation. I don't want to point the finger at GnuPG, however, given that Win32 has a long history of wacky bugs. From bjk at luxsci.net Sat Dec 15 18:32:00 2007 From: bjk at luxsci.net (Ben Kibbey) Date: Sat, 15 Dec 2007 12:32:00 -0500 Subject: assuan_read_from_server() and return value In-Reply-To: <87mysgug09.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200711231902.lANJ22OU007693@rs41.luxsci.com> <87fxyjaksq.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200712081745.lB8Hj2rF001140@rs41.luxsci.com> <87mysgug09.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200712151733.lBFHX2n5026146@rs41.luxsci.com> On Wed, Dec 12, 2007 at 03:47:18PM +0100, Marcus Brinkmann wrote: > > After the inquire callback is finished, assuan_transact() sends END to > > terminate the inquire then calls _assuan_read_from_server() again. > > Are you sure? That's not my reading of the code: > > assuan-client.c::assuan_transact() > [...] > > if (!inquire_cb) > { > assuan_write_line (ctx, "END"); /* get out of inquire mode */ > _assuan_read_from_server (ctx, &okay, &off); /* dummy read */ > rc = _assuan_error (ASSUAN_No_Inquire_Callback); > } > else > { > rc = inquire_cb (inquire_cb_arg, line); > if (!rc) > rc = assuan_send_data (ctx, NULL, 0); /* flush and send END */ > if (!rc) > goto again; > } I do have an inquire callback set. I was referring to the END sent from assuan_send_data(). Then _assuan_read_from_server() is called to get the error code (if any) of the inquire (with my patch applied). > > Without the patch, _assuan_read_from_server() > > returns the value returned from _assuan_read_line() (zero). I use > > GPG_ERR codes on the server. Pinentry uses ASSUAN_ errors and there is > > no way to tell if the error is an GPG_ERR_ or an ASSUAN_ error. > > Not quite correct. We have a heuristic to differentiate: Values that > have the high bits set indicate a gpg error with a source set. All > our servers set a gpg error source. On the other hand, low values > indicate an assuan based error code. This is not failure proof, but > covers current and expected usage. By the way: It is currently > undefined how assuan error codes can be extended by user defined error > codes. In gpg-error, there are reserved values for that. Breaks when GPG_ERR_SOURCE_UNKNOWN is used, and this is the default. > > > So I > > guess pinentry has to migrate to use GPG_ERR_ codes, which may break > > clients, or I have to wait until libassuan removes ASSUAN_ codes > > completely forcing libassuan users to use GPG_ERR_ codes, which seems > > unlikely to happen any time soon? > > We can map assuan error codes to gpg error codes (see the function > _assuan_error in mkerrors). Has the error source problem above. I have rewritten my app to handle pinentry specially, although it will break when pinentry uses gpg-error codes. But I still need the patch applied in order to get any inquire error code from the server. -- Benjamin J. Kibbey bjk at luxsci.net/jabber/freenode 3019 F5FC AA33 5BC7 BE9F 09D2 393E DBD2 40D5 FA7E From bjk at luxsci.net Sat Dec 15 18:33:10 2007 From: bjk at luxsci.net (Ben Kibbey) Date: Sat, 15 Dec 2007 12:33:10 -0500 Subject: assuan external loop over socket In-Reply-To: <87eje3aka2.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200710251400.l9PE05WX010150@rs19.luxsci.com> <87myu6xap6.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200712021750.lB2Ho2Wg013657@rs41.luxsci.com> <87eje3aka2.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200712151734.lBFHY2UD027812@rs41.luxsci.com> On Mon, Dec 03, 2007 at 04:08:05PM +0100, Marcus Brinkmann wrote: > Allow me to ask for a clarification: You want to read status messages > *while* you have an inquire operation ongoing? Normally, assuan > servers do not send status messages while they are receiving inquire > data. I have never considered this possibility. It seems overly complex. Yeah, this is what I meant, but it's not crucial. I did find another use in my app for external IO over a socket, so the sooner this feature can get added, the better. :) Thanks, -- Benjamin J. Kibbey bjk at luxsci.net/jabber/freenode 3019 F5FC AA33 5BC7 BE9F 09D2 393E DBD2 40D5 FA7E From JPClizbe at tx.rr.com Sun Dec 16 02:46:19 2007 From: JPClizbe at tx.rr.com (John Clizbe) Date: Sat, 15 Dec 2007 19:46:19 -0600 Subject: LDAPS configure error on Windows Message-ID: <4764836B.3050908@tx.rr.com> configure's check for ldap_start_tls_s fails on Win32 even though the function is defined and exists. The problem stems from Windows support two versions of most functions, one for wide chars (UNICODE) and a default (ANSI). checking whether LDAP via "-lwldap32" is present and sane... yes checking for ldap_get_option... yes checking for ldap_set_option... yes checking for ldap_start_tls_s... no From winldap.h #ifdef UNICODE #define ldap_start_tls_s ldap_start_tls_sW #else #define ldap_start_tls_s ldap_start_tls_sA #endif Sorry I don't know enough autotools to offer a patch, but it would seem that inserting the snippet #ifdef _WIN32 #define ldap_start_tls_s ldap_start_tls_sA #endif would modify behavior enough for the link to succeed. For now I'll just continue patching config.h -- John P. Clizbe Inet: JPClizbe(a) tx DAWT rr DAHT con Ginger Bear Networks keyserver hkp://keyserver.gingerbear.net "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: 677 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20071215/b0887d98/attachment.pgp From marcus.brinkmann at ruhr-uni-bochum.de Mon Dec 17 17:00:31 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 17 Dec 2007 17:00:31 +0100 Subject: assuan external loop over socket In-Reply-To: <200712151734.lBFHY2UD027812@rs41.luxsci.com> References: <200710251400.l9PE05WX010150@rs19.luxsci.com> <87myu6xap6.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200712021750.lB2Ho2Wg013657@rs41.luxsci.com> <87eje3aka2.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200712151734.lBFHY2UD027812@rs41.luxsci.com> Message-ID: <878x3tqpjz.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sat, 15 Dec 2007 12:33:10 -0500, Ben Kibbey wrote: > > On Mon, Dec 03, 2007 at 04:08:05PM +0100, Marcus Brinkmann wrote: > > Allow me to ask for a clarification: You want to read status messages > > *while* you have an inquire operation ongoing? Normally, assuan > > servers do not send status messages while they are receiving inquire > > data. I have never considered this possibility. It seems overly complex. > > Yeah, this is what I meant, but it's not crucial. It's also outside of the Assuan protocol "as intended". :) So, if we can discard this use case, we can make the following discussion simpler. Otherwise, we should discuss the situation with and without this use case separately. > I did find another use > in my app for external IO over a socket, so the sooner this feature can > get added, the better. :) Did you consider not using assuan_transact for asynchronous operations a la GPGME? Even if this is not the best solution, it would help me if you could say that doing so would address your use case completely, or if you see other interfaces to be affected. Thanks, Marcus From wk at gnupg.org Thu Dec 20 10:40:28 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Dec 2007 10:40:28 +0100 Subject: [Announce] GnuPG 1.4.8 released Message-ID: <8763ytd7qr.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-1 release: Version 1.4.8. This is GnuPG's 10th birthday celebration release. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility, samrtcard support and is compliant with the OpenPGP Internet standard as described by RFC-4880 (the recently released update of RFC-2440). Note that this version is from the GnuPG-1 series and thus smaller than those from the GnuPG-2 series, easier to build and also better portable. In contrast to GnuPG-2 (e.g version 2.0.8) it comes with no support for S/MIME or other tools useful for desktop environments. Fortunately you may install both versions alongside on the same system without any conflict. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 1.4.8 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the following files in the *gnupg* directory: gnupg-1.4.8.tar.bz2 (3242k) gnupg-1.4.8.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.4.8.tar.gz (4550k) gnupg-1.4.8.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.4.7-1.4.8.diff.bz2 (330k) A patch file to upgrade a 1.4.7 GnuPG source. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. In the *binary* directory, you should find these files: gnupg-w32cli-1.4.8.exe (2117k) gnupg-w32cli-1.4.8.exe.sig GnuPG compiled for Microsoft Windows and OpenPGP signature. This is a command line only version; the source files are the same as given above. Note, that this is a minimal installer and unless you are just in need for the gpg binary, you are better off using the full featured installer at http://www.gpg4win.org . A new version of Gpg4win, including this version of GnuPG will be available and announced soon. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.4.8.tar.bz2 you would use this command: gpg --verify gnupg-1.4.8.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a keyserver like gpg --recv-key 1CE0C630 The distribution key 1CE0C630 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-1.4.8.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-1.4.8.tar.bz2 and check that the output matches the second line from the following list: 29803a37645493104b239247505418f9c5bedd88 gnupg-1.4.8.tar.gz 4b63267358e5c70f05b48e27d6877bad2636cabd gnupg-1.4.8.tar.bz2 e69d50a34c9f8d80aca366494228e2be0e8c641b gnupg-1.4.7-1.4.8.diff.bz2 6ef3f9ba7a36ad1da53a02a8733bf77bc5305587 gnupg-w32cli-1.4.8.exe What's New =========== * Changed the license to GPLv3. * Improved detection of keyrings specified multiple times. * Changes to better cope with broken keyservers. * Minor bug fixes. * The new OpenPGP standard is now complete, and has been published as RFC-4880. The GnuPG --openpgp mode (note this is not the default) has been updated to match the new standard. The --rfc2440 option can be used to return to the older RFC-2440 behavior. The main differences between the two are "--enable-dsa2 --no-rfc2440-text --escape-from-lines --require-cross-certification". * By default (i.e. --gnupg mode), --require-cross-certification is now on. --rfc2440-text and --force-v3-sigs are now off. * Allow encryption using legacy Elgamal sign+encrypt keys if option --rfc2440 is used. * Fixed the auto creation of the key stub for smartcards. * Fixed a rare bug in decryption using the OpenPGP card. * Fix RFC-4880 typo in the SHA-224 hash prefix. Old SHA-224 signatures will continue to work. Internationalization ==================== GnuPG comes with support for 28 languages. Due to a lot of new and changed strings some translations are not entirely complete. The Chinese (Simple and Traditional), Czech, Dutch, French, German, Norwegian, Polish, Romanian, Russian, Spanish, Swedish and Turkish translations are close to be complete. Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, order extensions or support or more general by donating money to the Free Software movement (e.g. http://www.fsfeurope.org/help/donate.en.html). Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by gpg's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. A service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team (David, Werner and the other contributors) -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20071220/ac14720e/attachment-0001.pgp -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From marcus.brinkmann at ruhr-uni-bochum.de Mon Dec 17 17:10:37 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 17 Dec 2007 17:10:37 +0100 Subject: assuan_read_from_server() and return value In-Reply-To: <200712151733.lBFHX2n5026146@rs41.luxsci.com> References: <200711231902.lANJ22OU007693@rs41.luxsci.com> <87fxyjaksq.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200712081745.lB8Hj2rF001140@rs41.luxsci.com> <87mysgug09.wl%marcus.brinkmann@ruhr-uni-bochum.de> <200712151733.lBFHX2n5026146@rs41.luxsci.com> Message-ID: <877ijdqp36.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sat, 15 Dec 2007 12:32:00 -0500, Ben Kibbey wrote: > > On Wed, Dec 12, 2007 at 03:47:18PM +0100, Marcus Brinkmann wrote: > > > After the inquire callback is finished, assuan_transact() sends END to > > > terminate the inquire then calls _assuan_read_from_server() again. > > > > Are you sure? That's not my reading of the code: > > > > assuan-client.c::assuan_transact() > > [...] > > > > if (!inquire_cb) > > { > > assuan_write_line (ctx, "END"); /* get out of inquire mode */ > > _assuan_read_from_server (ctx, &okay, &off); /* dummy read */ > > rc = _assuan_error (ASSUAN_No_Inquire_Callback); > > } > > else > > { > > rc = inquire_cb (inquire_cb_arg, line); > > if (!rc) > > rc = assuan_send_data (ctx, NULL, 0); /* flush and send END */ > > if (!rc) > > goto again; > > } > > I do have an inquire callback set. I was referring to the END sent from > assuan_send_data(). Ok. > Then _assuan_read_from_server() is called to get the > error code (if any) of the inquire (with my patch applied). Ah, so now we are talking about the _assuan_read_from_server at the "again:" label in _assuan_transact? In this case, the ERR should set OKAY to 0 and OFF to the offset of the error code, and then assuan_transact should execute: if (!okay) { rc = atoi (line); if (rc > 0 && rc < 100) rc = _assuan_error (ASSUAN_Server_Fault); else if (rc > 0 && rc <= 405) rc = _assuan_error (rc); } Thereby returning the error code as it should. Why is that code not working for you? > > > Without the patch, _assuan_read_from_server() > > > returns the value returned from _assuan_read_line() (zero). I use > > > GPG_ERR codes on the server. Pinentry uses ASSUAN_ errors and there is > > > no way to tell if the error is an GPG_ERR_ or an ASSUAN_ error. > > > > Not quite correct. We have a heuristic to differentiate: Values that > > have the high bits set indicate a gpg error with a source set. All > > our servers set a gpg error source. On the other hand, low values > > indicate an assuan based error code. This is not failure proof, but > > covers current and expected usage. By the way: It is currently > > undefined how assuan error codes can be extended by user defined error > > codes. In gpg-error, there are reserved values for that. > > Breaks when GPG_ERR_SOURCE_UNKNOWN is used, and this is the default. Yes, but sometimes the right response to "this hurts" is "don't do it then". As there is no good reason not to set the error source, it should be set if gpg-error is used. > > > So I > > > guess pinentry has to migrate to use GPG_ERR_ codes, which may break > > > clients, or I have to wait until libassuan removes ASSUAN_ codes > > > completely forcing libassuan users to use GPG_ERR_ codes, which seems > > > unlikely to happen any time soon? > > > > We can map assuan error codes to gpg error codes (see the function > > _assuan_error in mkerrors). > > Has the error source problem above. > > I have rewritten my app to handle pinentry specially, although it will > break when pinentry uses gpg-error codes. It shouldn't break if pinentry sets an error source, which it would if we modify it to use gpg-error. > But I still need the patch > applied in order to get any inquire error code from the server. I am still (by now probably even more than in the beginning) as to what the actual error case code flow is. At the risk of trying your patience here, can you walk me through it one more time? Thanks, Marcus From wk at gnupg.org Mon Dec 17 10:58:48 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 17 Dec 2007 10:58:48 +0100 Subject: LDAPS configure error on Windows In-Reply-To: <4764836B.3050908@tx.rr.com> (John Clizbe's message of "Sat, 15 Dec 2007 19:46:19 -0600") References: <4764836B.3050908@tx.rr.com> Message-ID: <87ejdlod5z.fsf@wheatstone.g10code.de> On Sun, 16 Dec 2007 02:46, JPClizbe at tx.rr.com said: > configure's check for ldap_start_tls_s fails on Win32 even though the function > is defined and exists. The problem stems from Windows support two versions of Thanks. I added autoconf support by testing for the A variant and /* Hack used for W32: ldap.m4 also tests for the ASCII version of ldap_start_tls_s because that is the actual symbol used in the library. winldap.h redefines it to our commonly used value, thus we define our usual macro here. */ #ifdef HAVE_LDAP_START_TLS_SA # ifndef HAVE_LDAP_START_TLS_S # define HAVE_LDAP_START_TLS_S 1 # endif #endif I did this for GnuPG-1, GnuPG-2 and Dirmngr. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Dec 20 10:55:16 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Dec 2007 10:55:16 +0100 Subject: [Announce] GnuPG's 10th birthday Message-ID: <87tzmdbshn.fsf@wheatstone.g10code.de> A Short History of the GNU Privacy Guard ======================================== It's been a decade now that the very first version of the GNU Privacy Guard [0] has been released. This very first version was not yet known under the name of GnuPG but dubbed "g10" as a reference on the German constitution article on freedom of telecommunication (Grundgesetz Artikel 10) and as a pun on the G-10 law which allows the secret services to bypass these constitutional guaranteed freedoms. Version 0.0.0 released on December 20th 1997 [1], was a barely working replacement of PGP avoiding all patented algorithm by using Elgamal and Blowfish instead of RSA and IDEA. It was prominently marked as a test version but nevertheless included most of the features of the current GnuPG. The data format however was not compatible with OpenPGP but oriented towards the PGP 2 format with a few extensions (e.g. to allow streaming of data). The OpenPGP working group was founded back in fall 1997 and I learned a bit to late about it to build "g10" according to the then existing draft. For copyright reasons it was practically not possible to reverse engineer the format used by PGP-5, so the establishment of the OpenPGP WG was the right thing at the right time. Before talking about GnuPG we need to go some more years back in history: To help political activists Phil Zimmermann published a software called Pretty Good Privacy (PGP) in 1991. PGP was designed as an easy to use encryption tool with no backdoors and disclosed source code. PGP was indeed intended to be cryptographically strong and not just pretty good; however it had a couple of inital bugs, most of all a home designed cipher algorithm. With the availability of the source code a community of hackers (Branko Lankester, Colin Plumb, Derek Atkins, Hal Finney, Peter Gutmann and others) helped him to fix these flaws and a get a solid version 2 out. Soon after that the trouble started. As in many counties the use or export of cryptographic devices and software was also strongly restricted in the USA. Only weak cryptography was generally allowed. PGP was much stronger and due to the Usenet and the availability of FTP servers and BBSs, PGP accidently leaked out of the country and soon Phil was sued for unlicensed munitions export. Those export control laws were not quite up to the age of software with the funny effect that exporting the software in printed form seemed not to be restricted. MIT Press thus published a book with the PGP source code which was then scanned outside the USA to form the base of PGP-2i ("i" for international). Since then that version was used widely. The criminal investigations against Phil ended in 1996 and he founded PGP Inc to write PGP-5. The first public release was done in spring 1997. The same year at the 39th IETF meeting at Munich in August Phil Zimmermann and Jon Callas asked the IETF to setup a working group to publish a standard for the protocol used by PGP-5 under the name OpenPGP. The main drive behind this was to allow widespread use of strong encryption even if at some point the new company would decide to stop selling and supporting PGP. As it turned out PGP Inc was acquired by Network Associates just a few months later and in 2002 this company actually ceased support and development of PGP (though the PGP product was later continued by the new PGP Corporation). Also often claimed to be Free Software, PGP has never fulfilled the requirements for it: PGP-5 is straight proprietary software; the availability of the source code alonedoes not make it free. PGP-2 has certain restrictions on commercial use [2] and thus puts restrictions on the software which makes it also non-free. Another problem with PGP-2 is that it requires the use of the patented RSA and IDEA algorithms. The patent on RSA was only valid in the USA but the patent on IDEA was and is still valid [3] in most countries. Although the GNU project listed a requirement for a PGP replacement for some years on its task list, it was not possible to start implementing it as long as patents on all public key algorithms were valid. That changed when in April 1997 the basic patent on public key algorithms expired (the Diffie-Hellman US patent 4200770) and finally in August when the broader Hellman-Merkle patent (4218582) expired. A month later, at the Individual-Network Betriebstagung at Aachen [4], Richard Stallman continued his talk with a BoF session where he asked the European hackers to start implementing public key software. The arms trafficker laws of the USA prohibited the GNU project to write such software in their country or even by US citizens working abroad. Thus he told the European hackers that they are in the unique position to help the GNU with crypto software. Being tired of writing SMGL conversion software and without a current fun project, I soon found my self hacking on PGP-2 parsing code based on the description in RFC-1991 and the pgformat.txt file. As this turned out to be easy I continued and finally came up with code to decrypt and create PGP-2 data. After I told the GNU towers that I will take up the PGP replacement implementation I spent the rest of the year replacing IDEA by Blowfish, RSA by Elgamal, implementing streaming encryption, adding some key management and getting the code into a reasonable shape. There used to be a plan for a free version of Secure Shell called PSST (later known as LSH) with a somewhat populated mailing lists maintained by Martin Hamilton. Martin was the so kind to setup a mailing list for g10 too and announced it on that list. This way we got the first subscribers. Eventually I made the first tarball, put it up to ftp.guug.de, the FTP server of the German Unix User Group, and wrote an announcement [5]. Right the next day Peter Gutmann offered to allow the use of his random number code for systems without a /dev/random. This eventually helped a lot to make GnuPG portable to many platforms. The next two months were filled with code updates and a lengthly discussion on the name; we finally settled for Anand Kumria's suggestion of GnuPG and made the first release under this name (gnupg-0.2.8) on Feb 24 [6]. Just a few days later an experimental version with support for Windows was released. (That release also fixed an alignment problem on Alpha boxes which was detected due to kernel log files filling up the hard disk and an admin asking whether they really need to be backed up. ;-) In July 1998 the first more or less OpenPGP draft compliant version was released. Matthew Skala had contributed Twofish code done cleanly From scratch (Twofish was at that time a promising AES candidate and suggested by Schneier as a Blowfish replacement; however we had some copyright concerns with the reference code). Michael Roth contributed a Triple-DES implementation later the year and thus completed the required set of OpenPGP algorithms. Over the next year the usual problems were solved, features discussed, complaints noticed and support for gpg in various other software was introduced by their respective authors. Finally, on September 7, 1999 the current code was released as version 1.0.0 with the major update of including Mike Ashley's GNU Privacy Handbook [7]. A year later the RSA patent was to expire on September 20; the patent holder placed the patent into the public domain 3 weeks earlier and thus we could release 1.0.3 with RSA support already on September 18. One of the major obstacles on widespread use public cryptography had gone (far too late of course). Also in 1999 the German government decided that strong encryption will not be regulated in any way and that its use is recommended for everyone. To publicly support this statement the Ministry of Economics funded the porting of GnuPG and related software to Microsoft Windows [8]. The US government was not keen to see that and tried to urge the German government to revise the decision to allow unregulated distribution of crypto software [9]. That did not work out and to the end the USA had no other way than to weaken their own export rules. Although we still develop GnuPG using servers located in Europe the new US export controls eventually allowed US hackers to contribute to GnuPG development. In 2001 David Shaw joined the project and since then he is one of the most active GnuPG hackers and the co-maintainer. It's now a long time since GnuPG could be managed as a fun project and thus I now spend most of my professional life maintaining and extending GnuPG. In 2001 I founded g10 Code, a Free Software company for the development and support of GnuPG and related software. The most known project is probably GnuPG-2 which started under the name NewPG as part of the broader Aegypten project. The main goal of Aegypten was to provide support for S/MIME under GNU/Linux and integrate that cleanly with other mail clients, most notably KMail. Although having been actively used since 2004, we released 2.0.0 only one years ago. It was not that much fun writing X.509/CMS (commonly named S/MIME) software compared to the elegant and very interoperable OpenPGP protocol. Having mastered that we meanwhile achieved to provide a software which is really useful and works nicely with almost any other S/MIME implementation. It also turned out that we could port GnuPG-2 to Windows - despite my original claim that a modern POSIX platform will be needed for GnuPG-2. This development also showed that it is viable to develop Free Software as a business. With the new tools and from a user's perspective S/MIME and OpenPGP will soon not make much of a difference anymore. However I had to smile when I today read a report on the last RSA Europe conference where a quick poll during a talk showed that OpenPGP is the mostly used encryption protocol. Recall that GnuPG is just one tool; there are numerous other tools out to solve related privacy problems. Kudos to all who worked on writing and deploying privacy tools over all these years! Happy Hacking, Werner [0] http://www/gnupg.org [1] ftp://ftp.gnupg.org/gcrypt/historic/g10-0.0.0.tar.gz [2] from pgpdoc2.txt: "Finally, if you want to turn PGP into a commercial product and make money selling it, then we must agree on a way for me to also make money on it. [...] Under no circumstances may PGP be distributed without the PGP documentation, including this PGP User's Guide." [3] "valid" is meant in the sense the patent holders use it and does not imply that I regard patents on software a valid concept. See http://www.fsfeurope.org/projects/swpat/background.en.html . [4] http://www.dascon.de/IN-BT97/programm.html [5] http://lists.gnupg.org/pipermail/gnupg-devel/1997-December/014131.html There are just a few mails in December mainly discussing patent things. [6] http://lists.gnupg.org/pipermail/gnupg-devel/1998-February/014208.html [7] http://lists.gnupg.org/pipermail/gnupg-announce/1999q3/000037.html [8] http://partners.nytimes.com/library/tech/99/11/cyber/articles/19encrypt.html [9] http://www.heise.de/tp/r4/artikel/5/5124/1.html -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20071220/00458bad/attachment.pgp -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Thu Dec 20 10:44:54 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Dec 2007 10:44:54 +0100 Subject: [Announce] GnuPG 2.0.8 released Message-ID: <87zlw5bsyx.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.8 This is GnuPG's 10th birthday celebration release. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data, create digital signatures, help authenticating using Secure Shell and to provide a framework for public key cryptography. It includes an advanced key management facility and is compliant with the OpenPGP and S/MIME standards. GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.8) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. GnuPG is distributed under the terms of the GNU General Public License (GPL version 3). GnuPG-2 works best on GNU/Linux or *BSD systems. What's New =========== * Enhanced gpg-connect-agent with a small scripting language. * New option --list-config for gpgconf. * Fixed a crash in gpgconf. * Gpg-agent now supports the passphrase quality bar of the latest Pinentry. * The envvars XAUTHORITY and PINENTRY_USER_DATA are now passed to the pinentry. * Fixed the auto creation of the key stub for smartcards. * Fixed a rare bug in decryption using the OpenPGP card. * Creating DSA2 keys is now possible. * New option --extra-digest-algo for gpgsm to allow verification of broken signatures. * Allow encryption with legacy Elgamal sign+encrypt keys with option --rfc2440. * Windows is now a supported platform. * Made sure that under Windows the file permissions of the socket are taken into account. This required a change of our socket emulation code and changed the IPC protocol under Windows. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.8 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the FTP server and ist mirrors you should find the following files in the gnupg/ directory: gnupg-2.0.8.tar.bz2 (3568k) gnupg-2.0.8.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.7-2.0.8.diff.bz2 (156k) A patch file to upgrade a 2.0.7 GnuPG source tree. This patch does not include updates of the language files. Note, that we don't distribute gzip compressed tarballs for GnuPG-2. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-2.0.8.tar.bz2 you would use this command: gpg --verify gnupg-2.0.8.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a keyserver like gpg --recv-key 1CE0C630 The distribution key 1CE0C630 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-2.0.8.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.8.tar.bz2 and check that the output matches the first line from the following list: baeb7962f9d3d4628ada78036d1f5d4480aaa2d9 gnupg-2.0.8.tar.bz2 80f8c84834122e988eaeeaddff070097b3a9f383 gnupg-2.0.7-2.0.8.diff.bz2 Internationalization ==================== GnuPG comes with support for 27 languages. Due to a lot of new and changed strings many translations are not entirely complete. The German, Polish, Russian, Swedish and Turkish translations are close to be complete. Documentation ============= We are currently working on an installation guide to explain in more detail how to configure the new features. As of now the chapters on gpg-agent and gpgsm include brief information on how to set up the whole thing. Please watch the GnuPG website for updates of the documentation. In the meantime you may search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. KDE's KMail is the most prominent user of GnuPG-2. In fact it has been developed along with the KMail folks. Mutt users might want to use the configure option "--enable-gpgme" and "set use_crypt_gpgme" in ~/.muttrc to make use of GnuPG-2 to enable S/MIME in addition to a reworked OpenPGP support. The manual is also available online in HTML format at http://www.gnupg.org/documentation/manuals/gnupg/ and in Portable Document Format at http://www.gnupg.org/documentation/manuals/gnupg.pdf . Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, order extensions or support or more general by donating money to the Free Software movement (e.g. http://www.fsfeurope.org/help/donate.en.html). Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. The GnuPG service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team (David, Marcus, Werner and all other contributors) -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20071220/22b45e58/attachment-0001.pgp -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From bernhard at intevation.de Thu Dec 20 12:30:18 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 20 Dec 2007 12:30:18 +0100 Subject: import of external certificates via command line In-Reply-To: <200710182149.11497.jan-oliver.wagner@intevation.de> References: <200710122324.45353.jan-oliver.wagner@intevation.de> <877iln768m.fsf@wheatstone.g10code.de> <200710182149.11497.jan-oliver.wagner@intevation.de> Message-ID: <200712201230.21529.bernhard@intevation.de> On Thursday 18 October 2007 21:49, Jan-Oliver Wagner wrote: > On Tuesday 16 October 2007 11:34, Werner Koch wrote: > > On Fri, 12 Oct 2007 23:23, jan-oliver.wagner at intevation.de said: > > > I wonder whether there is a way to import an external certificate > > > (found with gpgsm --list-external-keys ?MyName > > > ) via command line ... ? > > > > Just use it within a couple of hours after --list-external-keys. ?You > > can list these certifciates: > > > > ? gpg --with-ephemeral --list-keys > > yes, I can see the certificate (using gpgsm, not gpg, of course). > > > By using them, they are made permanent. > > How do I do this? I tried to encrypt something to this ID > but gpgsm says it is an unknown key. > I exported the key successfully, but this did not make it permanent. > Then I imported it successfully. > > Wouldn't it make sense to have --recv-keys implemented > for gpgsm with the method to search a key and then import it? > Currently, --recv-keys says it is not implemented. Any solution to this meanwhile? -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1571 bytes Desc: not available Url : /pipermail/attachments/20071220/ffb41eb5/attachment.bin From alan.watt at per-se.com Mon Dec 17 17:04:19 2007 From: alan.watt at per-se.com (Alan Watt) Date: Mon, 17 Dec 2007 11:04:19 -0500 Subject: GPG & Floating point? Message-ID: <47669E03.1010105@per-se.com> Can anybody answer the question whether GPG uses any floating point instructions during decryption? I'm running some performance tests on a 4-core SPARC T-2000 verses my current production environment, and GPG decryption performance is nowhere near as improved as I would expect. The actual performance I get per thread is about equal to an old 296 MHz Ultra-SPARC II processor. In most other tasks, the T-2000 is much, much faster. Since all the cores on the T-2000 chip share the same FPU, any significant use of floating point basically throttles the chip down to a single thread. Thanks Alan Watt Alan.Watt at McKesson.Com From wk at gnupg.org Thu Dec 20 13:33:07 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Dec 2007 13:33:07 +0100 Subject: GPG & Floating point? In-Reply-To: <47669E03.1010105@per-se.com> (Alan Watt's message of "Mon, 17 Dec 2007 11:04:19 -0500") References: <47669E03.1010105@per-se.com> Message-ID: <87zlw5a6m4.fsf@wheatstone.g10code.de> On Mon, 17 Dec 2007 17:04, alan.watt at per-se.com said: > Can anybody answer the question whether GPG uses any floating point > instructions during decryption? Nothing serious. There might be a few used with printf or calculation of file sizes but that won't harm the performance. > I'm running some performance tests on a 4-core SPARC T-2000 verses my > current production environment, and GPG decryption performance is > nowhere near as improved as I would expect. The actual performance I > get per thread is about equal to an old 296 MHz Ultra-SPARC II It depends on what you are measuring: Is it about bulk operation (processing large files) or the performace of the public key operations on short data. The latter can be improved by using the assembler code for the big integer math; check out what links are set in mpi/. Bulk encryption is limited by the encryption code and the SHA-1 hash function. Are you using the same algorithms on both machines? Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Tue Dec 18 00:02:15 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 17 Dec 2007 18:02:15 -0500 Subject: gnupg 1.4.7 build system bug: gpgkeys_ldap compile error while libcurl in non-standard path In-Reply-To: <47542EBC.3090306@yahoo.com.cn> References: <684194.27183.qm@web15008.mail.cnb.yahoo.com> <20071129003939.GA6508@jabberwocky.com> <47542EBC.3090306@yahoo.com.cn> Message-ID: <20071217230215.GA5382@jabberwocky.com> On Tue, Dec 04, 2007 at 12:28:44AM +0800, It's me FKtPp ;) wrote: > David Shaw ??: > > On Tue, Nov 27, 2007 at 11:17:46PM +0800, FKtPp wrote: > >> Dear developers, > >> > >> I find this bug while compiling gnupg 1.4.7 on solaris 10/8 x86 edition on my machine. > >> > >> PRE-REQUIREMENTS: > >> > >> 1) if you have curl/libcurl installed in non-standard place(which was true for solaris in /opt/sfw subdirectory) > >> > >> 2) you chose to compile in curl support. > >> > >> 3) your configure decide to compile in ldap support. > >> > >> RESULT: > >> > >> Compile error while compile gpgkeys_ldap things. gpgkeys_ldap_* need libcurl header/libs path to be correct compiled/linked. > > > > Can you show me the error you get? It would be helpful. > > Sorry, for the late reply. I was previously not on list... > > 1) my configuration commandline is: > > ./configure --prefix=/opt/sfw --with-libcurl=/opt/sfw Can you try this patch? You will need to regenerate the Makefile after you apply the patch (automake). Index: Makefile.am =================================================================== --- Makefile.am (revision 4665) +++ Makefile.am (working copy) @@ -49,4 +49,5 @@ gpgkeys_hkp_CPPFLAGS = @LIBCURL_CPPFLAGS@ gpgkeys_hkp_LDADD = ../util/libcompat.a @LIBCURL@ @GETOPT@ gpgkeys_finger_CPPFLAGS = @LIBCURL_CPPFLAGS@ +gpgkeys_ldap_CPPFLAGS += @LIBCURL_CPPFLAGS@ endif Thanks! David From wk at gnupg.org Thu Dec 20 16:10:02 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Dec 2007 16:10:02 +0100 Subject: import of external certificates via command line In-Reply-To: <200712201230.21529.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 20 Dec 2007 12:30:18 +0100") References: <200710122324.45353.jan-oliver.wagner@intevation.de> <877iln768m.fsf@wheatstone.g10code.de> <200710182149.11497.jan-oliver.wagner@intevation.de> <200712201230.21529.bernhard@intevation.de> Message-ID: <87fxxx8ks5.fsf@wheatstone.g10code.de> On Thu, 20 Dec 2007 12:30, bernhard at intevation.de said: >> Wouldn't it make sense to have --recv-keys implemented >> for gpgsm with the method to search a key and then import it? >> Currently, --recv-keys says it is not implemented. > > Any solution to this meanwhile? No. It is a bit of work because we need to write a little dialog similar to the one used by gpg --search-key. Implementing a straight --recv-key is not possible because there is no standard way to single out a key by means of a standard identifier like the fingerprint or SN+IssuerDN. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From m_pupil at yahoo.com.cn Thu Dec 20 17:04:01 2007 From: m_pupil at yahoo.com.cn (It's me FKtPp ;)) Date: Fri, 21 Dec 2007 00:04:01 +0800 Subject: gnupg 1.4.7 build system bug: gpgkeys_ldap compile error while libcurl in non-standard path In-Reply-To: <20071217230215.GA5382@jabberwocky.com> References: <684194.27183.qm@web15008.mail.cnb.yahoo.com> <20071129003939.GA6508@jabberwocky.com> <47542EBC.3090306@yahoo.com.cn> <20071217230215.GA5382@jabberwocky.com> Message-ID: <476A9271.8050002@yahoo.com.cn> David Shaw ????: > On Tue, Dec 04, 2007 at 12:28:44AM +0800, It's me FKtPp ;) wrote: > >> David Shaw ????: >> >>> On Tue, Nov 27, 2007 at 11:17:46PM +0800, FKtPp wrote: >>> >>>> Dear developers, >>>> >>>> I find this bug while compiling gnupg 1.4.7 on solaris 10/8 x86 edition on my machine. >>>> >>>> PRE-REQUIREMENTS: >>>> >>>> 1) if you have curl/libcurl installed in non-standard place(which was true for solaris in /opt/sfw subdirectory) >>>> >>>> 2) you chose to compile in curl support. >>>> >>>> 3) your configure decide to compile in ldap support. >>>> >>>> RESULT: >>>> >>>> Compile error while compile gpgkeys_ldap things. gpgkeys_ldap_* need libcurl header/libs path to be correct compiled/linked. >>>> >>> Can you show me the error you get? It would be helpful. >>> >> Sorry, for the late reply. I was previously not on list... >> >> 1) my configuration commandline is: >> >> ./configure --prefix=/opt/sfw --with-libcurl=/opt/sfw >> > > Can you try this patch? You will need to regenerate the Makefile > after you apply the patch (automake). > > Index: Makefile.am > =================================================================== > --- Makefile.am (revision 4665) > +++ Makefile.am (working copy) > @@ -49,4 +49,5 @@ > gpgkeys_hkp_CPPFLAGS = @LIBCURL_CPPFLAGS@ > gpgkeys_hkp_LDADD = ../util/libcompat.a @LIBCURL@ @GETOPT@ > gpgkeys_finger_CPPFLAGS = @LIBCURL_CPPFLAGS@ > +gpgkeys_ldap_CPPFLAGS += @LIBCURL_CPPFLAGS@ > endif > Sorry, but I've already made heavy change to my system's default configuration, and I can't reproduce the problem now... But the after the patch and reconfigure, the result Makefile is identical to my workaround file, so I am sure it works well. Sorry for NO test... Best Regards. FKtPp From bernhard at intevation.de Fri Dec 21 10:46:00 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 21 Dec 2007 10:46:00 +0100 Subject: import of external certificates via command line In-Reply-To: <87fxxx8ks5.fsf@wheatstone.g10code.de> References: <200710122324.45353.jan-oliver.wagner@intevation.de> <200712201230.21529.bernhard@intevation.de> <87fxxx8ks5.fsf@wheatstone.g10code.de> Message-ID: <200712211046.01262.bernhard@intevation.de> On Thursday 20 December 2007 16:10, Werner Koch wrote: > On Thu, 20 Dec 2007 12:30, bernhard at intevation.de said: > >> Wouldn't it make sense to have --recv-keys implemented > >> for gpgsm with the method to search a key and then import it? > >> Currently, --recv-keys says it is not implemented. > > > > Any solution to this meanwhile? > > No. ?It is a bit of work because we need to write a little dialog > similar to the one used by gpg --search-key. Why not have an option like --import-external-keys PATTERN which just tries to import all found keys? Or an option to --list-external-keys? For the command line workflow it would be fine if I know that with the current settings my PATTERN will match the keys I want and with the next command I would just import them. So it is really frustrating because I can list and dump the key attributes, but not get the key out of the system though it has it. > Implementing a straight > --recv-key is not possible because there is no standard way to single > out a key by means of a standard identifier like the fingerprint or > SN+IssuerDN. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20071221/4eac3789/attachment.pgp From bernhard at intevation.de Fri Dec 21 10:48:24 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 21 Dec 2007 10:48:24 +0100 Subject: Frontend for GPG In-Reply-To: <3ac86fa70712111623wd83e701vd07440a6966dde65@mail.gmail.com> References: <3ac86fa70712111623wd83e701vd07440a6966dde65@mail.gmail.com> Message-ID: <200712211048.25215.bernhard@intevation.de> On Wednesday 12 December 2007 01:23, Brad Tilley wrote: > Are there any docs that describe a programmatic > interface to gpg or how to go about this sort of thing with a > os.system and/or os.popen library? The canonical way would be to use gpgme, but of course this might already have to many feature for your use case. It would be cool to have python gpgme bindings. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20071221/56ca3af5/attachment.pgp From wk at gnupg.org Fri Dec 21 14:00:28 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Dec 2007 14:00:28 +0100 Subject: import of external certificates via command line In-Reply-To: <200712211046.01262.bernhard@intevation.de> (Bernhard Reiter's message of "Fri, 21 Dec 2007 10:46:00 +0100") References: <200710122324.45353.jan-oliver.wagner@intevation.de> <200712201230.21529.bernhard@intevation.de> <87fxxx8ks5.fsf@wheatstone.g10code.de> <200712211046.01262.bernhard@intevation.de> Message-ID: <87abo42oer.fsf@wheatstone.g10code.de> On Fri, 21 Dec 2007 10:46, bernhard at intevation.de said: > Or an option to --list-external-keys? This option exists as well as --dump-external-keys Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bernhard at intevation.de Fri Dec 21 17:15:13 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 21 Dec 2007 17:15:13 +0100 Subject: import of external certificates via command line In-Reply-To: <87abo42oer.fsf@wheatstone.g10code.de> References: <200710122324.45353.jan-oliver.wagner@intevation.de> <200712211046.01262.bernhard@intevation.de> <87abo42oer.fsf@wheatstone.g10code.de> Message-ID: <200712211715.17932.bernhard@intevation.de> On Friday 21 December 2007 14:00, Werner Koch wrote: > On Fri, 21 Dec 2007 10:46, bernhard at intevation.de said: > > Or an option to --list-external-keys? > > This option exists as well as --dump-external-keys No it does not give me the key, only the attributes. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20071221/3814216b/attachment.pgp From wk at gnupg.org Fri Dec 21 18:09:08 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Dec 2007 18:09:08 +0100 Subject: import of external certificates via command line In-Reply-To: <200712211715.17932.bernhard@intevation.de> (Bernhard Reiter's message of "Fri, 21 Dec 2007 17:15:13 +0100") References: <200710122324.45353.jan-oliver.wagner@intevation.de> <200712211046.01262.bernhard@intevation.de> <87abo42oer.fsf@wheatstone.g10code.de> <200712211715.17932.bernhard@intevation.de> Message-ID: <87ir2synyj.fsf@wheatstone.g10code.de> On Fri, 21 Dec 2007 17:15, bernhard at intevation.de said: > No it does not give me the key, only the attributes. You may then use the listed fingerprint to export the key. Note that you must use the fingerprint, the keyid is wrong and the issuer DN is definitely wrong; only the fingerprint is ... Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Dec 27 20:06:08 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 27 Dec 2007 20:06:08 +0100 Subject: Moving the server to a new box Message-ID: <8763ykt0tb.fsf@wheatstone.g10code.de> Hi! The GnuPG server is moving to a new hardware and thus you may encounter a couple of problems for some time. Please don't report such problems. www.gnupg.org and lists.gnupg.org should basically work as soon as the DNS has catched up. FTP has already been migrated some time ago. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From alon.barlev at gmail.com Sat Dec 29 21:32:57 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 29 Dec 2007 22:32:57 +0200 Subject: logger-file vs log-file options (gnupg-2 regression?) Message-ID: <9e0cf0bf0712291232s1636caa7y93aa8b7778ea4325@mail.gmail.com> Hello, The logger-file was changed to log-file in gnupg-2. The logger-fd was kept. The man page continue to document logger-file. What is correct? Best Regards, Alon Bar-Lev. From tomp at idirect.com Mon Dec 31 00:25:16 2007 From: tomp at idirect.com (Tom Pegios) Date: Sun, 30 Dec 2007 18:25:16 -0500 Subject: compiling GnuPG for x86_64-pc-mingw32 Message-ID: <477828DC.8050601@idirect.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The x86_64-pc-mingw32 (64-bit) version of GnuPG can be built on MSYS now but requires 2 changes to the source code. in configure.ac original is ........................ case "${host}" in *-mingw32*) dnl NETLIBS="$NETLIBS -lwsock32" W32LIBS="-lwsock32" ;; *) ;; esac ....................... needs to be changed to ....................... case "${host}" in x86_64-pc-mingw32) dnl NETLIBS="$NETLIBS -lws2_32" W32LIBS="-lws2_32" ;; *-mingw32*) dnl NETLIBS="$NETLIBS -lwsock32" W32LIBS="-lwsock32" ;; *) ;; esac ....................... libwsock32.a doesn't exist in x86_64-pc-mingw32 but libws2_32.a does and works. in util/regcomp.c original is: ........................... size_t regerror (errcode, preg, errbuf, errbuf_size) int errcode; const regex_t *preg; char *errbuf; size_t errbuf_size; ............................... needs to be changed to : ............................... size_t regerror (int errcode, const regex_t *preg, char *errbuf, size_t errbuf_size) .............................. this will prevent the following error: ................................ In file included from regex.c:50: regcomp.c:528: error: expected declaration specifiers or '...' before 'preg' regcomp.c:528: error: expected declaration specifiers or '...' before 'errbuf' regcomp.c:528: error: expected declaration specifiers or '...' before 'errbuf_si ze' regcomp.c:528: error: conflicting types for 'regerror' ../include/_regex.h:555: error: previous declaration of 'regerror' was here regcomp.c: In function 'regerror': regcomp.c:533: error: old-style parameter declarations in prototyped function definition regcomp.c:528: error: parameter name omitted regcomp.c:537: error: expected expression before 'errcode' regcomp.c:537: error: too few arguments to function '__builtin_expect' regcomp.c:546: error: expected expression before 'errcode' regcomp.c:550: error: 'errbuf_size' undeclared (first use in this function) regcomp.c:550: error: (Each undeclared identifier is reported only once regcomp.c:550: error: for each function it appears in.) regcomp.c:557: error: 'errbuf' undeclared (first use in this function) make[1]: *** [regex.o] Error 1 .................................. If these 2 changes can be included in GnuPG this will allow for a successful 64-bit build under windows without any file modifications. Using -lws2_32 instead of -lwsock32 works appears to work on a 32-bit build. I'm not sure of the differences between the two libs. Regards Tom Pegios -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8-svn-4660. (x86_64-pc-MingW32) iEYEAREIAAYFAkd4KNsACgkQxDTq4V42xe4kigCgqu0c2UtjlcF6ugbtsl+1KQBz f3wAmgOoyYRNdwY1VnXT6gGe1Z0t1jZx =c9wd -----END PGP SIGNATURE----- From lists at lina.inka.de Fri Dec 21 02:05:50 2007 From: lists at lina.inka.de (Bernd Eckenfels) Date: Fri, 21 Dec 2007 01:05:50 -0000 Subject: GPG & Floating point? In-Reply-To: <87zlw5a6m4.fsf@wheatstone.g10code.de> References: <47669E03.1010105@per-se.com> <87zlw5a6m4.fsf@wheatstone.g10code.de> Message-ID: <20071220235141.GA27059@lina.inka.de> On Thu, Dec 20, 2007 at 01:33:07PM +0100, Werner Koch wrote: > Alan wrote: > > I'm running some performance tests on a 4-core SPARC T-2000 verses my > > current production environment, and GPG decryption performance is > > nowhere near as improved as I would expect. The actual performance I > > get per thread is about equal to an old 296 MHz Ultra-SPARC II On T1/T2 it is possible to see the number of FP operations with cpustat: http://developers.sun.com/solaris/articles/t1t2_perf_counter.html#FloatingPointComputation Besides that, a T1 single core is pretty slow, and as long as the code is not optimized for using the hardware accelerator it might really look very slow. > It depends on what you are measuring: Is it about bulk operation > (processing large files) or the performace of the public key operations > on short data. The latter can be improved by using the assembler code > for the big integer math; check out what links are set in mpi/. Bulk > encryption is limited by the encryption code and the SHA-1 hash > function. Are you using the same algorithms on both machines? Exactly. I wonder if there is platform code to use the T2000 crypto hardware accelerator for DSA/RSA: http://www.sun.com/servers/coolthreads/tnb/faq.jsp#q_10 (not sure if there is any way to speed up hashing besides hand crafting assembler for the T1). Gruss bernd -- (OO) -- Bernd_Eckenfels at M?rscher_Strasse_8.76185Karlsruhe.de -- ( .. ) ecki@{inka.de,linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E eckes at IRCNet v:+497211603874 f:+49721151516129 (O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!