Re: Bug#132767: debsum support should be mandatory
On Fri, 8 Feb 2002, Manoj Srivastava wrote:
> >>"Jason" == Jason Gunthorpe <jgg@debian.org> writes:
> Jason> If you keep the package files as you said then it all works exactly the
> Jason> same way as signing the individual filelists.
>
> Not quite the same. It adds complexity, increases the book
> keeping infrastructure, and disallows the practice of users
> sharing/transfering .debs on their own, without using the
> Packages/Release/Apt mechanism. Bad idea.
As I said at the end of my message it is not exclusive. People who can
make signed debs can do so, Debian just isn't.
> Strawman. No security mechanism is perfect, and no
> verification system can detect bugs in the underlying process. Just
> because there are bugs in packages that prevent perfect security does
> not mean we should weaken security measures.
Oh please, my example must be a serious concern for anyone doing
post-intrusion clean up - you can't just dimiss it just because
per-deb sigs cannot ever solve that problem. That's the entire point of
the other method :P
> I see no reason why signing the debs with the same key that
> signs the Release file is so very evil. If dpkg allows for multiple
> detatched sigs for each content block in the ar archive, we can have
> the best of both worlds.
This will never happen. A 30G mirror hit to add sigs is unnacceptable. The
key that signs the release file(s) for stable releases are well secured
and only used during the release process, it is infeasible to use them on
.debs in the archive.
> we support now. But we are not talking about now -- we are talking
> about changes that need to be made to provide cryptographic
> verification of machines.
IMHO per packages signatures will never have a significant role in Debian
proper. I belive the model cannot be made to work sufficiently well for
us.
However, I belive Progeny was making effective use of them - as I said, I
don't care, both methods need to exist.
> I assume you mean for the sig to already have ben
> generated. We may not be able to trust dpkg on the target machine; so
> the file list has to be generated, and the signature as well, in the
> deb itself. Or else dpkg becomes the single point of failure, and we
> can't transition from a machine in an unknown state to a machine in
> a known state.
No, the filelist does not have to be present in the .deb, only the
signature (ie during .deb signing the file list is created in /tmp, it is
signed and the signature included in the .deb, the file in /tmp is
discarde). dpkg can produce the file list on the client side. This is much
better because it immediately enables the entire archive, not just those
packages that happen to have been re-uploaded.
> Well, I would like a detatched sig to be arttached to the .deb
> as well at this phase, so that we do not need to rely on the
> Packages/Relase file mechanism; and I would be able to distribute a
> single .deb and still have the target machine be able to verify
> things ``the debian way''.
See flame-war on -private for so many reasons why this just is
ineffective..
> (In real life, my colleages have had to sneaker-and-floppy-net
> code over to protected networks with no connections outside; code
And this would be a situation that has nothing to do with Debian where
having debsigs in general can be very good. That does not mean it is good
for Debian.
Jason
Reply to: