No.

Please read all the long threads on gnupg-users to learn why this is not a good
idea. You may also want to read Ross Anderson's "Security Engineering".

May I ask for the status of this bug?

Is this going to be implemented in the gnupg 2.x series?

May I ask what happen with this bug?

Just trying to keep track of these bugs in Debian Bug Tracking System.

Makese sense.

Marked as resolved in Gentoo.

Is there still a gnome VFS? This wish is a bit too old. Re-open it if you like.

So now, what shall we do proper file locking and make sure that the user has
permissions to both files? It will be quite some code to get this all done right.

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?

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.

Hi!

These options are going to be removed from the manpage?

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?

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.

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.

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.

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.

Done. Thanks.

In general I don't like pkg-config because it adds an extra dependecy above the
required libraries and introduces other problems. However, for GPA we already
have lot of dependencies and thus I would accept a patch.

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)

Would be great to have included if 2.1 is the ecc release.

I would love to just have 1 agent for everything.

There is no ECC support for the agent, yet. The ssh protocol is different from
the OpenPGP Protocol. It should be easy to add support, though.

Done for master (f1e1387).

Done for 2.1

D152: 342_gnupg-2.0.18_show-session-trunc.diff

Backport to 2.0 done (f772757e)

Backport to 1.4. done (cfb193a1).

You need to use another pinentry. It is easy to write a pinentry which allows
this. I won't do this becuase it defeats the actual purpose of pinentry.

(Understood there are no immediate plans for a release, but if/when we do have
one, the change will be ready)

Change committed to 1.4, 2.0, and master.

I'll setup a testing enviroment soon again and keep you informed!

Okay, fixed in master commit ea9df94. Goes into 2.1 Thanks.

I don't quite understand your point here. In any case GpgOL is not abale to
send encrypted mail via Exchange.