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.

The gpgme-config scripts goes along with the gpgme.m4 code. A .pc file won't be
able to do what we can do with this combination.

Please disregard my stupid comments about GPA. I was on the wrong track.

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.

Fix pushed.

Regarding the ERR thing: You are right and I wonder why gcc (4.6.3) didn't
caught it.

The malloc + strcpy is a standard pattern. Example;

  struct {
    int flags;
    char name[1];
  } *foo;

  foo = xmalloc (sizeof *foo + strlen (string));
  strcpy (foo->name, string);

will always work correctly. The sizeof returns the length of the
structure which includes 1 byte for name. The strlen computes the
length of string without the terminator. However we alloacted one
extra byte (the name[1]) and thus everything is fine.

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.

You mean there is a useless process running which should better be killed, right?

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.

The second thing I was wondering about was, is line 71:

x = g_malloc (sizeof *x + strlen (name) );

strlen() won't count the terminating byte whereas strcpy will copy it.

Fixed in master.

I assume this has been fixed.

This won't add a dependency on pkg-config. The reporter requests, that you
ship a .pc file, so packages dependening on gpgme can use pkg-config to
determine compiler and linker flags when building against gpgme. There is no
request to make gpa use pkg-config.