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

Re: Bug#93612: Support for new archive structure



On Fri, 13 Apr 2001, Jason Gunthorpe wrote:

> On Fri, 13 Apr 2001, Raphael Hertzog wrote:
> 
> > > > I'm really beginning to think that the only valid alternative is
> > > > to have a Release file and its signature for each CD.
> > > 
> > > Absolutely not.
> > 
> > Why ? Of course, it's a pain for the Release manager to sign & check all
> > those files but I don't see why it wouldn't be an acceptable solution ...
> 
> Because anyone should be able to build a CD set without having to get the
> release manager to sign the thing. 

I agree. Keep in mind that
  "correct signed Release file on CD" != "this is an official Debian CD"
but
  "correct signed Release file on CD" == "CD contains some official Debian
   packages"
and
  "md5sum of CD matches publication on cdimage.d.o" == "this is an official
   Debian CD"

(Any warning/error message displayed by apt-cdrom should make this difference
very clear.)

> Look, no matter what you do, you always end up with a lame situation. The
> fewest people will be affected, and the largest gains realized if the
> Package file has extra entries. 
> 
> a) Use verbatim package files and call them 'Packages'
>   - Everyone can make CD set, and we still have end-to-end security
>   - apt file:/../ does not work properly on those discs 
> b) Use verbatim package files and call them 'Packages.something'
>   - Everyone can make CD set, and we still have end-to-end security
>   - apt file:/../ does not work properly on those discs 
> c) Resign the Release files
>   - Only Debian can make disks, we loose end-to-end security
>     and the RM/Security/etc groups have to sign a bajillion files
>   - Hurd looses again, since their weirdo CD's have to be resigned
>   - Debian derivitives loose, since their weirdo CD's have to be resigned
>   - apt file:/../ works
> d) Do nothing
>   - No security :P

e) The Packages of the FTP archive is copied verbatim to CD as
   Packages.complete
   Packages on CD contains a strict subset of Packages.complete with
   all packages&info in exactly the same order (probably alphabetical).
     Verification structure:
   Verify signature of Release/Release.gpg
   grep -q `md5sum Packages.complete | cut -d ' ' -f 1` Release || echo Problem
   diff Packages.complete Packages | grep -q '^> ' && echo Problem
   package install: grep md5sum-of-package Packages  (or Packages.complete)

   - Everyone can make CD set, and we still have end-to-end security
   - apt file:/../ works properly on those discs 
     except that Packages fails verification but people who use this will
     already know that; should be overridable easily (and looking for a
     Packages.complete when Packages fails shouldn't be too hard to implement
     for any access method)

Furthermore, mounted CDs should work with ftp:/../ and http:/../ too.

Also keep in mind that we should absolutely not care about the name of any 
file. The _contents_ (i.e. md5sum) is all that matters.

(That's also why I don't have a problem with the simple grep and diff above.
A wrongly copied Packages or "problematic" Packages that couples "Package: a"
with "MD5Sum: b" causes inconvenience is but no security risk.)

And lastly, anyone with hostile intentions can easily make/ship a CD which
contains a modified apt that doesn't check signatures at all. End-to-end
security is only "guaranteed" for very paranoid people that actually go and
manually re-check everything that apt-cdrom checks.


Regards,
  Anne Bezemer



Reply to: