incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: [VOTE] Apache OpenOffice Community Graduation Vote
Date Sun, 26 Aug 2012 19:54:05 GMT

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:orcmid@apache.org] 
> Sent: Sunday, August 26, 2012 12:12
> To: general@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:orcmid@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:drew@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 


Mime
View raw message