sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jeff Johnson
Subject: Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
Date: Wed, 01 Jun 2011 15:44:08 -0400

On Jun 1, 2011, at 2:09 PM, Scott Grayban wrote:

> Maybe I'm the rookie here but not a linux "rookie", I have been using
> linux for the past 15 years, just google my name, and I always run into
> the group that would rather take the "easiest way" and ignore a issue
> that is bound to come up.
> 
> At some point the current DB is going to be to large to handle muchless
> transport it via plastic media whether its dvd, blue-ray or flash drive.

4Gb is large for a data store? Get a grip please, peta-byte databases
are almost routine these days and no amount of growth in the SKS key
stores is going to suddenly explode exponentially.

Transport simply isn't an issue for a store that is smaller
than distro DVD's and isn't likely to need changing, nor
"sneaker net" transport any time soon. There's only, what 200?
500? people in the world who care (and know) what a SKS dump is.

> Sure we have cheap TB drives now but that isn't going to be practicable
> in the future to transport/share/copy the DB dump. I hear that some

So how many people do you predict needing a SKS sump 10 years from now:
        1000? 10000? 10000?
You are arguing from the size and complexity of transporting a SKS dump
file and that is mostly irrelevant.

> people are already running into corrupt PTree db's and have to rebuild
> them every few weeks... just this alone should be a warning.
> 

Bah ... Berkeley DB haters are everywhere,rampant FUD,  and the PTree problems 
are
invariably lack of tuning expertise, and no knowledge of what procedures to 
follow
when the dreaded "corruption" occurs. Ignorance is no basis for arguing
        Danger Will Robinson! PTree corruption means meteor storms!

> PGP (keyserver.pgp.com) has been allowing keys to be deleted for years
> and they even scrub their DB of revoked and expired keys and that hasn't
> degraded the trust yet. It's just practicable to remove stuff like this.

The decision to never remove any key materiel is one of policy not 
implementation.

> You wouldn't keep moldy old bread would you ?
> 

And I don't use moldy Debian code either: breaks my teeth when I chew on it.

73 de Jeff

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]