Distinguish between trusted and untrusted signatures and keys. #1993

DemiMarie · 2022-04-07T22:45:30Z

RPM needs to be able to differentiate between “key not found” (RPMRC_NOKEY) and “key or signature not trusted” (RPMRC_NOTTRUSTED). A signature made by a revoked subkey is very much the latter situation.

pmatilai · 2022-04-08T07:04:43Z

Demi, development of the OpenPGP parser is frozen now, remember?

pmatilai · 2022-04-08T07:08:15Z

As a case, this may well be something rpm needs to handle, but going forward (ie assuming Sequoia and/or other "proper" implementation) I only see the in-tree parser maintained stripped to bare bone with no subkey support. So really, don't work on it anymore.

DemiMarie · 2022-04-08T08:14:18Z

Demi, development of the OpenPGP parser is frozen now, remember?

Good point. Does this also apply to the keyring code and similar? My understanding is that more work is needed there, such as to using fingerprints instead of key IDs. Also, I think the tests that this PR includes are valuable; they should pass for Sequoia-based RPM as well.

In any case, I could see this PR being useful for downstreams that can’t use Rust or need something they can backport.

nwalfield · 2022-04-08T11:26:15Z

In the very least, it would be good if the test case were merged.

DemiMarie · 2022-04-08T12:04:24Z

In the very least, it would be good if the test case were merged.

The test case fails with current RPM, as RPM currently doesn’t know when it needs to distrust a signature. This is still nowhere close to a full OpenPGP implementation (that’s orders of magnitude more complex), but it is enough to make gpg2 --export-options export-minimal --armor --output=output.asc -- '<TRUSTED_FINGERPRINT>' && rpmkeys --import output.asc safe (at least ignoring expired subkeys, which are a trivial add-on) and that’s what I mostly care about.

DemiMarie · 2022-04-12T12:06:25Z

@pmatilai would you be okay with merging this change so that the test case can be included, and so that LTS distributions have something they can backport if they wish?

nwalfield · 2022-04-12T12:47:36Z

I'm a bit concerned about the new certificates added in 126d896. The certificates will expire in two years. If an OpenPGP backend handles expiration, then I think these tests will begin to fail. It would probably be better to recreate the certificates without an expiration time.

$ sq inspect first-signing-key-revoked.asc
first-signing-key-revoked.asc: OpenPGP Certificate.

    Fingerprint: C9E4585A5D0201A9A077CE60D115BE9BEBDDD264
Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm
Public-key size: 256 bits
  Creation time: 2022-03-26 22:10:10 UTC
Expiration time: 2024-03-25 22:10:10 UTC (creation time + P730D)
...
$ sq inspect rpm.org-ed25519-subkey-2-test.pub
rpm.org-ed25519-subkey-2-test.pub: OpenPGP Certificate.

    Fingerprint: 7B32CBC30D3423162732DD859DD6F039A0E0C1C7
Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm
Public-key size: 256 bits
  Creation time: 2022-03-26 18:42:08 UTC
Expiration time: 2024-03-25 18:42:08 UTC (creation time + P730D)
...
$ sq inspect rpm.org-ed25519-subkey-test.pub
rpm.org-ed25519-subkey-test.pub: OpenPGP Certificate.

    Fingerprint: 7B32CBC30D3423162732DD859DD6F039A0E0C1C7
Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm
Public-key size: 256 bits
  Creation time: 2022-03-26 18:42:08 UTC
Expiration time: 2024-03-25 18:42:08 UTC (creation time + P730D)

DemiMarie · 2022-04-13T02:41:58Z

I'm a bit concerned about the new certificates added in 126d896. The certificates will expire in two years. If an OpenPGP backend handles expiration, then I think these tests will begin to fail. It would probably be better to recreate the certificates without an expiration time.

Good idea. Does the logic look good?

DemiMarie · 2022-04-13T05:46:34Z

