<div dir="auto"><div>Hi Simon,<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 2, 2025, 08:26 Simon Josefsson via rb-general <<a href="mailto:rb-general@lists.reproducible-builds.org" target="_blank" rel="noreferrer">rb-general@lists.reproducible-builds.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"Arnout Engelen" <<a href="mailto:arnout@bzzt.net" rel="noreferrer noreferrer" target="_blank">arnout@bzzt.net</a>> writes:<br>
<br>
> On Tue, Jul 1, 2025, at 09:59, fosslinux via rb-general wrote:<br>
>> On 6/30/25 17:29, Ismael Luceno wrote:<br>
>> >> some set of instructions and a set of opaque "source inputs" files which<br>
>> >> may include previously built binaries, without any requirement that<br>
>> >> those previously built binaries can be rebuilt or is even free software.<br>
>> > That can't possibly qualify as reproducible.<br>
>> <br>
>> Any suggestions for what to call it? There is value to such work, and it is at minimum very closely related to <br>
>> reproducible builds.<br>
><br>
> I think it's pretty much impossible to avoid people 'maliciously'<br>
> misrepresenting their product as 'reproducible' when it really isn't -<br>
> that doesn't seem like something tweaking the definition can fix. I do<br>
> think it's still useful to have precise terms so we can make the<br>
> distinctions clear, though.<br>
><br>
> I agree "Reproducible Builds" as a whole means "from source to binary".<br>
<br>
That would make Debian installer CDs impossible to call reproducible,<br>
since they are built from binaries for which we do not have source code.<br><br>[ ... snip ... ]</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Does this refer to binary firmware specifically?</div><div dir="auto"><br></div><div dir="auto">I would hope that we could agree that building an artifact composed partly or entirely from 100% DFSG binary packages that are themselves reproducible would produce a transitively reproducible build.</div><div dir="auto"><br></div><div dir="auto">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?".</div><div dir="auto"><br></div><div dir="auto">I'm not initially sure how/whether an exception clause could be written to allow binary inputs under some circumstances, without reducing the effectiveness of the definition (because, for example, copying an entirely opaque blob from one directory to another could be argued as within such a redefinition).</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">James</div><div dir="auto"></div></div>