it is the decision of the user to use such a certificate.

Additionally, we might want some sort of delayed or batched CRL-checking that doesn't block signature verification with another network interaction, but would protect the user against future problems.

it's too bad that this is not considered something worth fixing upstream -- at the moment, debian's python3-gpg will only work with one specific version of python3 because of this, which makes package transitions more complex than they should be.

Agreed, Signing subkeys can be useful for checking historical signatures. And even encryption subkeys *can* be useful after their expiration, e.g. when doing historical auditing.

When i read the manpage, nroff-formatted against an 80-column terminal, it says, literally:

Any fix for this should be included in the test suite to avoid a regression :)

This decision suggests that the accessibility of the current source tree
for new contributors (who are more likely to find the static, archaic
changelogs distracting) is unimportant.

I'm not sure why a special case should be needed -- failure to create
the .kbx should not be a failure for a decryption operation in general.

So, to protect against this attack, the client needs to do both of the following:

Here are two examples:

@werner suggests using an ephemeral home directory. this is an important point.

@justus asked for examples.

OK, i've pushed 0471ff9d3bf8d6b9a359f3c426d70d0935066907 and 149041b0b917f4298239fe18b5ebd5ead71584a6 to branch T3490-proposal1. It cuts GnuPG's own simple test suite down from about 3 minutes to 1.5 minutes for me. I haven't tested the speedup for the full test suite yet.

To clarify, i'll push them to a separate branch for you to decide whether to merge.

I'll push some patches for proposal 1.

In the autocrypt spec, this is called a "setup code", not a "backup code" :)

agreed, generically changing this check to log_info doesn't make sense. However, in *this circumstance*, gpg actually has no error.

can you try it with --homedir /does/not/exist

Hm, perhaps this non-zero return code is due to not being able to write to the GNUPGHOME directory, actually. It goes away when GNUPGHOME is writable. That doesn't make sense either -- this operation doesn't actually depend on being able to write to GNUPGHOME, so it shouldn't return a different error code if GNUPGHOME is unwritable.

I guess it depends on whether you want gpgme to be an interface to OpenPGP certificates more generally (in which case, exposing the primary flag would be useful), or just a gpg frontend (in which case, the current behavior might be ok)

But there can be several user IDs that are marked primary, right? I know that gpg tries to not let that happen, but there are other OpenPGP toolkits out there, and composite/hybridized keys, etc where this could happen.

I agree with @kristianf that dirmngr should be more clever about this sort of failure. The error message could be clearer at least, but the right response is really to skip all IPv4 addresses if the machine has no IPv4 stack, and to skip all IPv6 addresses if the machine has no IPv6 stack.

I spoke with the author of onionbalance, and they said:

I'm fine with (and i totally understand) wanting nothing but UTC in the machine interface and internal representations.

I've changed the text of this report from "filter" to "screener" to match the preferred terminology. thanks for the clarification.

I think this is now resolved, as of rG926d07c5fa05

I am not proposing changing the order of the *hashed* subpackets in a signature. I'm proposing removing/changing/canonicalizing the *unhashed* subpackets in a signature. Sorry if i didn't make that clear enough in the initial message.

I thoroughly agree that this is not required by the specs.

I think any existing script that assumes UTC should add an explicit Z suffix. (that is, i don't think the breakage is a big deal, and anyone writing scripts that needs this kind of precision will be more likely be thankful that we have a sensible, normalized interface).

Is it possible that this is related to T3278 ?

fwiw, i agree that GnuPG should interpret these as ISO-8601 strings. At the very least:

Nice find, @gniibe ! So this looks like a bug either in GnuPG's test suite, or in parse_expire_string, right? How do you think it should be addressed?

The comment from aa above appears to be misdirected/spam.

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.