incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott O'Bryan <>
Subject Re: How to review so-called "binary releases"?
Date Wed, 14 Nov 2018 14:04:27 GMT
What about maven repos?  Are those by definition not generally binary releases?

Sent from my iPhone

> On Nov 14, 2018, at 5:12 AM, Daniel Shahaf <> wrote:
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message