From marcoagpinto at mail.telepac.pt Thu Jul 1 02:06:12 2010 From: marcoagpinto at mail.telepac.pt (Marco A.G.Pinto) Date: Thu, 1 Jul 2010 01:06:12 +0100 Subject: Introduction from Marco Message-ID: <003401cb18b1$37374c40$8d48f655@btqqwkhbo8khqls> Hello!!! I am Marco from Portugal. I am 36 years old and I am a computer science expert (I know a few things.. lol... no one can be a very good expert in such a broad subject). I would like to offer my help in translating to Portuguese. I have been involved on several projects in the past: - PGP 2.6.3.i - Alex Chiu's site and documentation of what he sells - EasyDivX - DVD2one - User guide of "EMM-Event UFO Detector" - DALnet etc... For around 10 years that I haven't used cryptography but as soon as my vacation begins (17/JUL/2010) I will have time for the task. Please tell me who I should contact. I already tried a couple of email addresses I found in the official site but no reply. PS->This email was sent both to the developers and translation mailing lists. Kind regards, >Marco A.G.Pinto ------------------------ From nicholas.cole at gmail.com Sun Jul 4 20:18:00 2010 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sun, 4 Jul 2010 19:18:00 +0100 Subject: --check-sigs cache and fingerprints In-Reply-To: <87eifp6pek.fsf@wheatstone.g10code.de> References: <87eifp6pek.fsf@wheatstone.g10code.de> Message-ID: On Wed, Jun 30, 2010 at 6:49 AM, Werner Koch wrote: > Nicholas Cole writes: > >> Is there any particular reason why the --with-colons output for >> --check-sigs lists the signing key fingerprint if the --no-sig-cache >> option is specified, but not if it doesn't? ?If not, could a future > > That is purely for performance reasons. ?Without the signature cache the > listing would be very slow. ?The cache is implemented using the old ring > trust packets which immediately follow a signature packet. ?There is no > space to put the fingerprint into the ring trust packet thus what we > have is only the keyid form the signature packet. > > If we wanted to print the fingerprint we would need to lookup the public > key which requires to scan the entire keyring - that's too slow. > > There are two ways to solve the problem: Either extend the ring trust > packet to also store the fingerprint or to make use of the forthcoming > keybox format which has space for all kind of meta data and does not > need the ugly hack with the ring trust packets. > > BTW, I am currently working on migrating secret keys from the secring to > the agent. ?After this has been done GnuPG 2.1 should be again stable > enough for testing and I can start to convert the code to use the keybox > format. ?Then a first 2.1 release is due and then we can start to add > all those features I promised for so long. Dear Warner, Thank you very much for the explanation. I always enjoy learning more about the reasons for things! The new format is very exciting (will it then be backported to gpg 1?). I do think it would be good, after there is a new keybox format, for the --with-colons list to also show the fingerprints. Best wishes, Nicholas From wk at gnupg.org Mon Jul 5 18:23:24 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Jul 2010 18:23:24 +0200 Subject: --check-sigs cache and fingerprints In-Reply-To: (Nicholas Cole's message of "Sun, 4 Jul 2010 19:18:00 +0100") References: <87eifp6pek.fsf@wheatstone.g10code.de> Message-ID: <87zky5nbib.fsf@vigenere.g10code.de> On Sun, 4 Jul 2010 20:18, nicholas.cole at gmail.com said: > The new format is very exciting (will it then be backported to gpg > 1?). I do think it would be good, after there is a new keybox format, No, I have no plans to backport it. gpg is widely used in unattended systems and we should not introduce any larger changes. gpg2 is suitable for most systems and may also be used on servers - there are however some problems for unattended use which we need to solve over time. I can think of a customized gpg-agent for servers which never requires any user interaction. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jul 6 14:29:22 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Jul 2010 14:29:22 +0200 Subject: gpg-agent: can't connect to the agent: IPC connect call failed In-Reply-To: <20100616031319.9b05b4e5e48d18b6dc565714b379f9f0.9af77b137a.wbe@email10.secureserver.net> (Gergely Lonyai's message of "Wed, 16 Jun 2010 03:13:19 -0700") References: <20100616031319.9b05b4e5e48d18b6dc565714b379f9f0.9af77b137a.wbe@email10.secureserver.net> Message-ID: <87aaq4n68t.fsf@vigenere.g10code.de> On Wed, 16 Jun 2010 12:13, aleph at mandriva.org said: > 2010-06-16 10:55:32 gpg-agent[1920] gpg-agent (GnuPG) 2.0.15 started > 2010-06-16 10:56:35 gpg-agent[1920] can't connect my own socket: Invalid > value passed to IPC I can't say exacly what this is. It would be useful to have a system call trace of this: strace -fo out gpg-agent --verbose --write-env-file $HOME/.gnupg/gpg-agent-info You may need to install the strace package first. Please send the output to me by private mail to avoid the possibility of leaking private information of your installation. Keys or passphrase should not appear in the file "out" but details of your system instalaltion are visible. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From emanuel at intevation.de Fri Jul 9 10:33:22 2010 From: emanuel at intevation.de (Emanuel =?iso-8859-1?q?Sch=FCtze?=) Date: Fri, 9 Jul 2010 10:33:22 +0200 Subject: [Gpg4win-devel] Portuguese translation of site+GnuPG In-Reply-To: <000f01cb1b01$3715bd80$645bf655@btqqwkhbo8khqls> References: <000f01cb1b01$3715bd80$645bf655@btqqwkhbo8khqls> Message-ID: <201007091033.26383.emanuel@intevation.de> Hi Marco, welcome and thanks for your message! On 04.07.2010 00:43, Marco A.G.Pinto wrote: > I offered myself to translate GnuPG's site and software to Portuguese > (Europe) a few days ago. great! > I tried to get the .PO files without success and I finally found them in > the site of the Windows version (but just for the software). > > Can someone direct me in the correct path? I wanted to translate GnuPG site > and GnuPG V2.0.15 but I am not sure if translating the .PO that is in the > Windows version will do the job... or will I need to translate both > versions? > > Could you explain to me all steps such as which fields to replace in the > .PO and character settings (UTF-8)? To translate DALnet I used UniRed > Editor and UTF-8 in the XML files which were later parsed by the Team > Leader. Can I use UniRed with the .PO's? Do you have found this Gpg4win page for translator? "How to translate all of Gpg4win into your language" http://gpg4win.de/localize-gpg4win.html There are useful information for you. I think, an easy thing to start translate is the Gpg4win installer. GpgEX and GpgOL are small work packages, too. All three use po files and are available in Gpg4win (on windows) only - not in the gnupg core package. A bigger project - but very useful for Portuguese speaking people - is to translate the Gpg4win compendium. Note: Gpg4win use the gnupg package (currently v2.0.15). Translation in gnupg has to do there. Please coordinate this via the gnupg-devel list. Are you familiar with svn? You could get a wald account for gpg4win svn access to check in your installer or compendium translations. GpgEX, GpgOL and gnupg are not contained in this gpg4win svn repository [1]. Regards Emanuel [1] http://wald.intevation.org/scm/?group_id=11 -- Emanuel Sch?tze | ++49-541-33 50 83 - 746 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 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 nicholas.cole at gmail.com Fri Jul 9 19:49:20 2010 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 9 Jul 2010 18:49:20 +0100 Subject: IMPORT_RES Message-ID: Dear All, The documentation in doc/DETAILS lists 13 outputs for IMPORT_RES: IMPORT_RES But gpg actually produces 14 numbers. Looking at the source code, the extra number is for , which is the penultimate number given. Best wishes, Nicholas From aleph at mandriva.org Fri Jul 9 23:51:28 2010 From: aleph at mandriva.org (Gergely Lonyai) Date: Fri, 09 Jul 2010 14:51:28 -0700 Subject: gpg-agent: can't connect to the agent: IPC connect call failed Message-ID: <20100709145128.9b05b4e5e48d18b6dc565714b379f9f0.024b87a0ec.wbe@email10.secureserver.net> > -------- Original Message -------- > Subject: Re: gpg-agent: can't connect to the agent: IPC connect call > failed > From: Werner Koch > Date: Tue, July 06, 2010 2:29 pm > To: "Gergely Lonyai" > Cc: gnupg-devel at gnupg.org > > > On Wed, 16 Jun 2010 12:13, aleph at mandriva.org said: > > > 2010-06-16 10:55:32 gpg-agent[1920] gpg-agent (GnuPG) 2.0.15 started > > 2010-06-16 10:56:35 gpg-agent[1920] can't connect my own socket: Invalid > > value passed to IPC > > I can't say exacly what this is. It would be useful to have a system > call trace of this: > > strace -fo out gpg-agent --verbose --write-env-file $HOME/.gnupg/gpg-agent-info > > You may need to install the strace package first. Please send the > output to me by private mail to avoid the possibility of leaking private > information of your installation. Keys or passphrase should not appear > in the file "out" but details of your system instalaltion are visible. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. gpg-agent --daemon --use-standard-socket --write-env-file "$GPGAGENTINFO" I used the "--use-standard-socket" option in the original launcher script. I removed its and not stop after 1-2 mins. This may be the causal of problem? Aleph From wk at g10code.com Tue Jul 13 18:06:27 2010 From: wk at g10code.com (Werner Koch) Date: Tue, 13 Jul 2010 18:06:27 +0200 Subject: [Announce] Libgcrypt 1.4.6 released Message-ID: <87iq4je58c.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.4.6. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.4.6: * New variants of the TIGER algorithm. * New cipher algorithm mode for AES-WRAP. Source code is hosted at the GnuPG FTP server and its mirrors as listed at . On the primary server the source file and its digital signature is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.6.tar.bz2 (1125k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.6.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.6.tar.gz (1391k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.6.tar.gz.sig Alternativley you may upgrade version 1.4.5 using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.5-1.4.6.diff.bz2 (16k) The SHA-1 checksums are: 445b9e158aaf91e24eae3d1040c6213e9d9f5ba6 libgcrypt-1.4.6.tar.bz2 dbe3fee0a9eea8128a1e47c973e0f432a62bfaa2 libgcrypt-1.4.6.tar.gz 9361c5ee7861548a4822e58baba95c81ec878384 libgcrypt-1.4.5-1.4.6.diff.bz2 For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. Note that this version is from the stable branch; the current development version is available at . Improving Libgcrypt is costly, but you can help! We are looking for organizations that find Libgcrypt useful and wish to contribute back. You can contribute by reporting bugs, improve the software [2], order extensions or support or more general by donating money to the Free Software movement (e.g. ). Commercial support contracts for Libgcrypt are available [3], and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company, is currently funding Libgcrypt development. We are always looking for interesting development projects. Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] See . [2] Note that copyright assignments to the FSF are required. [3] See the service directory at . -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 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 tom at ritter.vg Mon Jul 19 05:11:00 2010 From: tom at ritter.vg (Tom Ritter) Date: Sun, 18 Jul 2010 23:11:00 -0400 Subject: make clean deleting source files Message-ID: <4C43C244.5070001@ritter.vg> I performed the following sequence of commands: $ wget ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.0.15.tar.bz2 $ tar xfj gnupg-2.0.15.tar.bz2 $ cd gnupg-2.0.15 $ ./configure $ stat common/status-codes.h $ make $ stat common/status-codes.h $ make clean $ stat common/status-codes.h <- file is now missing At that point, I am unable to run 'make'. I'm not familiar with the complex Makefile and Makefile-generating tools, but removing the source file is intentional per line 30 in common\Makefile.am > CLEANFILES = audit-events.h status-codes.h Those lines have been present since 2007 (revision 4628). I'm confused as to what's going on here - either something seems to be wrong with 'make clean' (less likely given the age of the code) or I'm misunderstanding what should happen when I run 'make clean'. -tom From smueller at chronox.de Mon Jul 19 06:53:33 2010 From: smueller at chronox.de (Stephan Mueller) Date: Mon, 19 Jul 2010 06:53:33 +0200 Subject: [PATCH]: base64 encoder update Message-ID: <1279515213.27980.2.camel@tauon> Hi, please see attached patch. It clears the line value when a new line is to be parsed. Also, it allows parsing an entire SMIME email without expecting the Content-type as a first line. Ciao Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgsm_base64.diff Type: text/x-patch Size: 723 bytes Desc: not available URL: From wk at gnupg.org Mon Jul 19 10:39:20 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Jul 2010 10:39:20 +0200 Subject: [Announce] GnuPG 2.0.16 released Message-ID: <87zkxnamrr.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.16. 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.10) 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 =========== * If the agent's --use-standard-socket option is active, all tools try to start and daemonize the agent on the fly. In the past this was only supported on W32; on non-W32 systems the new configure option --use-standard-socket may now be used to use this feature by default. * The gpg-agent commands KILLAGENT and RELOADAGENT are now available on all platforms. * Minor bug fixes. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.16 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.16.tar.bz2 (3910k) gnupg-2.0.16.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.15-2.0.16.diff.bz2 (51k) A patch file to upgrade a 2.0.15 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.16.tar.bz2 you would use this command: gpg --verify gnupg-2.0.16.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.16.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.16.tar.bz2 and check that the output matches the first line from the following list: e7eb4f60026884bd90803b531472bc518804b95d gnupg-2.0.16.tar.bz2 be77c0ba597b9ad9e38941e85ba1750890067227 gnupg-2.0.15-2.0.16.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. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 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 wk at gnupg.org Tue Jul 20 09:22:16 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Jul 2010 09:22:16 +0200 Subject: make clean deleting source files In-Reply-To: <4C43C244.5070001@ritter.vg> (Tom Ritter's message of "Sun, 18 Jul 2010 23:11:00 -0400") References: <4C43C244.5070001@ritter.vg> Message-ID: <87sk3eipnb.fsf@vigenere.g10code.de> On Mon, 19 Jul 2010 05:11, tom at ritter.vg said: > I'm confused as to what's going on here - either something seems to be > wrong with 'make clean' (less likely given the age of the code) or I'm > misunderstanding what should happen when I run 'make clean'. Yeah, this is a bug. The rule to build status-codes.h is only included in maintainer-mode (./configure --enable-maintainer-mode) as a fix for bug#1164. I'll fix that for the next release. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Wed Jul 21 11:45:39 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 21 Jul 2010 11:45:39 +0200 Subject: [Pyme-help] Retrieve key from keyserver In-Reply-To: <4C469F3E.3040302@riseup.net> References: <4C469F3E.3040302@riseup.net> Message-ID: <201007211145.39942.bernhard@intevation.de> Am Mittwoch, 21. Juli 2010 09:18:22 schrieb Jerome Charaoui: > I'd like to know if it's possible to retrieve a PGP key from a keyserver > with PyMe. > > According to the GPGME documentation, this should be possible by > combining mode.LOCAL with mode.EXTERN. However when I try this I > consistently get a EOF error. A good question. I would direct it to gnupg-devel@ and ask if it is possible with GPGME. In order to facilitate the question I directly post it there. If it is possible with GPGME, it should be possible with pyme as well. Make sure to use the right gpgme gnupg2 version before trying. > I verified my GPG confguration and the correct keyservers are in there. > Also, retrieving keys from command-line GPG works fine. The gpg2 command line does not use gpgme, but it demonstrates the the configuration and the helpers are all there. -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.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 Wed Jul 21 14:46:16 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Jul 2010 14:46:16 +0200 Subject: [Pyme-help] Retrieve key from keyserver In-Reply-To: <201007211145.39942.bernhard@intevation.de> (Bernhard Reiter's message of "Wed, 21 Jul 2010 11:45:39 +0200") References: <4C469F3E.3040302@riseup.net> <201007211145.39942.bernhard@intevation.de> Message-ID: <87pqyhgfzb.fsf@vigenere.g10code.de> > Am Mittwoch, 21. Juli 2010 09:18:22 schrieb Jerome Charaoui: >> I'd like to know if it's possible to retrieve a PGP key from a keyserver >> with PyMe. >> >> According to the GPGME documentation, this should be possible by >> combining mode.LOCAL with mode.EXTERN. However when I try this I >> consistently get a EOF error. What this kludge dioes is to use the --locate-keys option of gpg: --locate-keys Locate the keys given as arguments. This command basically uses the same algorithm as used when locating keys for encryption or signing and may thus be used to see what keys gpg2 might use. In particular external methods as defined by --auto-key-locate may be used to locate a key. Only public keys are listed. -auto-key-locate `parameters' -no-auto-key-locate GnuPG can automatically locate and retrieve keys as needed using this option. This happens when encrypting to an email address (in the "user at example.com" form), and there are no user at example.com keys on the local keyring. This option takes any number of the following arguments, in the order they are to be tried: cert locate a key using DNS CERT, as specified in 2538bis (currently in draft): http://www.josefsson.org/rfc2538bis/ pka locate a key using DNS PKA. ldap locate a key using the PGP Universal method of checking "ldap://keys.(thedomain)". keyserver locate a key using whatever keyserver is defined using the -keyserver option. (keyserver URL) In addition, a keyserver URL as used in the -keyserver option may be used here to query that particular keyserver. Thus you need to define an auto-key-locate in gpg.conf. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jerome at riseup.net Wed Jul 21 23:21:09 2010 From: jerome at riseup.net (Jerome Charaoui) Date: Wed, 21 Jul 2010 17:21:09 -0400 Subject: gpgme: downloading a key from a keyserver Message-ID: <4C4764C5.9010108@riseup.net> Hello, I'd like to use GPGME to download a specific key from a keyserver identified by a fingerprint. I'd like to do this as a discrete operation, not as part of signing a key or encrypting a message. The reason I'd like to do this is to be able to examine the details of a public key (name, email, etc.) before adding it to the keyring and actually doing stuff with it. I'm aware of the LOCAL|EXTERN modes which use the --locate-keys of GnuPG, but according to the manual and my experience, the "external" part only kicks in when signing or encrypting. Thanks, -- Jerome From buanzo at buanzo.com.ar Thu Jul 22 01:02:02 2010 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Wed, 21 Jul 2010 20:02:02 -0300 Subject: gpgme: downloading a key from a keyserver In-Reply-To: <4C4764C5.9010108@riseup.net> References: <4C4764C5.9010108@riseup.net> Message-ID: <4C477C6A.8070809@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/21/2010 06:21 PM, Jerome Charaoui wrote: > The reason I'd like to do this is to be able to examine the details of a > public key (name, email, etc.) before adding it to the keyring and > actually doing stuff with it. I'm working on an instant messaging system based on SSL and OpenPGP, and what you're asking to do via GPGME is JUST one of the things I need to do... so... I'm adding pressure to your question :P - -- Arturo "Buanzo" Busleiman Independent Linux and Security Consultant - OWASP - SANS - OISSG . http://www.buanzo.com.ar/pro/eng.html ..: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkxHfGoACgkQAlpOsGhXcE3OpwCfecBQmXgtC6dmHLCYCh6xDWm4 RmIAnRHa61gnArmjiias4ZmK7fxUMygv =Kc6o -----END PGP SIGNATURE----- From huebners at uni-potsdam.de Thu Jul 22 15:48:51 2010 From: huebners at uni-potsdam.de (=?ISO-8859-15?Q?Sebastian_H=FCbner?=) Date: Thu, 22 Jul 2010 15:48:51 +0200 Subject: GPGME passphrase Message-ID: <4C484C43.7010204@uni-potsdam.de> Hello everybody, I am using the GPGME library for signing files with GnuPG. Basically everthing works fine. But I have the following question: When I run my application for the first time I have to enter the passphrase for the private key. When I run the application again I don't have to enter the passphrase anymore even if I've cleared the context (gpgme_signers_clear(ctx)) before signing the file. I'd like to enter the passphrase every time I run the application. How can I achive that? Thanks in advance, Sebastian H?bner From wk at gnupg.org Fri Jul 23 14:36:51 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 23 Jul 2010 14:36:51 +0200 Subject: [Announce] Security Alert for GnuPG 2.0 - Realloc bug in GPGSM Message-ID: <877hkmfk7w.fsf@vigenere.g10code.de> Realloc Bug with X.509 certificates in GnuPG ============================================== 2010-07-23 Summary ======= While trying to import a server certificate for a CDN service, a segv bug was found in GnuPG's GPGSM tool. It is likely that this bug is exploitable by sending a special crafted signed message and having a user verify the signature. [ Please do not send private mail in response to this message. The mailing list gnupg-devel is the best place to discuss this problem (please subscribe first so you don't need moderator approval [1]). ] Impact ====== All applications using GnuPG's GPGSM tool to process S/MIME messages or manage X.509 certificates are affected. The bug exists in all versions of GnuPG including the recently released GnuPG 2.0.16. GPG (i.e. OpenPGP) is NOT affected. GnuPG 1.x is NOT affected because it does not come with the GPGSM tool. An exploit is not yet known but it can't be ruled out for sure that the problem has not already been identified by some dark forces. Description =========== Importing a certificate with more than 98 Subject Alternate Names [2] via GPGSM's import command or implicitly while verifying a signature causes GPGSM to reallocate an array with the names. The bug is that the reallocation code misses assigning the reallocated array to the old array variable and thus the old and freed array will be used. Usually this leads to a segv. It might be possible to use one of the techniques to exploit assignments to malloced and freed memory. Such an exploit won't be easy to write because the attack vector must fit into a valid ASN.1 DER encoded DN. To further complicate the task, that DN is not used directly but after a transformation to RFC-2253 format. Solution ======== Apply the following patch. The patch is required for all GnuPG versions < 2.0.17. It applies to 2.0.16 but should apply to many older versions as well. --- kbx/keybox-blob.c (revision 5367) +++ kbx/keybox-blob.c (working copy) @@ -898,6 +898,7 @@ rc = gpg_error_from_syserror (); goto leave; } + names = tmp; } names[blob->nuids++] = p; if (!i && (p=x509_email_kludge (p))) Support ======= g10 Code GmbH [3], a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. Support contracts or other financial backing will greatly help us to improve the quality of GnuPG. Thanks ====== Peter Gutmann for his "A mighty fortress is our PKI" mail to the cryptography ML which contained a pointer to a certificate to exhibit the problem. This bug was created, found and fixed by Werner Koch. [1] See http://lists.gnupg.org/mailman/listinfo/gnupg-devel [2] [3] See http://www.gnupg.org/service.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 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 smueller at chronox.de Mon Jul 26 09:26:35 2010 From: smueller at chronox.de (Stephan Mueller) Date: Mon, 26 Jul 2010 09:26:35 +0200 Subject: gpgsm: not checking root certificate (was Re: [PATCH] MD2 for libgcrypt) Message-ID: <201007260926.35940.smueller@chronox.de> Hi, quoting Werner: > > Yes, agreed from my side as well. But what can you do if customers force you > > to use it, even with MD2? > > An option might be to add flag to trustlist.txt, similar to "relax", > which suppresses validation of the root certificate. > > I agree that validation of the root certifciate is not necessary because > we check the fingerprint anyway. However that extra check revealed some > probelms in the past and thus I don't want to drop it completely. I > can't remeber but there might have been a specification which required > this validation. > > This won't help Daniel's request for adding a MD2 to use libgcrypt as a > crypto bench. Do you think of something like the attached patches (they are not tested yet)? Ciao Stephan -- | Cui bono? | -------------- next part -------------- A non-text attachment was scrubbed... Name: call-agent.c.patch Type: text/x-patch Size: 404 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgsm.h.patch Type: text/x-patch Size: 418 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: certchain.c.patch Type: text/x-patch Size: 638 bytes Desc: not available URL: From wk at gnupg.org Tue Jul 27 08:57:01 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Jul 2010 08:57:01 +0200 Subject: gpgsm: not checking root certificate In-Reply-To: <201007260926.35940.smueller@chronox.de> (Stephan Mueller's message of "Mon, 26 Jul 2010 09:26:35 +0200") References: <201007260926.35940.smueller@chronox.de> Message-ID: <87d3u92z0i.fsf@vigenere.g10code.de> On Mon, 26 Jul 2010 09:26, smueller at chronox.de said: > Do you think of something like the attached patches (they are not tested yet)? Yes, that was my idea. However, while looking at the code I realized that we don't check the root certificate if it is already trusted (i.e. listed in trustlist.txt). The check is only done for not-yet-trusted certificates, so that the user can get some info on the certificate. The problem you encounter is due to the import function which calls gpgsm_basic_cert_check() for each certificate. There are two ways to avoid this: gpgsm --import --debug-no-chain-validation ROOTCERT or change the code in gpgsm_basic_cert_check to look at the trustlist.txt first. Thus if you put the fingerprint of the root certificate into trustlist.txt before importing the certificate, it should work fine. Given the required changes I think that adding MD2 to libgcrypt would be easier. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From smueller at chronox.de Tue Jul 27 09:15:34 2010 From: smueller at chronox.de (Stephan Mueller) Date: Tue, 27 Jul 2010 09:15:34 +0200 Subject: gpgsm: not checking root certificate In-Reply-To: <87d3u92z0i.fsf@vigenere.g10code.de> References: <201007260926.35940.smueller@chronox.de> <87d3u92z0i.fsf@vigenere.g10code.de> Message-ID: <201007270915.34233.smueller@chronox.de> Am Dienstag, 27. Juli 2010, um 08:57:01 schrieb Werner Koch: Hi Werner, > On Mon, 26 Jul 2010 09:26, smueller at chronox.de said: > > Do you think of something like the attached patches (they are not tested > > yet)? > > Yes, that was my idea. However, while looking at the code I realized > that we don't check the root certificate if it is already trusted > (i.e. listed in trustlist.txt). The check is only done for > not-yet-trusted certificates, so that the user can get some info on the > certificate. I see. > > The problem you encounter is due to the import function which calls > gpgsm_basic_cert_check() for each certificate. There are two ways to > avoid this: > > gpgsm --import --debug-no-chain-validation ROOTCERT > > or change the code in gpgsm_basic_cert_check to look at the > trustlist.txt first. Thus if you put the fingerprint of the root > certificate into trustlist.txt before importing the certificate, it > should work fine. > > Given the required changes I think that adding MD2 to libgcrypt would be > easier. I am unsure about your last statement. When we consider --debug-no-chain- validation and add the fingerprint to trustlist.txt, then we neither need a code change to gpgsm nor the MD2 hash. Which change do you think of that are harder than the MD2 addition? All I currently see is adding some information to the gpgsm man page about how to handle root certificates based on MD2. Ciao Stephan -- | Cui bono? | From wk at gnupg.org Tue Jul 27 10:03:51 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Jul 2010 10:03:51 +0200 Subject: gpgsm: not checking root certificate In-Reply-To: <201007270915.34233.smueller@chronox.de> (Stephan Mueller's message of "Tue, 27 Jul 2010 09:15:34 +0200") References: <201007260926.35940.smueller@chronox.de> <87d3u92z0i.fsf@vigenere.g10code.de> <201007270915.34233.smueller@chronox.de> Message-ID: <87vd811hco.fsf@vigenere.g10code.de> On Tue, 27 Jul 2010 09:15, smueller at chronox.de said: > I am unsure about your last statement. When we consider --debug-no-chain- > validation and add the fingerprint to trustlist.txt, then we neither need a > code change to gpgsm nor the MD2 hash. It was meant as 1) Use --debug-no-chain-validation with --import. To work with that root certificate the fingerprint needs to be put into trustlist.txt; but it should be sufficient to do this after the import. or 2) Change the import code to look at the trustlist.txt. The proposed code changes would require that the user enters the fingerprint into trustlist.txt before importing. > All I currently see is adding some information to the gpgsm man page about how > to handle root certificates based on MD2. That might be the easiest way to accomplish it. Would you mind to test approach 1)? I can then add this workaround to the docs. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From smueller at chronox.de Tue Jul 27 10:25:49 2010 From: smueller at chronox.de (Stephan Mueller) Date: Tue, 27 Jul 2010 10:25:49 +0200 Subject: gpgsm: not checking root certificate In-Reply-To: <87vd811hco.fsf@vigenere.g10code.de> References: <201007260926.35940.smueller@chronox.de> <201007270915.34233.smueller@chronox.de> <87vd811hco.fsf@vigenere.g10code.de> Message-ID: <201007271025.49938.smueller@chronox.de> Am Dienstag, 27. Juli 2010, um 10:03:51 schrieb Werner Koch: Hi Werner, > On Tue, 27 Jul 2010 09:15, smueller at chronox.de said: > > I am unsure about your last statement. When we consider --debug-no-chain- > > validation and add the fingerprint to trustlist.txt, then we neither need > > a code change to gpgsm nor the MD2 hash. > > It was meant as > > 1) Use --debug-no-chain-validation with --import. To work with that > root certificate the fingerprint needs to be put into trustlist.txt; > but it should be sufficient to do this after the import. > > or > > 2) Change the import code to look at the trustlist.txt. The proposed > code changes would require that the user enters the fingerprint into > trustlist.txt before importing. > > > All I currently see is adding some information to the gpgsm man page > > about how to handle root certificates based on MD2. > > That might be the easiest way to accomplish it. Would you mind to test > approach 1)? I can then add this workaround to the docs. Sure, can do that, but give me a bit of time. > > > Salam-Shalom, > > Werner Ciao Stephan -- | Cui bono? | From smueller at chronox.de Wed Jul 28 22:01:18 2010 From: smueller at chronox.de (Stephan Mueller) Date: Wed, 28 Jul 2010 22:01:18 +0200 Subject: gpgsm: not checking root certificate In-Reply-To: <87vd811hco.fsf@vigenere.g10code.de> References: <201007260926.35940.smueller@chronox.de> <201007270915.34233.smueller@chronox.de> <87vd811hco.fsf@vigenere.g10code.de> Message-ID: <201007282201.19074.smueller@chronox.de> On Dienstag 27 Juli 2010 10:03:51 Werner Koch wrote: Hi Werner, > On Tue, 27 Jul 2010 09:15, smueller at chronox.de said: > > I am unsure about your last statement. When we consider --debug-no- chain- > > validation and add the fingerprint to trustlist.txt, then we neither need > > a code change to gpgsm nor the MD2 hash. > > It was meant as > > 1) Use --debug-no-chain-validation with --import. To work with that > root certificate the fingerprint needs to be put into trustlist.txt; > but it should be sufficient to do this after the import. > > or > > 2) Change the import code to look at the trustlist.txt. The proposed > code changes would require that the user enters the fingerprint into > trustlist.txt before importing. > > > All I currently see is adding some information to the gpgsm man page > > about how to handle root certificates based on MD2. > > That might be the easiest way to accomplish it. Would you mind to test > approach 1)? I can then add this workaround to the docs. Approach 1) works as expected. I am using the native Ubuntu Lucid gpg2 packages without support for MD2: $ gpgsm --import Class\ 1\ Public\ Primary\ Certification\ Authority.cer gpgsm: unknown hash algorithm `1.2.840.113549.1.1.2' gpgsm: (Dies ist der MD2 Algorithmus) gpgsm: self-signed certificate has a BAD signature: Allgemeiner Fehler gpgsm: Grundlegende Zertifikatpr?fungen fehlgeschlagen - nicht importiert gpgsm: gesamte verarbeitete Anzahl: 1 gpgsm: nicht importiert: 1 $ gpgsm --import --debug-no-chain-validation Class\ 1\ Public\ Primary\ Certification\ Authority.cer gpgsm: WARNING: bypassing basic certificate checks gpgsm: gesamte verarbeitete Anzahl: 1 gpgsm: importiert: 1 ==> adding the following to trustlist.txt and giving gpg-agent a HUP: # OU=Class 1 Public Primary Certification Authority # O=VeriSign, Inc. # C=US 90:AE:A2:69:85:FF:14:80:4C:43:49:52:EC:E9:60:84:77:AF:55:6F S relax ==> An email signed with a certificate based on the imported Verisign CA certificate could be verified successfully > > > Salam-Shalom, > > Werner Ciao Stephan -- | Cui bono? | From bernhard at intevation.de Thu Jul 29 11:16:23 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 29 Jul 2010 11:16:23 +0200 Subject: GPGME passphrase In-Reply-To: <4C484C43.7010204@uni-potsdam.de> References: <4C484C43.7010204@uni-potsdam.de> Message-ID: <201007291116.26664.bernhard@intevation.de> Am Donnerstag, 22. Juli 2010 15:48:51 schrieb Sebastian H?bner: > I am using the GPGME library for signing files with GnuPG. > Basically everthing works fine. > > But I have the following question: > > When I run my application for the first time I have to enter the > passphrase for the private key. > When I run the application again I don't have to enter the passphrase > anymore > even if I've cleared the context (gpgme_signers_clear(ctx)) before > signing the file. gpgme calls its engines for operation, e.g. gpg2 or gpgsm. They will ask gpg-agent for secret key operations and gpg-agent can cache secret keys. This is configurable. > I'd like to enter the passphrase every time I run the application. > How can I achive that? Restart or use a different gpg-agent each run or change the gpg-agent configuration to not cache passwords. (Check gpg-agent documentation for the options.) Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.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: 3696 bytes Desc: not available URL: From bernhard at intevation.de Thu Jul 29 11:33:03 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 29 Jul 2010 11:33:03 +0200 Subject: [Gpg4win-devel] X509 Root certificates and trusting them Message-ID: <201007291133.09170.bernhard@intevation.de> Am Freitag, 21. Mai 2010 12:03:22 schrieb Bernhard Reiter: > The recommended way for a > production X509 /CMS system is that a list of trusted X509 root > certificates is maintained by the administrator of the system > directly for dirmngr and possibly the global gpgsm. For gpgsm to be able to use certificates, you need to have the full validated chain of certificates. [Third edition] Especially for the root certificate, the person administrating the machines (e.g. you) must ensure four conditions are given. (Paths examples are for GNU systems, the paths will be different for Mac OS or Windows.) a) You need to have the root certificate and be sure that the file you have is really the root certificate you would like to trust. You need to do this best at installation time, because later - in the heat of the moment - users will go along with everthing unchecked just to get the task done. b.1) Make sure dirmngr trusts the root certificate. info dirmngr Installation konqueror info:/dirmngr/Installation http://gnupg.org/documentation/manuals/dirmngr/Installation.html In short, recommended is to use the system dirmngr, place the root certification file in .der format in /etc/dirmngr/trusted-certs and restart the dirmngr service. b.2) Current revocation status information must be available. gpgsm will ask dirmngr to validate each certificate. As administrator you need to make sure that dirmngr can do that check. Usually certificates contain information where to get the revocation list via http or ldap. So dirmngr should be able to do http and ldap calls to the internet. Secure connections are not necessary as revocation info is already signed. You can tune dirmngr to use proxies or always ask specific servers via ldap. There are a number of other ways, like OCSP, to get revocation information. Too much to list them here. With sane certificate authorities and network settings it will just work with the revocation lists out of the box. If you need to trouble shoot, you can turn off checking of revocation information for a moment to verify that this is the problem. Leaving this off for production will degrade security significantly. Users should have "prefer-system-dirmngr" in their local gpgsm.conf (Usually ~/.gnupg/gpgsm.conf). So that the system dirmngr is asked all the time. c) Make sure gpg-agent trusts the root certificate Recommended way is to do this system wide: c.1) Place the right line in /etc/gnupg/trustlist.txt References: Existence of configuration file: info gnupg2 Installation konqueror info:/gnupg2/Installation http://gnupg.org/documentation/manuals/gnupg/Installation.html Format of trustlist.txt: info gnupg2 "Invoking GPG-AGENT" "Agent Configuration" konqueror info:/gnupg2/Agent Configuration http://gnupg.org/documentation/manuals/gnupg/Agent-Configuration.html c.2) Make sure all users either * have no personal trustlist.txt or * have the option "include-default" in it. The file will usually searched at ~/.gnupg/trustlist.txt. I guess all gpg-agents will need a kick after the trustlist.txt change. Try sending a SIGHUP to all gpg-agent processes, e.g. pkill -SIGHUP gpg-agent or reboot. In general: If you wish to update all users' private configuration files, you can try using Gnupg's helper application called applygnupgdefaults Documentation starts here: info gnupg2 "Helper Tools" applygnupgdefaults konqueror info:/gnupg2/applygnupgdefaults http://gnupg.org/documentation/manuals/gnupg/applygnupgdefaults.html Hints for reading the documentation: Using the documentation of your installed version is preferred, because it usually is most correct. Use "info" on the commandline, if you are familiar with it. It will be installed on many GNU systems. There are other exotic texinfo console viewers of course like tkman or pinfo. If you have konqueror installed using "info:gnupg2" as URL will also work. Konqueror internally uses the script /usr/share/apps/kio_info/kde-info2html which on Debian Lenny comes with the kdebase-kio-plugins package. This is my prefered method. Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.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 Thu Jul 29 16:30:31 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 29 Jul 2010 16:30:31 +0200 Subject: GPGME passphrase In-Reply-To: <201007291116.26664.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 29 Jul 2010 11:16:23 +0200") References: <4C484C43.7010204@uni-potsdam.de> <201007291116.26664.bernhard@intevation.de> Message-ID: <87eiempdh4.fsf@vigenere.g10code.de> On Thu, 29 Jul 2010 11:16, bernhard at intevation.de said: > change the gpg-agent configuration to not cache passwords. > (Check gpg-agent documentation for the options.) This option might be useful as weel: --ignore-cache-for-signing This option will let gpg-agent bypass the passphrase cache for all signing operation. Note that there is also a per-session option to control this behaviour but this com- mand line option takes precedence. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From pk at opensc-project.org Thu Jul 29 20:35:20 2010 From: pk at opensc-project.org (Peter Koch) Date: Thu, 29 Jul 2010 20:35:20 +0200 Subject: Terminating and reactivating an OpenPGPCard and/or CryptoStick Message-ID: Hi Werner (and of course anybody else who wants to answer the following question)! I would like to reset a CryptoStick. As you might know a CryptoStick is a USB card reader with a builtin OpenPGP V2 card. According to the handbook this should be easy. Just a TERMINATE DF followed by an ACTIVATE FILE. But the handbook also mentions that some OpenPGP card might supprt these commands and others might not. And the last three historical bytes will answer the questions wether a card has TERMINATE/ACTIVATE-support or not. The ATR of my CryptoStick is: 3B:FA:13:00:FF:81:31:80:45:00:31:C1:73:C0:01:00:00:90:00:B1, so the last three historical bytes are 00:90:00 and page 27 of the OpenPGP V2 manuals explains: > The last 3 bytes of the Historical bytes in this format are a status indicator > byte and two processing status bytes SW1/SW2 (normally 9000). > > The status indicator byte is evaluated by the OpenPGP application as follows: > > 00 =No information given > Card does not offer life cycle management, commands TERMINATE DF and ACTIVATE FILE are not supported > 03 =Initialisation state > OpenPGP application can be resetted to default values with an ACTIVATE FILE command > 05 =Operational state (activated) > Card supports life cycle management, commands TERMINATE DF and ACTIVATE FILE are available So should I nevertheless block all my PINs and give it a try?? Peter From wk at gnupg.org Fri Jul 30 08:56:01 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 30 Jul 2010 08:56:01 +0200 Subject: Terminating and reactivating an OpenPGPCard and/or CryptoStick In-Reply-To: (Peter Koch's message of "Thu, 29 Jul 2010 20:35:20 +0200") References: Message-ID: <8739v1pif2.fsf@vigenere.g10code.de> On Thu, 29 Jul 2010 20:35, pk at opensc-project.org said: > According to the handbook this should be easy. Just a TERMINATE DF > followed by an ACTIVATE FILE. However terminate is only allowed if PW1 and PW3 are blocked. Thus I use these commands with gpg-connect-agent: scd serialno scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 44 00 00 scd apdu 00 e6 00 00 /echo card has been reset to factory defaults > So should I nevertheless block all my PINs and give it a try?? I can't tell you my cards show Status Indicator: 05 abd thus the life cycle management is supported. I have no crypt strick to test it out. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From smueller at chronox.de Fri Jul 30 09:27:03 2010 From: smueller at chronox.de (Stephan Mueller) Date: Fri, 30 Jul 2010 09:27:03 +0200 Subject: gpgsm: not checking root certificate Message-ID: <201007300927.04055.smueller@chronox.de> On Dienstag 27 Juli 2010 10:03:51 Werner Koch wrote: Hi Werner, > On Tue, 27 Jul 2010 09:15, smueller at chronox.de said: > > I am unsure about your last statement. When we consider --debug-no- chain- > > validation and add the fingerprint to trustlist.txt, then we neither need > > a code change to gpgsm nor the MD2 hash. > > It was meant as > > 1) Use --debug-no-chain-validation with --import. To work with that > root certificate the fingerprint needs to be put into trustlist.txt; > but it should be sufficient to do this after the import. > > or > > 2) Change the import code to look at the trustlist.txt. The proposed > code changes would require that the user enters the fingerprint into > trustlist.txt before importing. > > > All I currently see is adding some information to the gpgsm man page > > about how to handle root certificates based on MD2. > > That might be the easiest way to accomplish it. Would you mind to test > approach 1)? I can then add this workaround to the docs. Approach 1) works as expected. I am using the native Ubuntu Lucid gpg2 packages without support for MD2: $ gpgsm --import Class\ 1\ Public\ Primary\ Certification\ Authority.cer gpgsm: unknown hash algorithm `1.2.840.113549.1.1.2' gpgsm: (Dies ist der MD2 Algorithmus) gpgsm: self-signed certificate has a BAD signature: Allgemeiner Fehler gpgsm: Grundlegende Zertifikatpr?fungen fehlgeschlagen - nicht importiert gpgsm: gesamte verarbeitete Anzahl: 1 gpgsm: nicht importiert: 1 $ gpgsm --import --debug-no-chain-validation Class\ 1\ Public\ Primary\ Certification\ Authority.cer gpgsm: WARNING: bypassing basic certificate checks gpgsm: gesamte verarbeitete Anzahl: 1 gpgsm: importiert: 1 ==> adding the following to trustlist.txt and giving gpg-agent a HUP: # OU=Class 1 Public Primary Certification Authority # O=VeriSign, Inc. # C=US 90:AE:A2:69:85:FF:14:80:4C:43:49:52:EC:E9:60:84:77:AF:55:6F S relax ==> An email signed with a certificate based on the imported Verisign CA certificate could be verified successfully > > > Salam-Shalom, > > Werner Ciao Stephan -- | Cui bono? | From pk at opensc-project.org Fri Jul 30 18:18:28 2010 From: pk at opensc-project.org (Peter Koch) Date: Fri, 30 Jul 2010 18:18:28 +0200 Subject: Terminating and reactivating an OpenPGPCard and/or CryptoStick In-Reply-To: <8739v1pif2.fsf@vigenere.g10code.de> References: <8739v1pif2.fsf@vigenere.g10code.de> Message-ID: Hi Werner! Since your OpenPGP card has a live cycle status indicator 05 I was wondering why both my CryptoStick an my OpenPGP card has 00. The reason is simple. My ATR is 3b:da:18:ff:81:b1:fe:75:1f:03:00:31:c5:73:c0:01:40:00:90:00:0c hence I believed that my historical bytes were 00:31:c5:73:c0:01:40:00:90:00 But Data Object 5F52 contains a copy of the historical bytes and this copy is 00:31:c5:73:c0:01:40: 05 :90:00 So Achim Pietig might add a short note to the documentation that the live cycle status indicator is contained in DO 5F52 only. Peter