incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrle Krantz <>
Subject Re: How to review so-called "binary releases"?
Date Wed, 14 Nov 2018 11:24:36 GMT
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?

Best Regards,

On Wed, Nov 14, 2018 at 12:08 PM Mark Thomas <> wrote:

> 1. Dependencies with inappropriate licenses. Perhaps more likely with
> binary releases because they tend to ship with more dependencies but I
> don't recall this ever being more than "Whoops. Tell the users. Do a new
> release to fix it. Be more careful in future. Carry on." for either
> binary or source releases.
> 2. Copyright infringement. The only instance I can recall of this was a)
> related to a source release and b) invalid because the accusing party
> had actually originally copied "their" source from us and removed our
> license headers. If anything, I think issue is less likely with a binary
> release.
> 3. Download traffic. Some binaries are large and much more likely to
> cause infrastructure issues if the mirror network is not used correctly.
> Infra has monitoring in place to a) identify issues and b) stop them
> causing outages.
> So overall, the liability looks to be well within what we are already
> managing. I don't see anything that concerns me. Unless I have missed
> something.
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message