trim local certifications from any handled key

#20 Declined
Deleted repository
default (707dd7b968f0)
  1. Daniel Kahn Gillmor

This is in light of recent discussions on sks-devel about sks propagating certifications explicitly marked as non-exportable.

Comments (8)

  1. Yaron Minsky

    What happens to all such keys in the database? I'd worry that you'll start throwing exceptions whenever such a key is encountered. Have you tested the patch?

  2. Yaron Minsky

    Sorry for the slow reply. A busy few days.

    I'm just confused with what happens with keys that are already in the database. Imagine that a new keyserver starts up with an out-of-date keydump, which is missing some keys that have non-exportable certifications. When that keyserver reconciles with one that does have these, aren't these going to lead to an exception being thrown somewhere?

    Rather than throwing an exception, I would have thought the right thing to do would be to filter out such certificates when you see them, or when you do a merge. Then, if one SKS server ran a search-and-destroy mission to filter out such certificates on its local copy, then it would cause merges with everyone that it gossiped with, thus squashing them from the whole network.

    That said, it's a little tricky during the period when some servers have this rule and some don't since the certificate squashing will happen on one side and not the other, leading to inconsistent handling of keys, and thus persistent differences.

    I only vaguely remember how it works, but I think there is a filter mechanism that is meant to deal with this case where different servers support different sets of filters on the keyset.

    All in, I don't see how this patch could be doing the right thing.

  3. Yaron Minsky

    Another very simple thing we can do: do this kind of filtering only on keys submitted through the HTTP interface, not through reconciled keys. Then you can stop this problem for new keys, without disrupting the replication mechanism.

  4. Daniel Kahn Gillmor author

    can you propose an alternate patch that you think would be doing the right thing? I see the filter lists in, but i don't see how to implement a new one in that framework.

    i agree that the synchronization phase across machines with/without this patch would be awkward, but it's better to have the awkward phase than to actively propagate data that is marked for non-propagation.

  5. Yaron Minsky

    How about my suggestion for filtering new keys that come through the HTTP interface? That will at least stop this mistake for new keys.

  6. Kristian Fiskerstrand

    I recommend that we reject this PR and can rather keep it in the back our our minds if we come up with a proper solution