Rebased on top of #2008 because otherwise #2004 breaks the tests.

pmatilai · 2022-04-13T09:48:45Z

NOTTRUSTED does seem like an entirely reasonable way to handle eg revoked subkeys as such, but sometimes sane behavior doesn't quite fit with the mad underlying OK/NOKEY etc semantics in rpm. I think this will require some more chewing before swallowing, if only because it quite fundamentally changes the landscape of rpm signature handling.

Up to now, imported == trusted since beginning of times, and there has never been a single case where rpm returns NOTTRUSTED. Which means that callers have no clear idea what it means and where they might encounter it, and so there almost certainly will be code in and out of rpm which will behave in unexpected/unwanted ways when presented with something else than OK/FAIL/NOKEY return. This also calls for test for the case where an installed packages has an NOTTRUSTED signature.

nwalfield · 2022-04-13T20:32:43Z

Here, @DemiMarie wrote:

I suggest fixing these tests in the internal parser, provided that tests are added that make sure the Sequoia backend won’t actually verify a signature using the bad subkey. My PR #1993 should do most of it.

I created three tests:

A package signed with a subkey
A package signed with an expired subkey
A package signed with a revoked subkey

Using the Sequoia backend, all three of these tests pass. It seems that not only is the internal OpenPGP parser unable to deal with this, but it can't even import the certificate:

269. rpmsigdig.at:304: testing rpmkeys --import, signed with a good subkey ...
../../tests/rpmsigdig.at:306:


if ! [ -d testing/ ]; then
    cp -aP "${RPMTEST}" .
    chmod -R u+w testing/
    mkdir -p testing/build
    ln -s ../data/SOURCES testing/build/
fi
export RPMTEST="${PWD}/testing"
export TOPDIR="${RPMTEST}/build"
export HOME="${RPMTEST}"

