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

Re: apt 0.6 and how it does *not* solve the problem

On Mon, Aug 23, 2004 at 12:59:59PM +1000, Russell Coker wrote:
> On Mon, 23 Aug 2004 09:34, Geoff <geoff.crompton@bjhcontrols.com.au> wrote:
> > There is an elaborate system to maintain quality in new Debian
> > developers (which seems like a good idea to me). Why not have some sort
> > of system for ensuring the quality in continuing DD?
> > If a DD didn't meet the criteria they would go into an inactive list,
> > and if they stayed in the inactive list for 3 months, would go into the
> > retired list, and their gpg keys _somehow_ invalidated. Is it possible
> > on a gpg key server to mark a key as invalid, with out access to the
> > private key?
> Sounds like a reasonable idea.  We can't automatically make the key invalid.  
> But we can have a central Debian key that's used to sign the keys of all 
> developers.  If such a signature was revoked then it would show the change in 
> status of the developer.
> Removing developers who don't meet certain criteria (EG no package uploads for 
> 6 months) from active status makes a lot of sense.  Anyone care to propose a 
> GR?

This doesn't work.  The problem is basically:

a) what about a package which they uploaded while valid, more than 6 months ago,
   that someone wants to download and install now.
b) if by date, what's to stop someone backdating a package and falsifying a
   mirror/proxy with a copy of their package.  The signature will still check

If you wanted to implement this the only safe way to do it and have the original
packages by ex-developers still installable is to have a central daemon check
the signature and co-sign the fact that they checked the signature at a certain
date (upload date) and that it was valid as of that time.  

So long as the daemon is secure and has an updated revocation list, this works.
Of course if the daemon's key is ever compromised then you have to re-validate
every package - but the vast majority will also have an up-to-date developer
signature against them, so only ex-maintainer packages will need a checkup.



Reply to: