incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: How to review so-called "binary releases"?
Date Wed, 14 Nov 2018 12:12:11 GMT
Myrle Krantz wrote on Wed, 14 Nov 2018 12:24 +0100:
> I had understood the reason that the foundation only officially supports
> source releases to be the fear of undetected malware in the release (like
> in the Ken Thompson hack).
> 
> Is that correct?  Are we all are in agreement that the probability of that
> kind of hack is very low?
> 
> I'd extend that by one step: Isn't the probably of that kind of hack
> *lower* if we compile our code ourselves, than if we ask our users to do it?

Yes, the problem with binary artifacts is that it's harder to audit them
to ensure they are not malicious.  (For source artifacts that is not a
problem because every change between successive source releases results
in a post-commit email and the PMC is assumed to review its commits@
mailing list.)  However, regarding Thompson's _Reflections on Trusting
Trust_ attack¹, that specific attack is not the primary concern here:
there's no need for a backdoor to be self-propagating in order to be of
concern to ASF.

The simple and immediate attack vector is for whoever generates binary
artifacts that end up on the dist/ tree — usually, the RM — to generate
them incorrectly, i.e., to build them not from the official source tree
but from a patched source tree.  (This can happen due to any number of
reasons: bug, malice, coercion…)  The concern is then:

    1. Given that it is possible for an RM to generate binary artifacts
    not from the official source, is it feasible for a PMC to review the
    binary artifacts to catch that?

    2. Suppose an RM generates malicious binary artifacts and uploads them
    to the dist/ tree, whence they are then downloaded.  Is ASF liable
    for the results?

The answer to (1) depends on the build platform and toolchain.
Reproducible builds [in the sense of "building the same source twice
gives bit-for-bit identical binaries"] can help with it.  When the
answer is negative, the next question is whether those unauditable
artifacts should be carried by ASF mirrors alongside the source
artifacts.

I don't know what the answer to (2) is.  IANAL.

Cheers,

Daniel

¹ Thompson postulates a self-propagating backdoor in a self-hosted compiler.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message