Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Reply-To: <orcmid@apache.org>
From: "Dennis E. Hamilton" <orcmid@apache.org>
To: "OOo-dev Apache Incubator " <ooo-dev@incubator.apache.org>
References: 
 <CAP-ksogNw3hy0RrUOBELkShLrdABb5Vhz6Uw6cp-8KFsFTJMNg@mail.gmail.com>
	 <CAP-ksohHWp4YuCmo32=k0MhnDUON-Dhf2ZBrQaUDq42a9asuCw@mail.gmail.com>
	 <CAAS6=7jtBppzByUm8+TsVRDocoGMtKU3X854P-HdxrUHLC-JkQ@mail.gmail.com>
	 <1345500234.7229.10.camel@sybil-gnome>
	 <CAAS6=7jMkQyJrHbkPRON9HBmg8bYH56jJkQYrmNnm6ViRTs5kA@mail.gmail.com>
 <1345510775.7229.29.camel@sybil-gnome>
 <00dc01cd7f3f$55498080$ffdc8180$@apache.org>
 <006d01cd83be$a3689f20$ea39dd60$@apache.org>
In-Reply-To: <006d01cd83be$a3689f20$ea39dd60$@apache.org>
Subject: FW: [VOTE] Apache OpenOffice Community Graduation Vote
Date: Sun, 26 Aug 2012 12:42:16 -0700
Message-ID: <00b601cd83c2$e6f59280$b4e0b780$@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: 
 AQFYhP1SdFxUd6lNuBuL/SUIAwLnIwDlA17zAtlbbdcBOd5RmQL4vUrPAcWi5uQCryKxDgLxX/dCl9vBP4A=
Content-Language: en-us

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]=20
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=20
   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. =20

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. =20

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. =20

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? =20

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]=20
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. =20

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. =20

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]=20
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