From mailinglisten at hauke-laging.de Thu Jun 3 05:02:42 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 3 Jun 2010 05:02:42 +0200 Subject: bug with one key's private keys spread over several keyrings when signing keys Message-ID: <201006030502.49587.mailinglisten@hauke-laging.de> Hello, I use gpg 2.0.15 (under GNU/Linux). I just tried to improve my gpg usage to more security while keeping a good level of convenience. My aim was to take the secret main key off my system as I need it for signing keys only (thus rather seldom). My general approach is this: I have created a LUKS partition on a USB stick so that I just have to plug it in when I need some of its data keeping it safe (offline) most of the time. The key file for this partition is in my home directory. I put my critical data on this stick and have it mounted by udev on ~/homeextension. I link my critical files to that stick. So I have created ~/homeextension/.gnupg/secring.gpg. I have deleted the secret main key from ~/.gnupg/secring.gpg (which is unconvenient IMHO as I had to export the secret subkeys, delete all secret keys and import the secret subkeys). My plan was to call gpg with an --secret- keyring parameter if I need the secret main key. So I imported that key into a new key ring: start cmd:> gpg --no-default-keyring \ --secret-keyring ~/homeextension/.gnupg/secring.gpg \ --keyring ~/.gnupg/pubring.gpg \ --import hauke__0xECCB5814.sec.asc The next step was to remove the subkeys completely by --edit-key. This was not possible without access to the public keys which does not make sense IMHO. You have to import keys in order to delete them... because secret keys cannot be deleted without deleting the respective public key. However, it seemed to work: start cmd:> gpg --no-default-keyring \ --secret-keyring ~/homeextension/.gnupg/secring.gpg \ --keyring ~/tmp/pubring.gpg --list-secret-keys /home/hl/homeextension/.gnupg/secring.gpg ----------------------------------------- sec 1024D/0xECCB5814 2005-09-05 uid Hauke Laging uid Hauke Laging uid Hauke Laging Let's have a look at the default key ring: start cmd:> gpg --list-secret-keys eccb5814 sec# 1024D/0xECCB5814 2005-09-05 uid Hauke Laging uid Hauke Laging uid Hauke Laging ssb 2048g/0xE623EF88 2005-09-05 [verf?llt: 2010-04-03] ssb 2048R/0x51B279FA 2010-03-04 [verf?llt: 2013-03-03] ssb 2048R/0x3A403251 2010-03-04 [verf?llt: 2013-03-03] ssb 2048R/0x2282921E 2010-03-08 [verf?llt: 2013-03-07] Everything as it should be. Now, after this not so short introduction, the bug: In my understanding gpg should have access to all secret keys if I add the new key ring. This works for --list-secret-keys: start cmd:> LC_ALL=C gpg \ --secret-keyring ~/homeextension/.gnupg/secring.gpg \ --list-secret-keys eccb5814 Keyring: /home/hl/.gnupg/secring.gpg ------------------------------------ sec# 1024D/0xECCB5814 2005-09-05 uid Hauke Laging uid Hauke Laging uid Hauke Laging ssb 2048g/0xE623EF88 2005-09-05 [expires: 2010-04-03] ssb 2048R/0x51B279FA 2010-03-04 [expires: 2013-03-03] ssb 2048R/0x3A403251 2010-03-04 [expires: 2013-03-03] ssb 2048R/0x2282921E 2010-03-08 [expires: 2013-03-07] Keyring: /home/hl/homeextension/.gnupg/secring.gpg -------------------------------------------------- sec 1024D/0xECCB5814 2005-09-05 uid Hauke Laging uid Hauke Laging uid Hauke Laging But it DOES NOT work for signing another key! Unless I misunderstand something about the usage of --secret-keyring: start cmd:> LC_ALL=C gpg \ --secret-keyring ~/homeextension/.gnupg/secring.gpg \ --edit-key 297AB799 [...] gpg> sign "Smartcard Test " was already signed by key 0xECCB5814 Do you want to sign it again anyway? (y/N) y [...] I have checked this key very carefully. Really sign? (y/N) y gpg: secret key parts are not available gpg: signing failed: Unusable secret key gpg> I can sign the key if I use just one secret key file: start cmd:> LC_ALL=C gpg --no-default-keyring \ --secret-keyring ~/homeextension/.gnupg/secring.gpg \ --edit-key 297AB799 [...] Really sign? (y/N) y You need a passphrase to unlock the secret key for user: "Hauke Laging " 1024-bit DSA key, ID 0xECCB5814, created 2005-09-05 gpg> It even works if I reverse the file order: start cmd:> LC_ALL=C gpg --no-default-keyring \ --secret-keyring ~/homeextension/.gnupg/secring.gpg \ --secret-keyring ~/.gnupg/secring.gpg --edit-key 297AB799 So it seems that gpg takes the private main key from the first key ring which contains any of that key only. This problem does not arise if all private keys are in the second key ring. Funnily it does not arise, too, if the decryption subkey is needed. So this problem seems to be related to signing keys. CU Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From hagen at zhuliguan.net Thu Jun 3 08:45:31 2010 From: hagen at zhuliguan.net (=?UTF-8?B?SGFnZW4gRsO8cnN0ZW5hdQ==?=) Date: Thu, 03 Jun 2010 08:45:31 +0200 Subject: bug with one key's private keys spread over several keyrings when signing keys In-Reply-To: <201006030502.49587.mailinglisten@hauke-laging.de> References: <201006030502.49587.mailinglisten@hauke-laging.de> Message-ID: <4C074F8B.2050301@zhuliguan.net> > So it seems that gpg takes the private main key from the first key ring which > contains any of that key only. According to the man page, --export-secret-subkeys does not omit the secret part of the primary key, but "renders it useless". IIUC the given keyrings are searched in order, and you have confirmed that it's indeed useless when found before the intact one. GPG does not seem to have functionality to strictly "spread" a key over keyrings. So this would be a feature request, not a bug. Cheers, Hagen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 489 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Thu Jun 3 15:47:56 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 3 Jun 2010 15:47:56 +0200 Subject: bug with one key's private keys spread over several keyrings when signing keys In-Reply-To: <4C074F8B.2050301@zhuliguan.net> References: <201006030502.49587.mailinglisten@hauke-laging.de> <4C074F8B.2050301@zhuliguan.net> Message-ID: <201006031547.56288.mailinglisten@hauke-laging.de> Am Donnerstag 03 Juni 2010 08:45:31 schrieb Hagen F?rstenau: > According to the man page, --export-secret-subkeys does not omit the > secret part of the primary key, but "renders it useless". IIUC the given > keyrings are searched in order, and you have confirmed that it's indeed > useless when found before the intact one. > > GPG does not seem to have functionality to strictly "spread" a key over > keyrings. So this would be a feature request, not a bug. Considering the circumstances it really looks like a bug. Spreading keys works for encryption and the usage of a smartcard is a similar situation: main key here, subkeys there. I have extended my tests: start cmd:> LC_ALL=C gpg --no-default-keyring \ --secret-keyring ~/.gnupg/secondsecring.gpg \ --secret-keyring ~/.gnupg/secring.gpg \ --list-secret-keys 297AB799 Keyring: /home/hl/.gnupg/secondsecring.gpg ------------------------------------------ sec 1024R/0x297AB799 2010-06-02 [expires: 2010-06-05] uid Smartcard Test ssb 1024R/0xF64B4F0F 2010-06-02 [expires: 2010-06-05] ssb 1024R/0xF17AAD5B 2010-06-02 [expires: 2010-06-05] ssb 1024R/0xD62B6574 2010-06-02 [expires: 2010-06-05] Keyring: /home/hl/.gnupg/secring.gpg ------------------------------------ sec 1024R/0x297AB799 2010-06-02 [expires: 2010-06-05] uid Smartcard Test ssb 1024R/0x92757F2A 2010-06-03 [expires: 2010-06-13] There is an encryption key in the first keyring but gpg takes the (needed) one from the second keyring without problem. CU Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From hagen at zhuliguan.net Thu Jun 3 16:16:35 2010 From: hagen at zhuliguan.net (=?ISO-8859-15?Q?Hagen_F=FCrstenau?=) Date: Thu, 03 Jun 2010 16:16:35 +0200 Subject: bug with one key's private keys spread over several keyrings when signing keys In-Reply-To: <201006031547.56288.mailinglisten@hauke-laging.de> References: <201006030502.49587.mailinglisten@hauke-laging.de> <4C074F8B.2050301@zhuliguan.net> <201006031547.56288.mailinglisten@hauke-laging.de> Message-ID: <4C07B943.3020004@zhuliguan.net> > Considering the circumstances it really looks like a bug. Spreading keys works > for encryption and the usage of a smartcard is a similar situation: main key > here, subkeys there. It works because these are different keys, so the right one is found at some point. In your case, however, there are two versions of your primary key: the real one and a broken one (deliberately replaced by dummy data). If the broken one is found first, it leads to the error you observed. You could argue that gpg should keep searching for a non-dummy primary key. Absent such a feature, the obvious workaround is to order your keyrings in such a way that the real primary key is found first. Cheers, Hagen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 489 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Jun 3 17:18:05 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 03 Jun 2010 11:18:05 -0400 Subject: bug with one key's private keys spread over several keyrings when signing keys In-Reply-To: <4C07B943.3020004@zhuliguan.net> References: <201006030502.49587.mailinglisten@hauke-laging.de> <4C074F8B.2050301@zhuliguan.net> <201006031547.56288.mailinglisten@hauke-laging.de> <4C07B943.3020004@zhuliguan.net> Message-ID: <4C07C7AD.5020708@fifthhorseman.net> On 06/03/2010 10:16 AM, Hagen F?rstenau wrote: > You could argue that gpg should keep searching for a non-dummy primary > key. I would make this argument. If gpg can distinguish dummy keys from non-dummy keys, and it has in its posession a non-dummy version of the key in question, it is a bug to not use it when the user requests it. > Absent such a feature, the obvious workaround is to order your > keyrings in such a way that the real primary key is found first. I agree this is a workaround (and it looks like the OP has already stumbled across it, as per the first message in this thread). I would disagree with the characterization of this needed bugfix as a "feature request", though. Hauke, would you mind filing a bug about this at the project bugtracker so it is at least on a to-do list someplace? https://bugs.g10code.com/gnupg/ Thanks for the report. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Thu Jun 3 17:45:33 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 3 Jun 2010 17:45:33 +0200 Subject: bug with one key's private keys spread over several keyrings =?iso-8859-15?q?when=09signing?= keys In-Reply-To: <4C07C7AD.5020708@fifthhorseman.net> References: <201006030502.49587.mailinglisten@hauke-laging.de> <4C07B943.3020004@zhuliguan.net> <4C07C7AD.5020708@fifthhorseman.net> Message-ID: <201006031745.33946.mailinglisten@hauke-laging.de> Am Donnerstag 03 Juni 2010 17:18:05 schrieb Daniel Kahn Gillmor: > Hauke, would you mind filing a bug about this at the project bugtracker > so it is at least on a to-do list someplace? > > https://bugs.g10code.com/gnupg/ Done. -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Fri Jun 4 09:27:31 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Jun 2010 09:27:31 +0200 Subject: bug with one key's private keys spread over several keyrings when signing keys In-Reply-To: <4C074F8B.2050301@zhuliguan.net> ("Hagen =?utf-8?Q?F=C3=BCrst?= =?utf-8?Q?enau=22's?= message of "Thu, 03 Jun 2010 08:45:31 +0200") References: <201006030502.49587.mailinglisten@hauke-laging.de> <4C074F8B.2050301@zhuliguan.net> Message-ID: <87typj6yvw.fsf@vigenere.g10code.de> On Thu, 3 Jun 2010 08:45, hagen at zhuliguan.net said: > GPG does not seem to have functionality to strictly "spread" a key over > keyrings. So this would be a feature request, not a bug. Right. The reason for this is that we don't have a way to merge secret keys. It is very unlikely that this will change because with GnuPG 2.1 we won't have secring anymore: All secret keys are then managed by the gpg-agent. This allows us to remove large parts of the code to keep the pubring and secring in sync. The new code is basically working; missing parts are import and export of secret keys. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From aleph at mandriva.org Wed Jun 16 12:13:19 2010 From: aleph at mandriva.org (Gergely Lonyai) Date: Wed, 16 Jun 2010 03:13:19 -0700 Subject: gpg-agent: can't connect to the agent: IPC connect call failed Message-ID: <20100616031319.9b05b4e5e48d18b6dc565714b379f9f0.9af77b137a.wbe@email10.secureserver.net> gpg-agent --verbose --write-env-file $HOME/.gnupg/gpg-agent-info gpg-agent: can't connect to the agent: IPC connect call failed I use the Mandriva Cooker (2010.1), and all gnupg softver is up to date. I try to start the gpg-agent like daemon and it create this log: 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 2010-06-16 10:56:35 gpg-agent[1920] this process is useless - shutting down 2010-06-16 10:56:38 gpg-agent[1920] gpg-agent (GnuPG) 2.0.15 stopped I find a similar report to OSX: http://old.nabble.com/gpg-agent-problems-under-MacOSX---libassuan-v2.0.0-related--td27956663.html Gergely Lonyai From nicholas.cole at gmail.com Thu Jun 24 11:57:54 2010 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Thu, 24 Jun 2010 10:57:54 +0100 Subject: --check-sigs cache and fingerprints Message-ID: Dear List, 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 update perhaps list the signing key fingerprint on all occasions? Best wishes, Nicholas From n-roeser at gmx.net Thu Jun 24 12:55:25 2010 From: n-roeser at gmx.net (Nico) Date: Thu, 24 Jun 2010 12:55:25 +0200 Subject: Documentation for --gen-random difficult to understand Message-ID: <4C23399D.50408@gmx.net> Hello! The GnuPG 2.0 documentation (current head of stable branch) has incomplete documentation of the --gen-random syntax. From doc/gpg.texi: > @item --gen-random @code{0|1|2} > @opindex gen-random > Emit @var{count} random bytes of the given quality level. If count is When I read that in the info manual/man page, I wondered what ?count? might be. (After reading the source code, it was obvious, though.) The first line should have ? @var{count}? appended, I think. Thanks -- Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From n-roeser at gmx.net Thu Jun 24 14:41:44 2010 From: n-roeser at gmx.net (Nico) Date: Thu, 24 Jun 2010 14:41:44 +0200 Subject: pgp2 option seems not to set disable_mdc Message-ID: <4C235288.2040200@gmx.net> Hello! The GnuPG 2.0.15 manual documents that --pgp2 implies --disable-mdc. When I print the value of opt.disable_mdc at the end of the main method in g10/gpg.c, I can see that it is still 0. The code does not seem to set it for PGP2. I assume that either the documentation or the code are buggy. But there may be additional options involving mdc (perhaps use_mdc()?) that disable MDC for PGP2-compliance mode, and do not use opt.disable_mdc. I?d be happy if someone could double-check and enlighten me (or fix the bug if it is one). Thanks -- Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu Jun 24 17:55:52 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 24 Jun 2010 11:55:52 -0400 Subject: pgp2 option seems not to set disable_mdc In-Reply-To: <4C235288.2040200@gmx.net> References: <4C235288.2040200@gmx.net> Message-ID: <689D164F-F1FF-48DA-8EA1-BCFAB0261849@jabberwocky.com> On Jun 24, 2010, at 8:41 AM, Nico wrote: > Hello! > > The GnuPG 2.0.15 manual documents that --pgp2 implies --disable-mdc. > When I print the value of opt.disable_mdc at the end of the main method > in g10/gpg.c, I can see that it is still 0. The code does not seem to > set it for PGP2. > > I assume that either the documentation or the code are buggy. But there > may be additional options involving mdc (perhaps use_mdc()?) that > disable MDC for PGP2-compliance mode, and do not use opt.disable_mdc. > > I?d be happy if someone could double-check and enlighten me (or fix the > bug if it is one). It's okay - the manual and the code are correct. --pgp2 causes RFC1991 to be true, and if RFC1991 is true, then MDCs are disabled (the MDC didn't exist in RFC-1991). It doesn't need to literally set opt.disable_mdc. David From pchanna1 at insightbb.com Thu Jun 24 16:46:22 2010 From: pchanna1 at insightbb.com (Patrick Hanna) Date: Thu, 24 Jun 2010 10:46:22 -0400 Subject: Problem using gnupg from PHP Message-ID: <59128DC4CD824941A54AE74AD3BCBB87@GATEWAY835GM> I am using exec() calls to run pgp from within a php script. I can decrypt a file without any problem but when I try to encrypt, I get a return code of 2 from pgp. Here are the commands that I am using. echo mypassphrase| gpg --passphrase-fd 0 --batch -o /home/pat/testfile.2 -d /home/pat/testfile.1 (Works great) gpg -e -r "myrecipient" -o /home/pat/testfiel.2 -e /home/pat/testfile.1 (Fails with return code = 2) Both commands work great from a shell command line. Inside my php script I use the following command structure: $gpgcmd = "gpg -e -r "recipient" -o /home/pat/testfiel.2 -e /home/pat/testfile.1"; exec($gpgcmd, $out_arr, $ret_code); I am using gnupg version 1.2.3 Can anyone tell me what the return code = 2 implies? Or any reason that the encryption is failing? Thank you, Pat -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Sun Jun 27 19:14:54 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 27 Jun 2010 13:14:54 -0400 Subject: --check-sigs cache and fingerprints In-Reply-To: References: Message-ID: <4C27870E.6090503@fifthhorseman.net> On 06/24/2010 05:57 AM, Nicholas Cole wrote: > 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 > update perhaps list the signing key fingerprint on all occasions? I just tested this, and I see the behavior Nicholas describes (the issuing key's fingerprint appears in field 13 only when --no-sig-cache is used, regardless of whether --fixed-list-mode is present) on both gpg 1.4.10 and 2.0.14. I agree that the issuing key's fingerprint should always be output, regardless of --no-sig-cache. I suspect the 64-bit keygrip emitted in field 5 is too small go guarantee uniqueness against an attacker with moderate resources. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Sun Jun 27 19:26:32 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 27 Jun 2010 13:26:32 -0400 Subject: Problem using gnupg from PHP In-Reply-To: <59128DC4CD824941A54AE74AD3BCBB87@GATEWAY835GM> References: <59128DC4CD824941A54AE74AD3BCBB87@GATEWAY835GM> Message-ID: <4C2789C8.1070708@fifthhorseman.net> On 06/24/2010 10:46 AM, Patrick Hanna wrote: > I am using exec() calls to run pgp from within a php script. I can decrypt > a file without any problem but when I try to encrypt, I get a return code of I'> 2 from pgp. I'm assuming you mean gpg here. a common problem people have when invoking gpg (or other commands) from a script invoke by a webserver (i'm assuming your php is run from a web server) is that the web server is run as a different user than their personal account. For example, the web server might run as the user "www-data" instead of "pchanna1". In that case, the web server will not have access to your gpg keyring, so it won't be able to find (for example) the recipient's keys that you want to target. You may want to try explicitly indicating the path to the desired keyring on the commandline (and ensuring that the ownership/permissions on the keyring you want the script to use are functional for the web server's user account) > I am using gnupg version 1.2.3 this is a rather old version. I encourage you to upgrade to the 1.4.x series at least (I use 1.4.10) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Mon Jun 28 14:35:45 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 28 Jun 2010 14:35:45 +0200 Subject: gpgsm not asking dirmngr for trusted root ca Message-ID: <201006281435.46407.bernhard@intevation.de> If dirmngr trusts a root ca, wouldn't it be cool if the gpgsm (or gpg-agent) could also use that information? While doing some tests today, I stumbled over the issue and that it is way to hard to maintain an installation wide root ca list. I suggest that a) "include-default" for the personal trustlist.txt is the default. So we might need to come up with " b) "include-default" somehow also uses the dirmngr trusted-certs/. c) gpg-agent should also use GNUPGHOME (at least for me it does not seem to do it. But I might have make a mistake.) d) The documentation is fixed info gpgsm Installation still has | XXX decribe how to maintain trustlist.txt and | /etc/gnupg/trustlist.txt. For reference, here is my test: I was picking Intevation's root ca. curl https://ssl.intevation.de/Intevation-Root-CA-2010.crt | openssl x509 -outform der >Intevation-Root-CA-2010.der and I put this into /etc/dirmngr/trusted-certs/ and restarted dirmngr and gave gpg-agent a SIGHUP kick. The dirmngr log shows I was successful: 2010-06-28 13:11:57 dirmngr[2444.0] dirmngr 1.0.4-svn0 stopped 2010-06-28 13:11:58 dirmngr[7602.0] Vertrauensw?rdiges Zertifikat `/etc/dirmngr/trusted-certs/Intevation-Root-CA-2010.der' wurde geladen Now I did import my personal certificate and the intermediate cert and tried to encrypt something and was surprised to being asked: cd tmp mkdir dot.gnupg LANG=en_us GNUPGHOME=~/tmp/dot.gnupg eval `gpg-agent --daemon` LANG=en_us GNUPGHOME=~/tmp/dot.gnupg gpgsm --list-keys #gpgsm: keybox `/home/bernhard/tmp/dot.gnupg/pubring.kbx' created LANG=en_us GNUPGHOME=~/tmp/dot.gnupg dirmngr-client --ping #dirmngr-client: a dirmngr daemon is up and running LANG=en_us GNUPGHOME=~/tmp/dot.gnupg gpgsm --prefer-system-dirmngr \ --import intevation-email-ca-2010.pem #gpgsm: total number processed: 1 #gpgsm: imported: 1 LANG=en_us GNUPGHOME=~/tmp/dot.gnupg gpgsm --prefer-system-dirmngr \ --import 06.pem #gpgsm: total number processed: 1 #gpgsm: imported: 1 LANG=en_us GNUPGHOME=~/tmp/dot.gnupg gpgsm --prefer-system-dirmngr \ -e -r 7B:EA:F9:D6:5B:5F:4A:D9:73:4A:56:07:48:F7:6C:04:88:8E:03:73 #gpgsm: root certificate is not marked trusted And now I get the pinentry dialog asking me for the root ca and the answer gets into my personal trustlist.txt. One way to spare users that question is using adding 11:B9:1B:31:EE:09:E0:84:4D:25:4E:58:7A:65:CE:51:84:F3:6B:70 S to /etc/gnupg/trustlist.txt And "include-default" to ~/.gnupg/trustlist.txt. Yes, ~/tmp/dot.gnupg/trustlist.txt did not work. dpkg -s gnupg2 dirmngr Package: gnupg2 Architecture: i386 Version: 2.0.15-0kk1 Package: dirmngr Version: 1.0.3.svn323-0kk1 -- 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: intevation-email-ca-2010.pem Type: application/x-x509-ca-cert Size: 8051 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 06.pem Type: application/x-x509-ca-cert Size: 6377 bytes Desc: not available URL: -------------- 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 bernhard at intevation.de Mon Jun 28 17:39:58 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 28 Jun 2010 17:39:58 +0200 Subject: gpgsm not asking dirmngr for trusted root ca In-Reply-To: <201006281435.46407.bernhard@intevation.de> References: <201006281435.46407.bernhard@intevation.de> Message-ID: <201006281739.59184.bernhard@intevation.de> Am Montag, 28. Juni 2010 14:35:45 schrieb Bernhard Reiter: > If dirmngr trusts a root ca, wouldn't it be cool > if the gpgsm (or gpg-agent) could also use that information? And if you want to check my signature on that email, here is the diff to fix that mailman issue: --- gpgsm not asking dirmngr for trusted root ca.mbox 2010-06-28 17:26:08.680510851 +0200 +++ repaired.mbox 2010-06-28 17:37:57.496508084 +0200 @@ -176,3 +176,4 @@ --Boundary-01=_icJKMwp0j0mE9Cu -Content-Type: application/x-x509-ca-cert; name="intevation-email-ca-2010.pem" +Content-Type: application/x-x509-ca-cert; + name="intevation-email-ca-2010.pem" Content-Transfer-Encoding: 7bit > While doing some tests today, I stumbled over the issue > and that it is way to hard to maintain an installation wide root ca list. > > I suggest that > a) "include-default" for the personal trustlist.txt is the default. > ? ? So we might need to come up with " > b) "include-default" somehow also uses the dirmngr trusted-certs/. > c) gpg-agent should also use GNUPGHOME (at least for me it does not seem to > do it. But I might have make a mistake.) > d) The documentation is fixed > ? ?info gpgsm Installation -- 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 bernhard at intevation.de Tue Jun 29 11:23:38 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 29 Jun 2010 11:23:38 +0200 Subject: [Gpg4win-devel] X509 Root certificates and trusting them In-Reply-To: <201005211203.25415.bernhard@intevation.de> References: <201005211203.25415.bernhard@intevation.de> Message-ID: <201006291123.41101.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. Especially for the root certificate, the person administrating the machines (e.g. you) must ensure three conditions are given. (Paths examples 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 fil is the root certificate you would like to trust. You need to do this best at installation time - as in the heat of the moment users will go along with everthing just to get the task done. b) 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 put it as .der file in /etc/dirmngr/trusted-certs and restart the dirmngr service. Live might be easier if users have "prefer-system-dirmngr" in their local gpgsm.conf (Usually ~/.gnupg/gpgsm.conf). 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 have "include-default" in their personal trustlist.txt. Usually ~/.gnupg/trustlist.txt. I guess all gpg-agent s will need a kick after the trustlist.txt change. Try sending a SIGHUP to all gpg-agent processes, e.g. killall -SIGHUP gpg-agent In order to update all users private configuration files at once, 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 prefered, because it might be more correct regarding on your installation. Use the command line "info", if you are familiar with it. It will be installed on many GNU systems. There are other textinfo console viewers of course like tkman or pinfo. If you have konqueror installed using "info:gnupg2" as URL will also work, using the script /usr/share/apps/kio_info/kde-info2html which on Debian Lenny comes with the kdebase-kio-plugins package. I usually prefer this. 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: smime.p7s Type: application/pkcs7-signature Size: 3696 bytes Desc: not available URL: From wk at gnupg.org Tue Jun 29 12:22:29 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 29 Jun 2010 12:22:29 +0200 Subject: [Gpg4win-devel] X509 Root certificates and trusting them In-Reply-To: <201006291123.41101.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 29 Jun 2010 11:23:38 +0200") References: <201005211203.25415.bernhard@intevation.de> <201006291123.41101.bernhard@intevation.de> Message-ID: <87aaqem93u.fsf@vigenere.g10code.de> On Tue, 29 Jun 2010 11:23, bernhard at intevation.de said: > Try sending a SIGHUP to all gpg-agent processes, e.g. > killall -SIGHUP gpg-agent DO NOT USE killall - it is a Linux specific command and has different semantics on other systems. Use *pkill* instead. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Tue Jun 29 15:16:49 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 29 Jun 2010 15:16:49 +0200 Subject: [Gpg4win-devel] X509 Root certificates and trusting them Message-ID: <201006291516.52617.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. [Second 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 have "include-default" in their personal trustlist.txt. Usually ~/.gnupg/trustlist.txt. I guess all gpg-agent s 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 restart. In order 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 prefered, because it usually is most correct. Use the command line "info", if you are familiar with it. It will be installed on many GNU systems. There are other exotic textinfo console viewers of course like tkman or pinfo. If you have konqueror installed using "info:gnupg2" as URL will also work. This can be started on the command line directly like listed above. Konqueror internally uses the script /usr/share/apps/kio_info/kde-info2html which on Debian Lenny comes with the kdebase-kio-plugins package. I usually prefer this. 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: smime.p7s Type: application/pkcs7-signature Size: 3696 bytes Desc: not available URL: From wk at gnupg.org Wed Jun 30 07:31:48 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Jun 2010 07:31:48 +0200 Subject: gpgsm not asking dirmngr for trusted root ca In-Reply-To: <201006281435.46407.bernhard@intevation.de> (Bernhard Reiter's message of "Mon\, 28 Jun 2010 14\:35\:45 +0200") References: <201006281435.46407.bernhard@intevation.de> Message-ID: <87mxud6q7v.fsf@wheatstone.g10code.de> Bernhard Reiter writes: > If dirmngr trusts a root ca, wouldn't it be cool > if the gpgsm (or gpg-agent) could also use that information? On a single user machine, yes. On a multi-user system a user may chose different trust anchors and thus it should only be an option. We have not implemented this in the past because Dirmngr and GnuPG are separate projects. That has changed 2 weeks ago: I merged Dirmngr into GnuPG 2.1 and this will make it easier to do something about it. There are a lot of other changes pending for GnuPG 2.1 and a review of trustlist.txt seems to be necessary. > a) "include-default" for the personal trustlist.txt is the default. > So we might need to come up with " > b) "include-default" somehow also uses the dirmngr trusted-certs/. I am thinking of an option like "include-dirmngr-trusted-certs" for trustlist.txt or better for the global trustlist. Dirmngr needs to maintain its own list of trusted root certificates because it is a system service and has no access to the user setting. The situation is actually a bit wishy-washy: Dirmngr as a system services trusts its list of trust anchors whereas gpgsm trusts its own list. But for revocation checks gpgsm implicitly trusts Dirmngr's idea of valid certificates. We can't change the later because the validity of a CRL is computed while loading it and not at the time a user (i.e. gpgsm) asks for the revocation status. > c) gpg-agent should also use GNUPGHOME (at least for me it does not seem to do > it. But I might have make a mistake.) Your fault ;-). I use GNUPGHOME=$(pwd) ./gpg-agent --daemon sh all the day to test gpg-agent. Take care: If you use bash and you are using --write-env-file in your gpg-agent.conf the shell will probably setup the environment variables to the standard gpg-agent (due to the bashrc). > d) The documentation is fixed > info gpgsm Installation > still has > > | XXX decribe how to maintain trustlist.txt and As well as the missing introduction chapter :-( Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jun 30 07:57:04 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Jun 2010 07:57:04 +0200 Subject: assuan_tcp_connect()? In-Reply-To: <200809071121.m87BL145023320@rs49.luxsci.com> (Ben Kibbey's message of "Sun\, 7 Sep 2008 07\:19\:48 -0400") References: <200809071121.m87BL145023320@rs49.luxsci.com> Message-ID: <87aaqd6p1r.fsf@wheatstone.g10code.de> Hi, I found this quite old mail: Ben Kibbey writes: > Any plans on including something equivalent any time soon? Or maybe > something like assuan_init_socket_server_ext() only for a client that > has already done the connect()? The current libassuan from SVN has an undocumented feature to connect to a TCP socket: gpg_error_t assuan_socket_connect (assuan_context_t ctx, const char *name, pid_t server_pid, unsigned int flags) /* Make a connection to the Unix domain socket NAME and return a new Assuan context in CTX. SERVER_PID is currently not used but may become handy in the future. Defined flag bits are: ASSUAN_SOCKET_CONNECT_FDPASSING sendmsg and recvmsg are used. NAME must either start with a slash and optional with a drive prefix ("c:") or use one of these URL schemata: file:// This is the same as the default just with an explicit schemata. assuan://: assuan://[]: Connect using TCP to PORT of the server with the numerical IPADDR. Not that the '[' and ']' are literal characters. */ This is likey to stay and will eventually be documented. feel free to play with it. For the server part no specific support is required, you do this all outside of assuan. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jun 30 07:49:23 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Jun 2010 07:49:23 +0200 Subject: --check-sigs cache and fingerprints In-Reply-To: (Nicholas Cole's message of "Thu\, 24 Jun 2010 10\:57\:54 +0100") References: Message-ID: <87eifp6pek.fsf@wheatstone.g10code.de> 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. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.