Bug#844431: Revised patch: seeking seconds

Ximin Luo infinity0 at debian.org
Wed Aug 16 16:34:00 UTC 2017


Bill Allombert:
> On Tue, Aug 15, 2017 at 07:49:55PM +0000, Holger Levsen wrote:
>> Also what you are saying ("a package that is reproducible according to the
>> policy definition must not show up as non-reproducible in tracker/DDPO based
>> on results from the reproducible infrastructure") doesnt really makes sense:
>> if a package shows up as unreproducible somewhere, it's not reproducible
>> according to our definition!
> 
> Again, reproducible means that it _can_ be reproduced. As long as a well-know
> process allows to reproduce the package, it is reproducible.
> 
> What you define is a different concept that deserve a different name.
> 
> Cheers,
> 

I think it is OK to call this "reproducible", it's a natural language word and these are always dependent on some context. Technically, everything is reproducible if you know the state of the machine when the original build was started. Some other projects give you a VM and tell you to build in the VM. That would be a "well-known process". But nobody really knows what's in the VM so it's not helpful for security. Having a strict definition of reproducibility, helps us be more convinced that the build process is really only dependent on the source code and build tools, and a very restricted set of other inputs.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



More information about the Reproducible-builds mailing list