On Aug 26, 2012, at 12:42 PM, Dennis E. Hamilton wrote: > FYI, concerning the matter of binaries distributed by the Apache OpenOffice > project. > > I neglected to consider a case that Dave Fisher just raised here on ooo-dev: > Where the binary dependencies relied upon in an Apache OpenOffice binary > distribution are accessed from at build time and where those are identifiably > preserved for purposes of replication/confirmation and also for any future > forensic need. That is an element in my topic (2) below.
Before we all light our hair on fire. I'm only saying that the build must not pull these out of svn, even as a backup. If you examine the current scripts that has been done already. Regards, Dave > > Please do not comment on the general@ i.a.o thread. It is a zombie in the > process of being burned at the stake. > > - Dennis > > -----Original Message----- > From: Dennis E. Hamilton [mailto:orc...@apache.org] > Sent: Sunday, August 26, 2012 12:12 > To: gene...@incubator.apache.org > Subject: 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 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: gene...@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: gene...@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 >
