Ack! Updated patch. Silly mistake in the first one.

D156: 356_gnupg-dev-tty.patch

D157: 355_gnupg-dev-tty.patch

Well actually it is a bug. :) The homedir specification should work.

There are actually two bugs:

1. the homedir is not forwarded to gpg-agent when it is started from gpg2

2. even if I start gpg-agent manually the homedir must be specified as absolute

path, not relative - this is very inconvenient

Sorry for reviving this bug, but, What is this implemented in gpg 1.4.x series?

Or this is going to be in the gpg 2.x series?

No, I can't reproduce the problem. I just came to check the status of the bug.
Thanks for the info werner.

Ok, then just check if the home given by the user exists, if not then exit.

well, i'm not a posix security expert, so take it with a piece of salt... but if
gpg followed symlinks on the pubring files, then it would be possible to symlink
the same public key db into two gnupg home directories.

The first example runs gpg on a file and displays what it sees in the file. The
--with-fingerprint only adds the fingerprint. The second example is a shortcut
for --list-keys --with-fingerprint and lists the keys known to gpg.

Given that running gpg on any file is not well defined; I would consider this a
minor bug. However, gpg 2.1 messes the output completely up and thus I need to
do something for it. But not for 1.4.

GnuPG creates the default home but not one given by the user.

It was set to resolved in 2011 because I was not able to replicate it. Are you
now able to replicate the problem?

Hi!

These options are going to be removed from the manpage?

Hi!

Is this bug solved? And if yes, in what version is resolved?

I think it should be fixed in 1.4 series, because, it just wastes entrophy
making a key. OR maybe gnupg should create the home dir if it doesn't exits, if
it fails, exit with an error code.

Well, then gpg will print a diagnostic message?

Sounds ok.

Actually not a bug - the --homedir ./.gnupg causes it.

Revocations are only an issue with key updates, which must be (and, in fact,
are) made on the basis of preferred keyserver URL's in self-signatures on keys.

With document signatures, the only important issue is to have the key retrieved
from somewhere, if it is not known to the verifier. I cannot see any way in
which an attacker can make things worse for anyone, if retrieval is attempted
from URL's in unhashed subpackets if the key is not available.

The application that I am working on is a pontentially very large archive of
signed documents (financial transaction authorizations) that also contains the
corresponding keys. The archive is supposed to be distributed/redundant, with
both the documents and the keys available from multiple servers and it can also
be migrated from one server to another. Servers can go online and offline all
the time, no address is permanent. It is trivially easy for a server to include
its own address into an unhashed subpacket and very useful, too. The server does
not have access to private keys.

Nothing needs to be explained to users if they can simply
gpg --verify document.asc
after retrieving it from the server. Much more needs to be explained if
instructions are necessary where to retrieve the corresponding public key.
Polluting the HKP/SKS infrastructure with all the keys (most of which are
disposable) that we use would impose an unfair burden on the infrastructure and
as such would be a very irresponsible thing to do.

So you suggest to follow the symlink before editing the file?

Revocations are an issue as I explained. I also don't see a point in not
putting them ins signed subpackets. There is no technical problem with that.

I guess your use case is to add a keyserver URL to a signature later to have an
easier way to retrieve the key. Tinkering with a signature after it has been
created is not a good idea - you can't easily explain it to people.

I would need to look it up myself. This has been implemented back in 1998 or 99.

How would not emitting an extra LF interfere with empty messages?
Has this decision been debated? If so, could you point me to the discussion?
Thank you in advance!

I respectfully disagree:
What you write is true for certification signatures, but not for document
signatures. Updates of keys should be driven by keyserver preference indications
on self-signatures on that key and those must obviously be hashed.
However, OpenPGP very cleverly allows for keyserver URLs in document signatures
and does take them into account. They are used for only one purpose: do download
the key if it is not known. In this case, unhashed subpackets are as good as
hashed ones (actually, better), because the cryptographic binding between the
signature and the public key can be verified anyway, there is no such thing as a
wrong source for the public key, if it does correspond to the signature.

That is actually a bug.

I will consider that for 2.1. Doing it for 1.4 will break all translations and
thus I don't belive it will be an improvement in the end.

We don't see a reason for this. 2k is the current best practise. See the long
discussions on gnupg-users which pop up every few months.

