On Aug 26, 2012, at 12:54 PM, Dave Fisher wrote: > > 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.
Correction - the scripts go to external sources first. I am prosing to take away the svn fallback. > > 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 >> >
