Re: Bug#93612: Support for new archive structure
Le Sat, Apr 14, 2001 at 08:15:49PM -0600, Jason Gunthorpe écrivait:
> > > It will add them both and it becomes trivial for someone to defeat the
> > > security mechanisms.
>
> > Why ?
>
> What do you mean 'Why?' Put the bad files in the insecure space and
> let-er-rip.
I can't understand that. apt know what has been signed and what packages
can be trusted. I guess that apt would warn the user if he had to use a
file which is only part of the insecured tree and on which there's no
valid trust path.
> > > The insecure one must be ignored for things to work
> > > correctly.
> >
> > That sounds ok to me. I don't see a problem here.
>
> *snort* Sure, I'll just wave a magic wand and it will all go away.
Anyway you'll have to do something like that. When you use for example
a Ximian tree and a Debian tree, some packages overlap, the Debian tree
will be signed and the Ximian may not be (or with a key not accepted by
the admin) and you will have to manage that. I don't see how it is harder
for the CD.
> As I said, I can think of no good way to eliminate the redundent tree,
> continue to support current CDs and provide protection against ways to
> defeat the validation mechanism.
Maybe some other apt hackers may think about it ? Because I can't believe
that it is not doable.
> *you* are assuming that just because it is easy for the CD scripts to do
> that it should be done and leaving the problem of supporting it up to *me*
No. I'm not willing to create problem for the sake of it, I just want to
do something that satisfies my view of what a debian cd should be.
> 1) The distinction between 'the user who wants secured' and not is
> rediculous and should be dropped
Sure, but why should it be up to me make that disappear ? You can make
this disappear too by managing correctly the CD.
> 2) There are no other tools. Switching to the pool layout pretty much
> foobared every other option besides APT, and dpkg-multicd already
> needed funny files.
Do you really think that all the tools were written by dumb people not
able to read Packages files and use the Filename field ?
A single CD can be used by any standard "file" access method. Be it one
from dselect or one from apt.
> Bullocks. Their should be a consistent set of functionality and nobody
> should ever be forced to pick one over the other.
Agreed. For the FTP/HTTP method, everything is ok. For mirror accessed by
files URI, it's ok.
For CD accessed by apt-cdrom, it may be ok if apt is able to give
precedence to trusted packages over non trusted packages.
For CD accessed by file URI, it's not ok actually but can be if the user
who really need security are aware of the woody-secured tree and if he
uses modern apt. What a big deal.
> We loose if it becomes hard to enable and use the validation mechanisms
> because people won't use them, and we are back to where we started.
It's not hard for 99,9% of our user. Like you said, the 0,01% person who
uses CD via loopback or anything like that either don't care or know about
woody-secured.
> A single CD tests nothing, you have to do a set and do testing to make
> sure that the swapping mechanism won't freak out.
Yup, I'm sure someone can afford that. I may even when I get back to
college.
> Non-apt stuff was broke the instant we decided to put pool/ on a CD, you
Why ? Old tools overcomed the non-US move without much troubles and
they'll overcome the pool move again.
> updated in 1997! We better not do something or it might break it!'
You're exagerating too. I never said that. I'm willing to make changes to
offer that, but I'm not willing to break things for that when there's a
possibility of not breaking it.
Cheers,
--
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Le bouche à oreille du Net : http://www.beetell.com
Naviguez sans se fatiguer à chercher : http://www.deenoo.com
Formation Linux et logiciel libre : http://www.logidee.com
Reply to: