this is also https://bugs.debian.org/866555

i think it's strictly worse, even when the certificates are "trusted" in sense (1) -- with OpenPGP keyserver lookups, at least it is the client who decides which keyserver to use, on what protocol, to look up the given issuer fingerprint.

I see at least two different kinds of "trust" here.

Making matters worse, i note that some CRLs, like those issued by MIT's Lincoln Lab are quick and easy to fetch over the Internet directly, but hang or timeout when fetched via Tor.

It wasn't a natural thing to do gpgme_op_import because i already had my gpgme_key_t object, which i was using to display an index of available keys to the user.

Please use the systemd unit files as shipped upstream. This allows the agent to be launched automatically whenever someone tries to use one of its sockets, but doesn't pre-emptively launch the agent until needed.

I'm not sure i understand why i'm "chasing a ghost" -- i'm reporting the experience of a developer (me!) who tried to use gpgme, read all the docs, and was still surprised and dismayed by the metadata leakage.

Thanks for the improvements, Marcus!

Can you describe the problems it would cause for gpgme? gpgme already currently expects that gpgv will return a failure for signatures made before the validity window of the key. so gpgme won't break just because gpgv is capable of returning a non-zero response.

ah, great! sorry i got confused :)

fwiw, faked-system-time is used in several non-gnupg packages in debian already.

fwiw, faked-system-time is used in several non-gnupg packages in debian already.

why should it wait for the timeout in the pselect call? shouldn't it be able to respond immediately to the final connection closing?

Yes, that commit was in 2010, but it was on the 2.1 branch, which never saw wide distribution until this year, which means that there are test suites (like the one mentioned in request-tracker) which simply fail hard when used against gpg 2.1. Is there explicit guidance that the GnuPG project wants to give to downstreams like request-tracker?

I'd like to hear a little more about the use cases we imagine for Anonymous OpenPGP certificates.

I'm re-opening this ticket because i think Valodim has clarified what he meant, which is different than what werner closed the ticket for.

Users expect to be able to make signatures (or to fail to make signatures) reliably and understandably. the fact that some pinentries fail in some obscure combinations of circumstances makes the process of making signatures unreliable and incomprehensible.

This is a disappointing resolution. There are many other reasons for having a daemon, which include keeping a sensitive piece of data in memory (and not on disk) for a limited period of time, while providing controlled access to it. This is exactly what gpg-agent does.

Thinking about it more broadly, i think that gpgv (and gpg, when used in signature verification mode) should have a return code that is as close to the true/false underlying semantics that users will want, rather than relying on status messages to distinguish between these cases.

for expiration (or for revocations flagged "key was superseded" instead of "compromised"), you can have a signature made *before* the key's expiration/revocation, but you might be verifying it *after* the key was revoked/expired.

including these tests (or something similar) in the gpg test suite would be a good way to avoid future regressions.

Note that T2923 includes a patch that might help.

My point is that without clear documentation of what is expected, it's pretty hard to tell whether the code is even working or not. Sounds like it isn't :(

I don't think this issue is actually resolved. there's a feature here (i think) but it's not documented to the point where anyone can figure out how to use it. If there's no way to use it, the feature should be removed (or at least deprecated).

I don't see how this duplicates T3074. If the web form is going to encourage people to ask for the team's encryption keys, it should just provide the encryption keys directly.

Agreed, i think the OP is asking for X when he wants Y, so that makes this request a little bit strange.

I don't think that's what we want. An OpenPGP certificate has a claimed temporal validity window: from the creation date of the certificate to its expiration or revocation date.

fwiw, i've also opened a bug for sbuild asking it to not force the locale into non-UTF-8: https://bugs.debian.org/866023

fwiw, i also find this password quality indicator rather dubious.

T2103 is the right place to discuss the password quality algorithm, not here.

In many cases, it's possible to make two connections (e.g. via ssh) to such a server, and in one of those connections explicitly do:

aiui, the point here is to have the user "service" get triggered somehow (through pam's pam_systemd.so's session module?) before ssh goes ahead and forms the socket. is that right? If the pre-launch mechanism is pam, is there a reason to do it as a systemd user service? That won't work for systems that have pam but don't have systemd, whereas a pam module that creates these will work.

I don't think this is a problem for GnuPG to fix. The user is running an OS that launches a version of gnome-keyring by default which doesn't fully-implement gpg-agent's functionality, and yet presents the gpg-agent interface. The user needs to either disable gnome-keyring, or upgrade to a version of the OS (or of gnome-keyring) that doesn't present the gpg-agent interface.

If you're putting a note at the top of ChangeLog-2011, it should probably mention where the *other* changelogs are, not just an explanation of what this file is doing here. And while this does explain to a user who has bothered to read it what's going on, it's still not particularly friendly.

thanks for considering this for > 2.2.

I'm not sure i understand. Current changelogs don't go into the source tree, and yet that's not a violation of the GPL, so clearly keeping changelogs in the source tree isn't a requirement in general.

I'm using 2.1.21-2 from the debian experimental build, and i'm not seeing this misbehavior.

I've pushed rGdee244b48060 in the branch T3172 as a proposed fix for this.

I didn't mean to remove the capability of having a restricted "extra-socket". I meant that we could remove (or deprecate) the capability of placing the restricted "extra-socket" at an arbitrary location. I agree with you that having the restricted "extra-socket" is an important capability that gpg shouldn't remove.

Those scripts are likely already broken if their input happens to be different than what they expect, so i don't much care about "breaking" them. That said, it sounds like you're suggesting that the default mode will just be "--decrypt" and we'll let people continue using it that way.

Can we activate this for --import and --recv-key as guilhem requested?

I've raised the priority here because this bug gets reported regularly and it seems a shame that we haven't fixed it yet, despite having a patch available for quite some time.

The branch dkg/T1967 contains a fix for this. Please review!

I've just pushed rGde441cb9cc87, taken from the gnupg-devel mailing list, message-id: 20160414161817.GA9527@gnu.org

I think it only lists the wrong "extra socket path" when one is specified in gpg-agent.conf, right?

I've just pushed a branch dkg/no-skel-files which implements this change.

Can you try with --standard-resolver ?

I just merged the current git head over on zelenka, which includes b83903f59ec5d49ac579f263da70ebc8dc3645b5, and managed to still get the same segfaults.

fwiw, this remains a problem on 2.1.20: https://buildd.debian.org/status/fetch.php?pkg=gnupg2&arch=s390x&ver=2.1.20-1&stamp=1491409561&raw=0

I don't have one of these systems handy to test with, but if the fix in dee026d7 does what it says it does, this sounds like it's probably OK to close in my book. if there are more problems, i'm sure we can re-open it.

Sure: