sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] 0x80D0489D - bad MPI in pubkey packet


From: Yaron Minsky
Subject: Re: [Sks-devel] 0x80D0489D - bad MPI in pubkey packet
Date: Wed, 3 Nov 2004 20:27:50 -0500

I agree that differences in presentation filters are a problem.  But
it's unreasonable to expect all SKS admins to adopt new versions the
moment they're released.  I expect this to largely settle out within a
few months.

Some kind of forced upgrade to SKS will be require at some point, no
doubt.  But I don't see a good reason to enforce it when
backwards-compatible mechanisms are available.  I am basically
unwilling to introduce unneeded incompatibilities just to force people
to upgrade.

y

On Wed, 3 Nov 2004 19:59:55 -0500, Jason Harris <address@hidden> wrote:
> On Wed, Nov 03, 2004 at 05:34:33PM -0500, Yaron Minsky wrote:
> 
> 
> > On Wed, 3 Nov 2004 15:18:45 -0500, Jason Harris <address@hidden> wrote:
> 
> > > Although I haven't (yet) applied patch-33, your desire to keep unusable
> > > keys/packets in SKS really bugs me.  Listing a raw keydump that includes
> > > 0x476B1681 causes mutt's pgpring to stop processing after:
> 
> > I don't mean to offend, but there is actually a good reason for my
> > reluctance.  SKS uses a synchronization protocol that requires that
> > each host in the system has a uniform view of what does and does not
> > belong in the repository.  Introducing changes at one host would cause
> > persistent differences between SKS hosts, that would waste time and
> > bandwidth as the system tried to resolve an irreconcilable difference.
> 
> AFAICT, these "fixes" should be implemented as actual filters that,
> yes, all hosts would be required to adopt.  Each admin would force
> an "sks cleandb" to remove the problem keys/packets once (each time
> the filters change).
> 
> If an admin doesn't want to upgrade, they will most likely be dropped
> as gossip peers by those who have upgraded.  While this may lead to
> more fragmentation of the "SKS network," ideally it will be a positive
> force to make the network more homogenous instead.
> 
> We're already seeing fragmentation caused by SKS servers running versions
> from 1.0.6 to 1.0.9, where your current "presentation" filters (in 1.0.8
> and later) mean that certain keys behave differently depending on which
> SKS server returns them.
> 
> 
> 
> --
> Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
> address@hidden _|_ web:  http://keyserver.kjsl.com/~jharris/
>           Got photons?   (TM), (C) 2004
> 
> 
>




reply via email to

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