Re: Bug#93612: Support for new archive structure
On Fri, 13 Apr 2001, Jason Gunthorpe wrote:
> On Sat, 14 Apr 2001, J.A. Bezemer wrote:
>
> > > 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
>
> > e) The Packages of the FTP archive is copied verbatim to CD as
> > Packages.complete
>
> That's b)
>
> > - apt file:/../ works properly on those discs
>
> Nope, packages fails verification and APT will stop without using the
> file, ditto for ftp, http, etc.
EVERY access method up to current potato APT will work nicely with this. If
woody/sid APT suddenly stops working correctly, thats a grave bug in APT and
nothing else.
That's because APT (and ONLY apt) is effectively changing the very definition
of "Packages file". Up to this moment:
Packages = file that is an index to all packages (virtually) available
in&under current directory
But you want to change that into:
Packages = file that contains security information on packages that either
are, or are not, available in&under current directory
> You'll have to fiddle around and switch it
> off via some-means-not-yet-determined.
You haven't even thought of that aspect, have you? I'm starting to think that
you didn't think of _any_ aspect carefully enough. This is Debian, not Red Hat
or M$. We are known for supplying our users with the options they need or
want, not for taking options away because of uncareful management decisions.
But, of course, that's why we're discussing things now: to create a solution
that doesn't take away any functionality for any one of our users. And I think
that's very well possible.
> Doing what you described, but swapping the names around is best. Then the
> name in the release file matches the name in the filesystem and you can
> get authentication with very little hassle.
Is there really any more "hassle" when names (that, as I stated, essentially
do not matter at all) are kept the way I suggested?
> Use an APT line like:
>
> deb-partial ftp:/..../ ...
>
> For instance.
Good, now you're thinking constructively. But instead of
deb and deb-partial
call them
deb-complete and deb
Then you can just forget about the deb-complete because the "new" deb can
handle anything.
> I *really* don't like that we suddenly have to start special casing all
> the tools that work with the Release file to work on CD's, thats really
> lame. (see below)
A "deb-partial" is _more_ a special case than a "deb" that handles
authentication via either a one-step or two-step process without the user
noticing it.
Besides, the scheme I proposed also seamlessly allows for partial http and ftp
mirrors that 1) can be authenticated if the access method has authentication
support and 2) work with APT and all other access methods you can think about.
Simply because it doesn't change the definition of "Packages file". Completely
backward and forward compatible.
Generalizing: I think the autentication sequence should be like this for
_any_ medium (cdrom,file,ftp,http,whatever):
Release/Release.gpg
|
Packages.complete
|
Packages
|
.deb file
with the special case that Packages.complete may be omitted if it is
exactly the same as Packages. I know this is a "radically" different way to
view things, but if you had looked at it this way from the very beginning,
there wouldn't have been any problem, would there? And it isn't too late to
change things, because this solution is even back- and forward compatible with
the current authentication structure.
(Except for the filenames, that as I said, don't matter. I even wonder why the
Packages.gz-s are mentioned in the Release file, because it's the _contents_
that matter and not the unzipped/gzip/bzip2/Xzip -1...-9 format it's
distributed in.)
> > 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
>
> There is a fairly direct means to validate the CD against the web-of-trust
Yes of course there is. What I said was that a piece (or collection) of
software fundamentally CANNOT authenticate itself. It must be authenticated by
the user doing every algorithm manually, or using trusted programs that do NOT
come from the software(collection) that is to be checked.
This essentially means that APT checking authentication provides a _false_
sence of security. Of course, it's another barrier that an impostor has to
take, and that's a good thing, but to anyone _really_ caring about security
it's of no use at all.
Regards,
Anne Bezemer
Reply to: