Re: Bug#93612: Support for new archive structure
On Sun, 15 Apr 2001, Raphael Hertzog wrote:
> > Having more than one tree means it will be detected more than once and
> > that certianly is not desirable, any may cause problems, like it asking
> > for the disks in a non-ideal order, or something equally lame.
> May or will cause problem ?
I can't predict that. It might work OK in some cases, probably not in all.
It is certainly not something I designed or tested for.
> > 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.
This scheme lets people make valid 'woody-secured' areas and hide nastly
little bombs in the normal 'woody' area.
> > 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.
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.
*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*
> You don't see the point ? With what aj proposed, the standard directory
> uses the standard Packages which works ok with all old tools (including
> file URI with apt, but also dselect and so on) and the people who
> requires a secured set of files will use woody-secured.
1) The distinction between 'the user who wants secured' and not is
rediculous and should be dropped
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.
> True, however people willing security over a loopbak mount are silly.
> The main point was not about having security on a file URI but rather
> about not breaking what already existed.
Bullocks. Their should be a consistent set of functionality and nobody
should ever be forced to pick one over the other.
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.
> Anyway I already commited the code to debian-cd CVS, someone please burn a
> CD with this new tree and check if apt-cdrom does really as bad as Jason says.
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.
> > Step back and look at why you are doing this - the only reason is so that
> > people using old APTs can continue to use file: URIs and loopback mounts
>
> It's a bit over exagerated, it's also for people not using apt. :)
Non-apt stuff was broke the instant we decided to put pool/ on a CD, you
are over-exagerating the importance of maintaning this compatibility.
I am *so* sick of this 'Oh! Somebody might be using a tool that was last
updated in 1997! We better not do something or it might break it!'
attitude.
We over came that for the new FTP structure, and here it is again being
used to defend a bad solution for the CDs. Wee.
Jason
Reply to: