Reproducible Builds Verification Format

[Hervé Boutemy]

Le jeudi 14 mai 2020, 14:18:38 CEST Arnout Engelen a écrit :
> On Thu, May 14, 2020 at 1:55 PM Morten Linderud <foxboron at archlinux.org>
> 
> wrote:
> > On Thu, May 14, 2020 at 01:39:57PM +0200, Arnout Engelen wrote:
> > > I don't think the buildinfo of the initial build should be a required
> > 
> > input
> > 
> > > for a rebuilder.
> > > 
> > > Now of course I know in practice it can be logistically convenient to
> > 
> > use the
> > 
> > > buildinfo from the initial build as input for the rebuilder. I'm not
> > 
> > saying we
> > 
> > > should forbid this. But I think we should design our standards / file
> > 
> > formats
> > 
> > > in such a way that we do not *require* rebuilders to have access to
> > > information from the initial build. For example, triggering a 'rebuild'
> > > whenever a new version is tagged in source control could in some cases
> > 
> > be a
> > 
> > > valid approach as well.
> > 
> > This is an implementation detail, isn't it? A buildinfo wouldn't be
> > required if
> > you are in an environment where the build environment doesn't change. But
> > in
> > many cases, this isn't the case. Dependencies we pulled could have new
> > versions
> > which could very well interfer with the build. And if we don't have the
> > buildinfo file at hand, how would we know what introduced the change?
> 
> I think we are in agreement: I was trying to explain why I think rebuilders
> should publish their resulting buildinfo, and while adding the rbvf concept
> proposed above can be useful, it should be shared along with the buildinfo,
> rather than instead of it.
while trying to do the whole process with JVM artifacts published to Maven 
Central, with builds done on misc OSes & misc build tools, we finally arrived 
to 3 concepts:
1. build spec = what's the recipe to build the project release?
2. build info = what's the result of the build?
3. build info compare = how does a build info of a rebuilder compare to the 
reference build that was published to the reference repository = Maven Central

the result is here https://github.com/jvm-repo-rebuild/reproducible-central
If you follow one row in the table, you will find in "build" column links to 
the spec (with key aspects smmarised in "env" column) and the rebuilder's 
build info, then in "Repro" column a link to the comparison with the reference 
artifacts as found in Maven Central

the intent of showing the result is not really to try to reuse formats, that 
were not done really to be reused for Linux distros for example, but to share 
the 3 concepts that seem key

In our discussions:
1. I often miss the spec part, which seems implicit (it is important in JVM 
Maven Central case to have an explicit build spec for each release, because 
each project does build independently, then there is no uniform way to build 
to have a chance to get the same output)

2. the build info comparison seems to be merged with the rebuilder build and 
comparison with reference build info

I would love that this (re)builders collector explicit these 3 concepts:
1. what is the list of build specs?
2. for each spec, what are the different build results collected? (one being 
probably the reference from an official source, then every other ones being 
considered as rebuilds)
3. for each rebuild, what is the output comparison against the reference?

> 
> I'm unsure if you are proposing a rebuild, or argueing for multiple seperate
> > builds of the same package at the same point in time. The latter is beside
> > the
> > goal of a rebuilder currently and would in any case be a CI/CD feature of
> > the
> > given distribution.
> 
> I'm not proposing any changes/rebuilds of existing infrastructure.
> 
> I'm mainly arguing that if we introduce a new concept/file format (the rbvf
> proposed above), we should be careful it won't prevent us from doing
> useful things (like indeed running multiple separate builds of the same
> package at the same time, or running a 'rebuild' without access to the
> buildinfo from the original build) in the future.
regarding format, I tried to understand in-toto but could not understand how 
to map anything of the 3 concepts, sorry.

Regards,

Hervé

> 
> 
> Arnout