Re: [Sks-devel] IPv6 peering; keydumps annoyingly large

[Matthew Palmer]

On Wed, Jun 01, 2011 at 02:18:24AM -0700, Scott Grayban wrote:
> So just wait and see until the last minute to clean it up when DB does
> become a issue ?
> 
> I don't like that idea... that means in some future the entire pool
> could be down if we take the "wait and see" approach.

Unless you're worried about hitting a DB size limit, I doubt that a growing
database will take down everyone together -- different servers in the pool
have different storage capacities.

> Why wait ? Why can't we run a script that will at least delete keys that
> have expired and revoked ? And then prevent such keys from being
> re-imported back into the db ? That would be the sensible thing to do
> now when we don't have any emergencies.

Sounds like something you and/or oakwhiz could get working on.  It'd be
better to work on the "live" database, rather than the dumps, because (as
you note) any naive deletion on any one server would be useless because
recon would just put it back, and if it's out of the DB then the dumps would
then reduce in size as a consequence.

I'd say you'd need a script (which could be in any language) to find and
delete keys matching whatever constraints you decide are relevant, and write
the key ID to a "blacklist" somewhere for ignoring.  Then modify SKS itself
to read and honour that blacklist (would require OCaml knowledge).  You
might also have to include the blacklist in or alongside the dumps, so that
new servers don't just get the keys back again from some server that hasn't
cleaned them out.

I recall there was a discussion not-that-long-ago about deleting keys in
relation to takedown notices or other forms of legal insanity; there might
be good ideas and/or contacts in that thread that would be worth looking at,
if you're serious about getting such a thing happening.

- Matt