Re: Bug#540215: Introduce dh_checksums
Hi Wouter,
I followed somewhat the discussion and I'm sorry for the delay
answering but package signatures are quite low in priority
in our roadmap currently:
http://wiki.debian.org/Teams/Dpkg/RoadMap
We would be glad however if someone would lead this project. I think this
project would benefit from a DEP so that we have a spec to refer to and so
that we can get buy-in from all other involved parties before going too far
in the implementation.
Otherwise it will be one more thread without clear outcome...
On Tue, 23 Mar 2010, Wouter Verhelst wrote:
> The idea would be to provide a path from a binary on disk to a GPG
> signature for installed packages of which the user no longer has the
> .deb file from which it was originally installed, nor the Packages
> and/or Release.gpg file that was used to download it.
Ok, it looks like a good goal.
> The proposal as it currently stands would be that:
> - md5sums are phased out in favour of a more generic 'checksums' file
> that would use a more secure hash algorithm than MD5 (one of the SHA*
> family of hashes would probably do at the moment).
> - When asked to sign a .deb file, dpkg(-deb) would extract the checksums
> data member from control.tar.gz, create a detached signature for that
> file, and store it as an additional data member in that .deb.
OK, but additional data members in .deb are ignored by dpkg like you
noted, this also means that it doesn't end up on the disk after unpack.
I assume your proposal is to modify dpkg to extract those and store them
somewhere. Is that true? In that case, where and under which format?
You have mentioned multiple signatures per package, would they be stored
in multiple ar member or in a single one?
My only wish at this point is to avoid exploding the number of
small administrative files in /var/lib/dpkg/info/ due to this new feature.
The biggest downside in your approach is that it's somewhat painful to
ensure that all the content of the package is signed. If the checksums
files is incomplete, what is supposed to happen? Is that something that
dpkg should take care of or should that be outside the scope of dpkg?
> The benefits of this method as opposed to storing the signature in the
> control.tar.gz file would be:
> - Autobuilders would not need to be modified to support signed packages.
> - Adding a member to an ar file and removing it again later can be done
> in a way which is idempotent; the same is not true for modifying a tar
> file. As such, it is trivially possible to remove signatures from a
> .deb file to allow its verification against the original .changes file
> that was used for its upload, should this at any point be necessary
> - If adding multiple signatures is possible in a way which does not
> modify the contents of the .deb file itself, then the archive-wide key
> could in theory be used to sign individual .deb files. While a massive
> increase of CPU power on ftp-master.d.o would be needed to support
> this, it would allow for easier key management on the end-user end.
> - It would not break backwards compatibility. I tried this, by manually
> adding a file "signature_01.asc" to a .deb file; dpkg was still able
> to install this package, it just ignored the unknown file.
The biggest concern I have with modifying the .deb multiple times along
the path is the fact that we're changing the checksum of the whole file
and we're not changing its name. Changing this invariant will lead to
problems. On the other hand, adding a signature should not require
changing the filename either.
Did ftpmaster (and buildd maintainers) comment on this problem?
> the metadata and maintainer scripts in the control.tar.gz file. Doing
> this would require some way to clarify the difference between data in
> control.tar.gz and data in data.tar.gz; current suggestions are to
> either use a prefix (something like CONTROL:preinst, for instance) or to
> use the path of the binary-as-installed (wherein the above would become
> "/var/lib/dpkg/info/<package>.preinst"). There aren't any strong
> feelings towards one or the other, however.
I prefer the prefix approach because the other one is hardcoding internal
information that is not guaranteed to be stable between the dpkg that
generates the .deb and the one that is used to unpack it.
If any tool outside of dpkg needs to map this to a real file, it should
use the appropriate interface (currently it's "dpkg-query --control-path
<package> <controlfile>").
As you see there are quite some questions that still need to be cleared up
and again I think the DEP process would allow us to answer them
progressively and end up with a clear agreed-upon plan.
Cheers,
--
Raphaël Hertzog
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/
Reply to: