Re: [VOTE] Apache OpenOffice Community Graduation Vote
On Sat, Aug 25, 2012 at 10:53 PM, Rob Weir wrote: > On Fri, Aug 24, 2012 at 4:35 PM, Greg Stein wrote: >> On Fri, Aug 24, 2012 at 4:00 PM, Rob Weir wrote: > > > >>> I can give the IPMC a hand here, if my point is too obscure. A policy >>> might look like this: >>> >>> Resolved: An Apache project's release consists of a canonical source >>> artifact, voted on and approved by the PMC. A PMC can also distribute >>> additional, non-source artifacts, including documentation, binaries, >>> samples, etc., that are provided for the convenience of the user. >>> These non-source artifacts must must be buildable from the canonical >>> source artifact. Additional 3rd party libraries may be included >>> solely in compliance with license policies defined by Apache Legal >>> Affairs. Additionally the non-source artifacts (or the PMC) must >>> and must not _. >> >> That's existing policy. As people keep saying (most recently, Joe, in >> no uncertain terms). >> > > Hi Greg, > > And Joe, as I'm sure you noticed, also said: > > "THERE IS NO PROBLEM HERE, > CURRENT POLICY FULLY COVERS WHAT AOO ACTUALLY > DOES. END OF DISCUSSION." > > This is my understanding as well. > > In any case, you seem to agree with the wording that I gave above, > since you say it represents existing policy. Since I can find no > place on the IPMC or ASF website where this policy is actually stated > (and please correct me if I missed it), it might be good if we took my > summary from above and put it into the Podling Release Guide. I know > there is an ongoing effort to clean up the IPMC website. I'd be happy > to submit a patch. Marvin gave the link earlier in this thread. 4th para is the relevant bit. http://www.apache.org/dev/release.html#what --tim - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache OpenOffice Community Graduation Vote
On 26.08.2012 13:15, Tim Williams wrote: > Marvin gave the link earlier in this thread. 4th para is the relevant bit. > > http://www.apache.org/dev/release.html#what The relevant part is in the last paragraph. However, that says "convenience" and defines version numbering requirements, but it does /not/ state that the binaries are not sanctioned by the ASF and are not part of the official ASF release. It would be very useful if that paragraph were amended to say so explicitly. I've had no end of trouble trying to explain to managers and customers that any binaries that come from the ASF are not "official". Regardless of the policy stated numerous times in this thread and on this list, this is not clear anywhere in the bylaws or other online documentation (that I can find). -- Brane P.S.: I asked this same question on legal-discuss a week ago. My post has not even been moderated through as of today, so referring people to that list doesn't appear to be too helpful. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache OpenOffice Community Graduation Vote
On Sun, Aug 26, 2012 at 7:26 AM, Branko Čibej wrote: > On 26.08.2012 13:15, Tim Williams wrote: >> Marvin gave the link earlier in this thread. 4th para is the relevant bit. >> >> http://www.apache.org/dev/release.html#what > > The relevant part is in the last paragraph. However, that says > "convenience" and defines version numbering requirements, but it does > /not/ state that the binaries are not sanctioned by the ASF and are not > part of the official ASF release. > And again, as I and others have stated, this is merely a label with no content to it. What does "sanctioned (or not sanctioned) by the ASF mean"? Anything specific? Remember, the binaries (or "Object form" in the words of the license) are also covered by the Apache License 2.0, and sections 7 and 8 of that license already say that it is provided as-is, and disclaims warranty and liability. In other words, the same license and the same disclaimers apply to source (which we seem to agree is part of the ASF release) and to binaries. So again I urge the IPMC to mind the seductive appeal of mere labeling and instead consider whether there is any actual constraints on activities and behavior for Podlings (or TLP's for that matter) based on whether something is a source or binary, e.g.: 1) Is there some required (or forbidden) way in which a distinction must be acknowledged in a release vote? 2) Is there some required (or forbidden) language on the download webpage? 3) Any required (or forbidden) language on release announcements? 4) Is there some required (or forbidden) constraint with distribution? So far I have heard some on this list suggest the AOO podling is doing something incorrect, something against ASF policy. But dispute repeated queries, no one has stated what exactly this is. This is extremely unfair to the podling, to any podling. It denies us the opportunity of addressing issues. Is this really how the IPMC operates? It reminds me of tactics practiced by Microsoft against open source -- intimate that something is wrong, but never offer specifics. We call it FUD there. What do we call it at the ASF? > It would be very useful if that paragraph were amended to say so > explicitly. I've had no end of trouble trying to explain to managers and > customers that any binaries that come from the ASF are not "official". That may be true for your users, but for mine they would just come back with, "What does that mean in practice?" > Regardless of the policy stated numerous times in this thread and on > this list, this is not clear anywhere in the bylaws or other online > documentation (that I can find). > I agree. > -- Brane > > P.S.: I asked this same question on legal-discuss a week ago. My post > has not even been moderated through as of today, so referring people to > that list doesn't appear to be too helpful. > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache OpenOffice Community Graduation Vote
On Sun, Aug 26, 2012 at 4:26 AM, Branko Čibej wrote: > On 26.08.2012 13:15, Tim Williams wrote: >> Marvin gave the link earlier in this thread. 4th para is the relevant bit. >> >> http://www.apache.org/dev/release.html#what > > The relevant part is in the last paragraph. However, that says > "convenience" and defines version numbering requirements, but it does > /not/ state that the binaries are not sanctioned by the ASF and are not > part of the official ASF release. > > It would be very useful if that paragraph were amended to say so > explicitly. I've had no end of trouble trying to explain to managers and > customers that any binaries that come from the ASF are not "official". > Regardless of the policy stated numerous times in this thread and on > this list, this is not clear anywhere in the bylaws or other online > documentation (that I can find). The possibility exists that when the question is put to legal-discuss, we will find that Roy's missives have been misinterpreted, and that so long as the imperative of a clean source release (uncontaminated by e.g. embedded jar files) is satisfied, it is permissible for a PMC to sanction accompanying binary artifacts which are wholly derived from said clean source. It is also possible that the V.P. of Legal (who is a Board member) will kick the question up to the Board and that they will take up a full-blown resolution clarifying the policy. Perhaps they will impose restrictions going forward such as the requirement that binaries to be blessed must be created via automatic processes kicked off by Infra on sterile build machines. Or perhaps there won't be a resolution, but the discussion will produce a new common understanding that PMCs have so much autonomy they can "release" a peanut butter and jelly sandwich alongside the source code as an "act of the corporation". And yet another possibility is that the Legal VP will issue a narrowly tailored rulying stating that AOO may release blessed binaries while incubating, but that after graduation only binaries produced on sterile build machines may be blessed. Who knows? We aren't going to resolve these questions on this list. In any case, I do not believe that it is in the best interests of either the ASF or the AOO podling (particularly those contributing towards the binary artifacts) for ambiguity to persist around issues of indemnification, and I don't think it's good for the ASF to walk backwards into a policy on binary releases accidentally. Apologies for keeping the zombie thread alive. If it were up to me, it would have hopped forums some time ago. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache OpenOffice Community Graduation Vote
No. There is NO WAY IN HELL the org can indemnify a volunteer who produces a binary build themselves. Please don't bother asking legal-discuss to tackle this. The way liability works in an incorporated volunteer charity is that you are not liable for "club" activities performed without negligence on your part. IANAL but this is the whole point of the law surrounding this area of human activity in the US. Building software on 3rd party hosts which are not operated by the org exposes you to the possibility that your system may be compromised beyond what is in source, and should you publish those artifacts to ASF mirrors you could be held liable for any damages your inattentiveness towards the system that produced those packages may have caused. Nothing the org can do other than adopt an insane indemnity policy will absolve a volunteer of that personal risk at this point. However, if the org decides on a method of producing production-quality builds itself and signs off on them itself as an org, then clearly only the ASF, and any malicious or negligent party, is exposed to any risks associated with widescale distribution. If the software is built by an ASF host using ASF-maintained software, you might be able to make the case before a judge that is was the ASF's fault for producing vulnerable builds on a compromised host. But you will have to plead that before a judge at this point should you be named in a suit, because we don't currently offer that level of management in our build farms. HTH > > From: Marvin Humphrey >To: general@incubator.apache.org >Sent: Sunday, August 26, 2012 10:09 AM >Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote > >On Sun, Aug 26, 2012 at 4:26 AM, Branko Čibej wrote: >> On 26.08.2012 13:15, Tim Williams wrote: >>> Marvin gave the link earlier in this thread. 4th para is the relevant bit. >>> >>> http://www.apache.org/dev/release.html#what >> >> The relevant part is in the last paragraph. However, that says >> "convenience" and defines version numbering requirements, but it does >> /not/ state that the binaries are not sanctioned by the ASF and are not >> part of the official ASF release. >> >> It would be very useful if that paragraph were amended to say so >> explicitly. I've had no end of trouble trying to explain to managers and >> customers that any binaries that come from the ASF are not "official". >> Regardless of the policy stated numerous times in this thread and on >> this list, this is not clear anywhere in the bylaws or other online >> documentation (that I can find). > >The possibility exists that when the question is put to legal-discuss, we will >find that Roy's missives have been misinterpreted, and that so long as the >imperative of a clean source release (uncontaminated by e.g. embedded jar >files) is satisfied, it is permissible for a PMC to sanction accompanying >binary artifacts which are wholly derived from said clean source. > >It is also possible that the V.P. of Legal (who is a Board member) will kick >the question up to the Board and that they will take up a full-blown >resolution clarifying the policy. Perhaps they will impose restrictions going >forward such as the requirement that binaries to be blessed must be created >via automatic processes kicked off by Infra on sterile build machines. Or >perhaps there won't be a resolution, but the discussion will produce a new >common understanding that PMCs have so much autonomy they can "release" a >peanut butter and jelly sandwich alongside the source code as an "act of the >corporation". > >And yet another possibility is that the Legal VP will issue a narrowly >tailored rulying stating that AOO may release blessed binaries while >incubating, but that after graduation only binaries produced on sterile build >machines may be blessed. > >Who knows? We aren't going to resolve these questions on this list. > >In any case, I do not believe that it is in the best interests of either the >ASF or the AOO podling (particularly those contributing towards the binary >artifacts) for ambiguity to persist around issues of indemnification, and I >don't think it's good for the ASF to walk backwards into a policy on binary >releases accidentally. > >Apologies for keeping the zombie thread alive. If it were up to me, it would >have hopped forums some time ago. > >Marvin Humphrey > >- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org > > > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache OpenOffice Community Graduation Vote
The point most people seem to make out of "sanctioned" or "official" builds revolves around indemnifying volunteers involved in the production of the release. I'm tired of rehashing release.html for the umpteenth time simply because Brane or you or some other newb lacks the experience to know the context behind the document, but as they say patches welcome (on site-...@apache.org). Every committer can alter the wording on that page and do something more productive than make clueless arguments on this ever devolving thread. AOO is mentored by some of the most experienced people in the org, please just ignore any further chaff from this thread and pay attention to the guidance you have been repeatedly given on this issue. AOO doesn't need to change anything to their current release processes other than to stop pointing source downloads at svn (which is the sole reason I won't vote for AOO candidates). - Original Message - > From: Rob Weir > To: general@incubator.apache.org > Cc: > Sent: Sunday, August 26, 2012 9:54 AM > Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote > > On Sun, Aug 26, 2012 at 7:26 AM, Branko Čibej wrote: >> On 26.08.2012 13:15, Tim Williams wrote: >>> Marvin gave the link earlier in this thread. 4th para is the relevant > bit. >>> >>> http://www.apache.org/dev/release.html#what >> >> The relevant part is in the last paragraph. However, that says >> "convenience" and defines version numbering requirements, but it > does >> /not/ state that the binaries are not sanctioned by the ASF and are not >> part of the official ASF release. >> > > And again, as I and others have stated, this is merely a label with no > content to it. What does "sanctioned (or not sanctioned) by the ASF > mean"? Anything specific? > > Remember, the binaries (or "Object form" in the words of the license) > are also covered by the Apache License 2.0, and sections 7 and 8 of > that license already say that it is provided as-is, and disclaims > warranty and liability. > > In other words, the same license and the same disclaimers apply to > source (which we seem to agree is part of the ASF release) and to > binaries. > > So again I urge the IPMC to mind the seductive appeal of mere labeling > and instead consider whether there is any actual constraints on > activities and behavior for Podlings (or TLP's for that matter) based > on whether something is a source or binary, e.g.: > > 1) Is there some required (or forbidden) way in which a distinction > must be acknowledged in a release vote? > > 2) Is there some required (or forbidden) language on the download webpage? > > 3) Any required (or forbidden) language on release announcements? > > 4) Is there some required (or forbidden) constraint with distribution? > > So far I have heard some on this list suggest the AOO podling is doing > something incorrect, something against ASF policy. But dispute > repeated queries, no one has stated what exactly this is. This is > extremely unfair to the podling, to any podling. It denies us the > opportunity of addressing issues. Is this really how the IPMC > operates? It reminds me of tactics practiced by Microsoft against > open source -- intimate that something is wrong, but never offer > specifics. We call it FUD there. What do we call it at the ASF? > >> It would be very useful if that paragraph were amended to say so >> explicitly. I've had no end of trouble trying to explain to managers > and >> customers that any binaries that come from the ASF are not > "official". > > That may be true for your users, but for mine they would just come > back with, "What does that mean in practice?" > >> Regardless of the policy stated numerous times in this thread and on >> this list, this is not clear anywhere in the bylaws or other online >> documentation (that I can find). >> > > I agree. > >> -- Brane >> >> P.S.: I asked this same question on legal-discuss a week ago. My post >> has not even been moderated through as of today, so referring people to >> that list doesn't appear to be too helpful. >> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache OpenOffice Community Graduation Vote
On 26.08.2012 16:46, Joe Schaefer wrote: > The point most people seem to make out of "sanctioned" > or "official" builds revolves around indemnifying volunteers > involved in the production of the release. > > > I'm tired of rehashing release.html for the umpteenth time > simply because Brane or you or some other newb lacks the > experience to know the context behind the document, but > as they say patches welcome (on site-...@apache.org). Every > committer can alter the wording on that page and do something > more productive than make clueless arguments on this > ever devolving thread. That's very helpful, thanks. So if someone asks me about ASF releases and binaries I should refer them to the legal-discuss archives, or these general@ archives, or simply tell them to find a founding member to condescendingly explain the obvious. Because I sure can't give 'em a link to some page on our web site. I'll refrain from spelling out the epithets that come to mind. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache OpenOffice Community Graduation Vote
Waah Brane- obviously you're not as community-oriented as you'd like to think. release.html is the byproduct of several years of writing oriented towards the lowest common denominator of the org, but if you think you know how to improve it you have all the requisite karma already. All that's missing is a clue. - Original Message - > From: Branko Čibej > To: general@incubator.apache.org > Cc: > Sent: Sunday, August 26, 2012 10:53 AM > Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote > > On 26.08.2012 16:46, Joe Schaefer wrote: >> The point most people seem to make out of "sanctioned" >> or "official" builds revolves around indemnifying volunteers >> involved in the production of the release. >> >> >> I'm tired of rehashing release.html for the umpteenth time >> simply because Brane or you or some other newb lacks the >> experience to know the context behind the document, but >> as they say patches welcome (on site-...@apache.org). Every >> committer can alter the wording on that page and do something >> more productive than make clueless arguments on this >> ever devolving thread. > > That's very helpful, thanks. So if someone asks me about ASF releases > and binaries I should refer them to the legal-discuss archives, or these > general@ archives, or simply tell them to find a founding member to > condescendingly explain the obvious. Because I sure can't give 'em a > link to some page on our web site. > > I'll refrain from spelling out the epithets that come to mind. > > -- Brane > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache OpenOffice Community Graduation Vote
On 26.08.2012 17:04, Joe Schaefer wrote: > Waah Brane- obviously you're not as community-oriented > as you'd like to think. release.html is the byproduct > of several years of writing oriented towards the lowest > common denominator of the org, but if you think you know > how to improve it you have all the requisite karma already. > > All that's missing is a clue. Joe, I know very well (and you know that I know) that I can edit most of the things that appear on our web site. But if community-oriented means that anyone should just edit those docs to scratch an itch and to hell with consensus and the consequences, then you're right, I'm definitely a misfit here. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache OpenOffice Community Graduation Vote
Better attitude, now all you need to do is subscribe to site-...@apache.org and join the rest of the people who care about the content of our site documentation. - Original Message - > From: Branko Čibej > To: general@incubator.apache.org > Cc: > Sent: Sunday, August 26, 2012 11:13 AM > Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote > > On 26.08.2012 17:04, Joe Schaefer wrote: >> Waah Brane- obviously you're not as community-oriented >> as you'd like to think. release.html is the byproduct >> of several years of writing oriented towards the lowest >> common denominator of the org, but if you think you know >> how to improve it you have all the requisite karma already. >> >> All that's missing is a clue. > > Joe, I know very well (and you know that I know) that I can edit most of > the things that appear on our web site. But if community-oriented means > that anyone should just edit those docs to scratch an itch and to hell > with consensus and the consequences, then you're right, I'm definitely a > misfit here. > > -- Brane > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache OpenOffice Community Graduation Vote
Sigh. Apache is a volunteer organization with a history and a culture. As a volunteer organization, it cannot possibly create and maintain a set of documents that describe every bit of cultural norm and historical context. New committers on existing projects learn from their communities. Podling members learn from their mentors. Even out here on general@, I've seen several iterations of some AOO people asking about signed builds and binary releases and experienced Apache members offering answers. This is how it works. Legal-discuss@ and board@ are *not* the normal way to answer these questions. Writing for myself, I see how the AOO situation differs from just about any previous project, and why AOO people would want a different answer to the question. And, over time and a whole lot of effort, a different answer may be forthcoming. However, until then, it is what it is, and a thread here is not going to change it. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache OpenOffice Community Graduation Vote
> Joe, I know very well (and you know that I know) that I can edit most of > the things that appear on our web site. But if community-oriented means > that anyone should just edit those docs to scratch an itch and to hell > with consensus and the consequences, then you're right, I'm definitely a > misfit here. Brane, editing the docs to do a better job of explaining is not 'to hell with consensus and consequences.' If you feel clear that you can see a way to improve without changing the semantics, all you'll get for your trouble is applause. 'Misfit' would be the label for someone who tried to change the policy by editing the document. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache OpenOffice Community Graduation Vote
On Aug 26, 2012, at 7:46 AM, Joe Schaefer wrote: > AOO doesn't need to change anything to their current release processes > other than to stop pointing source downloads at svn (which is the sole > reason I won't vote for AOO candidates). Well this is worth discussion. On this page [1]: The source downloads go through aoo-closer.cgi, but all of the hashes and signatures go through www.a.o/dist/. Is that your issue? Or is it this page [2]? Please help me understand what is wrong and it will be fixed. Best Regards, Dave [1] http://incubator.apache.org/openofficeorg/downloads.html [2] http://www.openoffice.org/download/other.html#tested-sdk - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache OpenOffice Community Graduation Vote
- Original Message - > From: Dave Fisher > To: general@incubator.apache.org > Cc: > Sent: Sunday, August 26, 2012 1:08 PM > Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote > > > On Aug 26, 2012, at 7:46 AM, Joe Schaefer wrote: > >> AOO doesn't need to change anything to their current release processes >> other than to stop pointing source downloads at svn (which is the sole >> reason I won't vote for AOO candidates). > > Well this is worth discussion. > > On this page [1]: > > The source downloads go through aoo-closer.cgi, but all of the hashes and > signatures go through www.a.o/dist/. Is that your issue? No, but I'm tired of talking about it. If you try to build from source the build system will download packages from svn.apache.org instead of from elsewhere or the mirrors. That violates infra policy. > > Or is it this page [2]? > > Please help me understand what is wrong and it will be fixed. > > Best Regards, > Dave > > [1] http://incubator.apache.org/openofficeorg/downloads.html > [2] http://www.openoffice.org/download/other.html#tested-sdk > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache OpenOffice Community Graduation Vote
On Sun, Aug 26, 2012 at 1:08 PM, Dave Fisher wrote: > > On Aug 26, 2012, at 7:46 AM, Joe Schaefer wrote: > >> AOO doesn't need to change anything to their current release processes >> other than to stop pointing source downloads at svn (which is the sole >> reason I won't vote for AOO candidates). > > Well this is worth discussion. > > On this page [1]: > > The source downloads go through aoo-closer.cgi, but all of the hashes and > signatures go through www.a.o/dist/. Is that your issue? > > Or is it this page [2]? > > Please help me understand what is wrong and it will be fixed. > This is the old bootstrap.sh issue, where build dependencies where being downloaded from svn, from out ext-sources directory. This is a superset of the issues Pedro had with the cat-b dependencies. We need to make it so the dependencies are all downloaded from somewhere else. Otherwise we're sucking ASF bandwidth. > Best Regards, > Dave > > [1] http://incubator.apache.org/openofficeorg/downloads.html > [2] http://www.openoffice.org/download/other.html#tested-sdk > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [VOTE] Apache OpenOffice Community Graduation Vote
Since my post was mentioned later on this thread, I thought I would summarize what I have as the take-away from intervening discussion. I have no intention to deal with the use of language (i.e., semantics of "convenience") and the way that tacit policy understanding is conveyed among Apache project participants. I will also refrain from any further additions to this topic. TAKE-AWAYS With regard to the production and delivery to users of authentic Apache OpenOffice binary builds, there seem to be the following concerns (especially for, but not limited to, Windows and Apple binaries and aggravated further by the restraints that are growing around evolving "App Store" requirements for consumer- and cloud-oriented platforms). I see three cases: 1. Authentication of binaries 2. Provenance of bundled binary dependencies 3. Availability of source for inspection, audit, and provenance 1. AUTHENTICATION OF BINARIES The desire for binaries to be signed using digital signatures with private keys held by the ASF is a natural concern for authentication of a variety of binaries produced by Apache projects. There appears to be agreement that any such signature introductions must be done by ASF-authorized agents. The conclusion is that infrastructure would perform such signings. These signings, by virtue of their modification of the unsigned binary, will invalidate any external signatures that were prepared as part of the release process. (It is possible to extract the internal signature and verify an external signature, if that is ever any question about that.) The signing party would have the reliance of the release-manager external signatures and other attestation that the binary is produced from the release sources. This still leaves open additional concerns about the conditions under which the binaries are produced and any difficulties that result. An alternative is for the signing authority to also produce the binaries, using the release sources directly on secured build machines. There are a number of technical problems that arise in this case, unless the release candidates were built in the same manner but not (yet) signed. That could work. It would also confirm that the binaries are indeed produced from the release's sources using the parameters for the platform presumably also included in the source materials. The remaining question is, what is being attested to by the production of binaries that are authenticated in this manner? Simply that they have been built in this manner and that it was done using ASF infrastructure, the integrity of which the ASF can be accountable for. It is not an attestation that there are no bugs, no security defects, or even that the IP provenance is assured to be clean. It is that the binary was produced under these particular verifiable conditions from the source materials provided as part of the source release along with dependencies on binaries incorporated in the build. It also provides a strong differentiator for binaries, however they might be identified, including even release candidates and developer builds, that were not provided in this manner. 2. PROVENANCE OF BUNDLED BINARY DEPENDENCIES A complication in (1) is the incorporation of binary resources on which the source-code release depends in order to be built. These might be authorized (and usually authenticated) redistributables having closed-source origins. These might be authorized open-source libraries that must be used without construction from sources in order for authentication of the dependency to be preserved. (E.g., there are security libraries that have NIST certification on the binary library, never the source, and the certification is also sustained only when the library is used with specific tooling.) For whatever reason, it is appropriate and preferable that the binary form of a dependency be relied upon, whether a jar file, a static library, or a dynamic library (DLL or SO) that becomes incorporated in the authenticated binary. The specific dependencies of such a nature would need to be accounted for as part of the authenticated build. That requires more traceability to specific artifacts and the basis for their reliance in some manner that does not involve building of the dependencies from sources as part of the build. This would probably require additional rigorous treatment to satisfy requirements for the integrity of the ASF project build. It might take more than simple reliance on the asserted IP and provenance of the upstream-obtained binaries. I am thinking that one needs to be specific to the artifact level, at least. 3. AVAILABILITY OF SOURCE FOR INSPECTION, AUDIT, AND PROVENANCE On this thread, the importance of having source code available has been stated as a strong requirement. As far as I can tell, this is a requirement for IP provenance more than anything else. Of course, the good-faith r
