This IS about GD - a proposal on dealing with the problem
kfitzner at excelcia.org
Sat Sep 10 03:58:57 CEST 2005
David Shaw wrote:
> On Fri, Sep 09, 2005 at 02:00:38PM -0600, Kurt Fitzner wrote:
>>Ok, that other thread isn't about the GD, but this one is. I think this
>>is something that should be discussed and a consensus reached.
>>Are they a good/bad signer?
>>Does something need to be done about them?
>>Should they be approached by the community?
>>PGP's position (and the argument I've heard from others) is that they
>>have a lone keyserver, not attached to anything else, if the keys and
>>junk signatures leak - SEF/SEP (Somebody Else's Fault, Somebody Else's
>>Problem). My response is, if a company produced a pool of toxic waste
>>and left it on private, but open and unprotected property, is that
>>company liable for that toxic waste getting out?
> So if I take material from www.cnn.com and distribute it around the
> net, it's CNN's fault for not protecting their data better?
CNN's articles are distributable with a URL. A public key needs to be
CNN doesn't attach extra data to an article that is in a form that the
distribution channels are reluctant to filter out for other reasons,
causing them to grow ad infinitum within the distribution system.
If there was a distribution network set up where anyone could submit
news articles where, once submitted to one, the articles would then be
automatically shared amongst other servers and then archived forever; if
that distribution system had the mechanism for, say, appending an update
to the article that would then be spread around and if CNN appended an
update to their articles every two weeks that said "Nothing has changed,
this article is still as it is intended to be - oh, and by the way, even
though we are appending this update every two weeks, we won't reevaluate
doing so for another six months".... if this were the case, then yes, I
would say CNN is then at fault.
> It might be useful to tone down the rage here. PGP isn't producing
> toxic waste. They're producing small packets of binary data. Nobody
> is actually being poisoned and dying here. Extra signatures on keys
> do not actually harm anyone, despite all the hysterics that they seem
> to cause. At best, this is an aesthetic problem.
The keyservers are the individuals being poisoned. It's a heavy metal
poison. In general, heavy metal poisons are dangerous because they
accumulate in the tissues of the affected individual and aren't
naturally cleaned and purged. Also, like the poisoning of many heavy
metals, this onem, if left to accumulate, will cause brain dysfunction
in the infected individuals.
> Also, these are not "junk" signatures. They have semantic meaning,
> and are used by many people. Please clarify what makes a signature a
> "junk" signature. I'd like to understand why you classify them that
Junk signatures because the form they are being distributed in is
meaningless. Signatures that expire in two weeks in a system which is
evaluated every six months are useful for exactly what, mway I ask?
They have semantic meaning the same way a child's "are we there yet"
questions every five minutes for the last hour of car ride have semantic
meaning. Yes, there is meaning conveyed, yes the meaning can be parsed,
but the same question (is this key valid/are we there yet) could have
been asked once in the time period and have been just as valid.
>>Their server and their signatures, but we are paying the price with
>>time, agravation, and quite possibly increased costs to keyserver
>>operators if something isn't done.
> Where is the time (aside from the time we keep spending talking about
> it)? Where is the aggravation?
> Costs? Picking a random GD signature off my key, it is 293 bytes
> long. Let's guess that there are around 10,000 keys that exist both
> on the SKS net and the GD. Let's also say that there is a malicious
> person out there who is bridging *every one* of those 10,000 keys. I
> doubt this is happening, but again, let's go with it. Given all those
> weighted-to-be-awful numbers, what does that come to? 2.8 megabytes.
> The GD reissues signatures on demand, more or less every 2 weeks. 52
> weeks in a year, so the GD will add 72.7 megabytes a YEAR to the SKS
> server net. 72.7 megabytes a year. In 8 years, we'll have enough to
> fill a CD-ROM.
How about we guess there is an order of magnitude more keys and that the
database is several gigabytes. Let's guess that in 2002 there were,
say, 1.6 million keys with 3.8 million signatures in general
circulation, and the database size was 1.6 gigabytes. Let's guess that
the key count was up about 150,000 keys from the previous year. Given
those guesses, what sort of impact might GD have? What sort of impact
might they have in ten years?
How about we also guess that not all servers are modern Athlon64X2
machines with more hard drive space than has a right to exist. Let's
say that some of them are old, otherwise castaway machines used because
they make good little servers. Old pentiums with ten or so gigs storage
- machines that, essentially, can handle the load now but might not be
able to with GD's junk data. Replacing those machines is a cost to the
providers. Losing those machines is a cost to the community.
> Allow me to opine that if we're hurting from 72.7 megabytes a year,
> than the keyserver net has other problems than the GD.
Opine allowed :) - please see above though.
>>My proposal is that a letter be sent to PGP requesting (I'd put
>>demanding, but that's simply my personal outrage speaking) they kindly
>>stop leaving toxic waste....er junk signatures... out where any naive
>>user can (and obviously does) spread them around. Perhaps it could be
>>suggested that they take part in the cleanup effort by supplying time
>>and money to operators to fix the problem. I propose this letter be
>>signed by as many of the OpenPGP and related support software
>>developers, key server operators, and even end users as will support it.
> Why the outrage? I really don't understand why people are so hopping
> mad about this. Turn on "import-clean" in your gpg.conf and you'll
> never see more than one GD signature at a time.
This is end-user spam filtering. By the same argument, because my
server's spam filter is 99.99% effective and I am essentially personally
unaffected by spam on a daily basis, that spam is not a problem.
I am upset because PGP being who they are had to know that:
- The keys would get out
- There was no mechanism for removing anything from any key once it
enters general keyserver distribution
I am upset because there is no truly useful purpose behind a two-week
shelf-life signature in a system where key validity is assessed every
I am upset because there can be no logical reason for what they are
doing except to create a dependance on their services and right now it
is at the expense of free service providers.
> It's fairly obvious at this point that someone is bridging the GD to
> the keyserver net. PGP (the company) isn't doing it, and PGP (the
> product) and GnuPG have no way to do it automatically. Again, may I
> suggest that before we implement changes in keyservers or send
> threatening letters to the PGP company or even just continue to vent,
> we simply track down who is doing it and ask them nicely to stop?
I don't accept that it is obvious that PGP (the company) isn't doing it.
I only accept that it is obvious that they say they aren't coing it. I
have seen no technical data that supports or contradicts the question of
whether or not they are responsible. If this exists, please point me to
it - I'll even try to evaluate it objectively. :)
> I've seen Jason pull off miracles at tracking down the origin of bad
> packets on the keyserver net. That would actually accomplish
> something, rather than getting all angry and scolding PGP (which might
> make people feel better, but likely won't change any part of the GD).
Oh, if enough people signed the request, I'm sure it could get
slashdotted - /. may not be very elegant in and of itself, but a harsh
article there would affect PGP's bottom line a little bit. Maybe just a
very little bit, but it would most likely be enough to put an end to the
More information about the Gnupg-users