rm -rf "${RPMTEST}"`rpm --eval '%_dbpath'`/*
runroot rpm --initdb


echo Checking package before importing key:
runroot rpmkeys --define '_pkgverify_level all' -Kv /data/RPMS/hello-2.0-1.x86_64-signed-with-subkey.rpm; echo $?
echo Importing key:
runroot rpmkeys --import /data/keys/alice.asc; echo $?
echo Checking for key:
runroot rpm -qi gpg-pubkey-eb04e625-* | grep Version
echo Checking package after importing key:
runroot rpmkeys --define '_pkgverify_level all' -Kv /data/RPMS/hello-2.0-1.x86_64-signed-with-subkey.rpm; echo $?
echo Checking package after importing key, no digest:
runroot rpmkeys --define '_pkgverify_level all' -Kv --nodigest /data/RPMS/hello-2.0-1.x86_64-signed-with-subkey.rpm; echo $?
echo Checking package after importing key, no signature:
runroot rpmkeys --define '_pkgverify_level all' -Kv --nosignature /data/RPMS/hello-2.0-1.x86_64-signed-with-subkey.rpm; echo $?

--- /dev/null	2022-03-31 08:23:21.524275212 +0000
+++ /home/us/neal/work/pep/rpm/b/tests/rpmtests.dir/at-groups/269/stderr	2022-04-13 20:27:07.767226325 +0000
@@ -0,0 +1 @@
+error: /data/keys/alice.asc: key 1 import failed.
--- -	2022-04-13 20:27:08.159403250 +0000
+++ /home/us/neal/work/pep/rpm/b/tests/rpmtests.dir/at-groups/269/stdout	2022-04-13 20:27:08.151227005 +0000
@@ -10,22 +10,23 @@
     MD5 digest: OK
 1
 Importing key:
-0
+1
...

Any idea what is going on here? Is it perhaps because the internal parser rejects certificates, because the primary key is not signing capable?

DemiMarie · 2022-04-14T03:24:45Z

Here, @DemiMarie wrote:

I suggest fixing these tests in the internal parser, provided that tests are added that make sure the Sequoia backend won’t actually verify a signature using the bad subkey. My PR #1993 should do most of it.

I created three tests:

A package signed with a subkey
A package signed with an expired subkey
A package signed with a revoked subkey

Using the Sequoia backend, all three of these tests pass. It seems that not only is the internal OpenPGP parser unable to deal with this, but it can't even import the certificate:

269. rpmsigdig.at:304: testing rpmkeys --import, signed with a good subkey ...
../../tests/rpmsigdig.at:306:


if ! [ -d testing/ ]; then
    cp -aP "${RPMTEST}" .
    chmod -R u+w testing/
    mkdir -p testing/build
    ln -s ../data/SOURCES testing/build/
fi
export RPMTEST="${PWD}/testing"
export TOPDIR="${RPMTEST}/build"
export HOME="${RPMTEST}"

rm -rf "${RPMTEST}"`rpm --eval '%_dbpath'`/*
runroot rpm --initdb


echo Checking package before importing key:
runroot rpmkeys --define '_pkgverify_level all' -Kv /data/RPMS/hello-2.0-1.x86_64-signed-with-subkey.rpm; echo $?
echo Importing key:
runroot rpmkeys --import /data/keys/alice.asc; echo $?
echo Checking for key:
runroot rpm -qi gpg-pubkey-eb04e625-* | grep Version
echo Checking package after importing key:
runroot rpmkeys --define '_pkgverify_level all' -Kv /data/RPMS/hello-2.0-1.x86_64-signed-with-subkey.rpm; echo $?
echo Checking package after importing key, no digest:
runroot rpmkeys --define '_pkgverify_level all' -Kv --nodigest /data/RPMS/hello-2.0-1.x86_64-signed-with-subkey.rpm; echo $?
echo Checking package after importing key, no signature:
runroot rpmkeys --define '_pkgverify_level all' -Kv --nosignature /data/RPMS/hello-2.0-1.x86_64-signed-with-subkey.rpm; echo $?

--- /dev/null	2022-03-31 08:23:21.524275212 +0000
+++ /home/us/neal/work/pep/rpm/b/tests/rpmtests.dir/at-groups/269/stderr	2022-04-13 20:27:07.767226325 +0000
@@ -0,0 +1 @@
+error: /data/keys/alice.asc: key 1 import failed.
--- -	2022-04-13 20:27:08.159403250 +0000
+++ /home/us/neal/work/pep/rpm/b/tests/rpmtests.dir/at-groups/269/stdout	2022-04-13 20:27:08.151227005 +0000
@@ -10,22 +10,23 @@
     MD5 digest: OK
 1
 Importing key:
-0
+1
...

Any idea what is going on here? Is it perhaps because the internal parser rejects certificates, because the primary key is not signing capable?

Did you try with #1993? Without #1993 RPM will reject a certificate that has a revoked subkey, if the revocation signature is the first one. #1993 makes the behavior reasonable.

DemiMarie · 2022-04-14T06:09:59Z

@nwalfield you ran into a different bug: RPM is rejecting some of the signatures because they have critical subpackets it doesn’t understand. I will file a patch to ignore the primary user ID flag.

nwalfield · 2022-04-14T13:55:13Z

I tried my test cases (09bce55) with your change (7e10e0d), but I see that rpmkeys still can't import the certificate:

--- /dev/null	2022-03-31 08:23:21.524275212 +0000
+++ .../rpm/b/tests/rpmtests.dir/at-groups/269/stderr	2022-04-14 13:46:23.958169731 +0000
@@ -0,0 +1 @@
+error: /data/keys/alice.asc: key 1 import failed.
--- -	2022-04-14 13:46:24.093698347 +0000
+++ .../rpm/b/tests/rpmtests.dir/at-groups/269/stdout	2022-04-14 13:46:24.086169984 +0000
@@ -10,22 +10,23 @@
     MD5 digest: OK
 1
 Importing key:
-0
+1
...

DemiMarie · 2022-04-14T14:04:43Z

I tried my test cases (09bce55) with your change (7e10e0d), but I see that rpmkeys still can't import the certificate:

--- /dev/null	2022-03-31 08:23:21.524275212 +0000
+++ .../rpm/b/tests/rpmtests.dir/at-groups/269/stderr	2022-04-14 13:46:23.958169731 +0000
@@ -0,0 +1 @@
+error: /data/keys/alice.asc: key 1 import failed.
--- -	2022-04-14 13:46:24.093698347 +0000
+++ .../rpm/b/tests/rpmtests.dir/at-groups/269/stdout	2022-04-14 13:46:24.086169984 +0000
@@ -10,22 +10,23 @@
     MD5 digest: OK
 1
 Importing key:
-0
+1
...

I suggest adding some debug logging in the subpacket parsing code to see which subpacket gets rejected.

nwalfield · 2022-04-14T14:40:36Z

I suggest adding some debug logging in the subpacket parsing code to see which subpacket gets rejected.

It's failing here:

	    /* Reject duplicate key usage flags */
	    if (_digp->saved & PGPDIG_SIG_HAS_KEY_FLAGS)
		return 1;

