Done with commit 010d26a for 2.1.6

Fixed in 2.0.28 (and in 2.1.x).

Hm, you make a good point about this being undesirable in the general case --
access to a normal gpg-agent shouldn't provide an attacker with a way to guess
passwords silently.

However, consider the mailpile case -- where gpg-agent is running on the
webserver, and the login webpage wants to verify a given user based on the
password for the user's secret key (and wants to avoid keeping some extra
/etc/shadow-equivalent file lying around).

Maybe such an application would start gpg-agent in a different/simpler mode? Or
should we recommend that such an application test the provided passphrase in
some other way, without using gpg-agent at all?

Does encrypt-to/hidden-encrypt-to in gpg.conf do this?

This feature has landed in the latest 2.0 and 2.1 branches and support has been
added in pinentry. I'm closing this now.

Hi dkg,

On the mailing list and in T1928, we discussed
why it shouldn't be possible for a program to pass the passphrase to gpg agent.
This feature request is at odds with the conclusion drawn there. Should this
issue be closed as WONTFIX?

Thanks,

:) Neal

Done with commit 25331bb for 2.1.5.
Won't be backported to 2.0 or 1.4.

This also changes the publication date to the date of the last commit for one of
the texi files. This was the original intention of the version.texi file but
that did not worked in a git world.

This also extends to keys stored on smartcards, see
https://lists.gnupg.org/pipermail/gnupg-devel/2015-June/029959.html

Won't be done for 2.0 but I will try to implement that for 2.1

Did you asked on the GUIX list whether they have a similar problem?

Oh well, resizing the buttons to a new fixed size would be a job in the source
of 10 minutes or so. However, this makes an very ugly Pinentry for every day's
use (i.e. entering a passphrase for an existing key). So, sorry, I won't take
that patch.

With native Windows code I mean native Windows code for GUIs instead of relying
on MFC or whatever is the latest GUI framework MS uses. This is similar to xlib
programm vs. GTK+ programming

Anyway, thanks for looking into this. I will retitle the bug to keep it open.
Maybe eventually someone starts to hack on it.

That might be possible. However outstarting gpg-agent won't be implemented for 1.4.

On Mon, May 18, 2015 at 10:37:08AM +0000, Werner Koch via BTS wrote:

Please start gpg-agent manually (gpgconf --launch gpg-agent) and set a fixed
GPG_AGENT_INFO envvar in your login script.

Exactly this thing I reported as a workaound. I'd like to see working gpg
without setting the GPG_AGENT_INFO variable before.

Please start gpg-agent manually (gpgconf --launch gpg-agent) and set a fixed
GPG_AGENT_INFO envvar in your login script.

I tested your pkg-config patch on Debian Jessie and everything still compiles
fine. I've applied the pkg-config patch. If gentoo is now using a newer
version of this patch, please let me know. Thanks.

Fixed in edd9a88.

This is about updating the docs. Will be done for 2.1 only.

This reminds me that we don't have a mail keyserver in 2.1 yet. Need to
evaluate whether it will be useful.

(funny due date removed)

Lot of things pertaining to keyservers changed in the meantime and we have a
couple of other things in mind as well.

Yes, auto-detection in dirmngr-client would be great, thanks!

Is this still a problem?

You can implemnnt something like this using 2.1 and the --extra-socket feature.
Give the extra socket appropriate permissions/ACLs

Fixed in master with commit 64e809b Will go into 2.1.4.

I changed that to a feature but I agree that the subkey selection mechanism
should take smartcards into account.

It would be surpising that suddendly a different subkey will be used for signing
if a smartcard is not available. Right, most users with several subkeys are
experts and know what they are going but nevertheless this is a change in behaviour.

Sorry, I don't understand why you have a ENOMEM problem there. You are using
Linux and thus you have copy-on-write which should not lead to such problem.
Right there are some corner cases but I doubt that they kick in here.

What kind garbage collector are you using? Can you check with the guix folks
whether they have a similar problem? IIRC, Guile also uses gpgme

You can't use SIGCHLD in a library.

My point is not speed of forking, but memory pressure. We have problems with
Nix package manager forking any apps, unless it uses vfork() (either
directly, or indirectly via posix_spawn).

If zombies are the only reason for double forking, there are other ways
around, e. g. ignoring SIGCHLD.

And speaking of bugs, don't we have tests? :-)

That would be a large change which for sure would introduce a lot of new bugs.
In comparison to other operations required for gpg startup the pissible speedup
between fork and vfork will be minor. In any case vfork is an ugly hack which
is not required on modern OSes with MMU. Using posix_spawn is not possible
because we do double forking.

If you have a real problem with the performance, we should first evaluate the
problem and then find a solution. Thus: Please describe the use case and why
you think that the process creation is the performance hog. GPGME has been
designed to overcome such performance problems by eventually introducing
co-porcesses so to fork gpg only once for many operations. We do this with
gpgsm already but have not yet seen an urgent need to also also change this for
gpg. However, if there is a real need for it we can do that.

Old plain fork is expensive, even on Linux, maybe because of garbage
collector.

https://github.com/zalora/defnix/commit/987a49aa77be5596ec2a352c1c758bce532b
5818
https://github.com/zalora/nix-
exec/commit/ea6eb396f0fa67df6568e1bf5dada41fb70a6ca2

Can you give a reason why you need this?

That is not a bug but due to non-supported certificate policy constraints.

If you want to ignore them as a workaround you may modify the function
unknown_criticals which you find in
gnupg/dirmngr/validate.c and gnupg/sm/validate.c. Add to the
"known" array the strings "2.5.29.36" and "2.5.29.54".

c3po: There is no need to sighup gpg-agent.
gpgconf --reload (or --kill) dirmngr is sufficent

I would also like to see this.

Maybe --refresh-keys without arguments for "the entire keyring" should also ask
for a confirmation "This will leak your entire keyring to the keyserver and
possibly an attacker. Do you really want to do this? (y/N)", or "--yes".

Please see T1930. And if you have time, please
test it for PC/SC.
For GnuPG's internal CCID driver, you can use reader-port=1 for the case of a).
I don't know if partial match will be useful for internal CCID driver.

D291: 599_gpg2-scd-issue-1930-patch.diff

Thank you for your patch. I think that it is more useful.
Well, it will change the semantics of "reader-port" option slightly (exact match
to partial match).
In this case, isn't it more useful for users to allow default reader when no
match (my patch attached)?

Please let me know your name so that I can acknowledge your name as original
patch author.
Please test my patch.

Well, I commited a change to gnupg and for documentation reasons also to pinentry.

When calling pinentry with a known key (but not for PIN or during key creation)
the internal cache id is converted to a keyinfo string and send to Pinentry.
example:

  SETKEYINFO n/FD692BD59D6640A84C8422573D469F84F3B98E53

That string identifies a key. It is prefixed with a letter with a secret
meaning (actually n = normal key, s = used for ssh). Pinnetries should not
interpret the string but take it as opaque data.

It is possible to backport this to 2.0 if there is an interest in this.

I would like to see this happen. It would be great if dirmngr could make
parcimonie obsolete, for example.

(should this be "category: dirmngr" instead of just adding it as a topic?)

Let me confirm. Does this bus still exist in recent version of gpg 1.4 and/or
2.0, 2.1?