Introducing: Semantically reproducible builds

[Vagrant Cascadian]

On 2023-05-29, David A. Wheeler wrote:
> On Sun, 28 May 2023 21:10:36 -0700, Vagrant Cascadian <vagrant at reproducible-builds.org> wrote:
>
>> Do such tools actually exist, or are we talking about something
>> theoretical here?  I am nervous about investing too much energy in
>> something without a specific, precise, working proof of concept.
>> 
>> In your earlier mention of OSSGadget, it was not immediately clear that
>> anything in there could actually do this sort of analysis... ?
>
> OSSGadget is a collection of tools.
> One of its tools is oss-reproducible, which measures this:
>
> https://github.com/microsoft/OSSGadget/blob/main/src/oss-reproducible/README.md

Ah, I got lost on the the top-level README.md, which did not mention it
at all (although looking back, apparently that was mentioned in the
initial email on this thread ... sorry, lazy me).


> They originally called it just verifying a "reproducible build".
> I learned about the tool, thought it was neat but I told them
> that using the term "reproducible build" for this was confusing.
> They agreed and decided to change their term to
> "semantically reproducible build". I thought the approach was
> interesting and so posted about it here.

Well, thanks for nudging them away from completely abusing the term
"Reproducible Builds"! Still not a fan of prepending with
"semantically" ...


>> I still expect it will be harder to actually do "semantically
>> reproducible builds" than "fully reproducible builds.
>
> This isn't intended for the developers and builders.
> It's a way to identify some packages that are low risk
> because, while the builds aren't reproducible, the
> differences are unlikely to be an issue.

So, maybe a third-party reviewing their dependency trees?


>> To be honest, it sounds like a lot of extra work to avoid fixing things
>> properly...
>
> As a user I often cannot choose what the builder or developer do.
> I can propose a patch set, but it takes time to create them,
> and there's no guarantee the project will accept them.

Well, the above-referenced oss-reproducible does not appear to be for
your average user either...

Even if a project will not accept the changes, presuming it is FOSS, you
can test the reproducibility locally and see what changes are necessary
to fix it. Although for huge dependency chains this obviously becomes
impractical... but huge dependency chains are arguably impractical in
their own right (and yet painfully pervasive).


Any tooling that facilitates review of software obviously is useful; I
certainly do not object to that.

I guess the initial mail subject "Introducing: Semantically reproducible
builds" kind of came off a bit wrong to me ... almost as a product
announcement, starting by essentially proposing something that weakens
the term "Reproducible Builds" that so many have worked so hard to
establish.

... which reminded me of a discussion a while back; which felt similarly
about weakening the meaning of reproducible builds:

  https://github.com/coreinfrastructure/best-practices-badge/issues/1865

I feel that issue was even worse than the current thread, but many of
the same points were made there, so it felt a bit like rehashing old
arguments...

I at least can see that the oss-reproducible language for "Semantic
Reproducibility" does clearly state the relationship to bit-for-bit
identical... but it still feels a bit too easy to conflate or confuse
with what feels to me like the authentic, real reproducible builds.


While I see that Reproducible Builds can be hard to achieve 100% of the
time (especially with projects outside of one's control or influence)
and I see value in getting a given build artifact more reproducible than
before ... and stepping stones and strategies that are useful to get
there may include partial fixes or workarounds... and I myself use such
stepping stones routinely...

Apparently, I hold a very strong stance on keeping the *focus* on
bit-for-bit reproducibility!


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20230529/4a928663/attachment.sig>