Also a lot of redirects, for example this bounces you from https to http.

Could be done by adding "--yes" to the command line. Requires a new version of the gpgme_op_delete functions with a flag "force".

As others have pointed out, we don't implement the Bell-Lapadula model.

Well, iff we implement that for gpg we also need to implement it for gpgsm.

FWIW, using a Debian specific thing is not portable and Unix sockets won't work on Windows. Thus using the standard localhost connection is simpler than adding extra complexity.

Okay, I implemented the second part and Tor is now used if availabale.
--no-use-tor disables Tor.
--use-tor forces use Tor and can't be reset.

I am not to familiar with the gnome keyring but from looking it up on the arch wiki, it seems to have this single sign on capability.

Sufficient workarounds have been found.

That is the way I get my certificate signed, there is nothing I can do about it ;-)

So this is basically 0what GNOME does with its keyring daemon and pinentry-gnome.

It's not really a good idea to use the same RSA key for encryption and signing. (Although when I wrote scute, I couldn't generate a CSR for the encryption key, because the CSR had to be self-signed, meh).

Btw, this was envoy: https://github.com/vodik/envoy

what I mean by unlocking is the act of using the passphrase to load the gpg and ssh keys and hence not needing to tip the phrase again afterwards.

I don't understand what you mean by unlocking gpg-agent. Can you please explain in detail what you try to achieve.

One problem I see is that S/MIME doesn't standardize sign+encrypt, but requires nesting of those operations, leaving it up to the implementor to pick the order etc. From an interoperability point of view, this seems like a world of hurt if you take this out of the context of MIME.

Do you have a use case?

So it seems that accessing through gpg-agent is the better solution.

Changing the message affects all translations.

Well, we don't maintain a wiki, so I think this should be tracked elsewhere.

With commit 9998b162b47931fb8a8ed961d53418d505358888:

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

T3252 is about meta data for each key.

Hm. Could you elaborate on that? Why do you think it's dangerous?

I consider allowing empty user ids too dangerous.

Implemented in da91d2106a17c796ddb066a34db92d33b21c81f7.

Implemented in f17862d47.

werner said this won't be fixed.

This has been improved by e467a000f87e87582f5838964b6f1e0a960d4445

In addition to Werner's concerns, making network requests to unverified URLs can be harmful in many ways. For example, it would allow a third-party to detect when the signature was verified, among other even nastier things.

Maybe for 2.2?

Another reoccurring concern is lingering agents spawned in test suites. See, e.g. a discussion from this week: https://github.com/pazz/alot/pull/1081#issuecomment-315131053

Well, we always have to weigh the costs with the benefits. From the description of the task, the benefit was to satisfy "people [who] really don't like having idle processes lying around", which is not a strong motivation to take implementation and maintenance cost of any solution.

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.

Sorry, I expressed my concern poorly. gpg does recognize the keys as being expired/revoked, but this is not reflected in the exit code of the gpg/gpgv process.

Werner's comments indicate that this is expected behavior. Also, concerns were raised that this is difficult to implement correctly, and it is difficult to test. So, I am closing as wontfix.

And SETQUALITYBAR.

It is unclear what the benefit of such a console pinentry for windows would be.

Loopback is now officially supported, so I am closing this.

I just tested this with Fedora 26, pinentry-gnome3 0.9.7 and Gnome Keyring 3.20.1. See below for a full trace. If this doesn't work for you, check that you have compiled pinentry with libsecret, and did not deactivate the feature in the gpg-agent.conf.

Without a strong use case, I am closing this feature request. It may well turn out that like --allow-emacs-pinentry, the best solution in each case will be to add specific options, and then a generic pass-through will never be required. And we don't want to add features just in case somebody might need them in the future.

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.

Done.

So both gpg and gpgv seem to return success (as in the exit code is 0) if the signature is correct, even if the key is revoked or expired:

We don't support pkg-config, because it is not POSIX. See https://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028474.html for discussion.

Given that we have reduced the number of operations to at most 2 (down from unlimited), and it is unclear if and how to proceed on this, I am closing here.

Fixed in rD1143a81c4691.

FWIW, OpenPGP's S2K and PKCS's PBKDF2 are very similar and don't make a difference except that we have calibration code for S2K in gpg-agent.

The TOFU trust model gives some more information about certificate usage. Beyond that I don't think this is well defined to be actionable in the backend.

Digicert TERENAPersonalCA3 doesn't use issuingDistributionPoint anymore. It's hard to survey CRLs that are actually in use, so I don't know if there are other important users, but the fact that nobody else reported such problems is an indication that it is not widely used among dirmngr users. Supporting this is a lot of work, because it makes validating certificates much more complicated, so this is unlikely to happen without strong motivation, so I am closing this here.

I removed the man page and the link for now. Currently there doesn't seem to be an easy way to update it automatically.

PGP/MIME is supported since Gpg4win 2.3.

Most people should use a graphical user interface, and the console gui for key generation doesn't ask too many questions, while the key editor allows to go "back". So I am closing this suggestion.

Still no better message with gpg 2.1.21:

Maybe this can be done by Neal along with the book?

The change werner mentioned previously is eaba8d58acda66f428870794115cb22c2590ec5e, but this is based on Elgamal. RFC4880 since then specified S2K, and better approaches are available, too (at least PBKDF2 is in libgcrypt). These could be used with HKDF for RSA and other asymmetric key generation methods.

gnupg 1.4 is phased out and only receives important updates.

In T2905#99236, @justus wrote:

There is nothing to fix in the way the underlying algorithm communicates its value to the frontend. Negative values mean red, positive values green. After that, you have to normalize that to 0...100.