You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by David Nalley <da...@gnsa.us> on 2018/11/06 22:06:50 UTC
Re: How to review so-called "binary releases"?
On Thu, Oct 25, 2018 at 9:39 PM Greg Stein <gs...@gmail.com> wrote:
>
> On Thu, Oct 25, 2018 at 12:25 PM Julian Hyde <jh...@apache.org> wrote:
>
> > Jim, you’re re-iterating the premise of my question. In the context of my
> > question, it doesn’t matter what these things are called. But we need to
> > know how reviewers are to handle them.
> >
> > Since I asked the original question, I have found the following policy[1]:
> >
> > > COMPILED PACKAGES
> > >
> > > The Apache Software Foundation produces open source software. All
> > > releases are in the form of the source materials needed to make
> > > changes to the software being released.
> > >
> > > As a convenience to users that might not have the appropriate tools to
> > > build a compiled version of the source, binary/bytecode packages MAY
> > > be distributed alongside official Apache releases. In all such cases, the
> > > binary/bytecode package MUST have the same version number as the
> > > source release and MUST only add binary/bytecode files that are the
> > > result of compiling that version of the source code release and its
> > > dependencies.
> >
> > This policy clarifies what these things may contain. I still need
> > clarification on what is the responsibility of a reviewer.
>
>
> It has been repeated several times already. There is no such thing as
> "reviewer" since these are not official releases. So they certainly
> shouldn't be voted upon. They are just some binaries hanging out on our
> server.
>
> I propose:
> >
> > 1. Reviewers have no way to verify the contents of the binaries and
> > therefore they have to trust that the release manager has built them
> > according to the documented release process.
> >
>
> And this is exactly why they are unofficial.
>
> -g
Playing devil's advocate for a moment, and primarily picking on Greg
since he won't take it personally and hopefully will indulge me. :)
So let's assume a PMC (or PPMC) goes through the same process with
binaries in terms of reviewing, voting on, promoting, and publishing
to the world a binary release on behalf of the PMC and Foundation.
Binaries are published to the same location that source tar balls are
- are featured on download pages provided by the ASF. Perhaps even
with the situation being that people download the binary artifacts
from ASF resources tens of thousands, or maybe even millions of times
more frequently than the source tarballs.
From that scenario I have some questions:
1. Would a reasonable person (or jury) suspend disbelief long enough
to consider our protestations that our 'releases' are source only, and
that as a Foundation we didn't release, propagate, promote, or
distribute the binaries in question? A rose by any other name.....
2. Should the Board be taking an active interest in projects (release
managers?) who promote and publish their binaries in this manner on
our hardware?
3. Is lack of Board action tantamount to tacit approval of this
behavior? Can we really claim ignorance?
4. Should Infrastructure be actively monitoring and removing binaries
which find their way to dist.a.o/archive.a.o - especially since our
header for dist.a.o says that the directories contain releases of
Apache software?
5. Should we be alerting individual release managers that publishing
convenience binaries exposes them individually to liability?
To my mind, allowing projects to distribute 'convenience binaries'
from our hardware, in a place we say contains releases, and which is
occasionally consumed in such a way as to dwarf what we call official
releases[1], makes them actions of the Foundation despite our
protestations. Even more so since we haven't claimed DMCA Safe Harbor
protections as a hosting provider rather than as an entity that
publishes its own content.
--David
[1] Cassandra mistakenly pointed people to a binary deb repo that was
running on our TLP boxes - the traffic to that deb repo was
responsible for 15% of the total bandwidth consumed by the Foundation
for the month or so that it ran in that fashion. No small feat.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by David Nalley <da...@gnsa.us>.
On Wed, Nov 14, 2018 at 11:32 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
<snip>
>
> I think Jim and Greg were describing theory, not practice. We can shout
> from the rooftops that We Do Not Release Binaries, but then you have
> download pages like [1] that present binary artifacts on equal footing
> with source artifacts, without even paying lip service by including the
> term "convenience" somewhere.
>
> The PMC in [1] _is_ releasing binaries as official artifacts — possibly
> in contravention of Board policy, but that's neither here nor there:
> users who visit download pages are not expected to know Board policies.
> A user who visits [1] _will_ consider the binary artifacts official,
> because they are presented as such.
>
> If that's an undesirable outcome, then the Board should enforce its
> policy that download pages aren't to present binaries as official
> artifacts. (Which, I think, is what David was getting at.)
>
<snip>
> [1] <http://redacted.apache.org/download.html>. (I won't name and
> shame, sorry. Could someone volunteer his own PMC's download page for
> a case study? I would volunteer Subversion but I think our download
> page is compliant.)
>
Yes, we can say they aren't official, but that denies the reality of
what projects are doing, and how the foundation celebrates them[1].
We also have multiple projects producing binaries, and signing those
binaries with the ASF's code signing keys[2] which we had to jump
through a lot of hoops to verify our identity as being the real Apache
Software Foundation. We have another project about to use the ASF's
corporate Apple Developer account to 'notarize' releases so they are
identified as originating from the ASF.[3]
IMO, we can label them as 'not releases' and put stickers on that say
'unofficial' but the reality is that we are distributing terabytes of
binaries every day from Foundation resources, occasionally even
stamping them with our official signing certificates, and that should
dispel any illusions we have about those not being actions of the
Foundation.
In my opinion as a single IPMC member (and only wearing that
particular hat), if your podling is shipping binaries, you should
review and vote on them. To ignore them seems irresponsible.
--David
[1] https://www.cnbc.com/2014/04/17/globe-newswire-the-apache-software-foundation-announces-100-million-downloads-of-apachetm-openofficetm.html
in which we issue a press release to celebrate that individuals all
over the world downloaded 100 million copies of a binary
"non-release".
[2] https://blogs.apache.org/infra/entry/code_signing_service_now_available
[3] https://lists.apache.org/thread.html/15ef4c390c6eba7ca80836c214b1121681310d44fe79b32f175aedc3@%3Cprivate.openoffice.apache.org%3E
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Hyde wrote on Wed, Nov 14, 2018 at 11:33:55 -0800:
> The question with which I started this discussion has not been
> answered. Given that a collection of artifacts is up for a vote, and
> those artifacts are a mixture of source and binary artifacts, what is
> a reviewer to do:
>
> 1. Vote -1. The release contains binaries.
>
I'd vote -1 on the binary artifacts only, since I can't review/audit
them, and vote on the source artifacts on their own merits.
> 2. Perform some cursory checks on the binaries (e.g. L&N) and vote accordingly.
>
> 3. Ignore the binaries. Vote only based on the source artifacts, but
> allow the binary artifacts to appear alongside them in
> https://www.apache.org/dist/ (and other places such as Maven Central).
>
> Current policy, for both the incubator and many other projects, seems
> to be 3. Yet this seems to me to contradict statements by Jim and Greg
> that we only produce source releases.
>
I think Jim and Greg were describing theory, not practice. We can shout
from the rooftops that We Do Not Release Binaries, but then you have
download pages like [1] that present binary artifacts on equal footing
with source artifacts, without even paying lip service by including the
term "convenience" somewhere.
The PMC in [1] _is_ releasing binaries as official artifacts — possibly
in contravention of Board policy, but that's neither here nor there:
users who visit download pages are not expected to know Board policies.
A user who visits [1] _will_ consider the binary artifacts official,
because they are presented as such.
If that's an undesirable outcome, then the Board should enforce its
policy that download pages aren't to present binaries as official
artifacts. (Which, I think, is what David was getting at.)
> My favorite is 2. It reflects reality - we DO release binary artifacts
> along with releases, we have to trust the release manager to have not
> compromised the binaries during the build process, but reviewers can
> help by running cursory checks.
Cheers,
Daniel
[1] <http://redacted.apache.org/download.html>. (I won't name and
shame, sorry. Could someone volunteer his own PMC's download page for
a case study? I would volunteer Subversion but I think our download
page is compliant.)
> I would like to achieve clarity by voting on the 3 alternatives above
> (plus any other alternatives people would like to propose).
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Myrle Krantz wrote on Wed, Nov 14, 2018 at 17:19:35 +0100:
> On Wed, Nov 14, 2018 at 1:12 PM Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
>
> > 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.
> >
>
> So if a project puts in the effort to
> a.) make their build reproducible (which can actually be very difficult to
> do), and
> b.) do a bit-for bid compare on a release across at least two build
> artifacts, created by different people on different machines...
>
> ...would we be willing to see that threat as sufficiently eliminated for
> our purposes? Would we then be willing to "officially" release binaries?
I would say yes.
I would further note that this is a *sufficient* condition, not a
necessary one. Often, binaries are _nearly_ reproducible but not _bit
for bit_ reproducible — for example, they might contain a date in the
RM's timezone, or the RM's uname(1) output, etc. Such differences are
auditable, and it would be reasonable for a PMC member to compare the
proposed binary artifact to one he built locally, see that the
differences are acceptable, and vote +1 on the binary artifact — just
like we do for source artifacts (when we compare tarballs to tags).
Cheers,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Wade Chandler <wa...@apache.org>.
IMO something real is missing from this whole conversation.
Does the ASF want to have successful projects? Honest question time. Would Tomcat have been successful if there had been source only downloads with no “official" runnable software? Were all those users for all those years compiling their own? No. They downloaded clearly official binaries. Does this page tomcat.apache.org tell an internet wonderer BEWARE…the binaries are not official? What about this one https://tomcat.apache.org/download-90.cgi … pretty sure the sources are the last thing on the page.
Was Maven successful because everyone built it? No. They downloaded what is clearly considered “official” binaries. This site http://maven.apache.org … what does it point out…unofficial binaries? No…download, install, run.
NetBeans…not going to make it here on “unofficial" binary releases funny business. What company wants someone installing that on their system? Security policies anyone? Sorry, just the truth.
httpd benefited from Linux distros binary distribution in this sense of releases as source, but if everyone had to “build” their httpd servers, it would not have been the success it has been; I think it is irrefutable. It’s success was not based on a bunch of admins who are not software engineers building it, nor was it built on web developers building C binaries; some of us maybe building ISAPI and NSAPI modules; that’s been a bit.
This whole conversation is missing a crucial point, and it is does Apache want to continue to be successful? And, do folks really understand how it has been successful to date? It wasn’t just those of us who contribute code. It was also people using that code, and most of those folks did not compile it.
Read this whole thread to this point. Does it even make sense? Is there a clear answer? It is just as confusing to this point as when the question was asked.
It is still a bunch of indirect dancing around of how the users need binaries, but some language needs to be there to make sure they (users) understand it is unofficial, and not really from Apache like the source code, but some how “convenience” from “some magic place". It leaves off the one point that really matters in the end; users using software makes successful projects and brings and retains donations; simple calculation. Do people use untrusted software? Not in commercial settings. I think this is exactly why “binary releases are NOT endorsed by ASF” will not fly very far.
There is a lot of time and resources wrapped up in these type conversations as well as Apache projects. Real clear guidance seems a must, and it has to be “real” and honest about what the decision means for successful projects.
Thank you,
Wade
> On Nov 13, 2018, at 3:49 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> Personally, given the amount of binary releases that are distributed off of
> our very own infrastructure (and I'm not even counting our namespace
> on things like Docker hub -- I'm just talking about the INFRA we run) I don't
> think that the argument "binary releases are NOT endorsed by ASF" will
> fly very far.
>
> I think the best defense for us is to, perhaps, position them as UGC, but
> given the practices around existing PMC I don't think that would be easy to
> do.
>
> So the question really boils down to -- how much of a liability this could
> potentially be for us?
>
>
> Thanks,
> Roman.
> On Tue, Nov 6, 2018 at 4:55 PM Daniel Shahaf <d.s@daniel.shahaf.name <ma...@daniel.shahaf.name>> wrote:
>>
>> CC += legal-discuss@ since this really isn't an incubator-specific topic any
>> more. The context is precompiled binary artifacts on
>> https://www.apache.org/dist/.
>>
>> David Nalley wrote on Tue, Nov 06, 2018 at 17:06:50 -0500:
>>> So let's assume a PMC (or PPMC) goes through the same process with
>>> binaries in terms of reviewing, voting on, promoting, and publishing
>>> to the world a binary release on behalf of the PMC and Foundation.
>>> Binaries are published to the same location that source tar balls are
>>> - are featured on download pages provided by the ASF. Perhaps even
>>> with the situation being that people download the binary artifacts
>>> from ASF resources tens of thousands, or maybe even millions of times
>>> more frequently than the source tarballs.
>>>
>>> From that scenario I have some questions:
>>>
>>> 1. Would a reasonable person (or jury) suspend disbelief long enough
>>> to consider our protestations that our 'releases' are source only, and
>>> that as a Foundation we didn't release, propagate, promote, or
>>> distribute the binaries in question? A rose by any other name.....
>>> 2. Should the Board be taking an active interest in projects (release
>>> managers?) who promote and publish their binaries in this manner on
>>> our hardware?
>>> 3. Is lack of Board action tantamount to tacit approval of this
>>> behavior? Can we really claim ignorance?
>>> 4. Should Infrastructure be actively monitoring and removing binaries
>>> which find their way to dist.a.o/archive.a.o - especially since our
>>> header for dist.a.o says that the directories contain releases of
>>> Apache software?
>>> 5. Should we be alerting individual release managers that publishing
>>> convenience binaries exposes them individually to liability?
>>
>> 6. What alternative can we offer to projects that want to distribute binaries?
>> Can the RM upload precompiled binaries to his https://home.a.o/~availid/ space?
>> Can the project's download page link to them as the
>> primary/canonical/recommended binaries? Can the project's download page link
>> to the RM's binaries as one alternative among many (compare
>> https://subversion.apache.org/packages#windows)?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
>> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org <ma...@apache.org>
> For additional commands, e-mail: legal-discuss-help@apache.org <ma...@apache.org>
Re: How to review so-called "binary releases"?
Posted by Julian Hyde <jh...@apache.org>.
+1 to everything Mark Thomas said.
On Wed, Nov 14, 2018 at 3:08 AM Mark Thomas <ma...@apache.org> wrote:
>
> On 13/11/2018 20:49, Roman Shaposhnik wrote:
> > Personally, given the amount of binary releases that are distributed off of
> > our very own infrastructure (and I'm not even counting our namespace
> > on things like Docker hub -- I'm just talking about the INFRA we run) I don't
> > think that the argument "binary releases are NOT endorsed by ASF" will
> > fly very far.
> >
> > I think the best defense for us is to, perhaps, position them as UGC, but
> > given the practices around existing PMC I don't think that would be easy to
> > do.
> >
> > So the question really boils down to -- how much of a liability this could
> > potentially be for us?
>
> Applying the usual test of "What issues have we seen in the last 20
> years?" I can't think of any that have been specific to a binary release.
>
> Of the issues I can recall with releases since I have been involved at
> the ASF (and I'm sketchy on the details because issues are few and far
> between and I haven't gone looking in the archives):
>
> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Dave Fisher <da...@comcast.net>.
Hi -
Sent from my iPhone
> On Nov 14, 2018, at 11:33 AM, Julian Hyde <jh...@apache.org> wrote:
>
> The question with which I started this discussion has not been
> answered. Given that a collection of artifacts is up for a vote, and
> those artifacts are a mixture of source and binary artifacts, what is
> a reviewer to do:
>
> 1. Vote -1. The release contains binaries.
>
> 2. Perform some cursory checks on the binaries (e.g. L&N) and vote accordingly.
This is what I do. I’ll build too, but that may not always work on my environment.
Regards,
Dave
>
> 3. Ignore the binaries. Vote only based on the source artifacts, but
> allow the binary artifacts to appear alongside them in
> https://www.apache.org/dist/ (and other places such as Maven Central).
>
> Current policy, for both the incubator and many other projects, seems
> to be 3. Yet this seems to me to contradict statements by Jim and Greg
> that we only produce source releases.
>
> My favorite is 2. It reflects reality - we DO release binary artifacts
> along with releases, we have to trust the release manager to have not
> compromised the binaries during the build process, but reviewers can
> help by running cursory checks.
>
> I would like to achieve clarity by voting on the 3 alternatives above
> (plus any other alternatives people would like to propose).
>
> Julian
>> On Wed, Nov 14, 2018 at 8:19 AM Myrle Krantz <my...@apache.org> wrote:
>>
>> On Wed, Nov 14, 2018 at 1:12 PM Daniel Shahaf <d....@daniel.shahaf.name>
>> wrote:
>>
>>> 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.
>>>
>>
>> So if a project puts in the effort to
>> a.) make their build reproducible (which can actually be very difficult to
>> do), and
>> b.) do a bit-for bid compare on a release across at least two build
>> artifacts, created by different people on different machines...
>>
>> ...would we be willing to see that threat as sufficiently eliminated for
>> our purposes? Would we then be willing to "officially" release binaries?
>>
>> Best Regards,
>> Myrle
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Julian Hyde <jh...@apache.org>.
The question with which I started this discussion has not been
answered. Given that a collection of artifacts is up for a vote, and
those artifacts are a mixture of source and binary artifacts, what is
a reviewer to do:
1. Vote -1. The release contains binaries.
2. Perform some cursory checks on the binaries (e.g. L&N) and vote accordingly.
3. Ignore the binaries. Vote only based on the source artifacts, but
allow the binary artifacts to appear alongside them in
https://www.apache.org/dist/ (and other places such as Maven Central).
Current policy, for both the incubator and many other projects, seems
to be 3. Yet this seems to me to contradict statements by Jim and Greg
that we only produce source releases.
My favorite is 2. It reflects reality - we DO release binary artifacts
along with releases, we have to trust the release manager to have not
compromised the binaries during the build process, but reviewers can
help by running cursory checks.
I would like to achieve clarity by voting on the 3 alternatives above
(plus any other alternatives people would like to propose).
Julian
On Wed, Nov 14, 2018 at 8:19 AM Myrle Krantz <my...@apache.org> wrote:
>
> On Wed, Nov 14, 2018 at 1:12 PM Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
>
> > 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.
> >
>
> So if a project puts in the effort to
> a.) make their build reproducible (which can actually be very difficult to
> do), and
> b.) do a bit-for bid compare on a release across at least two build
> artifacts, created by different people on different machines...
>
> ...would we be willing to see that threat as sufficiently eliminated for
> our purposes? Would we then be willing to "officially" release binaries?
>
> Best Regards,
> Myrle
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Myrle Krantz <my...@apache.org>.
On Wed, Nov 14, 2018 at 1:12 PM Daniel Shahaf <d....@daniel.shahaf.name>
wrote:
> 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.
>
So if a project puts in the effort to
a.) make their build reproducible (which can actually be very difficult to
do), and
b.) do a bit-for bid compare on a release across at least two build
artifacts, created by different people on different machines...
...would we be willing to see that threat as sufficiently eliminated for
our purposes? Would we then be willing to "officially" release binaries?
Best Regards,
Myrle
Re: How to review so-called "binary releases"?
Posted by Scott O'Bryan <da...@gmail.com>.
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 <d....@daniel.shahaf.name> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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
Re: How to review so-called "binary releases"?
Posted by Jim Jagielski <ji...@jaguNET.com>.
The reason we "only officially" support source code releases is because that is what we produce.
> On Nov 14, 2018, at 6:24 AM, Myrle Krantz <my...@apache.org> wrote:
>
> 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,
> Myrle
>
> On Wed, Nov 14, 2018 at 12:08 PM Mark Thomas <ma...@apache.org> 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: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Myrle Krantz <my...@apache.org>.
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,
Myrle
On Wed, Nov 14, 2018 at 12:08 PM Mark Thomas <ma...@apache.org> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: How to review so-called "binary releases"?
Posted by Mark Thomas <ma...@apache.org>.
On 13/11/2018 20:49, Roman Shaposhnik wrote:
> Personally, given the amount of binary releases that are distributed off of
> our very own infrastructure (and I'm not even counting our namespace
> on things like Docker hub -- I'm just talking about the INFRA we run) I don't
> think that the argument "binary releases are NOT endorsed by ASF" will
> fly very far.
>
> I think the best defense for us is to, perhaps, position them as UGC, but
> given the practices around existing PMC I don't think that would be easy to
> do.
>
> So the question really boils down to -- how much of a liability this could
> potentially be for us?
Applying the usual test of "What issues have we seen in the last 20
years?" I can't think of any that have been specific to a binary release.
Of the issues I can recall with releases since I have been involved at
the ASF (and I'm sketchy on the details because issues are few and far
between and I haven't gone looking in the archives):
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Wade Chandler <wa...@apache.org>.
IMO something real is missing from this whole conversation.
Does the ASF want to have successful projects? Honest question time. Would Tomcat have been successful if there had been source only downloads with no “official" runnable software? Were all those users for all those years compiling their own? No. They downloaded clearly official binaries. Does this page tomcat.apache.org tell an internet wonderer BEWARE…the binaries are not official? What about this one https://tomcat.apache.org/download-90.cgi … pretty sure the sources are the last thing on the page.
Was Maven successful because everyone built it? No. They downloaded what is clearly considered “official” binaries. This site http://maven.apache.org … what does it point out…unofficial binaries? No…download, install, run.
NetBeans…not going to make it here on “unofficial" binary releases funny business. What company wants someone installing that on their system? Security policies anyone? Sorry, just the truth.
httpd benefited from Linux distros binary distribution in this sense of releases as source, but if everyone had to “build” their httpd servers, it would not have been the success it has been; I think it is irrefutable. It’s success was not based on a bunch of admins who are not software engineers building it, nor was it built on web developers building C binaries; some of us maybe building ISAPI and NSAPI modules; that’s been a bit.
This whole conversation is missing a crucial point, and it is does Apache want to continue to be successful? And, do folks really understand how it has been successful to date? It wasn’t just those of us who contribute code. It was also people using that code, and most of those folks did not compile it.
Read this whole thread to this point. Does it even make sense? Is there a clear answer? It is just as confusing to this point as when the question was asked.
It is still a bunch of indirect dancing around of how the users need binaries, but some language needs to be there to make sure they (users) understand it is unofficial, and not really from Apache like the source code, but some how “convenience” from “some magic place". It leaves off the one point that really matters in the end; users using software makes successful projects and brings and retains donations; simple calculation. Do people use untrusted software? Not in commercial settings. I think this is exactly why “binary releases are NOT endorsed by ASF” will not fly very far.
There is a lot of time and resources wrapped up in these type conversations as well as Apache projects. Real clear guidance seems a must, and it has to be “real” and honest about what the decision means for successful projects.
Thank you,
Wade
> On Nov 13, 2018, at 3:49 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> Personally, given the amount of binary releases that are distributed off of
> our very own infrastructure (and I'm not even counting our namespace
> on things like Docker hub -- I'm just talking about the INFRA we run) I don't
> think that the argument "binary releases are NOT endorsed by ASF" will
> fly very far.
>
> I think the best defense for us is to, perhaps, position them as UGC, but
> given the practices around existing PMC I don't think that would be easy to
> do.
>
> So the question really boils down to -- how much of a liability this could
> potentially be for us?
>
>
> Thanks,
> Roman.
> On Tue, Nov 6, 2018 at 4:55 PM Daniel Shahaf <d.s@daniel.shahaf.name <ma...@daniel.shahaf.name>> wrote:
>>
>> CC += legal-discuss@ since this really isn't an incubator-specific topic any
>> more. The context is precompiled binary artifacts on
>> https://www.apache.org/dist/.
>>
>> David Nalley wrote on Tue, Nov 06, 2018 at 17:06:50 -0500:
>>> So let's assume a PMC (or PPMC) goes through the same process with
>>> binaries in terms of reviewing, voting on, promoting, and publishing
>>> to the world a binary release on behalf of the PMC and Foundation.
>>> Binaries are published to the same location that source tar balls are
>>> - are featured on download pages provided by the ASF. Perhaps even
>>> with the situation being that people download the binary artifacts
>>> from ASF resources tens of thousands, or maybe even millions of times
>>> more frequently than the source tarballs.
>>>
>>> From that scenario I have some questions:
>>>
>>> 1. Would a reasonable person (or jury) suspend disbelief long enough
>>> to consider our protestations that our 'releases' are source only, and
>>> that as a Foundation we didn't release, propagate, promote, or
>>> distribute the binaries in question? A rose by any other name.....
>>> 2. Should the Board be taking an active interest in projects (release
>>> managers?) who promote and publish their binaries in this manner on
>>> our hardware?
>>> 3. Is lack of Board action tantamount to tacit approval of this
>>> behavior? Can we really claim ignorance?
>>> 4. Should Infrastructure be actively monitoring and removing binaries
>>> which find their way to dist.a.o/archive.a.o - especially since our
>>> header for dist.a.o says that the directories contain releases of
>>> Apache software?
>>> 5. Should we be alerting individual release managers that publishing
>>> convenience binaries exposes them individually to liability?
>>
>> 6. What alternative can we offer to projects that want to distribute binaries?
>> Can the RM upload precompiled binaries to his https://home.a.o/~availid/ space?
>> Can the project's download page link to them as the
>> primary/canonical/recommended binaries? Can the project's download page link
>> to the RM's binaries as one alternative among many (compare
>> https://subversion.apache.org/packages#windows)?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
>> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org <ma...@apache.org>
> For additional commands, e-mail: legal-discuss-help@apache.org <ma...@apache.org>
Re: How to review so-called "binary releases"?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
Personally, given the amount of binary releases that are distributed off of
our very own infrastructure (and I'm not even counting our namespace
on things like Docker hub -- I'm just talking about the INFRA we run) I don't
think that the argument "binary releases are NOT endorsed by ASF" will
fly very far.
I think the best defense for us is to, perhaps, position them as UGC, but
given the practices around existing PMC I don't think that would be easy to
do.
So the question really boils down to -- how much of a liability this could
potentially be for us?
Thanks,
Roman.
On Tue, Nov 6, 2018 at 4:55 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> CC += legal-discuss@ since this really isn't an incubator-specific topic any
> more. The context is precompiled binary artifacts on
> https://www.apache.org/dist/.
>
> David Nalley wrote on Tue, Nov 06, 2018 at 17:06:50 -0500:
> > So let's assume a PMC (or PPMC) goes through the same process with
> > binaries in terms of reviewing, voting on, promoting, and publishing
> > to the world a binary release on behalf of the PMC and Foundation.
> > Binaries are published to the same location that source tar balls are
> > - are featured on download pages provided by the ASF. Perhaps even
> > with the situation being that people download the binary artifacts
> > from ASF resources tens of thousands, or maybe even millions of times
> > more frequently than the source tarballs.
> >
> > From that scenario I have some questions:
> >
> > 1. Would a reasonable person (or jury) suspend disbelief long enough
> > to consider our protestations that our 'releases' are source only, and
> > that as a Foundation we didn't release, propagate, promote, or
> > distribute the binaries in question? A rose by any other name.....
> > 2. Should the Board be taking an active interest in projects (release
> > managers?) who promote and publish their binaries in this manner on
> > our hardware?
> > 3. Is lack of Board action tantamount to tacit approval of this
> > behavior? Can we really claim ignorance?
> > 4. Should Infrastructure be actively monitoring and removing binaries
> > which find their way to dist.a.o/archive.a.o - especially since our
> > header for dist.a.o says that the directories contain releases of
> > Apache software?
> > 5. Should we be alerting individual release managers that publishing
> > convenience binaries exposes them individually to liability?
>
> 6. What alternative can we offer to projects that want to distribute binaries?
> Can the RM upload precompiled binaries to his https://home.a.o/~availid/ space?
> Can the project's download page link to them as the
> primary/canonical/recommended binaries? Can the project's download page link
> to the RM's binaries as one alternative among many (compare
> https://subversion.apache.org/packages#windows)?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> but I just wanted to highlight that we don't have to restrict our reviews to what is legally needed.
Which is the same for source releases i.e. to vote +1 on a release it just has to compile, but tests could still be failing and/or it could not work. With most of the incubator release I vote on I don’t test that it works only that it compiles, I assume the PPMC has done the other bits.
Thanks,
Justin
Re: How to review so-called "binary releases"?
Posted by Cédric Champeau <ce...@gmail.com>.
While officially binaries are only convenience, it happened several times
with Groovy that we downvote a release _because_ of broken binaries. So we
integrate them as part of our review process. Basically, we do the usual
checks on sources (checksums, signatures, build, ...), but we _also_ check
that the convenience binaries work. That means, unzip, try to run the app,
play with it, ... Most of this process is automated during the build, there
are still a few quirks because of cross-platform testing, but I just wanted
to highlight that we don't have to restrict our reviews to what is legally
needed.
Le mer. 7 nov. 2018 à 01:55, Daniel Shahaf <d....@daniel.shahaf.name> a
écrit :
> CC += legal-discuss@ since this really isn't an incubator-specific topic
> any
> more. The context is precompiled binary artifacts on
> https://www.apache.org/dist/.
>
> David Nalley wrote on Tue, Nov 06, 2018 at 17:06:50 -0500:
> > So let's assume a PMC (or PPMC) goes through the same process with
> > binaries in terms of reviewing, voting on, promoting, and publishing
> > to the world a binary release on behalf of the PMC and Foundation.
> > Binaries are published to the same location that source tar balls are
> > - are featured on download pages provided by the ASF. Perhaps even
> > with the situation being that people download the binary artifacts
> > from ASF resources tens of thousands, or maybe even millions of times
> > more frequently than the source tarballs.
> >
> > From that scenario I have some questions:
> >
> > 1. Would a reasonable person (or jury) suspend disbelief long enough
> > to consider our protestations that our 'releases' are source only, and
> > that as a Foundation we didn't release, propagate, promote, or
> > distribute the binaries in question? A rose by any other name.....
> > 2. Should the Board be taking an active interest in projects (release
> > managers?) who promote and publish their binaries in this manner on
> > our hardware?
> > 3. Is lack of Board action tantamount to tacit approval of this
> > behavior? Can we really claim ignorance?
> > 4. Should Infrastructure be actively monitoring and removing binaries
> > which find their way to dist.a.o/archive.a.o - especially since our
> > header for dist.a.o says that the directories contain releases of
> > Apache software?
> > 5. Should we be alerting individual release managers that publishing
> > convenience binaries exposes them individually to liability?
>
> 6. What alternative can we offer to projects that want to distribute
> binaries?
> Can the RM upload precompiled binaries to his https://home.a.o/~availid/
> space?
> Can the project's download page link to them as the
> primary/canonical/recommended binaries? Can the project's download page
> link
> to the RM's binaries as one alternative among many (compare
> https://subversion.apache.org/packages#windows)?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: How to review so-called "binary releases"?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
Personally, given the amount of binary releases that are distributed off of
our very own infrastructure (and I'm not even counting our namespace
on things like Docker hub -- I'm just talking about the INFRA we run) I don't
think that the argument "binary releases are NOT endorsed by ASF" will
fly very far.
I think the best defense for us is to, perhaps, position them as UGC, but
given the practices around existing PMC I don't think that would be easy to
do.
So the question really boils down to -- how much of a liability this could
potentially be for us?
Thanks,
Roman.
On Tue, Nov 6, 2018 at 4:55 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> CC += legal-discuss@ since this really isn't an incubator-specific topic any
> more. The context is precompiled binary artifacts on
> https://www.apache.org/dist/.
>
> David Nalley wrote on Tue, Nov 06, 2018 at 17:06:50 -0500:
> > So let's assume a PMC (or PPMC) goes through the same process with
> > binaries in terms of reviewing, voting on, promoting, and publishing
> > to the world a binary release on behalf of the PMC and Foundation.
> > Binaries are published to the same location that source tar balls are
> > - are featured on download pages provided by the ASF. Perhaps even
> > with the situation being that people download the binary artifacts
> > from ASF resources tens of thousands, or maybe even millions of times
> > more frequently than the source tarballs.
> >
> > From that scenario I have some questions:
> >
> > 1. Would a reasonable person (or jury) suspend disbelief long enough
> > to consider our protestations that our 'releases' are source only, and
> > that as a Foundation we didn't release, propagate, promote, or
> > distribute the binaries in question? A rose by any other name.....
> > 2. Should the Board be taking an active interest in projects (release
> > managers?) who promote and publish their binaries in this manner on
> > our hardware?
> > 3. Is lack of Board action tantamount to tacit approval of this
> > behavior? Can we really claim ignorance?
> > 4. Should Infrastructure be actively monitoring and removing binaries
> > which find their way to dist.a.o/archive.a.o - especially since our
> > header for dist.a.o says that the directories contain releases of
> > Apache software?
> > 5. Should we be alerting individual release managers that publishing
> > convenience binaries exposes them individually to liability?
>
> 6. What alternative can we offer to projects that want to distribute binaries?
> Can the RM upload precompiled binaries to his https://home.a.o/~availid/ space?
> Can the project's download page link to them as the
> primary/canonical/recommended binaries? Can the project's download page link
> to the RM's binaries as one alternative among many (compare
> https://subversion.apache.org/packages#windows)?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
CC += legal-discuss@ since this really isn't an incubator-specific topic any
more. The context is precompiled binary artifacts on
https://www.apache.org/dist/.
David Nalley wrote on Tue, Nov 06, 2018 at 17:06:50 -0500:
> So let's assume a PMC (or PPMC) goes through the same process with
> binaries in terms of reviewing, voting on, promoting, and publishing
> to the world a binary release on behalf of the PMC and Foundation.
> Binaries are published to the same location that source tar balls are
> - are featured on download pages provided by the ASF. Perhaps even
> with the situation being that people download the binary artifacts
> from ASF resources tens of thousands, or maybe even millions of times
> more frequently than the source tarballs.
>
> From that scenario I have some questions:
>
> 1. Would a reasonable person (or jury) suspend disbelief long enough
> to consider our protestations that our 'releases' are source only, and
> that as a Foundation we didn't release, propagate, promote, or
> distribute the binaries in question? A rose by any other name.....
> 2. Should the Board be taking an active interest in projects (release
> managers?) who promote and publish their binaries in this manner on
> our hardware?
> 3. Is lack of Board action tantamount to tacit approval of this
> behavior? Can we really claim ignorance?
> 4. Should Infrastructure be actively monitoring and removing binaries
> which find their way to dist.a.o/archive.a.o - especially since our
> header for dist.a.o says that the directories contain releases of
> Apache software?
> 5. Should we be alerting individual release managers that publishing
> convenience binaries exposes them individually to liability?
6. What alternative can we offer to projects that want to distribute binaries?
Can the RM upload precompiled binaries to his https://home.a.o/~availid/ space?
Can the project's download page link to them as the
primary/canonical/recommended binaries? Can the project's download page link
to the RM's binaries as one alternative among many (compare
https://subversion.apache.org/packages#windows)?
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Carlos Santana <cs...@gmail.com>.
The Jim we are in strongly agreement then :-)
Willem
Yes I think that’s the word “DISCLAIMER”, was the concept and idea I was describing.
I think it depends on the binary (ie npm tgz, jar, docker image, dll, executable) and location (website, sftp, maven, npm registry, nuget, etc) on where to put this. Up to each community what’s the best was to make user downloading aware that this DISCLAIMER exist.
- Carlos Santana
@csantanapr
> On Nov 7, 2018, at 8:10 PM, Willem Jiang <wi...@gmail.com> wrote:
>
> DISCLAIMER
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Willem Jiang <wi...@gmail.com>.
If the binary release is not the official releases, we need to let
people know about it. Adding the DISCLAIMER could help us with that.
For the other binary release such as Maven release, Docker release
how can we introduce the DISCLAIMER for it?
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Wed, Nov 7, 2018 at 11:59 PM Jim Jagielski <ji...@jagunet.com> wrote:
>
> IMO, that was (and in many cases) still IS a Good Thing... the issue is that it must be made clear that what the ASF releases are source code artifacts. Any binary releases that are done are not official releases of the foundation nor the PMC, but are community provided conveniences.
>
> > On Nov 7, 2018, at 8:14 AM, Carlos Santana <cs...@gmail.com> wrote:
> >
> > Jim
> >
> > What do you think now?
> > Was that a good or bad thing?
> >
> > TLDR; I’m in favor of convenient binaries is just the how they are handled.
> >
> > Sorry for my brevity, what I meant is that binaries should not be beside next to the source release seating on the same server and giving the same guarantees for both type of artifacts (source vs binary).
> >
> > Now in terms of convenience :-)
> > ASF should not block a project of making binaries available to their community for what ever purpose they think appropriate (ie nightly, binary of a RC, binary of final RC)
> >
> > ASF should provide guidance to the projects to make sure they make their communities aware that a source artifact is different from a binary artifact.
> > A project for example can put warnings and bold text on the location (ie directory, readme, inside the binary, download webpage, wiki etc) where the community downloads a copy of the binary.
> > The warning can say this is not a release of the ASF, is just a convenient binary “download on your own risk”, we provide sha256 sum and maybe the binary is even signed, but best practice is for you to download the source and be in control of building the binary.
> >
> >
> >
> > - Carlos Santana
> > @csantanapr
> >
> >> On Nov 7, 2018, at 7:04 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
> >>
> >> Just a FYI that in the early days of the ASF (and the httpd project), community binaries were a common offering...
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Jim Jagielski <ji...@jaguNET.com>.
IMO, that was (and in many cases) still IS a Good Thing... the issue is that it must be made clear that what the ASF releases are source code artifacts. Any binary releases that are done are not official releases of the foundation nor the PMC, but are community provided conveniences.
> On Nov 7, 2018, at 8:14 AM, Carlos Santana <cs...@gmail.com> wrote:
>
> Jim
>
> What do you think now?
> Was that a good or bad thing?
>
> TLDR; I’m in favor of convenient binaries is just the how they are handled.
>
> Sorry for my brevity, what I meant is that binaries should not be beside next to the source release seating on the same server and giving the same guarantees for both type of artifacts (source vs binary).
>
> Now in terms of convenience :-)
> ASF should not block a project of making binaries available to their community for what ever purpose they think appropriate (ie nightly, binary of a RC, binary of final RC)
>
> ASF should provide guidance to the projects to make sure they make their communities aware that a source artifact is different from a binary artifact.
> A project for example can put warnings and bold text on the location (ie directory, readme, inside the binary, download webpage, wiki etc) where the community downloads a copy of the binary.
> The warning can say this is not a release of the ASF, is just a convenient binary “download on your own risk”, we provide sha256 sum and maybe the binary is even signed, but best practice is for you to download the source and be in control of building the binary.
>
>
>
> - Carlos Santana
> @csantanapr
>
>> On Nov 7, 2018, at 7:04 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>> Just a FYI that in the early days of the ASF (and the httpd project), community binaries were a common offering...
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by ajs6f <aj...@apache.org>.
Another example: for some projects, the most important distribution is via Maven Central. We can distribute source and binary there, of course, but my guess would be that the vast majority of consumers are pulling the binaries and linking directly against them, using source distributions only for UX/UI assistance in their IDEs, and for Apache dependencies they require in an automated build, maybe not even that.
ajs6f
> On Nov 7, 2018, at 10:23 AM, Dave Fisher <da...@comcast.net> wrote:
>
> Hi -
>
> There are some projects where the binary is all the users want. For example, Apache OpenOffice. In that case these binaries are an exception and while on dist they are not mirrored and instead we distribute through SourceForge.
>
> I think if binaries are kept in a separate folder from source then DISCLAIMERs could be required to be added.
>
> To move to a new url would be very disruptive. To tell projects that they can no longer distribute binaries for community convenience would not be a small, reversible change.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
>> On Nov 7, 2018, at 5:14 AM, Carlos Santana <cs...@gmail.com> wrote:
>>
>> Jim
>>
>> What do you think now?
>> Was that a good or bad thing?
>>
>> TLDR; I’m in favor of convenient binaries is just the how they are handled.
>>
>> Sorry for my brevity, what I meant is that binaries should not be beside next to the source release seating on the same server and giving the same guarantees for both type of artifacts (source vs binary).
>>
>> Now in terms of convenience :-)
>> ASF should not block a project of making binaries available to their community for what ever purpose they think appropriate (ie nightly, binary of a RC, binary of final RC)
>>
>> ASF should provide guidance to the projects to make sure they make their communities aware that a source artifact is different from a binary artifact.
>> A project for example can put warnings and bold text on the location (ie directory, readme, inside the binary, download webpage, wiki etc) where the community downloads a copy of the binary.
>> The warning can say this is not a release of the ASF, is just a convenient binary “download on your own risk”, we provide sha256 sum and maybe the binary is even signed, but best practice is for you to download the source and be in control of building the binary.
>>
>>
>>
>> - Carlos Santana
>> @csantanapr
>>
>>> On Nov 7, 2018, at 7:04 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>>
>>> Just a FYI that in the early days of the ASF (and the httpd project), community binaries were a common offering...
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Paul King <pa...@asert.com.au>.
I also agree that moving to a different URL would be disruptive. In Apache
Groovy, we have a separate directory for the official (source) release as
distinct from the convenience binaries which are in a separate directory. I
think we copied the approach from Apache Ant. Our release notes stress the
official nature of the source release. IANAL, but I'd think such an
approach could be argued as providing a clear distinction between the
artifacts in terms of any potential liability.
Cheers, Paul.
On Thu, Nov 8, 2018 at 1:24 AM Dave Fisher <da...@comcast.net> wrote:
> Hi -
>
> There are some projects where the binary is all the users want. For
> example, Apache OpenOffice. In that case these binaries are an exception
> and while on dist they are not mirrored and instead we distribute through
> SourceForge.
>
> I think if binaries are kept in a separate folder from source then
> DISCLAIMERs could be required to be added.
>
> To move to a new url would be very disruptive. To tell projects that they
> can no longer distribute binaries for community convenience would not be a
> small, reversible change.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Nov 7, 2018, at 5:14 AM, Carlos Santana <cs...@gmail.com> wrote:
> >
> > Jim
> >
> > What do you think now?
> > Was that a good or bad thing?
> >
> > TLDR; I’m in favor of convenient binaries is just the how they are
> handled.
> >
> > Sorry for my brevity, what I meant is that binaries should not be beside
> next to the source release seating on the same server and giving the same
> guarantees for both type of artifacts (source vs binary).
> >
> > Now in terms of convenience :-)
> > ASF should not block a project of making binaries available to their
> community for what ever purpose they think appropriate (ie nightly, binary
> of a RC, binary of final RC)
> >
> > ASF should provide guidance to the projects to make sure they make their
> communities aware that a source artifact is different from a binary
> artifact.
> > A project for example can put warnings and bold text on the location (ie
> directory, readme, inside the binary, download webpage, wiki etc) where the
> community downloads a copy of the binary.
> > The warning can say this is not a release of the ASF, is just a
> convenient binary “download on your own risk”, we provide sha256 sum and
> maybe the binary is even signed, but best practice is for you to download
> the source and be in control of building the binary.
> >
> >
> >
> > - Carlos Santana
> > @csantanapr
> >
> >> On Nov 7, 2018, at 7:04 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
> >>
> >> Just a FYI that in the early days of the ASF (and the httpd project),
> community binaries were a common offering...
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: How to review so-called "binary releases"?
Posted by Dave Fisher <da...@comcast.net>.
Hi -
There are some projects where the binary is all the users want. For example, Apache OpenOffice. In that case these binaries are an exception and while on dist they are not mirrored and instead we distribute through SourceForge.
I think if binaries are kept in a separate folder from source then DISCLAIMERs could be required to be added.
To move to a new url would be very disruptive. To tell projects that they can no longer distribute binaries for community convenience would not be a small, reversible change.
Regards,
Dave
Sent from my iPhone
> On Nov 7, 2018, at 5:14 AM, Carlos Santana <cs...@gmail.com> wrote:
>
> Jim
>
> What do you think now?
> Was that a good or bad thing?
>
> TLDR; I’m in favor of convenient binaries is just the how they are handled.
>
> Sorry for my brevity, what I meant is that binaries should not be beside next to the source release seating on the same server and giving the same guarantees for both type of artifacts (source vs binary).
>
> Now in terms of convenience :-)
> ASF should not block a project of making binaries available to their community for what ever purpose they think appropriate (ie nightly, binary of a RC, binary of final RC)
>
> ASF should provide guidance to the projects to make sure they make their communities aware that a source artifact is different from a binary artifact.
> A project for example can put warnings and bold text on the location (ie directory, readme, inside the binary, download webpage, wiki etc) where the community downloads a copy of the binary.
> The warning can say this is not a release of the ASF, is just a convenient binary “download on your own risk”, we provide sha256 sum and maybe the binary is even signed, but best practice is for you to download the source and be in control of building the binary.
>
>
>
> - Carlos Santana
> @csantanapr
>
>> On Nov 7, 2018, at 7:04 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>> Just a FYI that in the early days of the ASF (and the httpd project), community binaries were a common offering...
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Dave Fisher <da...@comcast.net>.
Hi -
There are some projects where the binary is all the users want. For example, Apache OpenOffice. In that case these binaries are an exception and while on dist they are not mirrored and instead we distribute through SourceForge.
I think if binaries are kept in a separate folder from source then DISCLAIMERs could be required to be added.
To move to a new url would be very disruptive. To tell projects that they can no longer distribute binaries for community convenience would not be a small, reversible change.
Regards,
Dave
Sent from my iPhone
> On Nov 7, 2018, at 5:14 AM, Carlos Santana <cs...@gmail.com> wrote:
>
> Jim
>
> What do you think now?
> Was that a good or bad thing?
>
> TLDR; I’m in favor of convenient binaries is just the how they are handled.
>
> Sorry for my brevity, what I meant is that binaries should not be beside next to the source release seating on the same server and giving the same guarantees for both type of artifacts (source vs binary).
>
> Now in terms of convenience :-)
> ASF should not block a project of making binaries available to their community for what ever purpose they think appropriate (ie nightly, binary of a RC, binary of final RC)
>
> ASF should provide guidance to the projects to make sure they make their communities aware that a source artifact is different from a binary artifact.
> A project for example can put warnings and bold text on the location (ie directory, readme, inside the binary, download webpage, wiki etc) where the community downloads a copy of the binary.
> The warning can say this is not a release of the ASF, is just a convenient binary “download on your own risk”, we provide sha256 sum and maybe the binary is even signed, but best practice is for you to download the source and be in control of building the binary.
>
>
>
> - Carlos Santana
> @csantanapr
>
>> On Nov 7, 2018, at 7:04 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>> Just a FYI that in the early days of the ASF (and the httpd project), community binaries were a common offering...
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: How to review so-called "binary releases"?
Posted by Carlos Santana <cs...@gmail.com>.
Jim
What do you think now?
Was that a good or bad thing?
TLDR; I’m in favor of convenient binaries is just the how they are handled.
Sorry for my brevity, what I meant is that binaries should not be beside next to the source release seating on the same server and giving the same guarantees for both type of artifacts (source vs binary).
Now in terms of convenience :-)
ASF should not block a project of making binaries available to their community for what ever purpose they think appropriate (ie nightly, binary of a RC, binary of final RC)
ASF should provide guidance to the projects to make sure they make their communities aware that a source artifact is different from a binary artifact.
A project for example can put warnings and bold text on the location (ie directory, readme, inside the binary, download webpage, wiki etc) where the community downloads a copy of the binary.
The warning can say this is not a release of the ASF, is just a convenient binary “download on your own risk”, we provide sha256 sum and maybe the binary is even signed, but best practice is for you to download the source and be in control of building the binary.
- Carlos Santana
@csantanapr
> On Nov 7, 2018, at 7:04 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> Just a FYI that in the early days of the ASF (and the httpd project), community binaries were a common offering...
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Jim Jagielski <ji...@jaguNET.com>.
Just a FYI that in the early days of the ASF (and the httpd project), community binaries were a common offering...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Carlos Santana <cs...@gmail.com>.
ASF should only distribute source
Having binaries/compiled along side of the source is not a good signal and confusing.
- Carlos Santana
@csantanapr
> On Nov 7, 2018, at 4:24 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>
> Hi,
>
>> On Tue, Nov 6, 2018 at 11:07 PM David Nalley <da...@gnsa.us> wrote:
>> ... To my mind, allowing projects to distribute 'convenience binaries'
>> from our hardware, in a place we say contains releases, and which is
>> occasionally consumed in such a way as to dwarf what we call official
>> releases[1], makes them actions of the Foundation despite our
>> protestations....
>
> I tend to agree and would feel *much* more comfortable if binaries
> went to a different place like binaries.apache.org where we can have
> all sort of loud disclaimers.
>
> I don't know how practical that is in terms of our mirroring system,
> and that might make releases a bit more complicated but it would make
> things much clearer IMO.
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Hi,
On Tue, Nov 6, 2018 at 11:07 PM David Nalley <da...@gnsa.us> wrote:
>... To my mind, allowing projects to distribute 'convenience binaries'
> from our hardware, in a place we say contains releases, and which is
> occasionally consumed in such a way as to dwarf what we call official
> releases[1], makes them actions of the Foundation despite our
> protestations....
I tend to agree and would feel *much* more comfortable if binaries
went to a different place like binaries.apache.org where we can have
all sort of loud disclaimers.
I don't know how practical that is in terms of our mirroring system,
and that might make releases a bit more complicated but it would make
things much clearer IMO.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How to review so-called "binary releases"?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
CC += legal-discuss@ since this really isn't an incubator-specific topic any
more. The context is precompiled binary artifacts on
https://www.apache.org/dist/.
David Nalley wrote on Tue, Nov 06, 2018 at 17:06:50 -0500:
> So let's assume a PMC (or PPMC) goes through the same process with
> binaries in terms of reviewing, voting on, promoting, and publishing
> to the world a binary release on behalf of the PMC and Foundation.
> Binaries are published to the same location that source tar balls are
> - are featured on download pages provided by the ASF. Perhaps even
> with the situation being that people download the binary artifacts
> from ASF resources tens of thousands, or maybe even millions of times
> more frequently than the source tarballs.
>
> From that scenario I have some questions:
>
> 1. Would a reasonable person (or jury) suspend disbelief long enough
> to consider our protestations that our 'releases' are source only, and
> that as a Foundation we didn't release, propagate, promote, or
> distribute the binaries in question? A rose by any other name.....
> 2. Should the Board be taking an active interest in projects (release
> managers?) who promote and publish their binaries in this manner on
> our hardware?
> 3. Is lack of Board action tantamount to tacit approval of this
> behavior? Can we really claim ignorance?
> 4. Should Infrastructure be actively monitoring and removing binaries
> which find their way to dist.a.o/archive.a.o - especially since our
> header for dist.a.o says that the directories contain releases of
> Apache software?
> 5. Should we be alerting individual release managers that publishing
> convenience binaries exposes them individually to liability?
6. What alternative can we offer to projects that want to distribute binaries?
Can the RM upload precompiled binaries to his https://home.a.o/~availid/ space?
Can the project's download page link to them as the
primary/canonical/recommended binaries? Can the project's download page link
to the RM's binaries as one alternative among many (compare
https://subversion.apache.org/packages#windows)?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org