Mailing List Archive

[PATCH v2 GnuPG] allow import without user ids
I included dkg's testing series, as expected the test only passes once the
second patch is applied.

Only three out of five of dkg's files are currently used: import of subkey
revocations that have no binding signature, as well as out-of-place user id
signatures, is out of scope for this patch. I included the others anyways,
since may be userful later on (without regenerating the whole series).

I also noticed that the way I handled invalid uids before didn't make much
sense: just because there is some invalid uid in a key, doesn't mean
cryptographically valid new packets can't be imported. I changed the patch to
reflect that.

Signed-Off-By: Vincent Breitmoser <look@my.amazin.horse>



_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH v2 GnuPG] allow import without user ids [ In reply to ]
On Tue 2019-05-21 20:03:08 +0200, Vincent Breitmoser wrote:
> I included dkg's testing series, as expected the test only passes once the
> second patch is applied.

thanks for this, Vincent!

> Only three out of five of dkg's files are currently used: import of subkey
> revocations that have no binding signature, as well as out-of-place user id
> signatures, is out of scope for this patch.

I think i understand why you think user ID self-sigs are out of scope
for this series -- they don't follow the user ID they're supposed to
follow, and they're not necessarily a security concern.

I don't understand why you think subkey revocation is out of scope for
this patch.

If i import primary+uid.asc followed by primary+subkey.asc after your
patch applies, then i should have a certificate with a functioning
subkey on it. That's your first test, which is good.

But if i then import primary+subkey+sub-revocation.asc, the subkey
should show as revoked, no? Otherwise, the user will believe that the
subkey is still valid. That's a significant security issue, comparable
in some ways to the failed import of the revocation certificate in your
final test.

Could you add this subkey revocation test between the two tests? You'd
be looking for a revoked subkey, i think.

> I also noticed that the way I handled invalid uids before didn't make much
> sense: just because there is some invalid uid in a key, doesn't mean
> cryptographically valid new packets can't be imported. I changed the patch to
> reflect that.

i think the changes you've made look good, but i confess that the logic
in the existing codebase is complex enough that i am not confident in my
ability to understand it, let alone these modifications. Having the
test suite is super helpful here to reason about it.

--dkg