<div dir="auto"><div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Jul 2, 2025, 09:39 Simon Josefsson <<a href="mailto:simon@josefsson.org">simon@josefsson.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">James Addison <<a href="mailto:jay@jp-hosting.net" target="_blank" rel="noreferrer">jay@jp-hosting.net</a>> writes:<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 ... ]<br>
><br>
><br>
> Does this refer to binary firmware specifically?<br>
<br>
I don't know.<br>
<br>
There are other corner cases: some existing binary debian packages where<br>
built using earlier versions of debian packages, and this recurse back<br>
to old versions of debian packages, some of them may have never even<br>
been in any official debian release.  Some necessary package may be<br>
ancient and removed even from <a href="http://archive.debian.org" rel="noreferrer noreferrer" target="_blank">archive.debian.org</a> and only exists on<br>
<a href="http://snapshot.debian.org" rel="noreferrer noreferrer" target="_blank">snapshot.debian.org</a>.  Both systems have policies in place to remove<br>
packages when various issues are identified (see<br>
<a href="https://snapshot.debian.org/removal/" rel="noreferrer noreferrer" target="_blank">https://snapshot.debian.org/removal/</a> for list), so these are known to<br>
not be complete historic records of what was ever published.  Some of<br>
those no longer public packages may be necessary to rebuild some old<br>
package that in turn through some chain of build dependency is needed to<br>
rebuild what we use today.<br>
<br>
I don't know if anyone did a transitive trace of what packages are<br>
necessary to rebuild all of modern Debian, does anyone know?  I know of<br>
<a href="https://rebuilder-snapshot.debian.net/" rel="noreferrer noreferrer" target="_blank">https://rebuilder-snapshot.debian.net/</a> which was an effort to publish<br>
all packages necessary to rebuild a 'stable' release, but it didn't<br>
include the transitive closure of that set of packages.<br>
<br>
This analysis needs to be done for each architecture too.  I fear even<br>
this analysis will be insufficient: when bootstrapping a new<br>
architecture, I think people historically have created fake packages<br>
used to boostrap things.  So you can't rely fully on the PACKAGE:VERSION<br>
to refer to the package that was actually used.<br>
<br>
Another problem is that the PACKAGE:VERSION mapping used by Debian<br>
packages does not easily or uniquely map to a strong cryptographic hash<br>
checksum of the original package binary.  You quickly need to rely on<br>
weak SHA1 identifiers, and I recall there has been multiple valid<br>
versions of the same binary (due to <a href="http://security.debian.org" rel="noreferrer noreferrer" target="_blank">security.debian.org</a> rebuilds or<br>
something like that).<br>
<br>
> I would hope that we could agree that building an artifact composed partly<br>
> or entirely from 100% DFSG binary packages that are themselves reproducible<br>
> would produce a transitively reproducible build.<br>
<br>
That depends on how you define "reproducible"...  I think most people<br>
here doesn't consider it required to rebuild the transitive closure of<br>
build dependencies to call something reproducible.  So in that case I<br>
don't think your statement is necessarily true.  Also consider the case<br>
with removed packages due to different DFSG interpretation (or<br>
definition) that changed over the years.<br>
<br>
> For closed-source binary firmware blobs, the situation does seem less<br>
> clear.  They arguably can be used as fixed inputs to a build to achieve<br>
> identical bit-for-bit output -- but if I understand correctly, it raises a<br>
> question of "is complete source code to all inputs required in order to<br>
> label/certify an artifact as reproducibly buildable?".<br>
<br>
Indeed.<br>
<br>
And if we don't have source code for object X, how can we tell that it<br>
is a firmware blob?  There is no simple way to know what it is, and some<br>
methods to establish what it is (disassembly) may be illegal.<br>
<br>
> I'm not initially sure how/whether an exception clause could be written to<br>
> allow binary inputs under some circumstances, without reducing the<br>
> effectiveness of the definition (because, for example, copying an entirely<br>
> opaque blob from one directory to another could be argued as within such a<br>
> redefinition).<br>
<br>
Agreed!  In my mind, there is a way out of that dilemma:<br>
<br>
1) One term, e.g., "recreatable", to cover the situation where you don't<br>
have source code for the transitive closure, and don't require<br>
rebuilding of that source code, of the set of build dependencies.  This<br>
leads to a degenerative build process of 'cp FOO BAR' to create a<br>
"recreatable" artifact.  The Debian LiveCD would fall into this<br>
category.<br>
<br>
2) Another term, e.g., "reproducible" to cover the situation where ALL<br>
source code for ALL build dependencies including their build<br>
dependencies, and so on, are available and used to recreate the<br>
bit-by-bit identical artifact.<br>
<br>
The problem is that many people seem to use the term "reproducible" to<br>
mean 1) today, so if we settle on these definitions, there will still be<br>
ambiguity unless everyone adopts the new definitions.<br>
<br>
There are at least two ways to reach 2) for an OS: bootstrappable builds<br>
or idempotent builds.  Guix show a bootstrappable build is feasible, I<br>
don't know anyone testing idempotent builds of any OS.<br>
<br>
/Simon<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Thank you - my initial feeling is that creating a similar parallel definition would be likely to divide contribution/community, and I feel skeptical and opposed to that.</div><div dir="auto"><br></div><div dir="auto">A stricter definition has the benefit that known deficiencies can be described and tracked like any other form of software bug.</div><div dir="auto"><br></div><div dir="auto">(I have realized that I have replied off-list and that my messages are pending moderation -- this is bad etiquette by me I think.  I will reply to this one message because I would like to participate, but then I'll probably pause)</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">James</div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div></div>