Re: PATCH: package verification in dpkg
On Fri, Mar 09, 2001 at 08:26:47PM -0700, Jason Gunthorpe wrote:
> On Fri, 9 Mar 2001, Ben Collins wrote:
> > > I see the deb signature stuff as providing potentially very high security,
> > > but the user has to be vigilant and maintain a very strict and complete
> > > policy.
> > The policies are not meant to be written by users, but by distributors
> > of the packages. IOW, Debian, Progeny, etc.
> Then IMHO they are not very worthwhile. When the best Debian can do is say
> 'all packages are signed by one of these 800 keys' :P
That's why the package should also get signed by the same dinstall key
that signs the release sig :P
dinstall key + maintainer key = security and accountability
That's something release keys cannot do.
> > Only in certain situations, and that situation is when using apt.
> > Restricting security to a tool that doesn't allow you to bypass it and
> > get the same security, is not perfect. Most users will at some point
> > install a .deb directly, without the user of apt.
> It is not limited to APT. It is limited to the data that is available via
> APT. Debs cannot be checked alone because there is not enough information
> to associate them with a release. (and before you go explaining the deb
> release signatures in this scheme remember that the ftp masters have
> rejected that idea)
Of course, which is why I said that the two compliment each other.
> > Yes, the debsig-verify tool does allow you to pass deeper data. Have you
> > looked at the tool at all? No, you can't do this through dpkg, so you
> I was not talking abou the debsig-verify tool. I was talking about the
> integration with dpkg, which does not have any of these features.
> If your answer is going to be to just always use debsig-verify directly
> then scrap the dpkg integration :P
No, my argument was that dpkg needs more ways to integrate with
> > > It does not show which signatures are present signing dates, etc, which
> > > may very well allow 'obsolete package' attacks to slip past.
> > You've spoken of these "obsolete attacks" and yet, you've never given me
> > an example of one which is actually a security risk. I don't see this as
> > a problem which signatures need to address.
> Oh I donno, stick that nice root exploitable openssh on a server that
> looks surprisingly like security.debian.org and pollute a DNS cache
> someplace. Users expecting to upgrade to a safe version will find the only
> available version is this buggy one. You could even spoof the version in
> the filename. Betcha most people won't notice the dpkg message is .1
> digits off.
> Log http/ftp transfers and automatically r00t he box after the buggy sshd
> is installed.
> The other one I like to bring up is the idea of a debian distribution that
> looks alot like potato, except that every root exploitable daemon/program
> is stuck at an older version. ''Worst of Debian''
You keep arguing as if anyone thinks that the .deb sig is trying to do
things that the release sig was meant to do. That is not the case. Stop
arguing against weak points of signing deb's compared to strong points
of having a release sig. The two work together. Where one fails the
other picks up. It's not a competition Jason, it's a cooperative effort
here. No one is trying to step on any toes.
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` firstname.lastname@example.org -- email@example.com -- firstname.lastname@example.org '