HTH

DemiMarie · 2022-04-14T14:56:58Z

I suggest adding some debug logging in the subpacket parsing code to see which subpacket gets rejected.

It's failing here:
	    /* Reject duplicate key usage flags */
	    if (_digp->saved & PGPDIG_SIG_HAS_KEY_FLAGS)
		return 1;
HTH

If the signature actually has more than one key usage subpacket in the hashed section, this is expected behavior, but I would also consider that to be a very strange signature. Otherwise, something has gone wrong somewhere. Can you check if the flag gets reset properly between signatures?

nwalfield · 2022-04-15T12:00:14Z

Using this MR plus #2026, the test keys that I generated can now be imported.

nwalfield

Overall, I think these changes are an improvement to the internal parser, but the complexity of the internal parser increasingly scares me.

nwalfield · 2022-04-15T12:22:24Z

rpmio/rpmpgp_internal.c

 	}
    }
+end:


This file usually uses exit, not end.

Good point. It will be a while before I can fix this, though.

nwalfield · 2022-04-15T12:28:53Z

tests/data/keys/first-signing-key-revoked.asc

+5nFoswUnFC2C9SpJeiZDLSgBAO5h6mRI9iafOref8xhCf6qAtnXD3J195VMX1zCU
+chEM
+=MpKy
+-----END PGP PUBLIC KEY BLOCK-----


This certificate expires and should be replaced with one that does not:

$ sq inspect < tests/data/keys/first-signing-key-revoked.asc -t: OpenPGP Certificate. Fingerprint: C9E4585A5D0201A9A077CE60D115BE9BEBDDD264 Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm Public-key size: 256 bits Creation time: 2022-03-26 22:10:10 UTC Expiration time: 2024-03-25 22:10:10 UTC (creation time + P730D) Key flags: certification, signing ...

That indeed should be done, sorry about that. I will be busy for a while with Qubes tasks.

nwalfield · 2022-04-15T14:11:11Z

rpmio/rpmpgp_internal.c

+		    (sig->saved & PGPDIG_UNTRUSTED))
+		    res = RPMRC_NOTTRUSTED;
+		else
+		    res = RPMRC_OK;


I agree with @pmatilai that we shouldn't change the API.

I think we can emit this type of information via my proposed lint interface. We should, of course, consider returning richer error messages when we transition to a new API.

I’m fine with using RPMRC_NOKEY instead.

If we return NOKEY, then I think the whole certificate is ignored, which is not what we want.

I think the better approach is to just ignore the subkey if it appears to be revoked, i.e., drop this change.

nwalfield · 2022-04-15T14:22:39Z

rpmio/rpmpgp_internal.c

