[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#540215: Introduce dh_checksums



On Wed, 2010-03-17 at 11:31 +0100, Wouter Verhelst wrote:
> On Wed, Mar 17, 2010 at 08:58:28AM +0100, Goswin von Brederlow wrote:
> > Wouter Verhelst <wouter@debian.org> writes:
> > > On Fri, Mar 12, 2010 at 05:16:55AM +0100, Goswin von Brederlow wrote:
> > >> Harald Braumann <harry@unheit.net> writes:
> > >> > On Wed, Mar 10, 2010 at 03:32:14PM +0100, Wouter Verhelst wrote:
> > >> >>
> > >> >> Having package.checksums be GPG-signed will take a significant change in
> > >> >> our infrastructure (buildd hosts, for instance, would need to have a way
> > >> >> to sign checksums files as well), so it's not going to happen
> > >> >> tomorrow.
> > >> 
> > >> That can be avoided by including a hash of the checksum file in the
> > >> Packages files.
> > >
> > > That doesn't help for the problem we're trying to fix here: having a
> > > path to a GPG signature from an individual binary on the hard disk,
> > > months or years after the package was installed.
> > >
> > > With your proposal, you lose the signatures once the package is out of
> > > the archive and you run 'apt-get update'.
> > 
> > Then don't do that. :)
> 
> We can hardly say to our users "if you want to be able to check
> signatures, never run run apt-get update"...

Not necessarily. I assume that it would be easy (and cheap) to preserve
a copy of the previous:
 http://ftp.debian.org/debian/dists/testing/InRelease
 http://ftp.debian.org/debian/dists/testing/main/binary-i386/Packages.diff/*

It would then be possible to reverse apply the diff, and validate the
packages when needed. The disk-space cost would be quite low. Currently,
that's 448K for 6 days (27MB/year), which is quite cheap compared to
cached binaries that have to be preserved too.

(And it comes to my mind that it might be possible to implement some
roll-back feature... If we were supporting to downgrade packages to some
extend;)

I have no strong preferences between signed APT and SIGNED DEBs... it is
just that the remaining of the thread showed that signed DEBs are quite
tough to implement. (and I still wonder how we could preserve the
current deb format with "tar.gz in ar", while signing the debs)

That's 2 more cents from me,

Franklin


Reply to: