[Reproducible-builds] .buildinfo should contain source hashes (as well as binary hashes)

Jérémy Bobbio lunar at debian.org
Sun Sep 20 18:43:48 UTC 2015


Ximin Luo:
> With our current .buildinfo setup, the above process is more
> complicated, because we *only* store hashes of the binary build
> environment.

I'm sorry but this is not accurate regarding the current
specification [1]. It says:

    Build-Environment

    List of all packages forming the build environment, their
    architecture if different from build architecture, and their
    version.

The idea to put a hash of the binary package in the
Build-Environment is a late addition to the original idea. It came as a
way to make `srebuild` job easier: retrieving a specific binary package
with its hash is already part of snapshot.debian.org interface. It also
makes unecessary to find the relevant repository snapshot and the
related headaches with how to handle expired signatures.

In any cases, we currently don't have code to store any hash of the
Build-Environment. If we wanted to store hashes of binary packages, then
we would need to have them in /var/lib/dpkg/status and it's not done
yet, even if Guillem said this would be a good thing to have.

> Currently, to run a DDC test, we would have to read the buildinfo
> file, find the hashes of the binary build-deps, lookup the source
> packages that corresponds to these hashes, find a different binary
> build-deps for these hashes, and run our DDC-checker. This takes many
> round trips, and contacting external infrastructure that isn't
> necessary.

You would not need to lookup the source packages using hashes. Using
package and version gives you enough info to retrieve a specific source
package from the archive.

> If .buildinfo files contained source hashes, the DDC-checker could
> work more directly, without requiring a remote repository of source
> hash <-> binary hash mappings.

I'm interested in `.buildinfo` in the context of the Debian project. The
Debian archive is designed to be immutable. A specific version of a
package will always correspond to the same source and binary files.
So I don't see why one would do complex “source hash - binary hash
mapping” when you can just rely on what is in the archive (and what has
been archived by snapshot.debian.org).

If by building thing that ought to match a specific package version you
get different result, then you will have to investigate in any cases.


Implementation-wise, getting the hash of the .dsc in the .buildinfo is
going to be very tricky. dpkg does not know about what's available in
the archive. It just knows about packages which are or were installed.

 [1]: https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification

-- 
Lunar                                .''`. 
lunar at debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-   
-------------- 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/20150920/7e5a4fe7/attachment.sig>


More information about the Reproducible-builds mailing list