+	    break;
+	case PGPSUBTYPE_EMBEDDED_SIG: /* embedded signature */
+	    impl = *p;
+	    break;


This code makes me suspect that rpm is not checking the primary key binding signature, which signing-capable subkeys must have to be valid. Is that right?

That is correct. RPM has never checked that signature, but it really should. It isn’t a security problem in the case of checking a signature immediately before installing the package, though, as the primary key is trusted to not have signed a subkey that doesn’t belong to it. I didn’t want to add even more complexity to this code, but feel free to add such a check.

nwalfield · 2022-04-15T14:31:18Z

rpmio/rpmpgp_internal.c

+	    if (plen < 2)
+		return 1; /* missing reason code */
+	    if (sigtype == PGPSIGTYPE_SUBKEY_REVOKE)
+		impl = *p;


Why is the reason for revocation subpacket only understood in the context of subkey revocations and not certificate revocations or user id revocations?

RPM doesn’t implement those kinds of revocations. My assumption is that keys imported into RPM are a result of gpg2 --export --armor --export-options=export-minimal -- <TRUSTED_FINGERPRINT> or similar.

nwalfield · 2022-04-15T14:41:08Z

rpmio/rpmpgp_internal.c

-		  selfsig->sigtype != PGPSIGTYPE_SUBKEY_BINDING))
-		xx = pgpVerifySelf(digp, selfsig, all, i);
+	    /* subkeys must be followed by binding or revocation signature */
+	    int xx = pgpVerifySelf(digp, selfsig, all, i, prevtag);



If we are willing to admit multiple self signatures, which I think the last commit and this one now allow, then we shouldn't fail if a self-sig can't be verified. We should only fail if no self signatures can be verified.

See above comment about assumptions: GPG’s --export --export-options=export-minimal should strip such signatures off, and RPM doesn’t have the machinery needed to judge if a given packet can be safely ignored. The Sequoia backend does and would handle this properly.

DemiMarie

The complexity of the internal parser scares me too, but I suspect most of that complexity is essential. I wonder how GRUB’s parser fares.

DemiMarie · 2022-04-15T15:43:32Z

rpmio/rpmpgp_internal.c

+	    break;
+	case PGPSUBTYPE_EMBEDDED_SIG: /* embedded signature */
+	    impl = *p;
+	    break;


That is correct. RPM has never checked that signature, but it really should. It isn’t a security problem in the case of checking a signature immediately before installing the package, though, as the primary key is trusted to not have signed a subkey that doesn’t belong to it. I didn’t want to add even more complexity to this code, but feel free to add such a check.

DemiMarie · 2022-04-15T15:44:50Z

rpmio/rpmpgp_internal.c

+	    if (plen < 2)
+		return 1; /* missing reason code */
+	    if (sigtype == PGPSIGTYPE_SUBKEY_REVOKE)
+		impl = *p;


RPM doesn’t implement those kinds of revocations. My assumption is that keys imported into RPM are a result of gpg2 --export --armor --export-options=export-minimal -- <TRUSTED_FINGERPRINT> or similar.

DemiMarie · 2022-04-15T15:51:34Z

rpmio/rpmpgp_internal.c

-		  selfsig->sigtype != PGPSIGTYPE_SUBKEY_BINDING))
-		xx = pgpVerifySelf(digp, selfsig, all, i);
+	    /* subkeys must be followed by binding or revocation signature */
+	    int xx = pgpVerifySelf(digp, selfsig, all, i, prevtag);



See above comment about assumptions: GPG’s --export --export-options=export-minimal should strip such signatures off, and RPM doesn’t have the machinery needed to judge if a given packet can be safely ignored. The Sequoia backend does and would handle this properly.

DemiMarie · 2022-04-15T15:52:01Z

rpmio/rpmpgp_internal.c

 	}
    }
+end:


Good point. It will be a while before I can fix this, though.

DemiMarie · 2022-04-15T15:52:23Z

rpmio/rpmpgp_internal.c

