From saravan1 at comp.nus.edu.sg Sun Mar 2 12:42:16 2008 From: saravan1 at comp.nus.edu.sg (Saravanan) Date: Sun, 2 Mar 2008 19:42:16 +0800 Subject: GnuPG Make_Printable_String Remote Buffer Overflow Vulnerability Message-ID: <001701c87c5a$78a3ca00$b95d8489@yourf3zsqh74e5> Hi, I have been trying to find an input that will utilize the Make_Printable_String so as to look into the vulnerability.But I am rather unsuccessful at finding such an input. Can advise me on any such input? Thanks. Saravanan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jari.aalto at cante.net Tue Mar 4 10:53:29 2008 From: jari.aalto at cante.net (Jari Aalto) Date: Tue, 04 Mar 2008 11:53:29 +0200 Subject: [RFC] gnupg 1.4.5: old default options file ignored Message-ID: [Please keep CC, I'm not in this list] Regarding following message: gpg: NOTE: old default options file `/home/foo/.pgp/options' ignored SUGGESTION Improve the message to announce new configuration file: gpg: NOTE: old default options file `/home/foo/.pgp/options' ignored. gpg: NOTE: Please migrate to gpg.conf Jari -- Welcome to FOSS revolution: we fix and modify until it shines From jari.aalto at cante.net Tue Mar 4 12:07:04 2008 From: jari.aalto at cante.net (Jari Aalto) Date: Tue, 04 Mar 2008 13:07:04 +0200 Subject: Cygwin FAT/FAT32: external program calls are disabled due to unsafe options file permissions Message-ID: Consider this: $ gpg --keyserver wwwkeys.pgp.net --recv-keys FD65117B 1CE0C630 gpg: WARNING: unsafe permissions on homedir `/cygdrive/x/home/foo/.pgp' gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: external program calls are disabled due to unsafe options file permissions gpg: keyserver communications error: general error gpg: keyserver receive failed: general error Unfortunately under Cygwin FAT, the file permissions do not convey the proper information: $ cd $HOME $ ls -la .pgp lrwxrwxrwx 1 root None 6 Oct 18 21:27 .pgp -> .gnupg $ ls -la .gnupg lrwxrwxrwx 1 root None 31 Oct 18 21:28 .gnupg -> version-control/.gnupg $ ls -la version-control/.gnupg | head -2 total 84 drwxr-xr-x 2 root None 0 Oct 12 19:48 . See this: $ unask 0022 $ mkdir xx $ chmod 777 xx ; ls -la xx drwxr-xr-x 2 root None 0 Mar 4 13:04 . $ chmod 600 xx ; ls -la xx drwxr-xr-x 2 root None 0 Mar 4 13:04 . drwxr-xr-x 2 root None 0 Mar 4 13:04 . SUGGESTION Please provide options to allow ignoring "external program calls are disabled", so that receiving PGP keys succeed. -- Welcome to FOSS revolution: we fix and modify until it shines From rdieter at math.unl.edu Tue Mar 4 16:03:18 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 04 Mar 2008 09:03:18 -0600 Subject: gpgme: need *both* gnupg and gnupg2? References: Message-ID: Rex Dieter wrote: > gpgme seems to need both gnupg(1) (for OpenPGP support) and gnupg(2) (for > CMS support), according to the README. > > Can gpg2 be used instead for gpgme's OpenPGP support (using something > like ./configure --with-gpg=/usr/bin/gpg2) to reduce it's external > dependencies to just gnupg2? > > I naively tried this, and some of the tests performed by 'make check' now > fail. Followup, it was part of the regular build (not just 'make check') that failed, in tests/gpg: $(GPG) --homedir . --allow-secret-key-import since gpg2 doesn't support --allow-secret-key-import I needed to also add --disable-gpg-test configure option for the build to succeed. -- Rex From wk at gnupg.org Tue Mar 4 16:41:11 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Mar 2008 16:41:11 +0100 Subject: [RFC] gnupg 1.4.5: old default options file ignored In-Reply-To: (Jari Aalto's message of "Tue, 04 Mar 2008 11:53:29 +0200") References: Message-ID: <874pbmzeco.fsf@wheatstone.g10code.de> On Tue, 4 Mar 2008 10:53, jari.aalto at cante.net said: > gpg: NOTE: old default options file `/home/foo/.pgp/options' ignored. > gpg: NOTE: Please migrate to gpg.conf Nope: The warning merely tells that there is an _unused_ ".gnupg/options" file - in addition to the _used_ gpg.conf. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Tue Mar 4 16:50:58 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue, 04 Mar 2008 16:50:58 +0100 Subject: gpgme: need *both* gnupg and gnupg2? In-Reply-To: References: Message-ID: <871w6qo5ct.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 04 Mar 2008 09:03:18 -0600, Rex Dieter wrote: > > Rex Dieter wrote: > > > gpgme seems to need both gnupg(1) (for OpenPGP support) and gnupg(2) (for > > CMS support), according to the README. > > > > Can gpg2 be used instead for gpgme's OpenPGP support (using something > > like ./configure --with-gpg=/usr/bin/gpg2) to reduce it's external > > dependencies to just gnupg2? > > > > I naively tried this, and some of the tests performed by 'make check' now > > fail. > > Followup, it was part of the regular build (not just 'make check') that > failed, in tests/gpg: > $(GPG) --homedir . --allow-secret-key-import > since gpg2 doesn't support --allow-secret-key-import Hu? Which version of gpg2, and what was the error message? Thanks, Marcus From wk at gnupg.org Tue Mar 4 17:32:19 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Mar 2008 17:32:19 +0100 Subject: Cygwin FAT/FAT32: external program calls are disabled due to unsafe options file permissions In-Reply-To: (Jari Aalto's message of "Tue, 04 Mar 2008 13:07:04 +0200") References: Message-ID: <87ir02xxf0.fsf@wheatstone.g10code.de> On Tue, 4 Mar 2008 12:07, jari.aalto at cante.net said: > $ gpg --keyserver wwwkeys.pgp.net --recv-keys FD65117B 1CE0C630 ^^^^^^^^^^^^^^^ Pretty please do not use this key server it mangles proper OpenPGP keys. Use an SKS keyserver. > Please provide options to allow ignoring "external program calls are > disabled", so that receiving PGP keys succeed. Already done: --no-permission-warning Suppress the warning about unsafe file and home directory (--homedir) permissions. Note that the permission checks that GnuPG performs are not intended to be authorita- tive, but rather they simply warn about certain common permission problems. Do not assume that the lack of a warning means that your system is secure. Note that the warning for unsafe --homedir permissions cannot be supressed in the gpg.conf file, as this would allow an attacker to place an unsafe gpg.conf file in place, and use this file to supress warnings about itself. The --homedir permissions warning may only be supressed on the command line. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From rdieter at math.unl.edu Tue Mar 4 17:16:41 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 04 Mar 2008 10:16:41 -0600 Subject: gpgme: need *both* gnupg and gnupg2? In-Reply-To: <871w6qo5ct.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <871w6qo5ct.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <47CD75E9.1070509@math.unl.edu> Marcus Brinkmann wrote: > At Tue, 04 Mar 2008 09:03:18 -0600, > Rex Dieter wrote: >> Rex Dieter wrote: >> >>> gpgme seems to need both gnupg(1) (for OpenPGP support) and gnupg(2) (for >>> CMS support), according to the README. >>> >>> Can gpg2 be used instead for gpgme's OpenPGP support (using something >>> like ./configure --with-gpg=/usr/bin/gpg2) to reduce it's external >>> dependencies to just gnupg2? >>> >>> I naively tried this, and some of the tests performed by 'make check' now >>> fail. >> Followup, it was part of the regular build (not just 'make check') that >> failed, in tests/gpg: >> $(GPG) --homedir . --allow-secret-key-import >> since gpg2 doesn't support --allow-secret-key-import > > Hu? Which version of gpg2, and what was the error message? gnupg-2.0.8, /usr/bin/gpg2 --homedir . --allow-secret-key-import \ --import Alpha/Secret.gpg Zulu/Secret.gpg gpg: WARNING: unsafe permissions on homedir `.' gpg: importing secret keys not allowed gpg: importing secret keys not allowed gpg: Total number processed: 2 gpg: secret keys read: 2 make[3]: *** [pubring.gpg] Error 2 -- Rex From bernhard at intevation.de Tue Mar 4 22:54:00 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 4 Mar 2008 22:54:00 +0100 Subject: gpgme: check_version() MUST be called, but examples miss it Message-ID: <200803042254.04803.bernhard@intevation.de> http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/doc/gpgme.texi?rev=1298 explains for check_version()_: In either case, the function initializes some sub-systems, and for this reason alone it must be invoked early in your program, before you make use of the other functions in @acronym{GPGME}. But the remaining examples codes in the documentation do not contain a hint towards it. It is a must to add it in the @node I/O Callback Example . I strongly recommend to add it to shorter examples as well as some (experienced) programmers will look at the examples first and might miss the requirement to use check_version(). It could be done using a pseudo-function like MY_GPGME_INIT() or [init gpgme] So people now initialisation must be done before using the snipplet. 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: smime.p7s Type: application/pkcs7-signature Size: 1571 bytes Desc: not available URL: From marcus.brinkmann at ruhr-uni-bochum.de Tue Mar 4 22:55:23 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue, 04 Mar 2008 22:55:23 +0100 Subject: gpgme: need *both* gnupg and gnupg2? In-Reply-To: <47CD75E9.1070509@math.unl.edu> References: <871w6qo5ct.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47CD75E9.1070509@math.unl.edu> Message-ID: <87ve42m9x0.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 04 Mar 2008 10:16:41 -0600, Rex Dieter wrote: > > Marcus Brinkmann wrote: > > At Tue, 04 Mar 2008 09:03:18 -0600, > > Rex Dieter wrote: > >> Rex Dieter wrote: > >> > >>> gpgme seems to need both gnupg(1) (for OpenPGP support) and gnupg(2) (for > >>> CMS support), according to the README. > >>> > >>> Can gpg2 be used instead for gpgme's OpenPGP support (using something > >>> like ./configure --with-gpg=/usr/bin/gpg2) to reduce it's external > >>> dependencies to just gnupg2? > >>> > >>> I naively tried this, and some of the tests performed by 'make check' now > >>> fail. > >> Followup, it was part of the regular build (not just 'make check') that > >> failed, in tests/gpg: > >> $(GPG) --homedir . --allow-secret-key-import > >> since gpg2 doesn't support --allow-secret-key-import > > > > Hu? Which version of gpg2, and what was the error message? > > gnupg-2.0.8, > > /usr/bin/gpg2 --homedir . --allow-secret-key-import \ > --import Alpha/Secret.gpg Zulu/Secret.gpg > gpg: WARNING: unsafe permissions on homedir `.' > gpg: importing secret keys not allowed > gpg: importing secret keys not allowed > gpg: Total number processed: 2 > gpg: secret keys read: 2 > make[3]: *** [pubring.gpg] Error 2 This is due to --enable-selinux-support, which is off by default, and seems unrelated to gpg 1 vs 2. (I didn't test it, though). Thanks, Marcus From bernhard at intevation.de Tue Mar 4 23:32:10 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 4 Mar 2008 23:32:10 +0100 Subject: pyme review In-Reply-To: <478382DD.1080703@katehok.ac93.org> References: <3ac86fa70712111623wd83e701vd07440a6966dde65@mail.gmail.com> <200801071137.09535.bernhard@intevation.de> <478382DD.1080703@katehok.ac93.org> Message-ID: <200803042332.16391.bernhard@intevation.de> Igor, On Tuesday 08 January 2008 15:04, Igor Belyi wrote: > > at some point in time we will give it a shot with pyme and then you > > will get reports. ;) congratulations on pyme! I gave it a spin and found it to be a usable piece of software and a capable gpgme wrapper! I even used it to write a test script for a gpgme defect, see https://bugs.g10code.com/gnupg/issue876. I am attaching this and another script which are Free Software. Feel free to include it in the examples or somewhere else. > I'd recommend to start with examples provided with pyme. There's even > some Glade based GUI ones if you like that sort of things. :) Yes, the pygpa is quite impressive. It lacks a bit of icons, though and some of the funcationality... :) > And as for the reports - Bring them on! ;) A few things that I have noticed. a) the use of check_version() is mandatory according to the gpgme documentation. (See section 2.6 Library Version Check). Your example applications fail to do it. This is a serious problem in my view. b) Some documentation links in the Debian package's html files just lead nowhere. A nice to have thing. c) It would be much more pythonic to use named parameter with default values for functions. It just feels wrong at places to write from pyme import core print "gpgme version:", core.check_version(None) where core.check_version() should just do the job. There are quite a few places where this would make the wrapper more usable, because the using code will we more python-style. d) In many places the return values really should be sequence, maybe lists or tuples. Currently somebody really must follow the linked pointer list in a way like: engine = core.get_engine_info() while (engine): print engine.file_name, engine.version engine = engine.next where someone would like to write: for engine in core.get_engine_info(): print engine.file_name, engine.version looks more pythonic to me. :) Thanks again for the nice library, I even saw that roundup uses it in the latest versions. Hopefully my remarks are useful! 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: testCMSgetkey.py Type: application/x-python Size: 1069 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: verifydetails.py Type: application/x-python Size: 2543 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Mar 4 23:39:26 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 04 Mar 2008 16:39:26 -0600 Subject: gpgme: need *both* gnupg and gnupg2? In-Reply-To: <87ve42m9x0.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <871w6qo5ct.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47CD75E9.1070509@math.unl.edu> <87ve42m9x0.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <47CDCF9E.1020702@math.unl.edu> Marcus Brinkmann wrote: > At Tue, 04 Mar 2008 10:16:41 -0600, >> /usr/bin/gpg2 --homedir . --allow-secret-key-import \ >> --import Alpha/Secret.gpg Zulu/Secret.gpg >> gpg: WARNING: unsafe permissions on homedir `.' >> gpg: importing secret keys not allowed >> gpg: importing secret keys not allowed >> gpg: Total number processed: 2 >> gpg: secret keys read: 2 >> make[3]: *** [pubring.gpg] Error 2 > > This is due to --enable-selinux-support, which is off by default, and > seems unrelated to gpg 1 vs 2. (I didn't test it, though). Thanks. Ok, sounds like I may have been a bit naive using --enable-selinux-support without fully understanding what it does exactly. Would someone kindly elaborate what --enable-selinux-support does? (responding, "just don't use it dummy!" is an acceptable answer too. :) ) -- Rex From wk at gnupg.org Wed Mar 5 08:25:02 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Mar 2008 08:25:02 +0100 Subject: gpgme: check_version() MUST be called, but examples miss it In-Reply-To: <200803042254.04803.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 4 Mar 2008 22:54:00 +0100") References: <200803042254.04803.bernhard@intevation.de> Message-ID: <87zltdvdip.fsf@wheatstone.g10code.de> On Tue, 4 Mar 2008 22:54, bernhard at intevation.de said: > I strongly recommend to add it to shorter examples as well as some > (experienced) programmers will look at the examples first and might miss These are example code snippets and clearly not complete applications. Note that even the inclusion of header files is left out. > the requirement to use check_version(). > It could be done using a pseudo-function like > MY_GPGME_INIT() That is not sufficient. A whole chapter describes the required preparations and the developer MUST read this chapter to use gpgme. There are even more severe pitfalls than leaving out the version check. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Wed Mar 5 08:40:18 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Mar 2008 08:40:18 +0100 Subject: gpgme: need *both* gnupg and gnupg2? In-Reply-To: <47CDCF9E.1020702@math.unl.edu> (Rex Dieter's message of "Tue, 04 Mar 2008 16:39:26 -0600") References: <871w6qo5ct.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47CD75E9.1070509@math.unl.edu> <87ve42m9x0.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47CDCF9E.1020702@math.unl.edu> Message-ID: <87mypdvct9.fsf@wheatstone.g10code.de> On Tue, 4 Mar 2008 23:39, rdieter at math.unl.edu said: > Thanks. Ok, sounds like I may have been a bit naive using > --enable-selinux-support without fully understanding what it does > exactly. Would someone kindly elaborate what --enable-selinux-support > does? (responding, "just don't use it dummy!" is an acceptable answer > too. :) ) The idea is that only the gpg process may access files with sensitive data (e.g. secring.gpg) this allows to set up proper ACLs for the gpg process. Now we can't allow gpg to export this sensitive data because any iser may issue the export command and thus get a copy of the secring.gpg. BTW --allow-secret-key-export is obsolete and a dummy option since 1.0.7 - you better remove it from. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bernhard at intevation.de Wed Mar 5 10:20:32 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 5 Mar 2008 10:20:32 +0100 Subject: gpgme: check_version() MUST be called, but examples miss it In-Reply-To: <87zltdvdip.fsf@wheatstone.g10code.de> References: <200803042254.04803.bernhard@intevation.de> <87zltdvdip.fsf@wheatstone.g10code.de> Message-ID: <200803051020.33152.bernhard@intevation.de> On Wednesday 05 March 2008 08:25, Werner Koch wrote: > On Tue, ?4 Mar 2008 22:54, bernhard at intevation.de said: > > I strongly recommend to add it to shorter examples as well as some > > (experienced) programmers will look at the examples first and might miss > > These are example code snippets and clearly not complete applications. > Note that even the inclusion of header files is left out. Yes, I know and I have noticed ... > > the requirement to use check_version(). > > It could be done using a pseudo-function like > > ??????MY_GPGME_INIT() > > That is not sufficient. ?A whole chapter describes the required > preparations and the developer MUST read this chapter to use gpgme. > There are even more severe pitfalls than leaving out the version check. I believe a reminder line could be instructive for the example - at last for the longer ones. For the IO Example which has a main() funcation, I believe not having it in there is a serious problem. In pyme, which was certainly done by a caring developer, the examples all miss the version check. 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: 189 bytes Desc: not available URL: From marcus.brinkmann at ruhr-uni-bochum.de Wed Mar 5 12:43:18 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed, 05 Mar 2008 12:43:18 +0100 Subject: gpgme: check_version() MUST be called, but examples miss it In-Reply-To: <200803042254.04803.bernhard@intevation.de> References: <200803042254.04803.bernhard@intevation.de> Message-ID: <87pru9mm5l.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 4 Mar 2008 22:54:00 +0100, Bernhard Reiter wrote: > > [1 ] > [1.1 ] > http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/doc/gpgme.texi?rev=1298 > explains for check_version()_: > In either case, the function initializes some > sub-systems, and for this reason alone it must be invoked early in > your program, before you make use of the other functions in > @acronym{GPGME}. > > But the remaining examples codes in the documentation do not contain a hint > towards it. It is a must to add it in the @node I/O Callback Example . I added a call to init_gpgme (an earlier example, used to be init_program) to the main program. > I strongly recommend to add it to shorter examples as well as some > (experienced) programmers will look at the examples first and might miss > the requirement to use check_version(). It would be more useful to have a documented, complete example with a step-by-step explanation and a Makefile. This could even be an introductory chapter. Thanks, Marcus From kasahara at nc.kyushu-u.ac.jp Fri Mar 7 06:29:46 2008 From: kasahara at nc.kyushu-u.ac.jp (Yoshiaki Kasahara) Date: Fri, 07 Mar 2008 14:29:46 +0900 (JST) Subject: gpgsm and mail address Message-ID: <20080307.142946.885046884881319010.kasahara@nc.kyushu-u.ac.jp> Hello, I just subscribed this ML to report a difficulty I faced recently when using gpgsm for S/MIME. One of my co-workers has a certificate which doesn't contains subjectAltName extension ("aka"), but does contain PKCS #9 emailAddress attribute in the DN. gpgsm -kv shows the certificate like this (name and address masked): ID: 0x42E8F696 S/N: 388E8742292DF9E49B236F1C50FC303D Issuer: /CN=S\x2fMIME for UPKI Project/OU=Class 1 OnSite Individual Subscriber CA/OU=Terms of use at https:\x2f\x2fwww.verisign.co.jp\x2frpa (c)06/OU=VeriSign Trust Network/O=National Institute of Informatics Subject: /CN=(His name)/OU=Terms of use at www.verisign.co.jp\x2frpa (c)06/OU=S\x2fMIME for UPKI Project/O=National Institute of Informatics/EMail=(his email address) validity: 2007-07-03 00:00:00 through 2008-07-02 23:59:59 key type: 1024 bit RSA policies: 2.16.840.1.113733.1.7.23.1:N: fingerprint: 03:8D:C5:66:87:66:5C:FE:46:70:E0:D3:AC:7C:B3:66:42:E8:F6:96 It seems that gpgsm doesn't recognize DN's EMail attribute as an email address, so I cannot specify his certificate by his email address. "gpgsm -kv " returns nothing. Here is an excerpt from RFC3850: Receiving agents MUST recognize email addresses in the subjectAltName field. Receiving agents MUST recognize email addresses in the Distinguished Name field in the PKCS #9 [PKCS9] emailAddress attribute: pkcs-9-at-emailAddress OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 } Note that this attribute MUST be encoded as IA5String. So I think it should be possible to use an email address in PKCS #9 emailAdderss attribute to specify his certificate. I'm using gpgsm (GnuPG) 2.0.8. Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasahara at nc.kyushu-u.ac.jp From flameeyes at gmail.com Sat Mar 8 01:05:44 2008 From: flameeyes at gmail.com (Diego 'Flameeyes' =?utf-8?Q?Petten=C3=B2?=) Date: Sat, 08 Mar 2008 01:05:44 +0100 Subject: gpg-agent (2.0.7) hardcodes usage of /tmp directory Message-ID: Hi, I've been fiddling around with pam_mktemp in Gentoo, which creates a private temporary directory per each user in /tmp/.private/$username, and sets the TMPDIR variable accordingly. Unfortunately gpg-agent ignores the TMPDIR variable entirely and always create its socket in /tmp. Would it be possible to make it respect TMPDIR instead? I think this is what the GNU coding standards suggests already, by the way. -- Diego "Flameeyes" Petten? http://blog.flameeyes.eu/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From wk at gnupg.org Mon Mar 10 10:49:36 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 10 Mar 2008 10:49:36 +0100 Subject: gpgsm and mail address In-Reply-To: <20080307.142946.885046884881319010.kasahara@nc.kyushu-u.ac.jp> (Yoshiaki Kasahara's message of "Fri, 07 Mar 2008 14:29:46 +0900 (JST)") References: <20080307.142946.885046884881319010.kasahara@nc.kyushu-u.ac.jp> Message-ID: <87skyysybz.fsf@wheatstone.g10code.de> On Fri, 7 Mar 2008 06:29, kasahara at nc.kyushu-u.ac.jp said: > gpgsm -kv shows the certificate like this (name and address masked): Please do a gpgsm --dump-cert 0x42E8F696 and a gpgsm -k --with-colons 0x42E8F696 so that we can better identify why the email RDN does not show up as an aka. You may also want to send me the certificate by private mail. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon Mar 10 19:12:01 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 10 Mar 2008 19:12:01 +0100 Subject: gpg-agent (2.0.7) hardcodes usage of /tmp directory In-Reply-To: ("Diego =?utf-8?Q?Petten=C3=B2=22'?= =?utf-8?Q?s?= message of "Sat, 08 Mar 2008 01:05:44 +0100") References: Message-ID: <87d4q2phxq.fsf@wheatstone.g10code.de> On Sat, 8 Mar 2008 01:05, flameeyes at gmail.com said: > Unfortunately gpg-agent ignores the TMPDIR variable entirely and always > create its socket in /tmp. IMHO this is correct. We are not using a temporary directory but a using /tmp as directory known to be local. This is a requirement for creating a socket. Consider the case the user would set TMPDIR to a remotely mounted file system on a very fast server; depending on the file system you would not be able to create a socket then. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From flameeyes at gmail.com Mon Mar 10 19:23:24 2008 From: flameeyes at gmail.com (Diego 'Flameeyes' =?utf-8?Q?Petten=C3=B2?=) Date: Mon, 10 Mar 2008 19:23:24 +0100 Subject: gpg-agent (2.0.7) hardcodes usage of /tmp directory References: <87d4q2phxq.fsf@wheatstone.g10code.de> Message-ID: Werner Koch writes: > On Sat, 8 Mar 2008 01:05, flameeyes at gmail.com said: > >> Unfortunately gpg-agent ignores the TMPDIR variable entirely and always >> create its socket in /tmp. > > IMHO this is correct. We are not using a temporary directory but a > using /tmp as directory known to be local. This is a requirement for > creating a socket. Consider the case the user would set TMPDIR to a > remotely mounted file system on a very fast server; depending on the > file system you would not be able to create a socket then. Uhm, what does tell you that /tmp is certainly local? What about nfsroot clients? /tmp might not be local either. Otherwise, a solution would be to expect the setup to provide an user-writable /var/run subdirectory and use that, which would be better suited for sockets. -- Diego "Flameeyes" Petten? http://blog.flameeyes.eu/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From wk at gnupg.org Mon Mar 10 22:39:57 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 10 Mar 2008 22:39:57 +0100 Subject: gpg-agent (2.0.7) hardcodes usage of /tmp directory In-Reply-To: ("Diego =?utf-8?Q?Petten=C3=B2=22'?= =?utf-8?Q?s?= message of "Mon, 10 Mar 2008 19:23:24 +0100") References: <87d4q2phxq.fsf@wheatstone.g10code.de> Message-ID: <87skyyntqq.fsf@wheatstone.g10code.de> On Mon, 10 Mar 2008 19:23, flameeyes at gmail.com said: > Uhm, what does tell you that /tmp is certainly local? What about nfsroot > clients? /tmp might not be local either. LAcking a standard, common Unix wisdom. And the fact that sockets of user servers are always created there. /tmp should be local for performance reesons; if you want to nfs mount it, you better make sure that clients get their own space so that you don't run into PID conflicts. > Otherwise, a solution would be to expect the setup to provide an > user-writable /var/run subdirectory and use that, which would be better > suited for sockets. That would indeed be the better solution but lacking any widespread adoption. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From flameeyes at gmail.com Tue Mar 11 11:51:03 2008 From: flameeyes at gmail.com (Diego 'Flameeyes' =?utf-8?Q?Petten=C3=B2?=) Date: Tue, 11 Mar 2008 11:51:03 +0100 Subject: gpg-agent (2.0.7) hardcodes usage of /tmp directory References: <87d4q2phxq.fsf@wheatstone.g10code.de> <87skyyntqq.fsf@wheatstone.g10code.de> Message-ID: Werner Koch writes: > LAcking a standard, common Unix wisdom. And the fact that sockets of > user servers are always created there. /tmp should be local for > performance reesons; if you want to nfs mount it, you better make sure > that clients get their own space so that you don't run into PID > conflicts. FWIW KDE creates its socket respecting $TMPDIR, as does XEmacs. I sincerely suspect it's more likely that $TMPDIR is local and fast than /tmp itself, if set. Plus there is a well-designed usage pattern with pam_mktemp to mitigate temporary file vulnerabilities. All in all, I still fail to see why hardcoding /tmp is better than respecting TMPDIR. -- Diego "Flameeyes" Petten? http://blog.flameeyes.eu/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From wk at gnupg.org Tue Mar 11 12:13:30 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Mar 2008 12:13:30 +0100 Subject: gpg-agent (2.0.7) hardcodes usage of /tmp directory In-Reply-To: ("Diego =?utf-8?Q?Petten=C3=B2=22'?= =?utf-8?Q?s?= message of "Tue, 11 Mar 2008 11:51:03 +0100") References: <87d4q2phxq.fsf@wheatstone.g10code.de> <87skyyntqq.fsf@wheatstone.g10code.de> Message-ID: <874pbdms2t.fsf@wheatstone.g10code.de> On Tue, 11 Mar 2008 11:51, flameeyes at gmail.com said: > All in all, I still fail to see why hardcoding /tmp is better than > respecting TMPDIR. Because it does not work. TMPDIR is commonly used if you need more space for temporary files and thus it is likely to be mounted on a remote file system. FWIW, ssh-agent also hard codes /tmp. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From rdieter at math.unl.edu Tue Mar 11 18:09:15 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 11 Mar 2008 12:09:15 -0500 Subject: gpg-agent (2.0.7) hardcodes usage of /tmp directory References: <87d4q2phxq.fsf@wheatstone.g10code.de> <87skyyntqq.fsf@wheatstone.g10code.de> <874pbdms2t.fsf@wheatstone.g10code.de> Message-ID: Werner Koch wrote: > On Tue, 11 Mar 2008 11:51, flameeyes at gmail.com said: > >> All in all, I still fail to see why hardcoding /tmp is better than >> respecting TMPDIR. > > Because it does not work. TMPDIR is commonly used if you need more > space for temporary files and thus it is likely to be mounted on a > remote file system. Imo, anyone who does so (making TMPDIR point to a non-local fs) is introducing problems of their own making, and isn't a use-case worth worrying much about. -- Rex From erictetz at gmail.com Wed Mar 12 02:00:02 2008 From: erictetz at gmail.com (Eric Tetz) Date: Tue, 11 Mar 2008 18:00:02 -0700 Subject: "constructive criticism of GPG" Message-ID: <5ac4e42f0803111800p17fbb78ct44e88e184daf9bb5@mail.gmail.com> I just subscribed briefly to bring this old post to your attention: http://lists.canonical.org/pipermail/kragen-tol/2001-March/000648.html I found it ween Googling for help, after going through pretty much the same steps he did, including being prompted to enter a message gpg couldn't possibly encrypt, and this: You need a User-ID to identify your key; the software constructs the user id from Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) " Real name: Eric Tetz (foo bar) Invalid character in name Real name: "Eric Tetz (foo bar) " Invalid character in name That's exactly the kind of UI where the meaning is obvious in retrospect (and to the programmer), yet is guaranteed to trip up first time users. What the user sees is AN EXAMPLE OF PROPER FORM, followed by A PROMPT: the intuitive response is to follow the example. It's a candy machine interface (http://tetzfiles.com/eric/code/docs/candyMachineInterfaces.html). In this case, showing the final form of the user ID is not only confusing, it SERVES NO PURPOSE. Why does it matter what form the ID ultimately takes, if the user is not allowed to enter the data in that form? It's much more straightforward to simply ask for what you want. If you really want to show them the final form, show them afterwards: GPG needs to construct a User-ID to identify your key. Real Name (First Last): Eric Tetz Email Address (username at host.com): erictetz at sandisk.com Comment: foo bar User-ID constructed: "Eric Tetz (foo bar) " Anyway, that's all. I just wanted to bring that post to your attention, because here it is 7 years later and people are still going through the exact same shit. :) Cheers, Eric From wk at gnupg.org Wed Mar 12 18:05:49 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 12 Mar 2008 18:05:49 +0100 Subject: gpgsm and mail address In-Reply-To: <20080307.142946.885046884881319010.kasahara@nc.kyushu-u.ac.jp> (Yoshiaki Kasahara's message of "Fri, 07 Mar 2008 14:29:46 +0900 (JST)") References: <20080307.142946.885046884881319010.kasahara@nc.kyushu-u.ac.jp> Message-ID: <87ejafkh3m.fsf@wheatstone.g10code.de> On Fri, 7 Mar 2008 06:29, kasahara at nc.kyushu-u.ac.jp said: > Subject: /CN=(His name)/OU=Terms of use at www.verisign.co.jp\x2frpa (c)06/OU=S\x2fMIME for UPKI Project/O=National Institute of Informatics/EMail=(his email address) Thanks for sending me the certificate. Actually there was no need for it. The reason for this bug is much simpler; The email RDN is not the first RDN and the code in gpgsm does only recognize the email if it is the first part. For example: if (strncmp (name, "1.2.840.113549.1.9.1=#", 22)) return NULL; /* No Email in DN. */ The fix is pretty straightforward; please give me a few days as I am currently attending a conference. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Wed Mar 12 18:10:16 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 12 Mar 2008 18:10:16 +0100 Subject: "constructive criticism of GPG" In-Reply-To: <5ac4e42f0803111800p17fbb78ct44e88e184daf9bb5@mail.gmail.com> (Eric Tetz's message of "Tue, 11 Mar 2008 18:00:02 -0700") References: <5ac4e42f0803111800p17fbb78ct44e88e184daf9bb5@mail.gmail.com> Message-ID: <877ig7kgw7.fsf@wheatstone.g10code.de> On Wed, 12 Mar 2008 02:00, erictetz at gmail.com said: > time users. What the user sees is AN EXAMPLE OF PROPER FORM, followed > by A PROMPT: the intuitive response is to follow the example. It's a You have a point here; gpg orginally aimed for the avaerage hacker and not for the casual user. Most users today use a GUI where different prompts are presented. The old bug report you mentioned is pretty out of date and listed a lot of things most of them have changed in the meantime. I think we should change the prompts. That needs to be done carefully to not break all translations. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Mar 13 08:11:28 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Mar 2008 08:11:28 +0100 Subject: gpgsm and mail address In-Reply-To: <20080307.142946.885046884881319010.kasahara@nc.kyushu-u.ac.jp> (Yoshiaki Kasahara's message of "Fri, 07 Mar 2008 14:29:46 +0900 (JST)") References: <20080307.142946.885046884881319010.kasahara@nc.kyushu-u.ac.jp> Message-ID: <87fxuvgktb.fsf@wheatstone.g10code.de> Hi, find attached a patch to fix this bug. There is one problem, though: You need to delete the certificate from gnupg's keystore and then import it again using the patched version: gpgsm --delete-key 0x42E8F696 gpgsm --import foo.crt Thanks for reporting, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gnupg-email-kludge-fix.diff URL: From richih.mailinglist at gmail.com Thu Mar 13 11:35:30 2008 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 13 Mar 2008 11:35:30 +0100 Subject: "constructive criticism of GPG" In-Reply-To: <877ig7kgw7.fsf@wheatstone.g10code.de> References: <5ac4e42f0803111800p17fbb78ct44e88e184daf9bb5@mail.gmail.com> <877ig7kgw7.fsf@wheatstone.g10code.de> Message-ID: <2d460de70803130335t4985d19ar8f78975afc3038fe@mail.gmail.com> Let me start by saying that I ran into that as well when I first used GPG years back. On Wed, Mar 12, 2008 at 6:10 PM, Werner Koch wrote: > I think we should change the prompts. That needs to be done carefully to > not break all translations. When strings change, translations will break. Given time, translators should be able to do their translations during the normal development cycle, though. Richard From kristo at no-log.org Thu Mar 13 14:00:02 2008 From: kristo at no-log.org (Kristo) Date: Thu, 13 Mar 2008 14:00:02 +0100 Subject: GnuPG with GPG-agent In-Reply-To: <87fxuvgktb.fsf@wheatstone.g10code.de> References: <20080307.142946.885046884881319010.kasahara@nc.kyushu-u.ac.jp> <87fxuvgktb.fsf@wheatstone.g10code.de> Message-ID: <47D92552.2070502@no-log.org> Hi, I am new to this list, so hello everybody. I'm using GnuPG 1.4.7 and it works fine. I would like to use gpg-agent but it seems that it is theoretically only available with GnuPG 2. But I did not find any executable to install it. I'm using Windows XP. I found a gpg-agent here : ftp://ftp.gnupg.org/gcrypt/alpha/binary/gnupg-w32cli-1.9.14.zip (found in http://www.gossamer-threads.com/lists/gnupg/devel/35838 ) and I tried to install it, I configured gpg.conf and gpg-agent.conf files, but it does not work. A friend sent me a pinentry he tried to compile for Windows, but it seems it does not work too and it may be the reason why gpg-agent does not work. Do you know where I can find an exe version of pinentry for Windows ? and a working gpg-agent ? Thanks a lot, Kris From kasahara at nc.kyushu-u.ac.jp Fri Mar 14 08:16:36 2008 From: kasahara at nc.kyushu-u.ac.jp (Yoshiaki Kasahara) Date: Fri, 14 Mar 2008 16:16:36 +0900 (JST) Subject: gpgsm and mail address In-Reply-To: <87fxuvgktb.fsf@wheatstone.g10code.de> References: <20080307.142946.885046884881319010.kasahara@nc.kyushu-u.ac.jp> <87fxuvgktb.fsf@wheatstone.g10code.de> Message-ID: <20080314.161636.926824993550542579.kasahara@nc.kyushu-u.ac.jp> Hi, On Thu, 13 Mar 2008 08:11:28 +0100, Werner Koch said: > find attached a patch to fix this bug. There is one problem, though: > You need to delete the certificate from gnupg's keystore and then import > it again using the patched version: I confirmed that now I can find his cert using his email address after re-importing his cert by the patched version. Thank you very much! -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasahara at nc.kyushu-u.ac.jp From rw at rlworkman.net Wed Mar 19 06:02:08 2008 From: rw at rlworkman.net (Robby Workman) Date: Wed, 19 Mar 2008 00:02:08 -0500 Subject: scim and pinentry-gtk2 In-Reply-To: <87hcfvg8wu.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <47BDF11A.8010500@rlworkman.net> <87hcfvg8wu.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <47E09E50.8040106@rlworkman.net> Sorry for the dupe, Marcus - forgot to send to list the first time. Marcus Brinkmann wrote: > At Thu, 21 Feb 2008 15:46:02 -0600, > Robby Workman wrote: >> To make a long story short, pinentry-gtk2 doesn't receive keyboard >> input when scim is being used. This has previously been reported >> to both Ubuntu and OpenSuSE, and after scim and friends were recently >> added to Slackware, we're seeing it there. >> >> https://bugs.launchpad.net/ubuntu/+source/pinentry/+bug/176815 >> >> https://bugzilla.novell.com/show_bug.cgi?id=330073#c5 >> >> Any idea what's at fault? > > pinentry grabs the keyboard and the screen by default (there is an > option to switch it off). Maybe scim doesn't work well with that? Hi Marcus, Sorry for the delay - I've unfortunately been short on time lately. Starting gpg-agent with the --no-grab option has no effect. This is quite annoying for users who need alternate input methods, especially scim. Maybe I'm missing something obvious, but here's how it appears to me: 1. Pinentry is a GTK+ app. 2. GTK+ apps can use GTK+ input methods. 3. Rather than using an input method, pinentry grabs the raw input. I understand that there are perhaps security concerns with not grabbing raw input, but surely there's a way to fix this? pinentry-qt handles this just fine, btw... -RW From sutter at informatik.hs-furtwangen.de Wed Mar 19 22:23:25 2008 From: sutter at informatik.hs-furtwangen.de (Phil Sutter) Date: Wed, 19 Mar 2008 22:23:25 +0100 Subject: Secret Sharing Message-ID: <20080319212325.GB12049@nuty.freewrt> Hi! With beginning of this month I've started writing my diploma thesis about implementing Secret Sharing in GnuPG. This topic has been discussed on this list way back in 1998, where implementing it was deferred until 1.0 is out. What is your current attitude towards an implementation? I would highly appreciate if you could send me some information about how to proceed, i.e. which people I should talk to, where to discuss implementation/design specific questions, where to send code for a review to, et cetera. Another thing is the Google Summer of Code. As I have to be finished with my work until first of September, my project fits into their timeline. What do you think, is it worth proposing it? Greetings, Phil From sutter at informatik.hs-furtwangen.de Thu Mar 20 01:13:48 2008 From: sutter at informatik.hs-furtwangen.de (Phil Sutter) Date: Thu, 20 Mar 2008 01:13:48 +0100 Subject: Secret Sharing In-Reply-To: <200803192351.01472.sergi@calcurco.cat> References: <20080319212325.GB12049@nuty.freewrt> <200803192351.01472.sergi@calcurco.cat> Message-ID: <20080320001348.GA6380@nuty.freewrt> Hi, On Wed, Mar 19, 2008 at 11:50:48PM +0100, Sergi Blanch i Torn? wrote: > I want to encourage you in this project. It looks very nice to have something > about secret sharing to play. I can share my experience (to help you to avoid > mystakes that I did) writing a patch. sounds great. I'm really looking forward to it. > The first that I can advise you is to read, read and read code. Not only the > GnuPG's ones, but specially these. In the ecc patch I didn't follow the > coding style and this makes hard a good adequacy. Some one else (Werner > probably, but authors file doesn't say it specifically, correct me if I > mistake) did it. This is an overload that if you work fine would be bypassed. That's surely true. Currently I'm reading much about the mathematical aspects of secret sharing as well as methods for realising multi-time schemes which e.g. allow adding/revoking users without having to distribute new keys to all participants. Since in another project I'm working on getting some kernel patches upstream, I already made first contact with "indent" and coding style in general, so all this is not completely new to me. > IMHO, is important to receive feedbacks, specially to realize that you are not > alone. Also publish it under a free software license when you have something > usable. Yes, of course. Not only because I'm hoping to eventually getting this upstream, GPL will be my choice of license. > Good luck! Thanks a lot! :) Greetings, Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sergi at calcurco.cat Wed Mar 19 23:50:48 2008 From: sergi at calcurco.cat (Sergi Blanch i =?iso-8859-1?q?Torn=E9?=) Date: Wed, 19 Mar 2008 23:50:48 +0100 Subject: Secret Sharing In-Reply-To: <20080319212325.GB12049@nuty.freewrt> References: <20080319212325.GB12049@nuty.freewrt> Message-ID: <200803192351.01472.sergi@calcurco.cat> Hi! I want to encourage you in this project. It looks very nice to have something about secret sharing to play. I can share my experience (to help you to avoid mystakes that I did) writing a patch. The first that I can advise you is to read, read and read code. Not only the GnuPG's ones, but specially these. In the ecc patch I didn't follow the coding style and this makes hard a good adequacy. Some one else (Werner probably, but authors file doesn't say it specifically, correct me if I mistake) did it. This is an overload that if you work fine would be bypassed. IMHO, is important to receive feedbacks, specially to realize that you are not alone. Also publish it under a free software license when you have something usable. Good luck! /Sergi. On Wednesday 19 March 2008 22:23:25 Phil Sutter wrote: > Hi! > > With beginning of this month I've started writing my diploma thesis > about implementing Secret Sharing in GnuPG. This topic has been > discussed on this list way back in 1998, where implementing it was > deferred until 1.0 is out. > What is your current attitude towards an implementation? > > I would highly appreciate if you could send me some information about > how to proceed, i.e. which people I should talk to, where to discuss > implementation/design specific questions, where to send code for a > review to, et cetera. > > Another thing is the Google Summer of Code. As I have to be finished > with my work until first of September, my project fits into their > timeline. What do you think, is it worth proposing it? > > Greetings, Phil > > _______________________________________________ > 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: not available Type: application/pgp-signature Size: 206 bytes Desc: This is a digitally signed message part. URL: From simon at josefsson.org Thu Mar 20 11:30:26 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 20 Mar 2008 11:30:26 +0100 Subject: Secret Sharing In-Reply-To: <20080319212325.GB12049@nuty.freewrt> (Phil Sutter's message of "Wed, 19 Mar 2008 22:23:25 +0100") References: <20080319212325.GB12049@nuty.freewrt> Message-ID: <878x0d8z7h.fsf@mocca.josefsson.org> Phil Sutter writes: > Hi! > > With beginning of this month I've started writing my diploma thesis > about implementing Secret Sharing in GnuPG. Cool! Good luck. > What is your current attitude towards an implementation? One thing that would concern me that this may modify code which is quite security critical. Having your patches make only the minimal necessary changes in the code path is likely to make your patches more acceptable. Make the behaviour optional, and if the user haven't enabled the feature, the code one would have to audit to convince your patch doesn't introduce any problem should be small. There are some aspects of secret sharing that aren't clear to me. For instance, would your implementation require that all the shared pieces be available locally in a file? One could invent ideas which involved network access instead of local access, but I'd be quite concerned with security and authentication in that case. If you post a short write-up with more details about how you intend to implement this, I think you will get feedback that will help you to avoid spending time implementing sub-optimal ideas. /Simon From wk at gnupg.org Thu Mar 20 12:09:57 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Mar 2008 12:09:57 +0100 Subject: Secret Sharing In-Reply-To: <200803192351.01472.sergi@calcurco.cat> ("Sergi Blanch i. =?utf-8?Q?Torn=C3=A9=22's?= message of "Wed, 19 Mar 2008 23:50:48 +0100") References: <20080319212325.GB12049@nuty.freewrt> <200803192351.01472.sergi@calcurco.cat> Message-ID: <87prtptzwa.fsf@wheatstone.g10code.de> On Wed, 19 Mar 2008 23:50, sergi at calcurco.cat said: > GnuPG's ones, but specially these. In the ecc patch I didn't follow the > coding style and this makes hard a good adequacy. Some one else (Werner Yeah GNU coding standard should be used for all new code. I use minor variations sometimes like "!foo" instead of "! foo" and "!foo" instead of "foo == 0" but that is just my personal taste. For all contributions the FSF requires a copyright assigbnment or at leas a disclaimer from the author and possible the employer. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Mar 20 12:14:45 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Mar 2008 12:14:45 +0100 Subject: Secret Sharing In-Reply-To: <20080319212325.GB12049@nuty.freewrt> (Phil Sutter's message of "Wed, 19 Mar 2008 22:23:25 +0100") References: <20080319212325.GB12049@nuty.freewrt> Message-ID: <87lk4dtzoa.fsf@wheatstone.g10code.de> On Wed, 19 Mar 2008 22:23, sutter at informatik.hs-furtwangen.de said: > What is your current attitude towards an implementation? There is no standard for it except for a flag telling that the secret key is shared. My major concerns with secret sharing is that I have no idea on how to make a good user interface. > I would highly appreciate if you could send me some information about > how to proceed, i.e. which people I should talk to, where to discuss > implementation/design specific questions, where to send code for a > review to, et cetera. gnupg-devel at gnupg.org is the place for this. > Another thing is the Google Summer of Code. As I have to be finished That is up to you. Don't count on my as mentor etc. I do not want to help that company in any way in particular not PR-wise. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From sutter at informatik.hs-furtwangen.de Thu Mar 20 20:04:38 2008 From: sutter at informatik.hs-furtwangen.de (Phil Sutter) Date: Thu, 20 Mar 2008 20:04:38 +0100 Subject: Secret Sharing In-Reply-To: <878x0d8z7h.fsf@mocca.josefsson.org> References: <20080319212325.GB12049@nuty.freewrt> <878x0d8z7h.fsf@mocca.josefsson.org> Message-ID: <20080320190438.GA3572@nuty.freewrt> Hi, On Thu, Mar 20, 2008 at 11:30:26AM +0100, Simon Josefsson wrote: > Cool! Good luck. thanks! > One thing that would concern me that this may modify code which is quite > security critical. Having your patches make only the minimal necessary > changes in the code path is likely to make your patches more acceptable. > Make the behaviour optional, and if the user haven't enabled the > feature, the code one would have to audit to convince your patch doesn't > introduce any problem should be small. Yes, of course. I don't even want to think about me compromising the GnuPG security. Also it's surely unnecessary to bloat up the code with a feature only relatively few people will be using. So having everything on a modular base should be the way to go. > There are some aspects of secret sharing that aren't clear to me. For > instance, would your implementation require that all the shared pieces > be available locally in a file? One could invent ideas which involved > network access instead of local access, but I'd be quite concerned with > security and authentication in that case. Well, this is exactly the problem I'm currently working on. Security indeed is a big problem here, as in fact secret data has to be exchanged somehow, and in many cases this allows bad people to collect shares until they are able to recreate the secret themselves. On the other hand GnuPG until now is just an application without daemon-functionality. I doubt it's economic to change this. > If you post a short write-up with more details about how you intend to > implement this, I think you will get feedback that will help you to > avoid spending time implementing sub-optimal ideas. Yes, I will do that as soon as I made up some methods of handling the actions involved in secret sharing. I've already thought about using existing GnuPG features for establishing secured connections, e.g. via encrypted emails. But the implementations of this kind of delayed communication still have to be evaluated. Greetings, Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sutter at informatik.hs-furtwangen.de Thu Mar 20 20:25:29 2008 From: sutter at informatik.hs-furtwangen.de (Phil Sutter) Date: Thu, 20 Mar 2008 20:25:29 +0100 Subject: Secret Sharing In-Reply-To: <87lk4dtzoa.fsf@wheatstone.g10code.de> References: <20080319212325.GB12049@nuty.freewrt> <87lk4dtzoa.fsf@wheatstone.g10code.de> Message-ID: <20080320192529.GB3572@nuty.freewrt> On Thu, Mar 20, 2008 at 12:14:45PM +0100, Werner Koch wrote: > My major concerns with secret sharing is that I have no idea on how to > make a good user interface. This is another good question, and in some ways also associated to my questions about how to design the processes. > > Another thing is the Google Summer of Code. As I have to be finished > > That is up to you. Don't count on my as mentor etc. I do not want to > help that company in any way in particular not PR-wise. Well, me neither. My motivations for doing it were mainly of monetary kind. As I'm writing my thesis internally, this is the only chance of getting paid for my work. When searching for a mentoring organisation, I think I'll anyway have to address GNU directly. So I'll do that and then see what they say. Greetings, Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sergi at calcurco.cat Thu Mar 20 23:08:22 2008 From: sergi at calcurco.cat (Sergi Blanch i =?utf-8?q?Torn=C3=A9?=) Date: Thu, 20 Mar 2008 23:08:22 +0100 Subject: Secret Sharing In-Reply-To: <20080320192529.GB3572@nuty.freewrt> References: <20080319212325.GB12049@nuty.freewrt> <87lk4dtzoa.fsf@wheatstone.g10code.de> <20080320192529.GB3572@nuty.freewrt> Message-ID: <200803202308.22455.sergi@calcurco.cat> On Thursday 20 March 2008 20:25:29 Phil Sutter wrote: > On Thu, Mar 20, 2008 at 12:14:45PM +0100, Werner Koch wrote: > > My major concerns with secret sharing is that I have no idea on how to > > make a good user interface. > > This is another good question, and in some ways also associated to my > questions about how to design the processes. As far as I know, it is not easy to solve this but neither is so hard. For an (n, t)-threshold scheme (where, I think means 'n' keys with any 't' keys enough to decrypt) should be like have access to this 't' keys like typing all the passphrases or introducing 't' smartcards. Would be a task for libassuan? The point that I really don't know is how could be possible to allow a live together on keys of different nature, like finite fields one with an ecc. /Sergi. From stephane at sente.ch Fri Mar 21 18:32:07 2008 From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Fri, 21 Mar 2008 18:32:07 +0100 Subject: gpg-agent and launchd Message-ID: Hi, I'd like to see support of launchd in gpg-agent. "launchd is a unified, open source service management framework for starting, stopping and managing daemons, programs and scripts" (wikipedia) It is open-source , under apache license, and is, under Darwin/MacOSX, responsible to launch all daemons and agents, based on different criteria, and will relaunch them if necessary. It replaces init, watchdogd, crond, etc. Though apache license is incompatible with GPL, launchd is a system component on OSX (this is even the key component, with PID 1). That shouldn't cause problem, would it? The goal is to have a well-integrated agent under MacOSX 10.5: the agent is launched when user logs in, is relaunched automatically in case of failure, and is stopped when user logs out. This is already achievable currently, but there are some limitations: - as gpg-agent runs as a daemon, we cannot watchdog it, and relaunch it automatically, without an external watch dog process - as we cannot make all user processes inherit from the environment variables of gpg-agent (user processes don't read the ~/.login or whatever), we need to stick with standard socket path, which works only if the home directory is mounted as a local file system - when user logs out, gpg-agent is not terminated automatically On a technical POV, a program launched by launchd must respect the following constraints (copied from launchd.plist(5) man page): It MUST NOT: ? Call daemon(3). ? Do the moral equivalent of daemon(3) by calling fork(2) and have the parent process exit(3) or _exit(2). It SHOULD NOT: ? Setup the user ID or group ID. ? Setup the working directory. ? chroot(2) ? setsid(2) ? Close "stray" file descriptors. ? Change stdio(3) to /dev/null. ? Setup resource limits with setrusage(2). ? Setup priority with setpriority(2). ? Ignore the SIGTERM signal. It SHOULD: ? Launch on demand given criteria specified in the XML property list. More information can be found later in this man page. ? Catch the SIGTERM signal. Avoiding fork() is possible, as it is already done for Win32. Avoiding the chdir() too, as well as avoiding changing uig, gid, sid. I found no setrusage() nor setpriority(), at first look. SIGTERM is not ignored, and actually used by the code to terminate properly. I have no idea about the two other constraints, Close "stray" file descriptors, and Change stdio(3) to /dev/null. Launching the agent on demand is unfortunately not possible: though we can configure launchd to create a secure socket, pass it through an environment variable, and launch gpg-agent only when the secure socket is being accessed, this is not possible for gpg-agent, because agent client processes (gpg) expect the GPG_AGENT_INFO to contain the socket path, the agent pid, and a version number. This cannot work for us, as the pid is unknown until the agent has been launched, and the created environment variable is only the socket path. Anyway, launching the agent at user's login works fine too. I modified gpg-agent 2.0.8 to add support for launchd: I had to modify only gpg-agent.c. I added a new command, --launchd, which is exclusive with --daemon and --server, and does currently the following: - it creates sockets, like in daemon mode - it does not fork - this is forbidden - it does not run any program on the command line - this is forbidden - it does not print the environment variables (though it might, maybe) - it passes back to launchd the environment variables; launchd will make all user processes inherit of these variables - it does not detach from tty (I don't know what this means and what are the consequences) - it doesn't chdir("/"), but the launchd plist sets the working dir to "/", so it should be equivalent - it removes the environment variables from launchd, when terminating Is there any interest here to review and maybe include that code (available on demand) into gpg-agent? St?phane From prlewis at letterboxes.org Fri Mar 21 22:50:25 2008 From: prlewis at letterboxes.org (Peter Lewis) Date: Fri, 21 Mar 2008 21:50:25 +0000 Subject: gpg-agent and poldi. Message-ID: <200803212150.30563.prlewis@letterboxes.org> Hello, Firstly, thanks for some great software :-) I've been using gpg for a couple of months now, including using poldi to log me in and unlock sessions with my cryptocard from the FSFE. However, I'm having a problem using gpg-agent to cache the smartcard's PIN along with the poldi PAM module. Specifically, once gpg-agent has cached the PIN, poldi no longer works, meaning that I can't use it for authenticating su / sudo commands or for unlocking the session or logging in on another terminal. I found this in the list archives: On Tue Jul 19 13:48:23 CEST 2005, Werner Koch said: > On Fri, 15 Jul 2005 13:33:51 +0300, Joachim Breitner said: >> Also, with scdaemon, there might be problems with other programs using >> the smartcard, e.g. HBCI, but also libpam-poldi. Haven't investigated >> that though. > > I already talked with Moritz about this. In general it should not > happen because gpg-agent is started after a successful login and poldi > needs then to relinquish control over the card reader. The problem > seems to be any PAM access later on (e.g. su). We might need to watch > out for a running scdaemon and utilize it the same way as gpg does it. Is there any progress towards making this work yet? Any fix / patch / workaround available? Many thanks, Peter. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part. URL: From fweimer at bfk.de Sat Mar 22 17:36:30 2008 From: fweimer at bfk.de (Florian Weimer) Date: Sat, 22 Mar 2008 17:36:30 +0100 Subject: gpg-agent (2.0.7) hardcodes usage of /tmp directory In-Reply-To: <87d4q2phxq.fsf@wheatstone.g10code.de> (Werner Koch's message of "Mon, 10 Mar 2008 19:12:01 +0100") References: <87d4q2phxq.fsf@wheatstone.g10code.de> Message-ID: <82od96wwa9.fsf@mid.bfk.de> * Werner Koch: > IMHO this is correct. We are not using a temporary directory but a > using /tmp as directory known to be local. This is a requirement for > creating a socket. Is it, really? They don't work for inter-node communication, but on the same node, everything should work as expected. (/dev/log works on NFS, too.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From wk at gnupg.org Wed Mar 26 12:10:34 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Mar 2008 12:10:34 +0100 Subject: [Announce] GnuPG 2.0.9 released Message-ID: <87k5jpzqol.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.9 The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data, create digital signatures, help authenticating using Secure Shell and to provide a framework for public key cryptography. It includes an advanced key management facility and is compliant with the OpenPGP and S/MIME standards. GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.8) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. GnuPG is distributed under the terms of the GNU General Public License (GPL version 3). GnuPG-2 works best on GNU/Linux or *BSD systems. What's New =========== * Gpgsm always tries to locate missing certificates from a running Dirmngr's cache. * Tweaks for Windows. * The Admin PIN for OpenPGP cards may now be entered with the pinpad. * Improved certificate chain construction. * Extended the PKITS framework. * Fixed a bug in the ambigious name detection. * Fixed possible memory corruption while importing OpenPGP keys (bug introduced with 2.0.8). * Minor bug fixes. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.9 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the FTP server and ist mirrors you should find the following files in the gnupg/ directory: gnupg-2.0.9.tar.bz2 (3631k) gnupg-2.0.9.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.8-2.0.9.diff.bz2 (114k) A patch file to upgrade a 2.0.8 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.9.tar.bz2 you would use this command: gpg --verify gnupg-2.0.9.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.9.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.9.tar.bz2 and check that the output matches the first line from the following list: 959bdb934e3a72d256bfbd0122d996a73adb5d1f gnupg-2.0.9.tar.bz2 f73c43b468c91a4fbe7e07e37bd5b84a7887b1f0 gnupg-2.0.8-2.0.9.diff.bz2 Internationalization ==================== GnuPG comes with support for 27 languages. Due to a lot of new and changed strings many translations are not entirely complete. The Chinese, German, Polish, Russian, Swedish and Turkish translations are close to be complete. Documentation ============= We are currently working on an installation guide to explain in more detail how to configure the new features. As of now the chapters on gpg-agent and gpgsm include brief information on how to set up the whole thing. Please watch the GnuPG website for updates of the documentation. In the meantime you may search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. KDE's KMail is the most prominent user of GnuPG-2. In fact it has been developed along with the KMail folks. Mutt users might want to use the configure option "--enable-gpgme" and "set use_crypt_gpgme" in ~/.muttrc to make use of GnuPG-2 to enable S/MIME in addition to a reworked OpenPGP support. The manual is also available online in HTML format at http://www.gnupg.org/documentation/manuals/gnupg/ and in Portable Document Format at http://www.gnupg.org/documentation/manuals/gnupg.pdf . Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, order extensions or support or more general by donating money to the Free Software movement (e.g. http://www.fsfeurope.org/help/donate.en.html). Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. The GnuPG service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team (David, Marcus, Werner and all other contributors) -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From lists at lina.inka.de Wed Mar 26 05:03:23 2008 From: lists at lina.inka.de (Bernd Eckenfels) Date: Wed, 26 Mar 2008 05:03:23 +0100 Subject: Secret Sharing In-Reply-To: <20080320190438.GA3572@nuty.freewrt> References: <20080319212325.GB12049@nuty.freewrt> <878x0d8z7h.fsf@mocca.josefsson.org> <20080320190438.GA3572@nuty.freewrt> Message-ID: <20080326040323.GA25112@lina.inka.de> On Thu, Mar 20, 2008 at 08:04:38PM +0100, Phil Sutter wrote: > Well, this is exactly the problem I'm currently working on. Security > indeed is a big problem here, as in fact secret data has to be exchanged > somehow, and in many cases this allows bad people to collect shares > until they are able to recreate the secret themselves. On the other hand > GnuPG until now is just an application without daemon-functionality. I > doubt it's economic to change this. The question is, what secrets are we talking about. I can imagine first of all, u plan a secret sharing where you simply "mix" user entry passphrases for the symmetric security (i.e. for encrypting files or keys). If we are talking about secret keys, the infrastructure (like a TCB booting from a self verifying media) is usually needed anyway. So it might not be needed to change Gnupg itself at all, you could just construct the secret key in a ram disk in such a secured device. (I am not sure if you plan to have a method, where you actually modify the actual algorithms to work with additional secrets. This would have the advantage that you never reconstruct the secret - but I am not sure if that is possible for RSA, DSA - possibly for ECC. So if we define that reconstructing the key is needed, a lot of that can be done outside the gnupg binary. Maybe you can even write a new daemon for the crypto card provider interface of gnupg.) > Yes, I will do that as soon as I made up some methods of handling the > actions involved in secret sharing. I've already thought about using > existing GnuPG features for establishing secured connections, e.g. via > encrypted emails. But the implementations of this kind of delayed > communication still have to be evaluated. Ah this sounds like you just want to have a GnuPG Encryption/Decryption mode which can be used by multiple users to work on Data. In that case the question is, if you want to exchnage the packet format to add new blocks for holding data which allows partial revealing of the session keys. Gruss Bernd From wk at gnupg.org Tue Mar 25 15:39:55 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Mar 2008 15:39:55 +0100 Subject: gpg-agent (2.0.7) hardcodes usage of /tmp directory In-Reply-To: <82od96wwa9.fsf@mid.bfk.de> (Florian Weimer's message of "Sat, 22 Mar 2008 17:36:30 +0100") References: <87d4q2phxq.fsf@wheatstone.g10code.de> <82od96wwa9.fsf@mid.bfk.de> Message-ID: <87r6dy3m10.fsf@wheatstone.g10code.de> On Sat, 22 Mar 2008 17:36, fweimer at bfk.de said: > Is it, really? They don't work for inter-node communication, but on > the same node, everything should work as expected. I am pretty sure that I once made that experience. Not necessary on GNU/Linux, though. I have no NFS at had but a quick test on CIFS shows bind(3, {sa_family=AF_FILE, path="/somewhere/xppro-c/tmp/foo.S"}, 31) = -1 EPERM (AF_FILE is an alias for AF_UNIX). Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Wed Mar 26 19:08:51 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Mar 2008 19:08:51 +0100 Subject: [Announce] GnuPG 1.4.9 released Message-ID: <8763v9uzm4.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-1 release: Version 1.4.9. This is a maintenance release to fix a possible vulnerability introduced with 1.4.8. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility, samrtcard support and is compliant with the OpenPGP Internet standard as described by RFC-4880 (the recently released update of RFC-2440). Note that this version is from the GnuPG-1 series and thus smaller than those from the GnuPG-2 series, easier to build and also better portable. In contrast to GnuPG-2 (e.g version 2.0.8) it comes with no support for S/MIME or other tools useful for desktop environments. Fortunately you may install both versions alongside on the same system without any conflict. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 1.4.9 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the following files in the *gnupg* directory: gnupg-1.4.9.tar.bz2 (3250k) gnupg-1.4.9.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.4.9.tar.gz (4554k) gnupg-1.4.9.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.4.8-1.4.9.diff.bz2 (12k) A patch file to upgrade a 1.4.8 GnuPG source. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. In the *binary* directory, you should find these files: gnupg-w32cli-1.4.9.exe (2119k) gnupg-w32cli-1.4.9.exe.sig GnuPG compiled for Microsoft Windows and OpenPGP signature. This is a command line only version; the source files are the same as given above. Note, that this is a minimal installer and unless you are just in need for the gpg binary, you are better off using the full featured installer at http://www.gpg4win.org . A new version of Gpg4win, including this version of GnuPG will be available and announced soon. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.4.9.tar.bz2 you would use this command: gpg --verify gnupg-1.4.9.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a keyserver like gpg --recv-key 1CE0C630 The distribution key 1CE0C630 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-1.4.9.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-1.4.9.tar.bz2 and check that the output matches the second line from the following list: 826f4bef1effce61c3799c8f7d3cc8313b340b55 gnupg-1.4.9.tar.bz2 52a245d20da70a3f79a2134c8ece3a1d30554ffa gnupg-1.4.9.tar.gz 59ec735f425c37722746be68bf12565e2380362e gnupg-1.4.8-1.4.9.diff.bz2 c2efad983dfe50e6d8007257bad2c76604be389a gnupg-w32cli-1.4.9.exe What's New =========== * Improved AES encryption performance by more than 20% (on ia32). Decryption is also a bit faster. * Fixed possible memory corruption bug in 1.4.8 while importing OpenPGP keys. Internationalization ==================== GnuPG comes with support for 28 languages. Due to a lot of new and changed strings some translations are not entirely complete. The Chinese (Simple and Traditional), Czech, Dutch, French, German, Norwegian, Polish, Romanian, Russian, Spanish, Swedish and Turkish translations are close to be complete. Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, order extensions or support or more general by donating money to the Free Software movement (e.g. http://www.fsfeurope.org/help/donate.en.html). Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by gpg's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. A service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team (David, Werner and the other contributors) -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From alon.barlev at gmail.com Thu Mar 27 11:59:49 2008 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 27 Mar 2008 12:59:49 +0200 Subject: GnuPG document installation location Message-ID: <9e0cf0bf0803270359r5319617ci5e7552e8e4a4a64f@mail.gmail.com> On 3/26/08, Werner Koch wrote: > Hello! > > We are pleased to announce the availability of a new stable GnuPG-2 > release: Version 2.0.9 Hello Werner, Can you please modify document installation to be placed into docdir and htmldir? These are new from autoconf-2.60, and I see you are using it now. You are currently installing document into pkgdatadir in both branches. Thanks! Aon. From wk at gnupg.org Thu Mar 27 13:51:23 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 27 Mar 2008 13:51:23 +0100 Subject: GnuPG document installation location In-Reply-To: <9e0cf0bf0803270359r5319617ci5e7552e8e4a4a64f@mail.gmail.com> (Alon Bar-Lev's message of "Thu, 27 Mar 2008 12:59:49 +0200") References: <9e0cf0bf0803270359r5319617ci5e7552e8e4a4a64f@mail.gmail.com> Message-ID: <87od90nxdg.fsf@wheatstone.g10code.de> On Thu, 27 Mar 2008 11:59, alon.barlev at gmail.com said: > Can you please modify document installation to be placed into docdir > and htmldir? Will do so. Thanks for the hint. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From Moritz.Schulte at rub.de Wed Mar 26 21:19:49 2008 From: Moritz.Schulte at rub.de (Moritz Schulte) Date: Wed, 26 Mar 2008 21:19:49 +0100 Subject: gpg-agent and poldi. In-Reply-To: <200803212150.30563.prlewis@letterboxes.org> References: <200803212150.30563.prlewis@letterboxes.org> Message-ID: <1206562789.8751.0.camel@monster> > Is there any progress towards making this work yet? Any fix / patch / > workaround available? An update from my side: there has been a lot of progress. One of the goals for the next Poldi release is that it uses scdaemon instead of accessing the card directly. That part was rather easy. Another goal is to allow for several so called "authentication methods". The current way of authentication through Poldi will be one of several authentication methods (another authentication method will implement x509 through the dirmngr PKI). Implementing these authentication method infrastructure is not finished yet. In the past I haven't been really good in predicting relase dates, thus I won't mention a date now. But I am sure it will be there rather soon. Thanks, moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From prlewis at letterboxes.org Fri Mar 28 11:01:44 2008 From: prlewis at letterboxes.org (Peter Lewis) Date: Fri, 28 Mar 2008 10:01:44 +0000 Subject: gpg-agent and poldi. In-Reply-To: <1206558635.5814.70.camel@monster> References: <200803212150.30563.prlewis@letterboxes.org> <1206558635.5814.70.camel@monster> Message-ID: <200803281001.49553.prlewis@letterboxes.org> On Wednesday 26 March 2008 at 19:10:35 Moritz Schulte wrote: > > Is there any progress towards making this work yet? Any fix / patch / > > workaround available? > > An update from my side: there has been a lot of progress. One of the > goals for the next Poldi release is that it uses scdaemon instead of > accessing the card directly. That part was rather easy. > > Another goal is to allow for several so called "authentication methods". > The current way of authentication through Poldi will be one of several > authentication methods (another authentication method will implement > x509 through the dirmngr PKI). Implementing these authentication method > infrastructure is not finished yet. > > In the past I haven't been really good in predicting relase dates, thus > I won't mention a date now. But I am sure it will be there rather soon. Hi Moritz, That's the best thing I could have heard. Thanks :-) Pete. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part. URL: