Tested patches are welcome (against git master of course).

Fixed in master

Is that still something we should go for?

We plan to do something similar for the Informsec grant.

Marking as resolved, as this seems to work fine now as far as I can tell (I'm
certainly happy).

scrypt has now been implemented.

D167: 370_scrypt.diff

Done in master.

If you use --textmode during encryption the native line endings on the
decryption system are used. Adding an extra option to for arbitrary conversions
is IMHO not a good idea beause it violates the Unix principle of having
dedicated tools which work together. tr(1) does what you want.

1.6 (current master) now has a feature to switch to a pure /dev/random based RNG.

Still have this issue. Here is an updated patch against 2.0.19. Please
consider including it, or provide some feedback if this is a bad idea / should
be done a different way.

Marking this as a bug since it restores useful functionality that was lost.

D151: 369_gnupg-2.0.19-showsession-trunc.patch

No. See the discussion on the maling lists for the reason why we limit the RSA
key size to 4k.

Again a warning: Do not propose the use of such large keys. The end effect is
that people don't use encryption because it is too slow on non-big machines.

See the Topics field above: wontfix.
The feature request has been rejected. If you still want to pursuit it, please
start a discussion at gnupg-devel and don't contine here at the BTS.

Not ure to understand you comment...
Have you added support for XDG basedir spec?

Add more complexity to the already complex configuration.

Please notice that backward compatibility can be preserved by continue to use
$HOME/.gnupg if it exits but using/creating XDG dirs when it is not exit.

That would be incompatible to previous versions and is thus not an option. If a
user wants this GNUPGHOME provides an easy way to do so. Keys should be
considered part of the configuration.

We won't do this for 1.4.

I would say this should go into 2.1.

What is your threat model?

It is already available in the latest 2.1-beta.

That is not possible for two reasons:

1. For v3 keys the fingerprint is different from the keyID.
2. We often have only the keyID but not the fingerprint available.

Ok I did some more research on this topic and it appears ECC is the fix for RSA
additional key sizes. Do you have any idea when ECC will be implemented into
this gem? This draft appears to be expired though so its unknown to me if there
are plans to get this implemented into the default software without requiring a
patch.

Draft: https://tools.ietf.org/html/draft-jivsov-openpgp-ecc-11

Once again thanks for the feedback. I tried to search but I kept getting errors
so I apologize if this was previously addressed.

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.