+		    (sig->saved & PGPDIG_UNTRUSTED))
+		    res = RPMRC_NOTTRUSTED;
+		else
+		    res = RPMRC_OK;


I’m fine with using RPMRC_NOKEY instead.

DemiMarie · 2022-04-15T15:59:26Z

tests/data/keys/first-signing-key-revoked.asc

+5nFoswUnFC2C9SpJeiZDLSgBAO5h6mRI9iafOref8xhCf6qAtnXD3J195VMX1zCU
+chEM
+=MpKy
+-----END PGP PUBLIC KEY BLOCK-----


That indeed should be done, sorry about that. I will be busy for a while with Qubes tasks.

nwalfield · 2022-04-15T16:23:49Z

I'll rework the patch series.

Is 6bf8f03 necessary? Also, this change isn't described by the commit message: DemiMarie@6bf8f03#diff-1b8795f690eee3ed483f0ce64cd81e4d42c681a13c98314a3250c4fac5159485R620

DemiMarie · 2022-04-15T16:26:23Z

I'll rework the patch series.

Thank you.

Is 6bf8f03 necessary? Also, this change isn't described by the commit message: DemiMarie@6bf8f03#diff-1b8795f690eee3ed483f0ce64cd81e4d42c681a13c98314a3250c4fac5159485R620

With the current code I believe it is a no-op, but it makes the code less error-prone and is an overall improvement.

teythoon · 2022-04-22T13:40:54Z

@nwalfield you ran into a different bug: RPM is rejecting some of the signatures because they have critical subpackets it doesn’t understand. I will file a patch to ignore the primary user ID flag.

That sounds vaguely familiar: #1813 (comment)

Right now the two are equivalent, but this will no longer be the case if one can parse a signature without actually loading the algorithm-specific data. This will be useful for re-parsing subkey binding and revocation signatures that have already been validated.

In OpenPGP, only certain types of packets are followed by one or more signatures. These include public keys, public subkeys, user IDs, and user attributes (which include photos). Signatures that revoke other signatures make this more complex, but RPM does not implement those. Therefore, do not advance `i` in pgpPrtParams() if the packet just parsed is not one of the four aforementioned types, since self-signatures are computed over the first packet and the immediately preceding packet. Also, do not set `prevtag`, since it is used in verifying self-signatures.

The pgpVerifySelf() API was rather clumsy. The type of the data packet should determine the type of its self-signature, not the other way around. This makes detecting wrongly-typed self-signatures much simpler. Now that pgpPrtParamsSubkeys() checks the type of self-signatures, subkey revocation signatures can be checked too. This allows importing keys that have revoked subkeys. Also add a bounds-check in pgpVerifySelf() in case the index passed is wrong.

According to RFC 4880, subkeys are supposed to only be followed by binding signatures, revocation signatures, and other subkeys. In practice, the most likely reason to get something else is a revocation signature of a type that RPM does not implement. This could include a revocation of a subkey binding signature or a revocation made by a designated revoker. In this case, it is not safe to import the key, as RPM might accept a signature made by a subkey whose secret portion has been compromised. Therefore, return an error in this case.

RPM could not handle revoked subkeys: old versions accepted signatures made by them, while more recent versions will usually fail to import the signature. This ignores such subkeys. Additionally, require all signatures following a subkey to be subkey binding or revocation signatures issued by the main key. Anything else is most likely an alternate method of revocation that RPM doesn’t implement, and so importing such a key would be unsafe.

RPMRC_NOKEY means that RPM does not have the key at all. In the case of a signature by a revoked subkey, RPM *does* have the key; it is just refusing to trust it. Therefore, RPMRC_NOTTRUSTED is the correct return code. The same is true if a subkey is incapable of signing: RPM has the key, but is refusing to trust signatures made by it.

Sequoia sets them in the keys it generates, causing breakage.

pmatilai · 2022-11-18T08:00:51Z

