incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <orc...@apache.org>
Subject FW: [VOTE] Apache OpenOffice Community Graduation Vote
Date Sun, 26 Aug 2012 19:42:16 GMT
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.

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