"Reproducible build" definition in OpenSSF glossary

[Ismael Luceno]

El 2 de julio de 2025 8:36:16 UTC, Simon Josefsson via rb-general <rb-general at lists.reproducible-builds.org> escribió:
>James Addison <jay at jp-hosting.net> writes:
<...>
>That depends on how you define "reproducible"...  I think most people
>here doesn't consider it required to rebuild the transitive closure of
>build dependencies to call something reproducible.

Indeed. We even know for a fact you can reproduce most builds with different compiler versions or different dependencies (as long as the API remains the same). Unfortunately we don't have enough information to use that to our advantage systematically, but we can certainly replace missing information or replace parts of the history w/o problems (though it takes quite some effort).

>> For closed-source binary firmware blobs, the situation does seem less
>> clear.  They arguably can be used as fixed inputs to a build to achieve
>> identical bit-for-bit output -- but if I understand correctly, it raises a
>> question of "is complete source code to all inputs required in order to
>> label/certify an artifact as reproducibly buildable?".
>
>Indeed.
>
>And if we don't have source code for object X, how can we tell that it
>is a firmware blob?  There is no simple way to know what it is, and some
>methods to establish what it is (disassembly) may be illegal.

If it is a firmware blob, there's no point in distributing it together with an application, so we only have a problem with shipping them in installer disks.

All we can do is ask vendors to open source the firmware or stop being cheap and include into the device so we can happily ignore it's existence. People make it way more complicated than it is.