[PATCH v2 GnuPG] allow import without user ids

[Daniel Kahn Gillmor]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190521/2a02607a/attachment.sig>