After way too much procrastinating and indecision...

We wont be able to axe the internal parser in 4.19, dunno about 4.20. But that's a long way off, and until then we need to support what we ship. To avoid having to pile this complexity on and on and on to deal with subkey this and subkey that, I think the only possible solution is to saw off the limb to save the patient: remove the subkey support (#2278). That's where like 90% of the complexities seem to be.

Clearly quite a bit of work has gone into this PR and I hate to throw that away, but it's not like I didn't warn right from the beginning. As most of this PR is dealing with subkey matters, merging it just to remove the added complexity right after doesn't make any sense. Lest it all go to waste: at least the bit to support Sequoia-generated keys deserve salvaging but that's really unrelated and should be filed separately. Ditto for test-cases, but only for the Sequoia backend. There may be others but lets first get the subkeys out, it'll be clearer then.

Thanks and apologies, I should've been firm with this right from the start. I'd like to claim the crystal ball on this all was still fuzzy in the spring but that'd be lame.

DemiMarie force-pushed the handle-revocation branch 3 times, most recently from d77af33 to ab39879 Compare April 8, 2022 00:16

nwalfield mentioned this pull request Apr 11, 2022

PGP key identifiers use binding signature's creation time, not certificate creation time #2004

Open

DemiMarie force-pushed the handle-revocation branch 2 times, most recently from dece7a1 to 82654aa Compare April 12, 2022 12:05

DemiMarie force-pushed the handle-revocation branch 3 times, most recently from eacc525 to 077f8fd Compare April 13, 2022 05:44

DemiMarie force-pushed the handle-revocation branch from 077f8fd to e675d47 Compare April 13, 2022 06:31

DemiMarie mentioned this pull request Apr 13, 2022

OpenPGP Backend based on Sequoia #1978

Closed

DemiMarie force-pushed the handle-revocation branch from e675d47 to 4d19b42 Compare April 14, 2022 04:18

nwalfield reviewed Apr 15, 2022

View reviewed changes

DemiMarie commented Apr 15, 2022

View reviewed changes

nwalfield mentioned this pull request Apr 15, 2022

Handle revocation #2027

Closed

DemiMarie force-pushed the handle-revocation branch from 7e10e0d to 8809f66 Compare April 22, 2022 13:18

DemiMarie added 7 commits October 22, 2022 23:46

Handle some critical subpackets

4088faf

Sequoia sets them in the keys it generates, causing breakage.

DemiMarie force-pushed the handle-revocation branch from 8809f66 to 4088faf Compare October 23, 2022 04:43

pmatilai closed this Nov 18, 2022

pmatilai mentioned this pull request Nov 18, 2022

Deprecate the internal OpenPGP parser #1935

Closed

Distinguish between trusted and untrusted signatures and keys. #1993

Distinguish between trusted and untrusted signatures and keys. #1993

Conversation

DemiMarie commented Apr 7, 2022

pmatilai commented Apr 8, 2022

pmatilai commented Apr 8, 2022

DemiMarie commented Apr 8, 2022

nwalfield commented Apr 8, 2022

DemiMarie commented Apr 8, 2022

DemiMarie commented Apr 12, 2022

nwalfield commented Apr 12, 2022

DemiMarie commented Apr 13, 2022

DemiMarie commented Apr 13, 2022

pmatilai commented Apr 13, 2022

nwalfield commented Apr 13, 2022

DemiMarie commented Apr 14, 2022

DemiMarie commented Apr 14, 2022

nwalfield commented Apr 14, 2022

DemiMarie commented Apr 14, 2022

nwalfield commented Apr 14, 2022

DemiMarie commented Apr 14, 2022

nwalfield commented Apr 15, 2022

nwalfield left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DemiMarie left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nwalfield commented Apr 15, 2022

DemiMarie commented Apr 15, 2022

teythoon commented Apr 22, 2022

pmatilai commented Nov 18, 2022