I need to verify this. It is possible that we do a keylisting while importing
keys and the keylisting prints to stdout. If that is the case, we can't change
it because gpgme and scripts may reply on it.

Using --quiet for --refresh-keys makse sens, though.

That's a known limitation of the protocol. We need this to allow for empty
mesages. Clearsigned messages are anyway only a compromise.

Well, that is clearly an installation error. You must install one of the
available pinentries. Distributions usually have a dependency on pinnentry.

That is not correct. An attacker may point to a source with a copy of the key
before a revocation has been issued. Granted, if the revocation has been done
becuase of a proven private key compromise, this does not help. In all other
cases it is useful.

Yeah, I rember that I was hit by this bug myself. I am not sure whetehr it
shall be fixed in 1.4. For interactive use gpg2 is better suited.

For backward compatibility I don't think it is a good idea to change the exit
code. However, printing a diagnostic is a good idea.

Another user reported in this (I can verify it):

During a full refresh of the keyring, gpg seems to output all information
to STDERR and STDOUT. This makes it inconvenient to have a cron job to refresh
keys, because it can result in a very large and fairly useless mail.

Please ensure that normal output goes to STDOUT and errors and warnings to
STDERR so that problems aren't lost in the noise from this command.

Indeed some "normal" messages go to stderr and some warnings go to stdout.

I will stay prepared for any testing or debugging that might be requested by
anyone of you guys (but it might take a week, as the reader belongs to someone
else), such a warning could have saved lots of time for each one of us.

And, only for your files, I made a mistake in the first E-Mail I wrote Ludovic:
It's not a Cherry ST-1044U, but a Cherry XX44 smartcard reader (ST-1044U seems
to be the USB-Descriptor)

We need some more information. You ,ay want to start gpg thi way:

  gpg -v --debug 1024 --gen-key

Has the agent been started? Try

  gpg-connect-agent 'getinfo version' /bye

If gpg still fails, the easiest way to track it down is by running it under a
debugger, or check the core file. Also try GnuPG 2.0.19 which have fixed the
problem

Hello Werner.

Do you need more information, or you can confirm and reproduce bug with given
description?

Sure, a "make clean" will delete the keyring and thus you see a message:
“imported" - if you run it a second time you see “not changed". That is all okay.

But please tell us the info I requested.

The first time I did run the test, the armor.test.log file was as
follows:

linux is a bit unspecific. Debian, Suse, Fedora, Ubuntu, Genttoo, Arch ?
I also need to see the log file - if you hesitate to post it to this BTS, feel
free to send it by PM to me (wk@gnupg.org) - Not HTML parts, you may want to
_gzip_ the log file.

On Tue, 2012-05-08 at 14:47 +0000, Werner Koch via BTS wrote:

Werner Koch <wk@gnupg.org> added the comment:

What OS and what shell are you using? Please also attach the file armor.test.log.

What OS and what shell are you using? Please also attach the file armor.test.log.

I assume you meant audit-codes.h and status-codes.h.
Right they were listed under CLEANFILES; which is wrong. I am currently fixing
this. Thanks.

Is it just me, or are both of my messages truncated to a single line?!

This is in no way specific to Kleopatra (the KDE certificate manager), gpgsm --

KDE's Kontact has been developed along with GnuPG, thus I wonder why you have
this problem. Can you please explain the problem a bit more detailed?

I'm using Linux Mint 12 Lisa, and I've tested on built-in 1.4.11 and on custom
built latest revision in repository - d64aa7.

1. I've created key with Primary key (P0), and 3 subkeys (S1, S2, S3). Export

this key for further tests.

2. Change expiration date of first subkey (S1). Everything seems OK.
3. Export whole key, remove it from gpg, import again - Everything is OK.
4. Back to step 2 - remove key, import original one.
5. Change expiration date of second or third subkey (S2, S3). Everything seems

OK again.

7. Export whole key, remove it from gpg, import again - we've missed S1 subkey,

and expiration date of changed subkey left as in step 1.

I've analyzed changes on each step via gpgsplit. My conclusion: GPG always edit
S1 subkey signature. Editing non-first subkey (S2, S3, S4…) edits (breaks) S1
signature. S2¸ S3… signatures leaved unchanged. GPG checks subkey signature
only at import. User doesn't know about subkeys breakage until he reexport it.