You don't need reproducible builds

[Morten Linderud]

On Sat, Aug 01, 2020 at 01:32:57PM -0400, Julien Lepiller wrote:
> Hi,
> 
> With a subject like that, I know I have your attention :). This is actually
> the title of a blog post I found on my social media, and I wanted to share in
> case you hadn't read it yet:
> 
> http://blog.cmpxchg8b.com/2020/07/you-dont-need-reproducible-builds.html?m=1
> 
> I think it is important to listen to criticism, as it will help us to better
> explain and educate about reproducible builds.
> 
> Thoughts on this?
> 
> Having met some of you at rb-summit in Paris, I know you're adorable people,
> but remember to be polite if you decide to comment on his blog. We don't want
> to sound like we're harassing people :)

The article misses the point, which is quite apparent when you read the
following section.

> Now if the vendor is compromised or becomes malicious, they can’t give the
> user any compromised binaries without also providing the source code. This
> ignores some complexities, like ensuring security updates are delivered even
> if one vendor is compromised, what to do if the reproducers stop working, or
> how to reach consensus if the reproducers and your vendor disagree on what
> software or fork you should be using.

Tavis only looks at reproducible builds from the standpoint of a proprietary
vendor. Which is obvious considering he works at Google. The section above
outlines that the vendor providing the binaries, also provides the source code.
But this is not the case for reproducible builds in the context of Linux
distributions, or Free and Open-Source software in general.

In our case (if I'm allowed to say that :p) the pristine source is separate from
the distributor of the binary, and you don't need to have the distributor
provide the source, you can fetch it yourself.

Tavis also includes the "god argument" of bugdoor, which Reproducible Builds
simply can't protect against, thus outside the scope of the project.


In short: It's a nice criticism of reproducible builds in the context of
proprietary vendors, but it doesn't hold up very well when we look at the Free
and Open-Source software communities.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20200801/a7517589/attachment.sig>