From rfransix at comcast.net Mon Mar 2 01:27:18 2009 From: rfransix at comcast.net (Richard Francis) Date: Sun, 1 Mar 2009 18:27:18 -0600 Subject: make on aix 4.3.2 fails with invalid asm statement Message-ID: Hi, make fails with these errors using gnu cc 2.95.3 on aix 4.3.2, have successfully used ./configure --disable-asm, though with same errors, (please refer to prior post (http://seo.xon.us/lists/020490.html) for similar scenario). help greatly appreciated, any info request on demand. # lslpp -L | grep gcc freeware.gnu.gcc.g++ 2.95.3.0 C GNU Compiler Collection Extras freeware.gnu.gcc.info 2.95.3.0 C GNU Compiler Info files freeware.gnu.gcc.rte 2.95.3.0 C GNU Compiler Collection server:/gnupg-1.4.9 # make make all-recursive Making all in m4 Target "all" is up to date. Making all in intl Target "all" is up to date. Making all in zlib Target "all" is up to date. Making all in util Target "all" is up to date. Making all in mpi source='mpih-div.c' object='mpih-div.o' libtool=no DEPDIR=.deps depmode=gcc /bin/sh ../scripts/depcomp /usr/local/bin/gcc -DHAVE_CONFIG_H -I. -I. . -I.. -I../include -D_THREAD_SAFE -I/usr/local/include -g -O2 -Wall -c mpih-div.c mpih-div.c: In function `mpihelp_mod_1': mpih-div.c:85: warning: implicit declaration of function `__udiv_w_sdiv' mpih-div.c:99: Invalid `asm' statement: mpih-div.c:99: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:100: Invalid `asm' statement: mpih-div.c:100: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:105: Invalid `asm' statement: mpih-div.c:105: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:106: Invalid `asm' statement: mpih-div.c:106: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:135: Invalid `asm' statement: mpih-div.c:135: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:135: Invalid `asm' statement: mpih-div.c:135: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c: In function `mpihelp_divrem': mpih-div.c:289: Invalid `asm' statement: mpih-div.c:289: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:353: Invalid `asm' statement: mpih-div.c:353: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c: In function `mpihelp_divmod_1': mpih-div.c:446: Invalid `asm' statement: mpih-div.c:446: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:447: Invalid `asm' statement: mpih-div.c:447: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:452: Invalid `asm' statement: mpih-div.c:452: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:453: Invalid `asm' statement: mpih-div.c:453: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:481: Invalid `asm' statement: mpih-div.c:481: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:481: Invalid `asm' statement: mpih-div.c:481: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Mon Mar 2 14:55:56 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 2 Mar 2009 14:55:56 +0100 Subject: GnuPG and Python In-Reply-To: <20090226142422.GJ4505@inocybe.teonanacatl.org> References: <49A2AC0E.8030305@buanzo.com.ar> <200902260839.34144.bernhard@intevation.de> <20090226142422.GJ4505@inocybe.teonanacatl.org> Message-ID: <200903021456.00422.bernhard@intevation.de> Am Donnerstag, 26. Februar 2009 15:24:22 schrieb Todd Zullinger: > Bernhard Reiter wrote: > > there is only one python gpgme interface http://pyme.sourceforge.net/ > >as py-gnupg does not seem to use gpgme. There are a couple > > of other non-gpgme python interface attempts. (Which I am too lazy > > too look up right now.) > There is also pygpgme: https://launchpad.net/pygpgme Oh, you are right. I've missed that one. I wonder what the differences are between pyme and pygpgme. Did anyone try both? Both seem to not have reached 1.0 it would be cool to have at least one python binding that work really well. James, Igor? Best Regards, Bernhard -- 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: 198 bytes Desc: This is a digitally signed message part. URL: From tmz at pobox.com Mon Mar 2 15:59:19 2009 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 2 Mar 2009 09:59:19 -0500 Subject: GnuPG and Python In-Reply-To: <200903021456.00422.bernhard@intevation.de> References: <49A2AC0E.8030305@buanzo.com.ar> <200902260839.34144.bernhard@intevation.de> <20090226142422.GJ4505@inocybe.teonanacatl.org> <200903021456.00422.bernhard@intevation.de> Message-ID: <20090302145919.GD10507@inocybe.teonanacatl.org> Bernhard Reiter wrote: > I wonder what the differences are between pyme and pygpgme. I *think* (having only read about pyme briefly a few months or more ago) that pyme is a bit more of a raw set of bindings to gpgme, being swig based. While pygpgme feels a little more "pythonic" in its design. Of course, I've only used pygpgme lightly and pyme not at all. And both are still quite young and could change as they mature. I know that yum (the Fedora, RHEL, and CentOS update tool) uses pygpgme for many of its gpg needs. Other than that, I haven't run into many tools using either. Hopefully I've not misrepresented or maligned the work of either the pyme or pygpgme authors. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If quizzes are quizzical, what are tests? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From buanzo at buanzo.com.ar Mon Mar 2 16:03:16 2009 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Mon, 02 Mar 2009 13:03:16 -0200 Subject: GnuPG and Python In-Reply-To: <20090302145919.GD10507@inocybe.teonanacatl.org> References: <49A2AC0E.8030305@buanzo.com.ar> <200902260839.34144.bernhard@intevation.de> <20090226142422.GJ4505@inocybe.teonanacatl.org> <200903021456.00422.bernhard@intevation.de> <20090302145919.GD10507@inocybe.teonanacatl.org> Message-ID: <49ABF534.8040806@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Todd Zullinger wrote: > Hopefully I've not misrepresented or maligned the work of either the > pyme or pygpgme authors. :) You actually provided quite an interesting feedback. Thank you Todd! - -- Arturo "Buanzo" Busleiman / Arturo Busleiman @ 4:900/107 Independent Linux and Security Consultant - SANS - OISSG - OWASP http://www.buanzo.com.ar/pro/eng.html Mailing List Archives at http://archiver.mailfighter.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkmr9TQACgkQAlpOsGhXcE0ymACfcJ2c1TUXJXEDX9v3umklKUQq X78AmwWb5q0xHVM8HGuXftYVZzfAjb8t =lTuR -----END PGP SIGNATURE----- From james at jamesh.id.au Mon Mar 2 15:28:39 2009 From: james at jamesh.id.au (James Henstridge) Date: Mon, 2 Mar 2009 09:28:39 -0500 Subject: GnuPG and Python In-Reply-To: <200903021456.00422.bernhard@intevation.de> References: <49A2AC0E.8030305@buanzo.com.ar> <200902260839.34144.bernhard@intevation.de> <20090226142422.GJ4505@inocybe.teonanacatl.org> <200903021456.00422.bernhard@intevation.de> Message-ID: <237378990903020628n6d5001e2u62c60c2fa6c33c80@mail.gmail.com> On Mon, Mar 2, 2009 at 8:55 AM, Bernhard Reiter wrote: > Am Donnerstag, 26. Februar 2009 15:24:22 schrieb Todd Zullinger: >> Bernhard Reiter wrote: >> > there is only one python gpgme interface > > http://pyme.sourceforge.net/ > >> >as py-gnupg does not seem to use gpgme. There are a couple >> > of other non-gpgme python interface attempts. (Which I am too lazy >> > too look up right now.) > >> There is also pygpgme: https://launchpad.net/pygpgme > > Oh, you are right. I've missed that one. > I wonder what the differences are between pyme and pygpgme. > > Did anyone try both? ?Both seem to not have reached 1.0 it would be cool to > have at least one python binding that work really well. > James, Igor? Don't worry too much about the version number of pygpgme: it is quite stable. It implements almost all of the gpgme 1.0 API, but is missing a few of the bits introduced in 1.1. It is currently used for the PGP processing done by Launchpad and has been quite stable. James. From belyi at users.sourceforge.net Mon Mar 2 17:23:02 2009 From: belyi at users.sourceforge.net (Igor Belyi) Date: Mon, 02 Mar 2009 11:23:02 -0500 Subject: GnuPG and Python In-Reply-To: <20090302145919.GD10507@inocybe.teonanacatl.org> References: <49A2AC0E.8030305@buanzo.com.ar> <200902260839.34144.bernhard@intevation.de> <20090226142422.GJ4505@inocybe.teonanacatl.org> <200903021456.00422.bernhard@intevation.de> <20090302145919.GD10507@inocybe.teonanacatl.org> Message-ID: <49AC07E6.6070505@users.sourceforge.net> Todd Zullinger wrote: > Bernhard Reiter wrote: > >> I wonder what the differences are between pyme and pygpgme. >> > > I *think* (having only read about pyme briefly a few months or more > ago) that pyme is a bit more of a raw set of bindings to gpgme, being > swig based. While pygpgme feels a little more "pythonic" in its > design. Of course, I've only used pygpgme lightly and pyme not at > all. And both are still quite young and could change as they mature. > > I know that yum (the Fedora, RHEL, and CentOS update tool) uses > pygpgme for many of its gpg needs. Other than that, I haven't run > into many tools using either. > > Hopefully I've not misrepresented or maligned the work of either the > pyme or pygpgme authors. :) > Yes, I think this is the right assessment of the implementation difference between pyme and pygpgme - pyme uses SWIG to have python binding for gpgme functions and then uses extra python classes/packages for pythonizing GPGME interface where as pygpgme does most of the work using Pyhton C API directly. In short, pyme hides behind SWIG from handling difference in Python and GPGME versions, where as pygpgme takes approach of having less dependencies on another product. I didn't know that yum uses pygpgme since I'm more used to the Debian distribution which in its turn has pyme package but no pygpgme. As a result, Linux distribution could be another factor for choosing one versus another. Although, I wish Debian could pick up pygpgme in its package set as well to have a better test ground for usability of both. That's my couple cents. Cheers, Igor, the PyMe maintainer. From james at jamesh.id.au Mon Mar 2 18:31:21 2009 From: james at jamesh.id.au (James Henstridge) Date: Mon, 2 Mar 2009 12:31:21 -0500 Subject: GnuPG and Python In-Reply-To: <49AC07E6.6070505@users.sourceforge.net> References: <49A2AC0E.8030305@buanzo.com.ar> <200902260839.34144.bernhard@intevation.de> <20090226142422.GJ4505@inocybe.teonanacatl.org> <200903021456.00422.bernhard@intevation.de> <20090302145919.GD10507@inocybe.teonanacatl.org> <49AC07E6.6070505@users.sourceforge.net> Message-ID: <237378990903020931g69f069aak5a726df2be130a42@mail.gmail.com> On Mon, Mar 2, 2009 at 11:23 AM, Igor Belyi wrote: > Yes, I think this is the right assessment of the implementation difference > between pyme and pygpgme - pyme uses SWIG to have python binding for gpgme > functions and then uses extra python classes/packages for pythonizing GPGME > interface where as pygpgme does most of the work using Pyhton C API > directly. In short, pyme hides behind SWIG from handling difference in > Python and GPGME versions, where as pygpgme takes approach of having less > dependencies on another product. The choice not to use swig was not an issue of dependencies, but rather bad experience with it in the past. I've seen too many memory leaks or crasher bugs in swig based bindings to trust it. I needed a binding that could be used by a long running web service without causing it to run out of memory. > I didn't know that yum uses pygpgme since I'm more used to the Debian > distribution which in its turn has pyme package but no pygpgme. As a result, > Linux distribution could be another factor for choosing one versus another. > Although, I wish Debian could pick up pygpgme in its package set as well to > have a better test ground for usability of both. I agree it'd be good to get pygpgme packaged for Debian/Ubuntu. I might try packaging it in my PPA when I've got some spare time. James. From belyi at users.sourceforge.net Mon Mar 2 18:39:09 2009 From: belyi at users.sourceforge.net (Igor Belyi) Date: Mon, 02 Mar 2009 12:39:09 -0500 Subject: GnuPG and Python In-Reply-To: <237378990903020628n6d5001e2u62c60c2fa6c33c80@mail.gmail.com> References: <49A2AC0E.8030305@buanzo.com.ar> <200902260839.34144.bernhard@intevation.de> <20090226142422.GJ4505@inocybe.teonanacatl.org> <200903021456.00422.bernhard@intevation.de> <237378990903020628n6d5001e2u62c60c2fa6c33c80@mail.gmail.com> Message-ID: <49AC19BD.6040603@users.sourceforge.net> James Henstridge wrote: > On Mon, Mar 2, 2009 at 8:55 AM, Bernhard Reiter wrote: > >> Am Donnerstag, 26. Februar 2009 15:24:22 schrieb Todd Zullinger: >> >>> Bernhard Reiter wrote: >>> >>>> there is only one python gpgme interface >>>> >> http://pyme.sourceforge.net/ >> >> >>>> as py-gnupg does not seem to use gpgme. There are a couple >>>> of other non-gpgme python interface attempts. (Which I am too lazy >>>> too look up right now.) >>>> >>> There is also pygpgme: https://launchpad.net/pygpgme >>> >> Oh, you are right. I've missed that one. >> I wonder what the differences are between pyme and pygpgme. >> >> Did anyone try both? Both seem to not have reached 1.0 it would be cool to >> have at least one python binding that work really well. >> James, Igor? >> > > Don't worry too much about the version number of pygpgme: it is quite > stable. It implements almost all of the gpgme 1.0 API, but is missing > a few of the bits introduced in 1.1. It is currently used for the PGP > processing done by Launchpad and has been quite stable. > I'd like to join James in confirming that PyMe in its turn is also stable. :o) It does not miss any of the gpgme bits due to the usage of the SWIG for the build but the main stopper for it to become 1.0 is the lack of good pydoc documentation for its own and generated from gpgme classes and methods. Plus, the current runtime dependency it has on Windows needs some improvement. Cheers, Igor From buanzo at buanzo.com.ar Mon Mar 2 19:59:26 2009 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Mon, 02 Mar 2009 16:59:26 -0200 Subject: GnuPG and Python In-Reply-To: <237378990903020628n6d5001e2u62c60c2fa6c33c80@mail.gmail.com> References: <49A2AC0E.8030305@buanzo.com.ar> <200902260839.34144.bernhard@intevation.de> <20090226142422.GJ4505@inocybe.teonanacatl.org> <200903021456.00422.bernhard@intevation.de> <237378990903020628n6d5001e2u62c60c2fa6c33c80@mail.gmail.com> Message-ID: <49AC2C8E.8050306@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 James Henstridge wrote: > Don't worry too much about the version number of pygpgme: it is quite > stable. It implements almost all of the gpgme 1.0 API, but is missing > a few of the bits introduced in 1.1. It is currently used for the PGP > processing done by Launchpad and has been quite stable. I just tried it out. Didn't work from the start. I had to modify the Makefile to use python 2.5 instead of default 2.4. After that, it plain worked. - -- Arturo "Buanzo" Busleiman / Arturo Busleiman @ 4:900/107 Independent Linux and Security Consultant - SANS - OISSG - OWASP http://www.buanzo.com.ar/pro/eng.html Mailing List Archives at http://archiver.mailfighter.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkmsLI4ACgkQAlpOsGhXcE2V2QCbB4C0SHShyTjlKloh8t+vT47r R5cAn0rhNHso+vMreqvLmlz1lCSokIrl =dKlo -----END PGP SIGNATURE----- From bernhard at intevation.de Tue Mar 3 08:32:36 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 3 Mar 2009 08:32:36 +0100 Subject: GnuPG and Python In-Reply-To: <237378990903020931g69f069aak5a726df2be130a42@mail.gmail.com> References: <49A2AC0E.8030305@buanzo.com.ar> <49AC07E6.6070505@users.sourceforge.net> <237378990903020931g69f069aak5a726df2be130a42@mail.gmail.com> Message-ID: <200903030832.40685.bernhard@intevation.de> Igor, James, thanks for your responses and for doing nice python packages of gpgme as Free Software! I suggest you should both use the 1.0 label for the next release. Think about that release numbers are mainly for journalists. ;) Am Montag, 2. M?rz 2009 18:31:21 schrieb James Henstridge: > On Mon, Mar 2, 2009 at 11:23 AM, Igor Belyi wrote: > > Yes, I think this is the right assessment of the implementation > > difference between pyme and pygpgme - pyme uses SWIG to have python > > binding for gpgme functions and then uses extra python classes/packages > > for pythonizing GPGME interface where as pygpgme does most of the work > > using Pyhton C API directly. In short, pyme hides behind SWIG from > > handling difference in Python and GPGME versions, where as pygpgme takes > > approach of having less dependencies on another product. > > The choice not to use swig was not an issue of dependencies, but > rather bad experience with it in the past. We (at Intevation) also found that swig was a good idea in 2000 and used it for pyshapelib. Later we found it was more getting in the way, so we probably will not use it for the next python wrapper we do. And pyshapelib has meanwhile be ported to be native. > I've seen too many memory > leaks or crasher bugs in swig based bindings to trust it. ?I needed a > binding that could be used by a long running web service without > causing it to run out of memory. So far I did not try pygpgme yet, but pyme which worked fine for a couple of short running scripts. I know that roundup 1.4 uses pyme and roundup often is run as a long term server process. This is a good sign for pyme. Best, Bernhard -- 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: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Mar 3 12:45:08 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Mar 2009 12:45:08 +0100 Subject: [Announce] GnuPG 2.0.11 released Message-ID: <87sklug797.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.11. 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.9) 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 in 2.0.11 ==================== * Fixed a problem in SCDAEMON which caused unexpected card resets. * SCDAEMON is now aware of the Geldkarte. * The SCDAEMON option --allow-admin is now used by default. * GPGCONF now restarts SCdaemon if necessary. * The default cipher algorithm in GPGSM is now again 3DES. This is due to interoperability problems with Outlook 2003 which still can't cope with AES. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.11 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 its mirrors you should find the following files in the gnupg/ directory: gnupg-2.0.11.tar.bz2 (3763k) gnupg-2.0.11.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.10-2.0.11.diff.bz2 (29k) A patch file to upgrade a 2.0.10 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.11.tar.bz2 you would use this command: gpg --verify gnupg-2.0.11.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.11.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.11.tar.bz2 and check that the output matches the first line from the following list: 9f71a342c5be686b0dcef082078af693802a558f gnupg-2.0.11.tar.bz2 5cf75b4405ba9ed908b85ef3b614ef06f3a6ab10 gnupg-2.0.10-2.0.11.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. Jedi, Maxim Britov, Jaime Su?rez and Nilg?n Belma Bug?ner have been kind enough to go over their translations and thus the Chinese, German, Russian, Spanish, and Turkish translations are pretty much 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 -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From comp.ogz at gmail.com Wed Mar 4 16:39:59 2009 From: comp.ogz at gmail.com (Oguz Yarimtepe) Date: Wed, 04 Mar 2009 17:39:59 +0200 Subject: gpgme usage Message-ID: <1236181206.3949.12.camel@ELK1655> Hi, I was trying to use the gpgme. I checked the tests directory and decided to play with the t-decrypt.c. I changed it a little so as to use my own keys at my system[1]. I also changed "t-support.h" so as to use my password[2]. I compiled as $ gcc mytest-decrypt.c `gpgme-config --libs` -o myencrypt and run as $ ./myencrypt Here is what i got: Oguz Yarimtepe comp.ogz at gmail.com Oguz Yarimtepe t-support.h:56: Unspecified source: Invalid argument When i comment the print_data (out); line at the mytest-decrypt.c, it works, of course without no output. I am trying to decrypt the cipher-1.asc.gpg file which is encrypted by using gpg command with the key at my system. [1] http://rafb.net/p/hBDQia89.html [2] http://rafb.net/p/0aO1A239.html It seems i am doing something wrong or misunderstood the basics. Can you guide me please? From wk at gnupg.org Thu Mar 5 12:24:05 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 05 Mar 2009 12:24:05 +0100 Subject: gpgme usage In-Reply-To: <1236181206.3949.12.camel@ELK1655> (Oguz Yarimtepe's message of "Wed, 04 Mar 2009 17:39:59 +0200") References: <1236181206.3949.12.camel@ELK1655> Message-ID: <87tz68ciwa.fsf@wheatstone.g10code.de> On Wed, 4 Mar 2009 16:39, comp.ogz at gmail.com said: > $ gcc mytest-decrypt.c `gpgme-config --libs` -o myencrypt Use gcc mytest-decrypt.c `gpgme-config --cflags --libs` -o myencrypt > Oguz Yarimtepe comp.ogz at gmail.com Oguz Yarimtepe > t-support.h:56: Unspecified source: Invalid argument You modified t-support and I don't know theversion of gpgme youare using. Thus I can't see anything from this error message. My guess is that you need to enable Large File support. The gpgme manual has a chapter on this. > [1] http://rafb.net/p/hBDQia89.html Please don't do this: It will eventually go away, some people are reading mail without having a net connection and it is harder to comment on the code. Better include the code directly and strip off parts which are not required. The message limit here is 40k which should be sufficient for most examples. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From comp.ogz at gmail.com Thu Mar 5 15:51:24 2009 From: comp.ogz at gmail.com (Oguz Yarimtepe) Date: Thu, 05 Mar 2009 16:51:24 +0200 Subject: gpgme usage In-Reply-To: <87tz68ciwa.fsf@wheatstone.g10code.de> References: <1236181206.3949.12.camel@ELK1655> <87tz68ciwa.fsf@wheatstone.g10code.de> Message-ID: <1236264684.8180.8.camel@gezenti> On Thu, 2009-03-05 at 12:24 +0100, Werner Koch wrote: > On Wed, 4 Mar 2009 16:39, comp.ogz at gmail.com said: > > > $ gcc mytest-decrypt.c `gpgme-config --libs` -o myencrypt > > Use > > gcc mytest-decrypt.c `gpgme-config --cflags --libs` -o myencrypt I had tried whether there is an output of --cflags usage but because gpgme-config --cflags doesnt produce anything, i didn't add it. > > You modified t-support and I don't know theversion of gpgme youare > using. Thus I can't see anything from this error message. > It is gpgme1.0-1.1.5. I just apt-get source libgpgme11-dev and checked the files. > My guess is that you need to enable Large File support. The gpgme > manual has a chapter on this. Should i really enable it? It is just the text file (cipher-1.asc at the tests directory.) > > > [1] http://rafb.net/p/hBDQia89.html > > Please don't do this: It will eventually go away, some people are > reading mail without having a net connection and it is harder to comment > on the code. Better include the code directly and strip off parts which > are not required. The message limit here is 40k which should be > sufficient for most examples. > > Ok i am sending the files then with this mail. The t-decrypt.c is the modified one. t-support.h is just showing which part i changed. > Salam-Shalom, > > Werner > -- Oguz Yarimtepe http://www.loopbacking.info -------------- next part -------------- A non-text attachment was scrubbed... Name: t-decrypt.c Type: text/x-csrc Size: 2869 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: t-support.h Type: text/x-chdr Size: 241 bytes Desc: not available URL: From wk at gnupg.org Thu Mar 5 23:00:10 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 05 Mar 2009 23:00:10 +0100 Subject: gpgme usage In-Reply-To: <1236264684.8180.8.camel@gezenti> (Oguz Yarimtepe's message of "Thu, 05 Mar 2009 16:51:24 +0200") References: <1236181206.3949.12.camel@ELK1655> <87tz68ciwa.fsf@wheatstone.g10code.de> <1236264684.8180.8.camel@gezenti> Message-ID: <87k573d40l.fsf@wheatstone.g10code.de> On Thu, 5 Mar 2009 15:51, comp.ogz at gmail.com said: >> My guess is that you need to enable Large File support. The gpgme >> manual has a chapter on this. > > Should i really enable it? It is just the text file (cipher-1.asc at the > tests directory.) If your system does not use LFS by default it can't work. Recall that you use a gpgme_data_seek in print_data and that function takes an off_t. GPGME has been build with LFS support and if your system doesn't use LFS by default we have a 32 / 64 bit mismatch in the off_t and thus the stack gets corrupted. gpgme_data_seek sees other arguments than you passed and thus it returns you an error. Please read the manual. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Fri Mar 6 09:19:34 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Mar 2009 09:19:34 +0100 Subject: Cross compilation failed In-Reply-To: <200902191333.34482.I.demonstrate@gmail.com> (Li He's message of "Thu, 19 Feb 2009 13:33:34 +0800") References: <200902191333.34482.I.demonstrate@gmail.com> Message-ID: <873adrcbc9.fsf@wheatstone.g10code.de> On Thu, 19 Feb 2009 06:33, i.demonstrate at gmail.com said: > Hi all. I want to make a Win32 port of GnuPG 2.0.10 from my sid with > the help of mingw32. The easiest way is to use the gpg4win installer (the tar.bz2 file) which makes sure that everthing is in place. If you want to manually build it, I suggest to create a directory $HOME/w32root or alternativley any other directory and set w32root=directory. Then you can just use ./autogen.sh --build-w32 && make install for all GnuPG related packages (those with that script). For the other packages you need to pass appropriate options to ./configure. Start with libgpg-error, libgcrypt, w32pth, libassuan, libksba. > When cross compiling libassuan, I got the following warnings: > configure: WARNING: > *** > *** Data structure for sending ancillary data missing. > *** Descriptor passing won't work. > *** > *** > *** No implementation of fopencookie or funopen available. > *** The assuan_get_data_fp feature won't work. > *** That's okay. > -L/home/heli/w32root/lib [...] > ../gl/libgnu.a ../common/libgpgrl.a -lz -lreadline -lws2_32 - > lgcrypt -lassuan -lgpg-error /home/heli/w32root/lib/libiconv.dll.a - > L/home/heli/w32root/lib libassuan requires libws2_32 as well. Compare your ld command to mine: ../gl/libgnu.a ../common/libgpgrl.a -lz -lws2_32 -L/home/wk/w32root/lib -lgcrypt -lgpg-error -L/home/wk/w32root/lib -lassuan -lws2_32 -L/home/wk/w32root/lib -lgpg-error Here you see -lws2_w32 after -lassuan. This is because my libassuan-config says this. $ ~/w32root/bin/libassuan-config --libs -L/home/wk/w32root/lib -lassuan -lws2_32 My conclusion is that you do did use "./autogen.sh --build-w32" for libassuan or forgot to run "make install". The GnuPG build command is: ./configure --enable-maintainer-mode --prefix=${w32root} \ --host=${host} --build=${build} \ --with-gpg-error-prefix=${w32root} \ --with-ksba-prefix=${w32root} \ --with-libgcrypt-prefix=${w32root} \ --with-libassuan-prefix=${w32root} \ --with-zlib=${w32root} \ --with-regex=${w32root} \ --with-pth-prefix=${w32root} \ --with-adns=${w32root} \ --without-included-gettext "$@" which uses "--with-libassuan-prefix=${w32root}" and thus takes libassuan-config from ~/w32root/bin/. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From ueno at unixuser.org Fri Mar 6 10:24:03 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Fri, 06 Mar 2009 18:24:03 +0900 Subject: Caching symmetric encryption passphrase with gpg-agent Message-ID: <87y6vjt364.fsf@broken.deisui.org> Hi, Perhaps this is a stupid idea, but let me propose a proof of concept. The attached is a patch which (partially) enables passphrase caching even if symmetric encryption is used. It diverts the S2K salt to the identity of the encrypted data. Here is the sample session: $ eval `gpg-agent --daemon` $ echo aaa | ./g10/gpg2 --status-fd=2 --symmetric > test.gpg [GNUPG:] S2K 3 2 6BB569FF913024B9 96 pinentry-gtk will prompt a passphrase. Then, $ ./g10/gpg2 --status-fd=2 < test.gpg pinentry-gtk will prompt a passphrase. Again, $ ./g10/gpg2 --status-fd=2 < test.gpg The cached passphrase is used here. $ echo bbb | ./g10/gpg2 --status-fd=2 --symmetric \ --s2k-salt 6BB569FF913024B9 > test.gpg The cached passphrase is used here since the same cache key 6BB569FF913024B9 is specified with --s2k-salt. What do you think? -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg2-symenc-passphrase-cache.diff Type: text/x-diff Size: 4154 bytes Desc: not available URL: -------------- next part -------------- Regards, -- Daiki Ueno From wk at gnupg.org Fri Mar 6 11:04:20 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Mar 2009 11:04:20 +0100 Subject: Caching symmetric encryption passphrase with gpg-agent In-Reply-To: <87y6vjt364.fsf@broken.deisui.org> (Daiki Ueno's message of "Fri, 06 Mar 2009 18:24:03 +0900") References: <87y6vjt364.fsf@broken.deisui.org> Message-ID: <87tz67arx7.fsf@wheatstone.g10code.de> On Fri, 6 Mar 2009 10:24, ueno at unixuser.org said: > Perhaps this is a stupid idea, but let me propose a proof of concept. > The attached is a patch which (partially) enables passphrase caching > even if symmetric encryption is used. It diverts the S2K salt to the > identity of the encrypted data. Here is the sample session: Using the salt as a cache id is a clever idea. That allows to decrypt a message during the caching time without entering the passphrase again. I am not sure whether there is a use case for this. Reusing the salt for another message defeats the purpose of the salt and thus makes no sense. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From comp.ogz at gmail.com Mon Mar 9 10:40:31 2009 From: comp.ogz at gmail.com (Oguz Yarimtepe) Date: Mon, 9 Mar 2009 11:40:31 +0200 Subject: gpgme usage In-Reply-To: <87k573d40l.fsf@wheatstone.g10code.de> References: <1236181206.3949.12.camel@ELK1655> <87tz68ciwa.fsf@wheatstone.g10code.de> <1236264684.8180.8.camel@gezenti> <87k573d40l.fsf@wheatstone.g10code.de> Message-ID: <20831c740903090240k5174451etc0baa2342f1f904b@mail.gmail.com> Hi, On Fri, Mar 6, 2009 at 12:00 AM, Werner Koch wrote: > On Thu, ?5 Mar 2009 15:51, comp.ogz at gmail.com said: > > > If your system does not use LFS by default it can't work. ?Recall that > you use a gpgme_data_seek in print_data and that function takes an > off_t. ?GPGME has been build with LFS support and if your system doesn't > use LFS by default we have a 32 / 64 bit mismatch in the off_t and thus > the stack gets corrupted. ?gpgme_data_seek sees other arguments than you > passed and thus it returns you an error. ?Please read the manual. > > I didn't need LFS so i recompiled gpgme by disabling lfs support, after your warning and reading the manual detaily. Then the code worked. I thought some people may had the same issue in the future and encounter with the thread. Better to make a feedback on the list. Thank you. -- O?uz Yar?mtepe www.loopbacking.info From comp.ogz at gmail.com Mon Mar 9 10:49:28 2009 From: comp.ogz at gmail.com (Oguz Yarimtepe) Date: Mon, 9 Mar 2009 11:49:28 +0200 Subject: verify problem Message-ID: <20831c740903090249l64817b34qbf989676b41f3603@mail.gmail.com> Hi, I was trying to verify a binary file which is signed by using "gpg -s" command. But i couldn't managed to make my code work. I decided to try a simple example to understand the basics so i checked the t-verify.c file under tests directory. I am using gpgme1.0-1.1.5 which is compiled with lfs support disabled. mytest-verify2.c is nearly same with the t-verify.c file. What i didn't understand about the code is, the signed message test_sig2, should be verified with a public key. How does gpgme_op_verify find that public key and verify the signed message whcih has a cleartext sign? So i need some help to figure out the problem. If i can understand what the problem with this code i can find what should i do at the mytest-verify.c which should be verifing a binary file. Thanx. -- O?uz Yar?mtepe www.loopbacking.info -------------- next part -------------- A non-text attachment was scrubbed... Name: mytest-verify2.c Type: text/x-csrc Size: 1150 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mytest-verify.c Type: text/x-csrc Size: 6177 bytes Desc: not available URL: From i.demonstrate at gmail.com Mon Mar 9 13:42:34 2009 From: i.demonstrate at gmail.com (He, Li) Date: Mon, 9 Mar 2009 20:42:34 +0800 Subject: Cross compilation failed In-Reply-To: <873adrcbc9.fsf@wheatstone.g10code.de> References: <200902191333.34482.I.demonstrate@gmail.com> <873adrcbc9.fsf@wheatstone.g10code.de> Message-ID: <200903092042.41734.I.demonstrate@gmail.com> On Friday 06 March 2009, Werner Koch wrote: > My conclusion is that you do did use "./autogen.sh --build-w32" for > libassuan or forgot to run "make install". The GnuPG build command > is: > > ./configure --enable-maintainer-mode --prefix=${w32root} \ > --host=${host} --build=${build} \ > --with-gpg-error-prefix=${w32root} \ > --with-ksba-prefix=${w32root} \ > --with-libgcrypt-prefix=${w32root} \ > --with-libassuan-prefix=${w32root} \ > --with-zlib=${w32root} \ > --with-regex=${w32root} \ > --with-pth-prefix=${w32root} \ > --with-adns=${w32root} \ > --without-included-gettext "$@" > > which uses "--with-libassuan-prefix=${w32root}" and thus takes > libassuan-config from ~/w32root/bin/. > > > > Shalom-Salam, > > Werner Thanks a lot! It works now :-D -- He, Li Shanghai Key Lab of Intelligent Information Processing School of Computer Science, Fudan University, Shanghai, China E-mail: I.demonstrate at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Mar 9 14:58:05 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Mar 2009 14:58:05 +0100 Subject: verify problem In-Reply-To: <20831c740903090249l64817b34qbf989676b41f3603@mail.gmail.com> (Oguz Yarimtepe's message of "Mon, 9 Mar 2009 11:49:28 +0200") References: <20831c740903090249l64817b34qbf989676b41f3603@mail.gmail.com> Message-ID: <87tz62ajde.fsf@wheatstone.g10code.de> On Mon, 9 Mar 2009 10:49, comp.ogz at gmail.com said: > should be verified with a public key. How does gpgme_op_verify find > that public key and verify the signed message whcih has a cleartext > sign? So i need some help to figure out the problem. The signature has a key ID and gpg uses this key id to find the key. The key needs to be in the pubring.gpg of course. There are gpg options to retrieve the key from an external sources (keyserver) on the fly. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From gniibe at fsij.org Tue Mar 10 01:50:17 2009 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 10 Mar 2009 09:50:17 +0900 Subject: USB Token for GnuPG Message-ID: <49B5B949.4070003@fsij.org> Hi, I'm new to this list, pardon my ignorance if any. I have an idea for USB Token which speaks OpenPGP card protocol, and its Free Software implementation. The use-case will be like FSFE membership card, but it won't require USB card reader. I have done a little development with Atmel AVR ATmega328P 20MHz. Currently, my mockup code works for "gpg --card-status" and "gpg --clearsign". RSA signing takes five seconds or so. Not that good, but not that bad, I think. I know that it's totally not secure than Smart Card. Still, I think that it could be used for some cases which don't require much security, and it could be a reference device side Free Software implementation. Does it make sense? Attached is a picture of my device. Any comments will be appreciated. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: fsij-usb-token-experimental.jpg Type: image/jpeg Size: 13676 bytes Desc: not available URL: From rfransix at comcast.net Tue Mar 10 04:45:04 2009 From: rfransix at comcast.net (Richard Francis) Date: Mon, 9 Mar 2009 22:45:04 -0500 Subject: compiling issue on aix 4.3.2.0 Message-ID: <9BB4AB8C6FE248569E334E0FC814F5F8@fortgolf58> Hi, Does anyone have a packaged installation for AIX v4.3.2, that works? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Mar 10 12:39:45 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Mar 2009 12:39:45 +0100 Subject: USB Token for GnuPG In-Reply-To: <49B5B949.4070003@fsij.org> (NIIBE Yutaka's message of "Tue, 10 Mar 2009 09:50:17 +0900") References: <49B5B949.4070003@fsij.org> Message-ID: <87iqmha9oe.fsf@wheatstone.g10code.de> Hi, On Tue, 10 Mar 2009 01:50, gniibe at fsij.org said: > I have done a little development with Atmel AVR ATmega328P 20MHz. > Currently, my mockup code works for "gpg --card-status" and > "gpg --clearsign". RSA signing takes five seconds or so. Not that Cool. Does that implement the ISO-7816 commands or did you changed the GnuPG code? FWIW, there is a somewhat related project which uses a chip from a regular card: http://wiki.privacyfoundation.de/GPFCryptoStick Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From comp.ogz at gmail.com Tue Mar 10 16:24:10 2009 From: comp.ogz at gmail.com (Oguz Yarimtepe) Date: Tue, 10 Mar 2009 17:24:10 +0200 Subject: cross compilation and GPGME: Invalid crypto engine error Message-ID: <1236698658.21511.10.camel@ELK1655> Hi, I cross compiled gpgme1.0-1.1.5 for STLinux2.2 system. First i cross compiled and installed pth-2.0.7, then libgpg-error-1.4, gnupg-1.4.6 and gpgme1.0-1.1.5. I disabled lfs while compiling gpgme. After installation i compiled my c code. When i ran the binary, i got the error message saying "GPGME: Invalid crypto engine error" at the line 111 that is gpgme_engine_check_version function. At the cross compiled system, i ran gpg --list-keys and i could see the keys. Also i could see the gpg -se -r "something" test.txt working. gpg -d also working. I might be doing something missing. Maybe some library files are missing. When i ran "gpg --list-keys" first time i had libbz2 and libusb errors saying the so files are missing. I found them from the devkit and transferred them to the cross platform. I will be happy if you give some clues to understand what the problem is. I may try recompiling or check some log files but i am not sure what to look. Thanx. From comp.ogz at gmail.com Tue Mar 10 16:36:38 2009 From: comp.ogz at gmail.com (Oguz Yarimtepe) Date: Tue, 10 Mar 2009 17:36:38 +0200 Subject: [Fwd: cross compilation and GPGME: Invalid crypto engine error] Message-ID: <1236699408.21511.14.camel@ELK1655> Related with the below issue this output may give a clue which i dont have what it means yet. gpgme_debug: level=9 posix-io.c:145: closing fd 4 posix-io.c:82: fd 3: about to read 79 bytes posix-io.c:89: fd 3: got 0 bytes posix-io.c:145: closing fd 3 posix-io.c:145: closing fd 4 posix-io.c:82: fd 3: about to read 79 bytes posix-io.c:89: fd 3: got 0 bytes posix-io.c:145: closing fd 3 trustcheck.h:111: GPGME: Invalid crypto engine trustcheck.h:163: GPGME: Invalid crypto engine -------- Forwarded Message -------- From: Oguz Yarimtepe Reply-To: gnupg-devel at gnupg.org To: gnupg-devel at gnupg.org Subject: cross compilation and GPGME: Invalid crypto engine error Date: Tue, 10 Mar 2009 17:24:10 +0200 Hi, I cross compiled gpgme1.0-1.1.5 for STLinux2.2 system. First i cross compiled and installed pth-2.0.7, then libgpg-error-1.4, gnupg-1.4.6 and gpgme1.0-1.1.5. I disabled lfs while compiling gpgme. After installation i compiled my c code. When i ran the binary, i got the error message saying "GPGME: Invalid crypto engine error" at the line 111 that is gpgme_engine_check_version function. At the cross compiled system, i ran gpg --list-keys and i could see the keys. Also i could see the gpg -se -r "something" test.txt working. gpg -d also working. I might be doing something missing. Maybe some library files are missing. When i ran "gpg --list-keys" first time i had libbz2 and libusb errors saying the so files are missing. I found them from the devkit and transferred them to the cross platform. I will be happy if you give some clues to understand what the problem is. I may try recompiling or check some log files but i am not sure what to look. Thanx. From buanzo at buanzo.com.ar Tue Mar 10 20:46:09 2009 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Tue, 10 Mar 2009 17:46:09 -0200 Subject: Semi-OT: Enigform for Wordpress Message-ID: <49B6C381.50507@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi team, Werner et al, yesterday I released an alpha-quality Enigform (Firefox plugin that uses GnuPG to sign HTTP requests and initiate secure sessions to mod_openpgp-enabled Apache servers) plugin for Wordpress. Basicly, it's just a hack of a standard HTTP Authentication plugin, but using the Enigform/mod_openpgp HTTP headers. Just thought someone might like it, considering the 'GnuPG and Python' thread is related to it! ;) Bye! - -- Arturo "Buanzo" Busleiman / Arturo Busleiman @ 4:900/107 Independent Linux and Security Consultant - SANS - OISSG - OWASP http://www.buanzo.com.ar/pro/eng.html Mailing List Archives at http://archiver.mailfighter.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkm2w4EACgkQAlpOsGhXcE2n2wCaAvOOQFp26By5QccnTk9Zv6Wb Tr8AnAtFQj4YuBi+vrE6RDX7Gn9aAKZB =lRfy -----END PGP SIGNATURE----- From gniibe at fsij.org Wed Mar 11 00:43:22 2009 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 11 Mar 2009 08:43:22 +0900 Subject: USB Token for GnuPG In-Reply-To: <87iqmha9oe.fsf@wheatstone.g10code.de> References: <49B5B949.4070003@fsij.org> <87iqmha9oe.fsf@wheatstone.g10code.de> Message-ID: <49B6FB1A.4080804@fsij.org> Hi, Werner Koch wrote: > Cool. Does that implement the ISO-7816 commands or did you changed the > GnuPG code? No changes needed for GnuPG code. Although it's quite bad code now (mostly hardcoded, many layer violation, etc.), it implements ISO-7816 commands on top of USB-ICC version A (T=0) protocol. While we don't change GnuPG, I needed changes for ccid. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503638 I am not that confident for USB-ICC protocol. I will report again for details for this bug soon. FSIJ (Free Software Initiative of Japan) will have a meeting next week for this USB Token. After that, I will put current implementation to our web site. Note that hardware design is just taken from AVR-USB project. Perhaps, I will publish RSA computation code for AVR separately, it's basically based on the work by Tom St Denis and heavenly hacked in AVR assembler. > FWIW, there is a somewhat related project which uses a chip from a regular > card: http://wiki.privacyfoundation.de/GPFCryptoStick Yes, I know this. I think that GPFCryptoStick would be good for real use. FSIJ's USB Token would be a kind of "development reference" or something. Given this little success, I am considering to implement ECC instead of RSA, because RSA 1024-bit won't survive so long, and we can expect less seconds for computation. -- From wk at gnupg.org Wed Mar 11 15:14:55 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Mar 2009 15:14:55 +0100 Subject: USB Token for GnuPG In-Reply-To: <49B6FB1A.4080804@fsij.org> (NIIBE Yutaka's message of "Wed, 11 Mar 2009 08:43:22 +0900") References: <49B5B949.4070003@fsij.org> <87iqmha9oe.fsf@wheatstone.g10code.de> <49B6FB1A.4080804@fsij.org> Message-ID: <87eix4w3hc.fsf@wheatstone.g10code.de> On Wed, 11 Mar 2009 00:43, gniibe at fsij.org said: > No changes needed for GnuPG code. Although it's quite bad code now > (mostly hardcoded, many layer violation, etc.), it implements ISO-7816 > commands on top of USB-ICC version A (T=0) protocol. I don't have a copy of 7816-12 here so I don't know any details. However it seems that there is a version B which sends complete APDUs. Any chance to implement that versions to get rid of the T=0 protocol with all its problems? > Given this little success, I am considering to implement ECC instead > of RSA, because RSA 1024-bit won't survive so long, and we can expect > less seconds for computation. There is I-D to extend OpenPGP with ECC and we are already working on an GnuPG implementation. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From comp.ogz at gmail.com Wed Mar 11 16:45:40 2009 From: comp.ogz at gmail.com (Oguz Yarimtepe) Date: Wed, 11 Mar 2009 17:45:40 +0200 Subject: cross problem at gpgme Message-ID: <1236786350.7794.5.camel@ELK1655> Hi, I have a cross compile problem of gpgme. Although i had set the LD_LIBRARY_PATH and LDFLAGS i am getting errors at the make process of gpgme. Below is how i compile: ./configure --host="sh4-linux" --prefix="$ROOTDIR/usr" --enable-maintainer-mode --without-pth-test --with-gpg="$ROOTDIR/usr/bin" --with-gpgsm="$ROOTDIR/usr/bin" --disable-largefile --with-pth=$ROOTDIR/usr $ make /opt/STM/STLinux-2.2/devkit/sh4/lib/gcc/sh4-linux/4.1.1/../../../../sh4-linux/bin/ld: skipping incompatible /lib/ld-linux.so.2 when searching for /lib/ld-linux.so.2 /opt/STM/STLinux-2.2/devkit/sh4/lib/gcc/sh4-linux/4.1.1/../../../../sh4-linux/bin/ld: cannot find /lib/ld-linux.so.2 collect2: ld returned 1 exit status make[3]: *** [libgpgme.la] Error 1 make[3]: Leaving directory `/home/oguz/libgcrypt/trustcheck/gpgme1.0-1.1.5/gpgme' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/oguz/libgcrypt/trustcheck/gpgme1.0-1.1.5/gpgme' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/oguz/libgcrypt/trustcheck/gpgme1.0-1.1.5' make: *** [all] Error 2 Is there any one that can give me an idea about what the problem is? The compile is searching /lib for ld-linux.so file but the path it should look is somewhere different. How can i set it? Thanx. From dshaw at jabberwocky.com Thu Mar 12 14:10:58 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 12 Mar 2009 09:10:58 -0400 Subject: HKP keyservers over SSL Message-ID: <8DB37A9C-106C-419D-AFD7-707ABE1A5226@jabberwocky.com> A few weeks ago, I added support for SSL to the HKP keyserver handler (gpg(2)keys_hkp) to help test some new keyserver work that is going on. (Though "Added" is a bit of a strong term - it's really just 4-5 lines of code to tell libcurl to accept SSL.) Anyway, Werner pointed out that we may want to do something more than that. After all, gpgsm manipulates X.509 certificates for lunch. So, let's talk about it a bit: How can we do something smart here, design-wise? It would be nice to also support client auth, and not just the standard server validation SSL test. Plumbing-wise, this may be a bit tricky. libcurl itself isn't really built to take certificates from anything other than a file. It supports multiple SSL engines (OpenSSL, NSS, GnuTLS) and the "certificate from a file" concept is universal. My understanding is that there is a way to manipulate the SSL connection (including specifying certificates), but that is OpenSSL specific and wouldn't work with one of the other backends. David From harakiri_23 at yahoo.com Thu Mar 12 16:25:55 2009 From: harakiri_23 at yahoo.com (Harakiri) Date: Thu, 12 Mar 2009 08:25:55 -0700 (PDT) Subject: HKP keyservers over SSL In-Reply-To: <8DB37A9C-106C-419D-AFD7-707ABE1A5226@jabberwocky.com> Message-ID: <580629.14317.qm@web52209.mail.re2.yahoo.com> --- On Thu, 3/12/09, David Shaw wrote: > From: David Shaw > Subject: HKP keyservers over SSL > To: gnupg-devel at gnupg.org > Date: Thursday, March 12, 2009, 9:10 AM > So, let's talk about it a bit: How can we do something > smart here, design-wise? It would be nice to also support > client auth, and not just the standard server validation SSL > test. How about adding LDAP auth to gpg key search before talking about HKP. http://lists.gnupg.org/pipermail/gnupg-users/2008-May/033370.html From dshaw at jabberwocky.com Thu Mar 12 19:31:56 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 12 Mar 2009 14:31:56 -0400 Subject: HKP keyservers over SSL In-Reply-To: <580629.14317.qm@web52209.mail.re2.yahoo.com> References: <8DB37A9C-106C-419D-AFD7-707ABE1A5226@jabberwocky.com> <580629.14317.qm@web52209.mail.re2.yahoo.com> Message-ID: <20090312183156.GA1295@jabberwocky.com> On Thu, Mar 12, 2009 at 08:25:55AM -0700, Harakiri wrote: > --- On Thu, 3/12/09, David Shaw wrote: > > > So, let's talk about it a bit: How can we do something > > smart here, design-wise? It would be nice to also support > > client auth, and not just the standard server validation SSL > > test. > > > > How about adding LDAP auth to gpg key search before talking about HKP. > > http://lists.gnupg.org/pipermail/gnupg-users/2008-May/033370.html I'm happy to look at a bug report, but please do not hijack other threads to report it. David From dkg at fifthhorseman.net Thu Mar 12 20:14:18 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 12 Mar 2009 15:14:18 -0400 Subject: HKP keyservers over SSL Message-ID: <49B95F0A.4060309@fifthhorseman.net> > A few weeks ago, I added support for SSL to the HKP keyserver handler > (gpg(2)keys_hkp) to help test some new keyserver work that is going > on. (Though "Added" is a bit of a strong term - it's really just 4-5 > lines of code to tell libcurl to accept SSL.) Anyway, Werner pointed > out that we may want to do something more than that. After all, gpgsm > manipulates X.509 certificates for lunch. There is also RFC 5081, which implements the use of OpenPGP certificates for TLS authentication. If there's a better place for rollout of that standard than OpenPGP keyserver queries, it doesn't spring immediately to mind. > So, let's talk about it a bit: How can we do something smart here, > design-wise? It would be nice to also support client auth, and not > just the standard server validation SSL test. We can support client authentication with additional curl arguments as well, via CURLOPT_SSLCERT and CURLOPT_SSLKEY. It'd be preferable to pass something like a named pipe to the latter argument before feeding it the key, to avoid writing the key to the filesystem. > Plumbing-wise, this may be a bit tricky. libcurl itself isn't really > built to take certificates from anything other than a file. It > supports multiple SSL engines (OpenSSL, NSS, GnuTLS) and the > "certificate from a file" concept is universal. I don't see any significant problem with writing certificates to a temporary file for this purpose, actually (i suppose there is the potential cleanup hassle in weird corner-case failures). Writing keys to a file seems more problematic, though. > My understanding is > that there is a way to manipulate the SSL connection (including > specifying certificates), but that is OpenSSL specific and wouldn't > work with one of the other backends. We're already specifying certificates via --keyserver-options ca-cert-file, and that works with the gnutls backend, fwiw. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu Mar 12 22:08:56 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 12 Mar 2009 17:08:56 -0400 Subject: HKP keyservers over SSL In-Reply-To: <49B95F0A.4060309@fifthhorseman.net> References: <49B95F0A.4060309@fifthhorseman.net> Message-ID: <20090312210856.GC1295@jabberwocky.com> On Thu, Mar 12, 2009 at 03:14:18PM -0400, Daniel Kahn Gillmor wrote: > > A few weeks ago, I added support for SSL to the HKP keyserver handler > > (gpg(2)keys_hkp) to help test some new keyserver work that is going > > on. (Though "Added" is a bit of a strong term - it's really just 4-5 > > lines of code to tell libcurl to accept SSL.) Anyway, Werner pointed > > out that we may want to do something more than that. After all, gpgsm > > manipulates X.509 certificates for lunch. > > There is also RFC 5081, which implements the use of OpenPGP certificates > for TLS authentication. If there's a better place for rollout of that > standard than OpenPGP keyserver queries, it doesn't spring immediately > to mind. Does anyone implement other than GnuTLS support 5081? libcurl can be built with different crypto libraries. > > So, let's talk about it a bit: How can we do something smart here, > > design-wise? It would be nice to also support client auth, and not > > just the standard server validation SSL test. > > We can support client authentication with additional curl arguments as > well, via CURLOPT_SSLCERT and CURLOPT_SSLKEY. It'd be preferable to > pass something like a named pipe to the latter argument before feeding > it the key, to avoid writing the key to the filesystem. Named pipes for this are a dangerous hack. Remember that that curl doesn't really process the CURLOPT_SSL* options. Rather, it passes them wholesale to the underlying crypto library. I don't think we can guarantee that all of the libraries involved here (openssl, gnutls, nss) will do the right thing with a named pipe (no seeks allowed!). Even if they did work today, there is no guarantee it would work forever. It's just not a stable API we can rely on. The key passphrase we can pass in memory - it's just the (presumably encrypted) key itself that has no easy way to transfer. (One way to look at it is that the key is presumably starting in the filesystem in the GPG keyring. It does seem a shame to write it out again though.) > > Plumbing-wise, this may be a bit tricky. libcurl itself isn't really > > built to take certificates from anything other than a file. It > > supports multiple SSL engines (OpenSSL, NSS, GnuTLS) and the > > "certificate from a file" concept is universal. > > I don't see any significant problem with writing certificates to a > temporary file for this purpose, actually (i suppose there is the > potential cleanup hassle in weird corner-case failures). Writing keys > to a file seems more problematic, though. Right. > > My understanding is > > that there is a way to manipulate the SSL connection (including > > specifying certificates), but that is OpenSSL specific and wouldn't > > work with one of the other backends. > > We're already specifying certificates via --keyserver-options > ca-cert-file, and that works with the gnutls backend, fwiw. Of course that works. As I said before, passing things by file is universal. The problem is that there is no reliable API for passing things *other than* by file. As we've already established, passing keys via file is a bit ugly. Not a catastrophe, as the key is presumably encrypted, but certainly ugly and prone to headaches. David From dkg at fifthhorseman.net Thu Mar 12 22:33:35 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 12 Mar 2009 17:33:35 -0400 Subject: HKP keyservers over SSL In-Reply-To: <20090312210856.GC1295@jabberwocky.com> References: <49B95F0A.4060309@fifthhorseman.net> <20090312210856.GC1295@jabberwocky.com> Message-ID: <49B97FAF.7080500@fifthhorseman.net> On 03/12/2009 05:08 PM, David Shaw wrote: > Does anyone implement other than GnuTLS support 5081? libcurl can be > built with different crypto libraries. No, only GnuTLS supports it at the moment, afaict. But GnuPG linked to Curl linked to GnuTLS isn't a completely uncommon situation either (e.g. that's the way the debian gnupg2 packages are configured). If gnupg could support it in this particular case, it'd be nice (though i suspect that's something we'd ultimately need to talk to the curl developers about). > Named pipes for this are a dangerous hack. Remember that that curl > doesn't really process the CURLOPT_SSL* options. Rather, it passes > them wholesale to the underlying crypto library. I don't think we can > guarantee that all of the libraries involved here (openssl, gnutls, > nss) will do the right thing with a named pipe (no seeks allowed!). > Even if they did work today, there is no guarantee it would work > forever. It's just not a stable API we can rely on. Hrm, yeah, that's probably true. > Of course that works. As I said before, passing things by file is > universal. Actually, looking at curl_easy_setopt(3), it appears that CURLOPT_CAINFO *doesn't* refer to a file when linked to NSS: > When built against NSS this is the directory that the NSS cer? > tificate database resides in. So even passing as a file isn't universal :( (i've never actually used curl linked against NSS, fwiw) It seems to me like client certificate support is something gnupg should have eventually, but i'm not certain that the feature should hold up anonymous TLS-wrapped HKP access. If gnupg were to support it, it would be an additional argument --keyserver-option, right? Another way around all of this is would be to not use curl at all, and implement the TLS layer directly in what's now the curl shim. This would also let us follow the HTTP upgrade approach over the same port, but would mean more code to maintain (and probably wouldn't handle as many edge cases as nicely as curl does for us automatically). It would also probably bind GnuPG to a single TLS library, since i doubt anyone wants to maintain multiple variants of the shim itself. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu Mar 12 23:20:36 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 12 Mar 2009 18:20:36 -0400 Subject: HKP keyservers over SSL In-Reply-To: <49B97FAF.7080500@fifthhorseman.net> References: <49B95F0A.4060309@fifthhorseman.net> <20090312210856.GC1295@jabberwocky.com> <49B97FAF.7080500@fifthhorseman.net> Message-ID: <20090312222036.GE1295@jabberwocky.com> On Thu, Mar 12, 2009 at 05:33:35PM -0400, Daniel Kahn Gillmor wrote: > It seems to me like client certificate support is something gnupg should > have eventually, but i'm not certain that the feature should hold up > anonymous TLS-wrapped HKP access. Oh, I agree. I just don't want to do anything now that will preclude doing the other stuff later, if we choose to. It's worth a bit of discussion to keep our options open for later. > If gnupg were to support it, it would > be an additional argument --keyserver-option, right? Probably, yes. > Another way around all of this is would be to not use curl at all, and > implement the TLS layer directly in what's now the curl shim. This > would also let us follow the HTTP upgrade approach over the same port, > but would mean more code to maintain (and probably wouldn't handle as > many edge cases as nicely as curl does for us automatically). It would > also probably bind GnuPG to a single TLS library, since i doubt anyone > wants to maintain multiple variants of the shim itself. I thought about this, but it's a path I'm reluctant to go down for all the reasons you mention. Curl takes care of a huge amount of annoyance for us. If we needed some special TLS code in Curl, instead of doing something GPG-specific, it would be cleaner all around to implement the code in a general fashion and just give it to the Curl folks. Tell me a bit about how you rigged up the SSLized sks server (it's a wrapper, no?) Let's say for the sake of argument that curl supported TLS upgrade (it doesn't - but let say it did). How difficult would it be to you to support it in sks? David From dkg at fifthhorseman.net Fri Mar 13 14:09:44 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Mar 2009 09:09:44 -0400 Subject: HKP keyservers over TLS [was: Re: HKP keyservers over SSL] In-Reply-To: <20090312222036.GE1295@jabberwocky.com> References: <49B95F0A.4060309@fifthhorseman.net> <20090312210856.GC1295@jabberwocky.com> <49B97FAF.7080500@fifthhorseman.net> <20090312222036.GE1295@jabberwocky.com> Message-ID: <49BA5B18.2070000@fifthhorseman.net> On 03/12/2009 06:20 PM, David Shaw wrote: > Curl takes care of a huge amount of > annoyance for us. If we needed some special TLS code in Curl, instead > of doing something GPG-specific, it would be cleaner all around to > implement the code in a general fashion and just give it to the Curl > folks. Yes, this does seem like a better way to go, if we can frame our changes in such a way that the curl folks are receptive > Tell me a bit about how you rigged up the SSLized sks server (it's a > wrapper, no?) Let's say for the sake of argument that curl supported > TLS upgrade (it doesn't - but let say it did). How difficult would it > be to you to support it in sks? At the moment, we're just running an nginx proxy as a TLS-based frontend, talking to SKS which is listening on the loopback. nginx configuration details are here: http://lists.gnu.org/archive/html/sks-devel/2009-03/msg00029.html It does *not* currently support TLS upgrade. As you said earlier, RFC 2817 never seemed to have caught on. I don't know what it would take to support it, either in sks directly, or by hacking together some other reverse proxy as a frontend. A brief review of the popular free tools capable of acting as reverse HTTP/HTTPS proxies (nginx, squid, varnish, pound) doesn't show any of these tools offering TLS Upgrade support. I suspect this is something that would need to be hacked together within SKS. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From marcus.brinkmann at ruhr-uni-bochum.de Fri Mar 13 22:36:03 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 13 Mar 2009 22:36:03 +0100 Subject: cross compilation and GPGME: Invalid crypto engine error In-Reply-To: <1236698658.21511.10.camel@ELK1655> References: <1236698658.21511.10.camel@ELK1655> Message-ID: <49BAD1C3.6070606@ruhr-uni-bochum.de> Oguz Yarimtepe wrote: > Hi, > > I cross compiled gpgme1.0-1.1.5 for STLinux2.2 system. First i cross > compiled and installed pth-2.0.7, then libgpg-error-1.4, gnupg-1.4.6 and > gpgme1.0-1.1.5. I disabled lfs while compiling gpgme. After installation > i compiled my c code. When i ran the binary, i got the error message > saying "GPGME: Invalid crypto engine error" at the line 111 that is > gpgme_engine_check_version function. This could be due to gpgme not finding the gpg binary. gpgme detects the path to gpg at configure time and it is compiled into the library. Check the output of configure, it prints the detected paths. It should have complained about cross compilation and given you advice to use --with-gpg=path to configure it, How did you invoke configure for cross compilation? > At the cross compiled system, i ran gpg --list-keys and i could see the > keys. Also i could see the gpg -se -r "something" test.txt working. gpg > -d also working. env GPGME_DEBUG=9 gives you more info about what GPGME is doing. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Fri Mar 13 22:41:57 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 13 Mar 2009 22:41:57 +0100 Subject: cross problem at gpgme In-Reply-To: <1236786350.7794.5.camel@ELK1655> References: <1236786350.7794.5.camel@ELK1655> Message-ID: <49BAD325.4080007@ruhr-uni-bochum.de> Oguz Yarimtepe wrote: > I have a cross compile problem of gpgme. Although i had set the > LD_LIBRARY_PATH and LDFLAGS i am getting errors at the make process of > gpgme. > > Below is how i compile: > > ./configure --host="sh4-linux" --prefix="$ROOTDIR/usr" > --enable-maintainer-mode --without-pth-test > --with-gpg="$ROOTDIR/usr/bin" --with-gpgsm="$ROOTDIR/usr/bin" > --disable-largefile --with-pth=$ROOTDIR/usr Oooh, you got some paths wrong. 1. --prefix must be the *host* path. This means that it should just be "/usr", not $ROOTDIR/usr. But this breaks make install, so ... 2. ... you need to specify $ROOTDIR with make install: $ make install DESTDIR="$ROOTDIR" 3. --with-gpg and --with-gpgsm also must be *host* paths, and in fact the full filename to the gpg binary, so: --with-gpg=/usr/bin/gpg --with-gpgsm=/usr/bin/gpgsm These files do not need to exist. They are not used at build time (unless you run the test suite, which is disabled when cross compiling). The --with-pth spec is fine. Good luck, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Fri Mar 13 22:25:46 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 13 Mar 2009 22:25:46 +0100 Subject: gpgme usage In-Reply-To: <20831c740903090240k5174451etc0baa2342f1f904b@mail.gmail.com> References: <1236181206.3949.12.camel@ELK1655> <87tz68ciwa.fsf@wheatstone.g10code.de> <1236264684.8180.8.camel@gezenti> <87k573d40l.fsf@wheatstone.g10code.de> <20831c740903090240k5174451etc0baa2342f1f904b@mail.gmail.com> Message-ID: <49BACF5A.7010900@ruhr-uni-bochum.de> Oguz Yarimtepe wrote: > I didn't need LFS so i recompiled gpgme by disabling lfs support, > after your warning and reading the manual detaily. Then the code > worked. I thought some people may had the same issue in the future and > encounter with the thread. Better to make a feedback on the list. It would be a good idea to rename the library then, just to make sure that you don't get accidential problems. I'd suggest gpgme-no-lfs. Although I don't really see why you wouldn't want to add the -D for LFS. It costs you nothing, and is the default for many environments (like GNOME). Thanks, Marcus From rfransix at comcast.net Sat Mar 14 05:15:17 2009 From: rfransix at comcast.net (Richard Francis) Date: Fri, 13 Mar 2009 23:15:17 -0500 Subject: Libgcrypt compile on aix 4.3.2.0 failing, any help? Message-ID: Any help on resolving this is greatly appreciated. This is from libgcrypt-1.4.3, and the make for 1.4.4 is below (both fail). # make make all-recursive Making all in mpi source='mpih-div.c' object='mpih-div.lo' libtool=yes DEPDIR=.deps depmode=gcc /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile gc c -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -Wpointer-arith -c -o mpih-div.lo mpih-div.c gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -Wpointer-arith -c mpih-div.c -Wp,-MD,.deps/mpih-div.TPlo -DPIC -o .libs /mpih-div.o mpih-div.c: In function `_gcry_mpih_mod_1': mpih-div.c:84: warning: implicit declaration of function `__udiv_w_sdiv' mpih-div.c:98: Invalid `asm' statement: mpih-div.c:98: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:99: Invalid `asm' statement: mpih-div.c:99: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:104: Invalid `asm' statement: mpih-div.c:104: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:105: Invalid `asm' statement: mpih-div.c:105: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:134: Invalid `asm' statement: mpih-div.c:134: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:134: Invalid `asm' statement: mpih-div.c:134: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c: In function `_gcry_mpih_divrem': mpih-div.c:288: Invalid `asm' statement: mpih-div.c:288: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:352: Invalid `asm' statement: mpih-div.c:352: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c: In function `_gcry_mpih_divmod_1': mpih-div.c:445: Invalid `asm' statement: mpih-div.c:445: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:446: Invalid `asm' statement: mpih-div.c:446: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:451: Invalid `asm' statement: mpih-div.c:451: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:452: Invalid `asm' statement: mpih-div.c:452: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:480: Invalid `asm' statement: mpih-div.c:480: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:480: Invalid `asm' statement: mpih-div.c:480: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. libgcrypt-1.4.4 make: # make make all-recursive Making all in mpi source='mpi-add.c' object='mpi-add.lo' libtool=yes DEPDIR=.deps depmode=gcc /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c -o mpi-add.lo mpi-add.c mkdir .libs gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c mpi-add.c -Wp,-MD,.deps/mpi-add.TPlo -DPIC -o .libs/mpi-add.o source='mpi-bit.c' object='mpi-bit.lo' libtool=yes DEPDIR=.deps depmode=gcc /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c -o mpi-bit.lo mpi-bit.c gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c mpi-bit.c -Wp,-MD,.deps/mpi-bit.TPlo -DPIC -o .libs/mpi-bit.o source='mpi-cmp.c' object='mpi-cmp.lo' libtool=yes DEPDIR=.deps depmode=gcc /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c -o mpi-cmp.lo mpi-cmp.c gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c mpi-cmp.c -Wp,-MD,.deps/mpi-cmp.TPlo -DPIC -o .libs/mpi-cmp.o source='mpi-div.c' object='mpi-div.lo' libtool=yes DEPDIR=.deps depmode=gcc /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c -o mpi-div.lo mpi-div.c gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c mpi-div.c -Wp,-MD,.deps/mpi-div.TPlo -DPIC -o .libs/mpi-div.o source='mpi-gcd.c' object='mpi-gcd.lo' libtool=yes DEPDIR=.deps depmode=gcc /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c -o mpi-gcd.lo mpi-gcd.c gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c mpi-gcd.c -Wp,-MD,.deps/mpi-gcd.TPlo -DPIC -o .libs/mpi-gcd.o source='mpi-inline.c' object='mpi-inline.lo' libtool=yes DEPDIR=.deps depmode=gcc /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compil e gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c -o mpi-inline.lo mpi-inline.c gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c mpi-inline.c -Wp,-MD,.deps/mpi-inline.TPlo -DPIC -o .libs/mpi-inline. o source='mpi-inv.c' object='mpi-inv.lo' libtool=yes DEPDIR=.deps depmode=gcc /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c -o mpi-inv.lo mpi-inv.c gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c mpi-inv.c -Wp,-MD,.deps/mpi-inv.TPlo -DPIC -o .libs/mpi-inv.o source='mpi-mul.c' object='mpi-mul.lo' libtool=yes DEPDIR=.deps depmode=gcc /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c -o mpi-mul.lo mpi-mul.c gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c mpi-mul.c -Wp,-MD,.deps/mpi-mul.TPlo -DPIC -o .libs/mpi-mul.o source='mpi-mod.c' object='mpi-mod.lo' libtool=yes DEPDIR=.deps depmode=gcc /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c -o mpi-mod.lo mpi-mod.c gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c mpi-mod.c -Wp,-MD,.deps/mpi-mod.TPlo -DPIC -o .libs/mpi-mod.o source='mpi-pow.c' object='mpi-pow.lo' libtool=yes DEPDIR=.deps depmode=gcc /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c -o mpi-pow.lo mpi-pow.c gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c mpi-pow.c -Wp,-MD,.deps/mpi-pow.TPlo -DPIC -o .libs/mpi-pow.o source='mpi-mpow.c' object='mpi-mpow.lo' libtool=yes DEPDIR=.deps depmode=gcc /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile gc c -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c -o mpi-mpow.lo mpi-mpow.c gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c mpi-mpow.c -Wp,-MD,.deps/mpi-mpow.TPlo -DPIC -o .libs/mpi-mpow.o source='mpi-scan.c' object='mpi-scan.lo' libtool=yes DEPDIR=.deps depmode=gcc /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile gc c -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c -o mpi-scan.lo mpi-scan.c gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c mpi-scan.c -Wp,-MD,.deps/mpi-scan.TPlo -DPIC -o .libs/mpi-scan.o source='mpicoder.c' object='mpicoder.lo' libtool=yes DEPDIR=.deps depmode=gcc /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile gc c -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c -o mpicoder.lo mpicoder.c gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c mpicoder.c -Wp,-MD,.deps/mpicoder.TPlo -DPIC -o .libs/mpicoder.o source='mpih-div.c' object='mpih-div.lo' libtool=yes DEPDIR=.deps depmode=gcc /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile gc c -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c -o mpih-div.lo mpih-div.c gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 -Wall -c mpih-div.c -Wp,-MD,.deps/mpih-div.TPlo -DPIC -o .libs/mpih-div.o mpih-div.c: In function `_gcry_mpih_mod_1': mpih-div.c:84: warning: implicit declaration of function `__udiv_w_sdiv' mpih-div.c:98: Invalid `asm' statement: mpih-div.c:98: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:99: Invalid `asm' statement: mpih-div.c:99: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:104: Invalid `asm' statement: mpih-div.c:104: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:105: Invalid `asm' statement: mpih-div.c:105: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:134: Invalid `asm' statement: mpih-div.c:134: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:134: Invalid `asm' statement: mpih-div.c:134: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c: In function `_gcry_mpih_divrem': mpih-div.c:288: Invalid `asm' statement: mpih-div.c:288: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:352: Invalid `asm' statement: mpih-div.c:352: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c: In function `_gcry_mpih_divmod_1': mpih-div.c:445: Invalid `asm' statement: mpih-div.c:445: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:446: Invalid `asm' statement: mpih-div.c:446: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:451: Invalid `asm' statement: mpih-div.c:451: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:452: Invalid `asm' statement: mpih-div.c:452: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:480: Invalid `asm' statement: mpih-div.c:480: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. mpih-div.c:480: Invalid `asm' statement: mpih-div.c:480: fixed or forbidden register 64 (mq) was spilled for class MQ_REGS. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Mar 13 21:22:16 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Mar 2009 21:22:16 +0100 Subject: HKP keyservers over SSL In-Reply-To: <20090312222036.GE1295@jabberwocky.com> (David Shaw's message of "Thu, 12 Mar 2009 18:20:36 -0400") References: <49B95F0A.4060309@fifthhorseman.net> <20090312210856.GC1295@jabberwocky.com> <49B97FAF.7080500@fifthhorseman.net> <20090312222036.GE1295@jabberwocky.com> Message-ID: <87tz5x5g1z.fsf@wheatstone.g10code.de> On Thu, 12 Mar 2009 23:20, dshaw at jabberwocky.com said: > annoyance for us. If we needed some special TLS code in Curl, instead > of doing something GPG-specific, it would be cleaner all around to > implement the code in a general fashion and just give it to the Curl Given that we "control" the then-to-be server code, we won't have any problems with ugly servers which was one of the reasons to use Curl. Actually the original GnuPG http code has support for GnuTLS and thus it will be easy implement TLS directly. The code might not be in GnuPG proper, but I use copies of it in other projects. One problem I have with Curl is that it is not GNU code and we would like to have all main features of GNU software implemented by GNU code. (Well, I know that David does not share this opinion.) Anyway, we should first define the goals and then see how to accomplish that. What we want is to make it harder to see what keys are fetched from the keyserver: Obviously that should be done with TLS and we need to authenticate the server to avoid MITM attacks. For the latter we have several options: 1. Use a full fledged X.509 based TLS authentication in the standard way, i.e. requiring the server to use a well known root certificate. This can be done using any GPLv3 compatible TLS code. 2. Same as one but use an OpenPGP certificate. This requires GnuTLS. 3. Use a list of server certificate fingerprints and compare against them. For example in the DNS which is secure enough for our threat model. Recall that the servers can still track key requests. 4. Extend X.509 to allow optional authentication using an OpenPGP certificate. This general mechanism can also be used for all kind of projects. It would allow to get better server authentication while still keeping standard HTTPS semantics. There are several ways on how to implement it; for example by creating an OpenPGP certificate with a user ID made up of the keygrip of the regular X.509 certificate. 5. Forget about this all and implement it properly using an anonymizer service. That service needs to batch up queries and insert dummy queries. Should not be to hard to get this implemented in TOR. 6. Replace the keyserver stuff using a GNUNet service. That would soon lead to the question why not to replace encrypted email as we are used to entirely by a p2p system. So, better forget about this for now. The more I think about it, option 5 (enhanced TOR) looks more and more promising. The basic question is why to come up with a limited anti-surveillance mechanism if we could get a strong one as well. I am pretty sure that a few years after the major keyservers will speak TLS, real anonymity will be requested and then we can start from scratch. Regarding authenticated writes to the keyservers (user certificates): I don't think that this will ever take off. It would be the first step to a managed PKI and we all know that PKIs don't work. I see no benefits for that. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From comp.ogz at gmail.com Sat Mar 14 12:43:50 2009 From: comp.ogz at gmail.com (Oguz Yarimtepe) Date: Sat, 14 Mar 2009 13:43:50 +0200 Subject: cross compilation and GPGME: Invalid crypto engine error In-Reply-To: <49BAD1C3.6070606@ruhr-uni-bochum.de> References: <1236698658.21511.10.camel@ELK1655> <49BAD1C3.6070606@ruhr-uni-bochum.de> Message-ID: <1237031040.7243.21.camel@ELK1655> On Fri, 2009-03-13 at 22:36 +0100, Marcus Brinkmann wrote: > Oguz Yarimtepe wrote: > > Hi, > > > > I cross compiled gpgme1.0-1.1.5 for STLinux2.2 system. First i cross > > compiled and installed pth-2.0.7, then libgpg-error-1.4, gnupg-1.4.6 and > > gpgme1.0-1.1.5. I disabled lfs while compiling gpgme. After installation > > i compiled my c code. When i ran the binary, i got the error message > > saying "GPGME: Invalid crypto engine error" at the line 111 that is > > gpgme_engine_check_version function. > > This could be due to gpgme not finding the gpg binary. gpgme detects the path > to gpg at configure time and it is compiled into the library. > > Check the output of configure, it prints the detected paths. It should have > complained about cross compilation and given you advice to use --with-gpg=path > to configure it, > After struggling with a little more, i gave up and transferred the files to the cross environment. Compiled them on the cross platform. Here is the version numbers and how i configure them. pth-2.0.7 ./configure --prefix=/usr, make, make install libgpg-error-1.4 ./configure --prefix=/usr, make, make install gnupg-1.4.6 ./configure --prefix=/usr --disable-largefile, make, make install gpgme1.0-1.1.5 ./configure --prefix=/usr --enable-static --with-gpg=/usr/bin/gpg --without-gpgsm --disable-largefile --without-pth-test I am attaching the c and header file also. The application is decrypting a file and creating the decrypted version. I created the encrypted file as gpg -se -r "Mr Receiver" thefile The program is taking thefile as input. It is working on my desktop machine but the same app is not running on the cross platform. The gpgme_data_read is returning 0 so the created file size is always 0. I am attaching the log file also after the GPGME_DEBUG=9 setting. Will be happy if someone guide me to make it work. Below is the settings of the cross environment # cat /proc/cpuinfo machine : STb7100 Reference board processor : 0 cpu family : sh4 cpu type : STb710x cpu flags : fpu cache type : split (harvard) icache size : 16KiB (2-way) dcache size : 32KiB (2-way) bogomips : 263.16 pll0_clk : 531.00MHz pll1_clk : 400.00MHz sh4_clk : 265.50MHz sh4_ic_clk : 132.75MHz module_clk : 66.37MHz slim_clk : 265.50MHz comms_clk : 100.00MHz tmu0_clk : 16.59MHz # cat /proc/meminfo MemTotal: 46216 kB MemFree: 21636 kB Buffers: 0 kB Cached: 19420 kB SwapCached: 0 kB Active: 4876 kB Inactive: 15952 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 46216 kB LowFree: 21636 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB Mapped: 3416 kB Slab: 2624 kB CommitLimit: 23108 kB Committed_AS: 4156 kB PageTables: 156 kB VmallocTotal: 523252 kB VmallocUsed: 372 kB VmallocChunk: 522880 kB > How did you invoke configure for cross compilation? > > > At the cross compiled system, i ran gpg --list-keys and i could see the > > keys. Also i could see the gpg -se -r "something" test.txt working. gpg > > -d also working. > > env GPGME_DEBUG=9 gives you more info about what GPGME is doing. > > Thanks, > Marcus > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: trustcheck.c Type: text/x-csrc Size: 474 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: trustcheck.h Type: text/x-chdr Size: 4049 bytes Desc: not available URL: -------------- next part -------------- gpgme_debug: level=9 posix-io.c:145: closing fd 4 posix-io.c:82: fd 3: about to read 79 bytes posix-io.c:89: fd 3: got 79 bytes fd 3: got `gpg (GnuPG) 1.4.6 Copyright (C) 2006 Free Software Foundation, Inc. This progra' posix-io.c:145: closing fd 3 posix-io.c:167: set notification for fd 3 posix-io.c:167: set notification for fd 4 posix-io.c:167: set notification for fd 5 posix-io.c:167: set notification for fd 6 posix-io.c:145: closing fd 4 posix-io.c:145: closing fd 6 posix-io.c:332: gpgme:select on [ r3 r5 ] posix-io.c:378: select OK [ r5 ] posix-io.c:332: gpgme:select on [ r5 ] posix-io.c:378: select OK [ r5 ] posix-io.c:82: fd 5: about to read 1024 bytes posix-io.c:89: fd 5: got 340 bytes fd 5: got `tru::1:1236586545:0:3:1:5 pub:u:1024:17:40E1989F942A4E66:1236586538:::u:::scESC: fpr:::::::::0F772D0FAB0426EC5FC9C2E040E1989F942A4E66: uid:u::::1236586538::B1F263E767B5CA05C1DEE169D11EC4F0A09E8F90::Mr Receiver : sub:u:2048:16:E1BD67542A86D5F0:1236586545::::::e: fpr:::::::::3BA720B8428086FAAC1B5272E1BD67542A86D5F0: ' keylist.c:397: keylist_colon_handler ctx = 0x4120b0, key = (nil), line = tru::1:1236586545:0:3:1:5 keylist.c:397: keylist_colon_handler ctx = 0x4120b0, key = (nil), line = pub:u:1024:17:40E1989F942A4E66:1236586538:::u:::scESC: keylist.c:397: keylist_colon_handler ctx = 0x4120b0, key = 0x412fd8, line = fpr:::::::::0F772D0FAB0426EC5FC9C2E040E1989F942A4E66: keylist.c:397: keylist_colon_handler ctx = 0x4120b0, key = 0x412fd8, line = uid:u::::1236586538::B1F263E767B5CA05C1DEE169D11EC4F0A09E8F90::Mr Receiver : keylist.c:397: keylist_colon_handler ctx = 0x4120b0, key = 0x412fd8, line = sub:u:2048:16:E1BD67542A86D5F0:1236586545::::::e: keylist.c:397: keylist_colon_handler ctx = 0x4120b0, key = 0x412fd8, line = fpr:::::::::3BA720B8428086FAAC1B5272E1BD67542A86D5F0: posix-io.c:332: gpgme:select on [ r3 r5 ] posix-io.c:378: select OK [ r5 ] posix-io.c:332: gpgme:select on [ r5 ] posix-io.c:378: select OK [ r5 ] posix-io.c:82: fd 5: about to read 1024 bytes posix-io.c:89: fd 5: got 0 bytes keylist.c:397: keylist_colon_handler ctx = 0x4120b0, key = 0x412fd8, line = (null) posix-io.c:145: closing fd 5 wait.c:160: setting fd 5 (item=0x413140) done posix-io.c:145: closing fd 3 wait.c:160: setting fd 3 (item=0x413020) done posix-io.c:167: set notification for fd 3 posix-io.c:167: set notification for fd 4 posix-io.c:167: set notification for fd 5 posix-io.c:167: set notification for fd 6 posix-io.c:167: set notification for fd 7 posix-io.c:167: set notification for fd 8 posix-io.c:167: set notification for fd 9 posix-io.c:167: set notification for fd 10 posix-io.c:332: gpgme:select on [ ] posix-io.c:145: closing fd 3 posix-io.c:145: closing fd 4 posix-io.c:145: closing fd 6 posix-io.c:145: closing fd 5 posix-io.c:145: closing fd 7 posix-io.c:145: closing fd 8 posix-io.c:145: closing fd 10 posix-io.c:145: closing fd 9 40E1989F942A4E66 receiver at somewhere.com Mr Receiver ret: 0 return size=0 From comp.ogz at gmail.com Sat Mar 14 13:15:39 2009 From: comp.ogz at gmail.com (Oguz Yarimtepe) Date: Sat, 14 Mar 2009 14:15:39 +0200 Subject: verify and recover Message-ID: <1237032948.7243.29.camel@ELK1655> I want to verify and recover a binary to its original version. It is normally done via gpg as gpg -s somefile gpg --verify somefile.gpg gpg -d somefile.gpg By assuming that i have the somefile.gpg which functions i can use to manage this issue? I tried gpgme_op_decrypt_verify but it seems there should be an encrypted data. gpgme_op_verify may be achieve this but i am not so sure how to use it. From marcus.brinkmann at ruhr-uni-bochum.de Sat Mar 14 16:37:49 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 14 Mar 2009 16:37:49 +0100 Subject: verify and recover In-Reply-To: <1237032948.7243.29.camel@ELK1655> References: <1237032948.7243.29.camel@ELK1655> Message-ID: <49BBCF4D.3010007@ruhr-uni-bochum.de> Oguz Yarimtepe wrote: > I tried gpgme_op_decrypt_verify but it seems there should be an > encrypted data. gpgme_op_verify may be achieve this but i am not so sure > how to use it. >From the manual: @deftypefun gpgme_error_t gpgme_op_verify (@w{gpgme_ctx_t @var{ctx}}, @w{gpgme_data_t @var{sig}}, @w{gpgme_data_t @var{signed_text}}, @w{gpgme_data_t @var{plain}}) The function @code{gpgme_op_verify} verifies that the signature in the data object @var{sig} is a valid signature. If @var{sig} is a detached signature, then the signed text should be provided in @var{signed_text} and @var{plain} should be a null pointer. Otherwise, if @var{sig} is a normal (or cleartext) signature, @var{signed_text} should be a null pointer and @var{plain} should be a writable data object that will contain the plaintext after successful verification. So, depending on detached or inline signature, you have to invoke it with different paramters. gpgme/tests/gpg/ contains example code. Thanks, Marcus From ueno at unixuser.org Mon Mar 16 10:23:52 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Mon, 16 Mar 2009 18:23:52 +0900 Subject: Caching symmetric encryption passphrase with gpg-agent In-Reply-To: <87tz67arx7.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri, 06 Mar 2009 11:04:20 +0100") References: <87y6vjt364.fsf@broken.deisui.org> <87tz67arx7.fsf@wheatstone.g10code.de> Message-ID: <871vsxlt1z.fsf@broken.deisui.org> >>>>> In <87tz67arx7.fsf at wheatstone.g10code.de> >>>>> Werner Koch wrote: > Using the salt as a cache id is a clever idea. That allows to decrypt a > message during the caching time without entering the passphrase again. > I am not sure whether there is a use case for this. As a developer of the Emacs interface, I have frequently been asked how to cache the passphrase for symmetric encryption, and I eventually added a special option epa-file-cache-passphrase-for-symmetric-encryption. So I'm confident that those who are reluctant to generate public keys just for caching passphrases will be happy if the caching is implemented in the gpg-agent level. > Reusing the salt for another message defeats the purpose of the salt and > thus makes no sense. I see. I will try to polish my patch not including the salt-reusing functionality. Regards, -- Daiki Ueno From comp.ogz at gmail.com Mon Mar 16 13:54:01 2009 From: comp.ogz at gmail.com (Oguz Yarimtepe) Date: Mon, 16 Mar 2009 14:54:01 +0200 Subject: verify and recover In-Reply-To: <49BBCF4D.3010007@ruhr-uni-bochum.de> References: <1237032948.7243.29.camel@ELK1655> <49BBCF4D.3010007@ruhr-uni-bochum.de> Message-ID: <1237208049.8262.34.camel@ELK1655> > So, depending on detached or inline signature, you have to invoke it with > different paramters. gpgme/tests/gpg/ contains example code. I had checked the example before but after i read your explanation i fixed my code. I had to comment the summary part at the check_result function (line 94 shows nil). One of the question i want to ask is whether every signature has a summary or not? Second i realized i need to have at least the file, that is the original unsigned and not encrypted file, size of memory both for gpgme_op_verify(ctx, in, NULL, out) and gpgme_op_decrypt_verify(ctx, in, out) work correctly. Is it possible to make them work also at lesser memory size or is it required some new implementation of code? I attached my verified version of t-verify.c -------------- next part -------------- A non-text attachment was scrubbed... Name: mytest-verify.c Type: text/x-csrc Size: 2497 bytes Desc: not available URL: From marcus.brinkmann at ruhr-uni-bochum.de Mon Mar 16 15:06:52 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 16 Mar 2009 15:06:52 +0100 Subject: verify and recover In-Reply-To: <1237208049.8262.34.camel@ELK1655> References: <1237032948.7243.29.camel@ELK1655> <49BBCF4D.3010007@ruhr-uni-bochum.de> <1237208049.8262.34.camel@ELK1655> Message-ID: <49BE5CFC.4000604@ruhr-uni-bochum.de> Oguz Yarimtepe wrote: > >> So, depending on detached or inline signature, you have to invoke it with >> different paramters. gpgme/tests/gpg/ contains example code. > > I had checked the example before but after i read your explanation i > fixed my code. I had to comment the summary part at the check_result > function (line 94 shows nil). One of the question i want to ask is > whether every signature has a summary or not? The test suite contains example code and regression tests. The regression tests are of course not very useful for your own code. Every sig has a summary, which uses the validity of the key in the keyring and the signature status to give an indication (green, yellow, red) for the signature that is usable in common applications such as mail user agents. > Second i realized i need to have at least the file, that is the original > unsigned and not encrypted file, size of memory both for > gpgme_op_verify(ctx, in, NULL, out) and gpgme_op_decrypt_verify(ctx, in, > out) work correctly. > > Is it possible to make them work also at lesser memory size or is it > required some new implementation of code? I don't really understand what you are asking here. If you do not want to store the result in memory, you can use other gpgme_data_t objects, such as one based on a file descriptor, file handle, or user callback. Thanks, Marcus From ueno at unixuser.org Tue Mar 17 09:37:09 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Tue, 17 Mar 2009 17:37:09 +0900 Subject: [PATCH] unify passphrase-repeat logic into gpg-agent Message-ID: <87wsao4kay.fsf@broken.deisui.org> Hi, I noticed that the function passphrase_to_dek (in g10/passphrase.c) repeats the passphrase prompt by itself, even though for other usage (such as key generation) gpgv2 leaves gpg-agent to do that job. I think that it is consistent with gpg-agent to handle any case where passphrase-repeat is needed. The attached patch moves the implementation of the logic from passphrase_to_dek to gpg-agent. This should not change the current behavior, but it will make it easier to implement the symenc passphrase-caching which I recently proposed. -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg-agent-passphrase-repeat.diff Type: text/x-diff Size: 9099 bytes Desc: not available URL: -------------- next part -------------- Regards, -- Daiki Ueno From wk at gnupg.org Tue Mar 17 12:16:20 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Mar 2009 12:16:20 +0100 Subject: [PATCH] unify passphrase-repeat logic into gpg-agent In-Reply-To: <87wsao4kay.fsf@broken.deisui.org> (Daiki Ueno's message of "Tue, 17 Mar 2009 17:37:09 +0900") References: <87wsao4kay.fsf@broken.deisui.org> Message-ID: <87mybk5ri3.fsf@wheatstone.g10code.de> On Tue, 17 Mar 2009 09:37, ueno at unixuser.org said: > The attached patch moves the implementation of the logic from > passphrase_to_dek to gpg-agent. Applied. Thanks. I changed the agent code a bit to return an error if the call from the repeated password entry failed. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dkg at fifthhorseman.net Mon Mar 23 17:25:36 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 23 Mar 2009 12:25:36 -0400 Subject: Bug#519333: gnupg: Please include support for encrypted keyserver queries [PATCH] In-Reply-To: <877i2gtfth.fsf@wheatstone.g10code.de> References: <20090311221142.16436.77877.reportbug@pond.riseup.net> <87skl8rph8.fsf@mid.deneb.enyo.de> <49C3F19B.10400@fifthhorseman.net> <87tz5k1r0q.fsf@wheatstone.g10code.de> <49C799E3.6020707@fifthhorseman.net> <877i2gtfth.fsf@wheatstone.g10code.de> Message-ID: <49C7B800.6050001@fifthhorseman.net> I'm moving this discussion about the merits of TLS-wrapped HKP to gnupg-devel. People just coming into the thread now can catch up on the history at http://bugs.debian.org/519333 On 03/23/2009 11:32 AM, Werner Koch wrote: > On Mon, 23 Mar 2009 15:17, dkg at fifthhorseman.net said: > >> certificate retrieval via cleartext HKP over tor does not: >> >> * assure me that the host i'm connecting to is in fact the keyserver >> which i trust to return reasonable information, or > > Who cares? you don't have any control over the keyservers and what ends > up on the servers. Nor do the keyservers can control this. Actually, i do run one of the public keyservers. Even if i didn't, there are some keyservers run by organizations which i believe have my interests in mind more than others. For example, i might prefer an organization who commits to the following behaviors: * never logs keyserver queries. * has well-documented and -followed machine hygiene/maintenance policies, making the machines less vulnerable to compromise. * runs free software that i can inspect for "phoning home" or escrowed access (backdoors). >> * assure me that data has not been tampered with in transit between the >> tor exit node and the keyserver, or > > OpenPGP keys are self-contained. Thus this is not an issue. I agree that it should be impossible for a malicious keyserver to forge new signatures. However, a malicious keyserver could non-detectably strip signatures (e.g. removing revocation certificates, or certificates with specific notations), which would have adverse consequences for the user. >> * hide my queries from an snoop on the same network segment as the >> keyserver or anywhere between the tor exit node and the keyserver. > > See my comment on gnupg-devel; given enough traffic to the keyservers > optionally with filler queries, it is not worse as with any other use of > tor. Or in short What is your threat model? But not all keyservers have enough guaranteed traffic, and not everyone wants to (or can afford to) saturate the network with filler queries. Furthermore, tor introduces an additional communications delay and a layer of fragility to keyserver queries. Have you ever run "gpg --refresh-keys" on a keyring with several hundred entries? My threat model is a motivated attacker looking to glean information about the relationships of interest to a particular entity based on their keyserver queries. Since many keyservers are on fairly public network segments (in colocation facilities, for example), the opportunity for sniffing traffic at the very least is high for an attacker with moderate resources. I should probably point out that i'm also interested in using keyservers in connection with active network sessions (for mutually authenticating servers and clients using SSH and TLS). Regular connections to a keyserver to check for updated keys, etc, can leak a significant amount of information about (for example) who is authorized to access a given service. A large organization using OpenPGP for this type of authentication could run its own keyserver hooked into the public gossip, and encrypt queries to avoid this leakage while still taking advantage of regular updates. The monkeysphere project (http://web.monkeysphere.info) currently uses keyservers in this way to mutually authenticate ssh connections. Some administrators have already suggested would be more interested in deploying this infrastructure if they were able to use private and integrity-checked connections to a keyserver of their choice. I don't believe that tor alone fulfills this requirement. > Anyway, > revocation certificates don't really work. It is too easy to corrupt > data on keyservers. This is a serious concern, and i'm embarrassed to say it's news to me. Could you point me toward some examples or something i should read up on to better understand the vulnerabilities? Without functional revocation certificates, the OpenPGP infrastructure is significantly weaker than i'd like it to be. I'd like to figure out how to make them work, if possible. > You should resort to a different mechanism for key retrieval that the > ad-hoc network of public keyservers. Could you propose a different mechanism that you feel is superior? I'm happy to evaluate alternatives, as i quite like the public keyserver network as i understand it (though i'm concerned by your unsettling remark above about the ease of corruption of public keyservers). >> While tor is certainly a good option to obscure where i'm connecting >> *from* (something which hkps does not achieve), it does not meet the >> same goals as a TLS-wrapped connection to a keyserver. > > I don't think that this bug tracker is the right meida to discuss such > stuff. I hope moving this to gnupg-devel is the right place. It may also be relevant to ietf-openpgp if you have serious qualms about the utility revocation certificates in general. It may also be of interest to sks-devel, whether you believe that the corruptibility of public keyservers is due to implementation issues or protocol flaws. Thanks for your feedback, Werner. This is a useful discussion for me, and hopefully others. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Mon Mar 23 18:56:51 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 23 Mar 2009 13:56:51 -0400 Subject: HKP keyservers over SSL In-Reply-To: <87tz5x5g1z.fsf@wheatstone.g10code.de> References: <49B95F0A.4060309@fifthhorseman.net> <20090312210856.GC1295@jabberwocky.com> <49B97FAF.7080500@fifthhorseman.net> <20090312222036.GE1295@jabberwocky.com> <87tz5x5g1z.fsf@wheatstone.g10code.de> Message-ID: <20090323175651.GA74822@jabberwocky.com> On Fri, Mar 13, 2009 at 09:22:16PM +0100, Werner Koch wrote: > What we want is to make it harder to see what keys are fetched from the > keyserver: Obviously that should be done with TLS and we need to > authenticate the server to avoid MITM attacks. For the latter we have > several options: > > 1. Use a full fledged X.509 based TLS authentication in the standard > way, i.e. requiring the server to use a well known root > certificate. This can be done using any GPLv3 compatible TLS code. > > 2. Same as one but use an OpenPGP certificate. This requires GnuTLS. > > 3. Use a list of server certificate fingerprints and compare against > them. For example in the DNS which is secure enough for our threat > model. Recall that the servers can still track key requests. > > 4. Extend X.509 to allow optional authentication using an OpenPGP > certificate. This general mechanism can also be used for all kind > of projects. It would allow to get better server authentication > while still keeping standard HTTPS semantics. There are several > ways on how to implement it; for example by creating an OpenPGP > certificate with a user ID made up of the keygrip of the regular > X.509 certificate. > > 5. Forget about this all and implement it properly using an anonymizer > service. That service needs to batch up queries and insert dummy > queries. Should not be to hard to get this implemented in TOR. > > 6. Replace the keyserver stuff using a GNUNet service. That would > soon lead to the question why not to replace encrypted email as we > are used to entirely by a p2p system. So, better forget about this > for now. > > The more I think about it, option 5 (enhanced TOR) looks more and more > promising. The basic question is why to come up with a limited > anti-surveillance mechanism if we could get a strong one as well. I am > pretty sure that a few years after the major keyservers will speak TLS, > real anonymity will be requested and then we can start from scratch. Personally, I like both options 1 and 5. I like the TOR idea (5) a lot. It's a clever way to work around some of the limitations of a public keyserver network. In the immediate sense, however, I see no reason to not support some of the other options as well. A TLS-wrapped hkp (1) does not affect a TOR implementation (and can, in fact, be used with a TOR implementation), and gives protection against casual snooping by a third party of which keys are being requested. So doing (1) does not block us from doing (5) either soon or in the future, plus even in the absence of TOR, (1) means more encryption on the wire, which is generally good for network hygiene. > Regarding authenticated writes to the keyservers (user certificates): I > don't think that this will ever take off. It would be the first step to > a managed PKI and we all know that PKIs don't work. I see no benefits > for that. I can see a use case for user certs to create private keyservers, but that's a fairly limited use case. I wonder if client certs might be more useful for server to server communications, rather than the client to server communications. The catch, of course, is that given how the keyserver gossip protocol works, a given keyserver pool must be willing to exclude everyone who does not similarly use client certs. David From jussi.eronen at med.ge.com Tue Mar 24 08:14:18 2009 From: jussi.eronen at med.ge.com (Eronen, Jussi (GE Healthcare)) Date: Tue, 24 Mar 2009 08:14:18 +0100 Subject: Cross-compiling libgcrypt fails Message-ID: <75A244ADD1BE9147A96165D2217F3350063B0BC7@BUDMLVEM07.e2k.ad.ge.com> Libgcrypt build fails with error messages ... ../src/.libs/libgcrypt.so: undefined reference to `_gcry_mpih_addmul_1' ../src/.libs/libgcrypt.so: undefined reference to `_gcry_mpih_rshift' ../src/.libs/libgcrypt.so: undefined reference to `_gcry_mpih_add_n' ../src/.libs/libgcrypt.so: undefined reference to `_gcry_mpih_mul_1' ../src/.libs/libgcrypt.so: undefined reference to `_gcry_mpih_submul_1' ../src/.libs/libgcrypt.so: undefined reference to `_gcry_mpih_lshift' ../src/.libs/libgcrypt.so: undefined reference to `_gcry_mpih_sub_n' ... I am building for powerpc 603e target with toolchain gcc-4.2.4, glibc-2.6.1 and binutils-2.19 on Fedora8. My fix (hack?) was to patch mpi/powerpc32/syntax.h with this patch: --- libgcrypt-1.4.4/mpi/powerpc32/syntax.h 2008-08-19 18:20:01.000000000 +0300 +++ libgcrypt-1.4.4.new/mpi/powerpc32/syntax.h 2009-03-13 11:42:45.000000000 +0200 @@ -46,9 +46,12 @@ #define ENTRY(name) \ ASM_GLOBAL_DIRECTIVE C_SYMBOL_NAME(name); \ + ASM_GLOBAL_DIRECTIVE name; \ ASM_TYPE_DIRECTIVE (C_SYMBOL_NAME(name), at function) \ + ASM_TYPE_DIRECTIVE (name, at function) \ .align ALIGNARG(2); \ C_LABEL(name) \ + name##: \ CALL_MCOUNT #define EALIGN_W_0 /* No words to insert. */ @@ -64,10 +67,13 @@ past a 2^align boundary. */ #define EALIGN(name, alignt, words) \ ASM_GLOBAL_DIRECTIVE C_SYMBOL_NAME(name); \ + ASM_GLOBAL_DIRECTIVE name; \ ASM_TYPE_DIRECTIVE (C_SYMBOL_NAME(name), at function) \ + ASM_TYPE_DIRECTIVE (name, at function) \ .align ALIGNARG(alignt); \ EALIGN_W_##words; \ - C_LABEL(name) + C_LABEL(name) \ + name##: #undef END #define END(name) \ Doesn't look the _right_ way but couldn't figure out anything else. After patching compiles and builds ok. --Jussi From dkg at fifthhorseman.net Wed Mar 25 01:17:44 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 24 Mar 2009 20:17:44 -0400 Subject: HKP keyservers over SSL In-Reply-To: <87tz5x5g1z.fsf@wheatstone.g10code.de> References: <49B95F0A.4060309@fifthhorseman.net> <20090312210856.GC1295@jabberwocky.com> <49B97FAF.7080500@fifthhorseman.net> <20090312222036.GE1295@jabberwocky.com> <87tz5x5g1z.fsf@wheatstone.g10code.de> Message-ID: <49C97828.2070808@fifthhorseman.net> Sorry, i somehow missed this message when it first came in :( On 03/13/2009 04:22 PM, Werner Koch wrote: > Actually the original GnuPG http code has support for GnuTLS and thus it > will be easy implement TLS directly. The code might not be in GnuPG > proper, but I use copies of it in other projects. > > One problem I have with Curl is that it is not GNU code and we would > like to have all main features of GNU software implemented by GNU code. > (Well, I know that David does not share this opinion.) I'd be interested in seeing this happen. I think that making sure critical infrastrcture works with all-GNU tools is a worthwhile ambition. > 1. Use a full fledged X.509 based TLS authentication in the standard > way, i.e. requiring the server to use a well known root > certificate. This can be done using any GPLv3 compatible TLS code. > > 2. Same as one but use an OpenPGP certificate. This requires GnuTLS. Or any other TLS suite that opts to implement RFC 5081. If the goal is all-GNU then using GnuTLS for (1) makes sense anyway, and it's a short jump from there to (2), assuming we can get some server-side support in place on popular keyservers. > 3. Use a list of server certificate fingerprints and compare against > them. For example in the DNS which is secure enough for our threat > model. Recall that the servers can still track key requests. I don't think i understand this option. Why is the DNS sufficiently secure here? > 4. Extend X.509 to allow optional authente ication using an OpenPGP > certificate. This general mechanism can also be used for all kind > of projects. It would allow to get better server authentication > while still keeping standard HTTPS semantics. There are several > ways on how to implement it; for example by creating an OpenPGP > certificate with a user ID made up of the keygrip of the regular > X.509 certificate. I'm very intrigued by this idea, though i think it has larger implications outside of HKP. My current thought along these lines was to use the same underlying key, but to provide an OpenPGP certificate matching the CN of the X.509 certificate. So a failed X.509 validation (e.g. from a trivially-created self-signed X.509 cert) would trigger a lookup within the user's local keyring based on the same name (assuming the CN matches the remote host of course). If gpg showed full calculated validity for that OpenPGP certificate, and the public key material matches the key material from the self-signed X.509 cert, then the connection would be considered to be properly authenticated. It seems to me that the new semantics this approach introduces for the User ID are more closely aligned to the common User ID semantics than an X.509 keygrip would be. But i could be missing other drawbacks, too. I welcome feedback on this idea. > 5. Forget about this all and implement it properly using an anonymizer > service. That service needs to batch up queries and insert dummy > queries. Should not be to hard to get this implemented in TOR. I've described in other e-mails why i think tor is a good idea, but an orthogonal one to the use of TLS. I don't think the two approaches address the same problem space. > 6. Replace the keyserver stuff using a GNUNet service. That would > soon lead to the question why not to replace encrypted email as we > are used to entirely by a p2p system. So, better forget about this > for now. ;) I think a GNUNet service that focuses on distributing key material would be a great thing to have, but i don't see it replacing HKP any time soon, with all the HKP clients that exist. > The more I think about it, option 5 (enhanced TOR) looks more and more > promising. The basic question is why to come up with a limited > anti-surveillance mechanism if we could get a strong one as well. I am > pretty sure that a few years after the major keyservers will speak TLS, > real anonymity will be requested and then we can start from scratch. In a future where the keyservers all speak TLS, and gpg supports TLS queries, users can opt to use tor or not without needing to change gpg, no? Can't gpg users already use tor for keyserver lookups in fact? (i haven't tried it myself). > Regarding authenticated writes to the keyservers (user certificates): I > don't think that this will ever take off. It would be the first step to > a managed PKI and we all know that PKIs don't work. I see no benefits > for that. I agree that authenticated (via TLS) writes seem fundamentally meaningless. As long as the keyservers check that an uploaded OpenPGP certificate is cryptographically valid, it's not clear that there's any reason to require an additional layer of per-transaction client authentication in order to accept a write. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Wed Mar 25 11:03:45 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 25 Mar 2009 11:03:45 +0100 Subject: Keyserver and Email over GNUNet (was: HKP keyservers over SSL) In-Reply-To: <87tz5x5g1z.fsf@wheatstone.g10code.de> References: <49B95F0A.4060309@fifthhorseman.net> <20090312222036.GE1295@jabberwocky.com> <87tz5x5g1z.fsf@wheatstone.g10code.de> Message-ID: <200903251103.50500.bernhard@intevation.de> On Friday 13 March 2009, Werner Koch wrote: > 6. Replace the keyserver stuff using a GNUNet service. That would > soon lead to the question why not to replace encrypted email as we > are used to entirely by a p2p system. So, better forget about this > for now. This will become a reality with keyserver and email quite soon I predict. At least it is a very good vision. I guess that pursing all three options TLS, Tor and p2p is worthwhile and they all have their own timeframe. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Neuer Graben 17, Osnabr?ck, DE; AG 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: 1599 bytes Desc: not available URL: From expat.iain at gmail.com Wed Mar 25 11:51:26 2009 From: expat.iain at gmail.com (iain) Date: Wed, 25 Mar 2009 11:51:26 +0100 Subject: Blackberry integration Message-ID: Is there any work being done to integrate GPG into the Blackberry systems from RIM? There is an offering from PGP, but this flavour is far better. From aoz.syn at gmail.com Wed Mar 25 16:45:48 2009 From: aoz.syn at gmail.com (RB) Date: Wed, 25 Mar 2009 09:45:48 -0600 Subject: Blackberry integration In-Reply-To: References: Message-ID: <4255c2570903250845j14f2976eq4725b26eba05579e@mail.gmail.com> On Wed, Mar 25, 2009 at 04:51, iain wrote: > Is there any work being done to integrate GPG into the Blackberry > systems from RIM? > > There is an offering from PGP, but this flavour is far better. The PGP offering also requires a minimum seat purchase, driving the cost way up for individual users. I, too, would love to see Blackberry and WM6 support, but fear those may be down the road a distance or even on myself. From jpaulo.melo at gmail.com Fri Mar 27 12:54:12 2009 From: jpaulo.melo at gmail.com (Joao Paulo Fernandes) Date: Fri, 27 Mar 2009 08:54:12 -0300 Subject: Generate a key pair with only one command line Message-ID: <1a27245d0903270454m6af721b7n90a808cf02c573cb@mail.gmail.com> People, is it possible to generate a gpg key--pair with only one command line ? Im trying to integrate GPG with Java but i m unable to, because gpg need a human interaction to choose data to gen the key. Some body could help me ? Thanks, JP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From comp.ogz at gmail.com Fri Mar 27 14:07:04 2009 From: comp.ogz at gmail.com (Oguz Yarimtepe) Date: Fri, 27 Mar 2009 15:07:04 +0200 Subject: GnuPG JAVA GUI Message-ID: <1238159231.7353.24.camel@ELK1655> Hi, Is there any java based GUI that can be used for encryption and signing a file? I read some threads saying that some people started to write a gui for gnupg but couldn't find whether they finished it or not. Maybe some of them can answer here. Thanx. From dkg at fifthhorseman.net Fri Mar 27 15:56:28 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 27 Mar 2009 10:56:28 -0400 Subject: Generate a key pair with only one command line In-Reply-To: <1a27245d0903270454m6af721b7n90a808cf02c573cb@mail.gmail.com> References: <1a27245d0903270454m6af721b7n90a808cf02c573cb@mail.gmail.com> Message-ID: <49CCE91C.5040500@fifthhorseman.net> On 03/27/2009 07:54 AM, Joao Paulo Fernandes wrote: > is it possible to generate a gpg key--pair with only one command line ? > Im trying to integrate GPG with Java but i m unable to, because gpg need a > human interaction to choose data to gen the key. > Some body could help me ? Read DETAILS (in the source, or in /usr/share/doc/gnupg on debian or debian-derived systems) and look for "Unattended Key Generation". hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri Mar 27 21:26:19 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 27 Mar 2009 16:26:19 -0400 Subject: GnuPG JAVA GUI In-Reply-To: <1238159231.7353.24.camel@ELK1655> References: <1238159231.7353.24.camel@ELK1655> Message-ID: <49CD366B.4040700@sixdemonbag.org> Oguz Yarimtepe wrote: > Is there any java based GUI that can be used for encryption and signing > a file? Not to my knowledge. A couple of years ago I and a couple of other graduate students in an HCI course created a Java mock-up of a better user interface for GnuPG operations, but that was never meant to be something ready for end users. From freebsd-listen at fabiankeil.de Sat Mar 28 18:11:53 2009 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Sat, 28 Mar 2009 18:11:53 +0100 Subject: HKP keyservers over SSL In-Reply-To: <20090323175651.GA74822@jabberwocky.com> References: <49B95F0A.4060309@fifthhorseman.net> <20090312210856.GC1295@jabberwocky.com> <49B97FAF.7080500@fifthhorseman.net> <20090312222036.GE1295@jabberwocky.com> <87tz5x5g1z.fsf@wheatstone.g10code.de> <20090323175651.GA74822@jabberwocky.com> Message-ID: <20090328181153.4045c590@fabiankeil.de> David Shaw wrote: > On Fri, Mar 13, 2009 at 09:22:16PM +0100, Werner Koch wrote: > > > What we want is to make it harder to see what keys are fetched from the > > keyserver: Obviously that should be done with TLS and we need to > > authenticate the server to avoid MITM attacks. For the latter we have > > several options: > > 5. Forget about this all and implement it properly using an anonymizer > > service. That service needs to batch up queries and insert dummy > > queries. Should not be to hard to get this implemented in TOR. > > The more I think about it, option 5 (enhanced TOR) looks more and more > > promising. The basic question is why to come up with a limited > > anti-surveillance mechanism if we could get a strong one as well. I am > > pretty sure that a few years after the major keyservers will speak TLS, > > real anonymity will be requested and then we can start from scratch. > > Personally, I like both options 1 and 5. I like the TOR idea (5) a > lot. It's a clever way to work around some of the limitations of a > public keyserver network. In the immediate sense, however, I see no > reason to not support some of the other options as well. A > TLS-wrapped hkp (1) does not affect a TOR implementation (and can, in > fact, be used with a TOR implementation), and gives protection against > casual snooping by a third party of which keys are being requested. If the keyserver is properly setup as a location hidden service, no third party should be able to snoop: http://www.torproject.org/hidden-services.html.en In related news, it would be great if more keyservers were (additionally) reachable as location hidden services. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From wk at gnupg.org Tue Mar 31 11:37:30 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 31 Mar 2009 11:37:30 +0200 Subject: Generate a key pair with only one command line In-Reply-To: <49CCE91C.5040500@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 27 Mar 2009 10:56:28 -0400") References: <1a27245d0903270454m6af721b7n90a808cf02c573cb@mail.gmail.com> <49CCE91C.5040500@fifthhorseman.net> Message-ID: <87ljqmuj6t.fsf@wheatstone.g10code.de> On 03/27/2009 07:54 AM, Joao Paulo Fernandes wrote: > is it possible to generate a gpg key--pair with only one command line ? > Im trying to integrate GPG with Java but i m unable to, because gpg need a > human interaction to choose data to gen the key. > Some body could help me ? FWIW, there is a Java binding for gpgme at ftp://ftp.gnupg.org/gcrypt/alpha/gnupgjava/ 50216 Jan 31 2005 gnupgjava-0.1.2-alpha-doc.zip 204984 Jan 31 2005 gnupgjava-0.1.2-alpha.jar 65 Jan 31 2005 gnupgjava-0.1.2-alpha.jar.sig It is a bit rusty and probably needs some polishing but might be useful. GPGME is a library to make access to GnuPG easier and the recommended way for applications to use GnuPG. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From gordian.klein at gmx.de Tue Mar 31 18:52:38 2009 From: gordian.klein at gmx.de (Gordian Klein) Date: Tue, 31 Mar 2009 18:52:38 +0200 Subject: problem with Decypher and Openpgp card Message-ID: <49D24A56.4020507@gmx.de> Hello, i have a problem with the decypher command from the OpenPGP Card. I verify CHV2 and then send my decypher cmd, but the card always returns SW_USE_CONDITIONS = 0x6985. What does this error mean? I couldnt find anything with google.. Thank you for any hint. Regards, Gordian From gnupg-devel at spodhuis.org Tue Mar 31 23:53:38 2009 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Tue, 31 Mar 2009 14:53:38 -0700 Subject: HKP keyservers over SSL In-Reply-To: <8DB37A9C-106C-419D-AFD7-707ABE1A5226@jabberwocky.com> References: <8DB37A9C-106C-419D-AFD7-707ABE1A5226@jabberwocky.com> Message-ID: <20090331215338.GA32245@redoubt.spodhuis.org> On 2009-03-12 at 09:10 -0400, David Shaw wrote: > A few weeks ago, I added support for SSL to the HKP keyserver handler > (gpg(2)keys_hkp) to help test some new keyserver work that is going > on. (Though "Added" is a bit of a strong term - it's really just 4-5 > lines of code to tell libcurl to accept SSL.) Anyway, Werner pointed > out that we may want to do something more than that. After all, gpgsm > manipulates X.509 certificates for lunch. > > So, let's talk about it a bit: How can we do something smart here, > design-wise? It would be nice to also support client auth, and not > just the standard server validation SSL test. David, some questions/suggestions if I may? I see from the URL which you posted to sks-devel: http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/keyserver/gpgkeys_hkp.c?root=GnuPG&rev=4924&r1=4878&r2=4924 that you're using: curl_easy_setopt(curl,CURLOPT_SSL_VERIFYPEER,(long)opt->flags.check_cert); How is this expected to interact with keyserver pools? Should every server know every pool which $random_people construct and include it in subjectAltName? How about certificate validation for that case? I strongly suspect that the only workable way forward here, for those who want to have verifiable certificates, is to have the client support Server Name Indication, SNI, per RFC 4366. The client presents the hostname it's talking to and the server has a collection of certificates, one for each pool it is part of, and serves up accordingly, with some cert being default. Each pool maintainer issues the certs to the keyserver operator and clients maintain a collection of auxilliary trusted CA certs. Eg, ~/.gnupg/ssl-ca/. A reasonable policy might be to require a nameConstraints extension in those CA certs, tying each to the pool itself. Eg, a gnupg.net CA might have: nameConstraints=permitted;DNS:*.keys.gnupg.net,keys.gnupg.net (if I understand the syntax correctly) and issue a cert to me for my keyserver as CN=pdp.keys.gnupg.net with subjectAltName=DNS:pdp.keys.gnupg.net,keys.gnupg.net,ipv6.keys.gnupg.net The gpg client would be able to use the copy of that CA cert to validate the served cert when round-robin for keys.gnupg.net took them to my server. This would in no way interfere with the presence of my keyserver in pool.sks-keyservers.net or any other pools, or the ability to reach it directly by its own name. The alternative is a long list of subjectAltName DNS fields which no sane CA is going to sign and which get uncontrollable quickly as pools come and go and no pool being able to do much to speak for the verifiability of certificates of their members. If instead we can establish that from day 1, hkps clients *will* use SNI then we can then just leave it to the PGP keyservers to develop nice admin interfaces for managing the collections of certs which a given keyserver will use. (For any nit-pickers out there: no, my keyserver is not currently in keys.gnupg.net, I merely use that as an example) Does this seem sensible? -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From admin at garyshood.com Sat Mar 21 08:25:16 2009 From: admin at garyshood.com (Gary Suggett) Date: Sat, 21 Mar 2009 07:25:16 -0000 Subject: gpgme_set_passphrase_cb seems to be ignored Message-ID: When I set a passphrase callback, it doesn't seem to be used, and pinentry runs instead. gpgme_set_passphrase_cb(ctx, return_pass, NULL); The application compiles fine, and the function return_pass is setup correctly, but pinentry runs no matter what I change. Is there a way to force this callback? From andreas.huettel at physik.uni-regensburg.de Mon Mar 30 15:07:34 2009 From: andreas.huettel at physik.uni-regensburg.de (Andreas K. Huettel) Date: Mon, 30 Mar 2009 13:07:34 -0000 Subject: gnupg 2.0.10 broke kgpg 3.5.9 ??? Message-ID: <200903301501.00961.andreas.huettel@physik.uni-regensburg.de> Dear developers, recently gpg 2.0.10 went "stable" in gentoo, and now a lot of people are seeing issues with kgpg (3.5.9). Gnupg output is not parsed correctly anymore, and a garbled keyring is displayed. For details, see http://bugs.gentoo.org/show_bug.cgi?id=263454 Do you have any clue what the problem in detail is, and/or how to fix it? Thanks in advance, Andreas (opening up a kgpg bug in parallel, see http://bugs.kde.org/show_bug.cgi?id=188473 ) -- Dr. Andreas K. Huettel Institute for Experimental and Applied Physics University of Regensburg D-93040 Regensburg Germany tel. +49 151 241 67748 (mobile) e-mail mail at akhuettel.de http://www.akhuettel.de/research/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: