Introducing: Semantically reproducible builds

Mattia Rizzolo mattia at mapreri.org
Tue May 30 20:35:47 UTC 2023


Many people expressed their "concerns" about this concept, and I agree
with them that really this concept should not be encouraged too much.

Let me add an extra note to this part:

On Sun, May 28, 2023 at 11:15:10PM -0400, David A. Wheeler wrote:
> I'm primarily trying to deal with the case where the developer has decided
> to *not* provide a reproducible build, and I have to estimate the likelihood
> of it being maliciously built (presumably as a part of decideing whether or not
> the package is safe to install). I'm primarily thinking of
> applying this process to mostly-unmanaged repositories
> like npm, PyPI, and RubyGems, *not* to managed repositories like
> most Linux distributions' repositories.

IMHO, in any serious situation where you actually need to care about the
trust of the binaries you are running, you should actually be building
those yourself (of have them built by a trusted 3rd party).
In no possible way it makes any sense to trust a random binary you found
on pypi/npm/etc, so just stop even looking at those.


Furthermore (unrelated to r-b), when using Open Source stuff like that,
you should be grabbing the sources rather than the binaries anyway, and
keep all of them, as you probably also want to be able to path/rebuild
any piece of the chain that produced the final binary even in a future
time, when the original source might not be available anymore; meaning
that you should be rebuilding everything from the start anyway to make
sure that you are able to do so.
And that point you should just go for real, full, Reproducible Builds.

I know that this is not a common practice: I know of many places that
copy the binaries/source from pypi/npm, etc into a organization-local
repository (to prevent pulling unreviewed sources), but unfortunately
it's not so common to actually try to rebuild everything... which really
miss the point.


The only conceivable use case I have for what you describe is to
explicitly check what the developer is publishing, to identify whether
there is reasons to be believe that the developer is compromised (i.e.:
if he is publishing compromised binaries everything done by them should
be pulled out and scrutinized more), but not with the goal of actually
go and use their binaries.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
More about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
-------------- 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/20230530/5f04ca96/attachment.sig>


More information about the rb-general mailing list