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 reliance on upstream sources always comes to bear, even for source-code contributions. But having access to all source is reported by some as being essential for ASF releases and that is tied to the notion that the source code is the release. (This is despite specific provision in the treatment of licenses for distributing certain binary artifacts in order to avoid license confusion.) I don't have any clarity on this. I know that it would be a serious burden to some projects if there were restriction to authenticated builds for open-source platforms only and/or restriction to exclusively open-source libraries for other dependencies not satisfied by the platform itself. To the extent that the requirement is for more than IP provenance and license reconciliation, I am not clear who is being held to account for any deeper scrutiny than that. Are the PMC votes for a release expected to establish some sort of serious attestation concerning the nature of the source? Instead, is the requirement of specific source-code availability instead a requirement for potential forensic requirements later in the lifecycle of a release? Can this be satisfied without the source be in the release, by whatever arrangement and assurance that could be made to ensure its availability whenever needed? I have only question in this area. I believe there is a definite concern, but I am not sure where it has teeth beyond a ritual requirement. - Dennis -----Original Message----- From: Dennis E. Hamilton [mailto:orc...@apache.org] Sent: Monday, August 20, 2012 18:50 To: general@incubator.apache.org Subject: RE: [VOTE] Apache OpenOffice Community Graduation Vote I do not dispute the existence of other reliable creators of binary distributions. The *nix packagings and installation in consumer desktops are notable for the value that they provide. I think that experience teaches us that there absolutely needs to be a way to obtain and install *authentic* binary distributions made using the release sources with a proper set of options for a given platform. It is near impossible to provide end-user support and bug confirmation without agreement on the authentic bindist that is being use and that it is a bindist made from known sources. And there are enough fraudulent distributions out there that this is critical as a way to safeguard users. For that reason alone, there needs to be an authenticated bindist, especially for Windows, the 80% that garners the focused attention of miscreants and opportunists. That is also the reason for wanting signed binaries that pass verification on Windows and OS X. There needs to be a way for everyday users to receive every assurance that they are installing an authentic bindist and that it is verifiable who the origin is. I suspect that reliable packagers of unique distributions (including any from IBM) will provide their own verifiable authenticity. - Dennis -----Original Message----- From: drew [mailto:d...@baseanswers.com] Sent: Monday, August 20, 2012 18:00 To: general@incubator.apache.org Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote [ ... ] --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
