[Reproducible-builds] Storing .deb checksums in ADMINDIR/status?

[David Kalnischkies]

On Tue, Jun 23, 2015 at 09:31:05AM +0200, Jérémy Bobbio wrote:
> But, as far as I know, this information is currently not recorded by
> dpkg and there is no way to know for sure which `.deb` has been used for
> a package currently installed. I have a couple of memories where this
> could have been useful outside of the aforementioned use case.

Not exactly a different use case, but higher level package managers have
pretty much the same problem while figuring out if the installed v1 is
the version v1 available from archive A, archive B or an entirely
different one you may or may not want to upgrade away from.

You can either ignore this problem and declare v1 a unique identifier or
run crazy like apt does and guess based on fields like the dependencies
if this is the same version or not, with all the subtil bugs arising
from either…


The big problem I see is which hash to store. dpkg itself currently
supports only MD5, adding more means finding a free implementation of
them to embed or add a new (then pseudo-essential) (pre-)dependency.
APT has so far opted for public-domain implementations, but you get
complains about it being slower than openssl and alike, which in
exchange is a can of (license-)worms apt didn't want to open so far.
If dpkg is willing to do that on the other hand…

Otherwise sticking with MD5 means that we formally require MD5 to be
available in repositories (we don't currently, but I guess very few
actually go to the trouble of not having it, so that is more
a theoretical concern) and that it is harder to get a deb file securely
as you can treat the MD5 just as an ID; you need to establish
authenticity some other way (= lookup more secure hashes in Packages
file, which you have to validate itself and so on, which is hard™ and
rules out simply using snapshots.d.o compared to e.g. SHA256).


A way to sidestep these problems would be to allow package managers to
ask dpkg to store arbitrary additional fields. This would basically
promote the (multi-release long) transition period you would have anyway
as dpkg can't retroactively calculate the hashes for already installed
packages to an eternal "chaos" of never being quiet sure if the fields
are available…


Best regards

David Kalnischkies
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20150624/587ab699/attachment.sig>