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 <hauke at laging.de>
uid                    Hauke Laging <mail at hauke-laging.de>
uid                    Hauke Laging <mailinglisten at hauke-laging.de>


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 <hauke at laging.de>
uid                    Hauke Laging <mailinglisten at hauke-laging.de>
uid                    Hauke Laging <mail at hauke-laging.de>
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 <hauke at laging.de>
uid                    Hauke Laging <mailinglisten at hauke-laging.de>
uid                    Hauke Laging <mail at hauke-laging.de>
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 <hauke at laging.de>
uid                    Hauke Laging <mailinglisten at hauke-laging.de>
uid                    Hauke Laging <mail at hauke-laging.de>

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 <smartcardtest at hauke-laging.de>" 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 <hauke at laging.de>"
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: </pipermail/attachments/20100603/b0864278/attachment.pgp>

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: </pipermail/attachments/20100603/47a51987/attachment.pgp>

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 <smartcardtest at hauke-laging.de>
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 <smartcardtest at hauke-laging.de>
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: </pipermail/attachments/20100603/8c1d2cd9/attachment.pgp>

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: </pipermail/attachments/20100603/d0ff9f04/attachment.pgp>

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: </pipermail/attachments/20100603/ebb44b84/attachment-0001.pgp>

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: </pipermail/attachments/20100603/93c54233/attachment.pgp>

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: <AANLkTik-EFSwYKGIzwY-UN2u8sevQRWMIjwi6TUN5c1y@mail.gmail.com>

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: </pipermail/attachments/20100624/eb30786b/attachment.pgp>

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: </pipermail/attachments/20100624/20b01aa0/attachment.pgp>

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: </pipermail/attachments/20100624/e840a0d5/attachment.htm>

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: <AANLkTik-EFSwYKGIzwY-UN2u8sevQRWMIjwi6TUN5c1y@mail.gmail.com>
References: <AANLkTik-EFSwYKGIzwY-UN2u8sevQRWMIjwi6TUN5c1y@mail.gmail.com>
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: </pipermail/attachments/20100627/8da25dbe/attachment-0001.pgp>

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: </pipermail/attachments/20100627/895e5c54/attachment.pgp>

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: </pipermail/attachments/20100628/16caae38/attachment.crt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 06.pem
Type: application/x-x509-ca-cert
Size: 6377 bytes
Desc: not available
URL: </pipermail/attachments/20100628/16caae38/attachment-0001.crt>
-------------- 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: </pipermail/attachments/20100628/16caae38/attachment.pgp>

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: </pipermail/attachments/20100628/4086a07e/attachment.pgp>

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: </pipermail/attachments/20100629/d3e05e6d/attachment-0001.bin>

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: </pipermail/attachments/20100629/77f465f0/attachment.bin>

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 <bernhard at intevation.de> 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 <bjk at luxsci.net> 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://<fname>
  
          This is the same as the default just with an explicit schemata.
  
        assuan://<ipaddr>:<port>
        assuan://[<ip6addr>]:<port>
           
          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: <AANLkTik-EFSwYKGIzwY-UN2u8sevQRWMIjwi6TUN5c1y@mail.gmail.com>
	(Nicholas Cole's message of "Thu\, 24 Jun 2010 10\:57\:54 +0100")
References: <AANLkTik-EFSwYKGIzwY-UN2u8sevQRWMIjwi6TUN5c1y@mail.gmail.com>
Message-ID: <87eifp6pek.fsf@wheatstone.g10code.de>

Nicholas Cole <nicholas.cole at gmail.com> 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.