Re: Bug#93612: Support for new archive structure
On Sat, 14 Apr 2001, J.A. Bezemer wrote:
> > 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.
Bullocks. The user will have the option to invoke a difficult mechanism to
turn it off for exactly such infrequent cases [For which 99% of the time
should not be ignored!] . To actually get reasonable security in automated
tools we need to be as paranoid and as strict as possible. The tool should
not quitely disable checking and continue in any situation!
Next you are going to be insisting that since some tools don't check MD5's
APT must have a grave bug if refuses to use files with bad checksums!
In this case it is very simple, if you put a new-style release file down
beside a set of Packages files *you* (the archive creator) have made a
statement that APT 5 should check this new information. If you then
proceed to screw up the contents of the Package files then it is entirely
your fault that it doesn't work.
> > 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
Yes, I haven't decided the name of the option. Clearly that means nothing
has been thought through. Geeze, take a chill pill :P
> > 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.
How exactly is adding a new feature to APT that lets it directly read
certian well-formed CD's for the 1% of the population that uses such CD's
as loop back mounts _more_ of a special, undesirable case than fixing
every tool that anyone ever writes to understand that the file names in
the Release file are in fact meaningless!
That is not an acceptable trade off, please stop maintaing that it is!
> 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
Yes, it will wave it's magic wand and determine that Packages.complete and
Packages are in fact, the same. If they aren't then it does some equally
magical thing that has all kinds of oppurtunity to introduce flaws from
the user's perspective - 'It is listed in Packages but APT wont use it!!
Its a bug!!!'
Sheeze! Make everything operate worse just so that a handful of people
don't have to change the way they are doing things!
> 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.
Anyone who really cares about security is not operating in a void that
expects to have self-authenticating software! They will validate their CD,
against the FTP site and/or the web of trust and they will validate the
keys they give to APT.
Jason
Reply to: