I have enabled login again and added the following login hint:
"Login via your Roundup account on bugs.gnupg.org has been disabled due to the migration to Phabricator. We apologise for any inconvenience caused. If you have previously used your Roundup account in this wiki, you can request a new password using the link above."

As part of switching debsig-verify from using --list-packets to gpg with --list-keys --with-colons and gpgv, it would be helpful to eventually be able to get the fingerprint instead of the keyid. This is needed because debsig-verify uses the keyid to select which one of its policy files it has to load, to apply for the subsequent actual verification of the .deb package.

This should be fixed by a0cc6e01. Just use the new gpgme_op_delete_ext operation with GPGME_DELETE_FORCE flag.

Werner indicated that the current behaviour is intentional.

GPGME does not use gpgv. What Justus likely meant is that we would need to change the common code used by gpgv and gpg. That may give problems in GPGME.

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.

Re-opening.

Implemented in c4506f624ed6854aa0ba1629aa2d1d43eb26900d.

We are in feature freeze and changing the status code of gpgv will likely cause problems for gpgme. We need to defer this.

I also have to add that, if this really has been resolved, it only covers up the case if the missing subkey(s) is/are on the smartcard(s), it does not solve the problem when none of the missing signing subkeys are in smartcards (as in, all on different computers). And it's clear that for version 2.1.22, it fails to get the available subkey on the disk for this case.

Done in a7bd2cbd.

@gniibe: I've tested 2.1.22 (from Debian experimental) and, while gpg --sign works, other programs (eg: git tag -s) still prompt to insert the card of the first signing subkey, despite the card with the second signing subkey being present.
Is that expected?

I implemented a possible fix in D442. The GnuPG Agent may call an external program (specified with the new --passphrase-checker option) to evaluate the passphrase's quality. This would allow to implement all kinds of metrics for passphrase strength, and to select one simply by choosing the right passphrase-checker.

Done in a8d0b8d23.

It's there in GnuPG 2.1 for a while, and bugs introduced by change were fixed.
So, I'm closing this bug.

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