openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Ready to setup release build machines?
Date Fri, 19 Aug 2016 17:37:30 GMT

> -----Original Message-----
> From: Kay Schenk []
> Sent: Friday, August 19, 2016 09:09
> To:
> Subject: Re: Ready to setup release build machines?
> On 08/12/2016 12:22 PM, Dennis E. Hamilton wrote:
> > I thought that the basic requirement is that the release manager(s) do
> any builds on a machine under their [exclusive] individual control.
> That also means satisfying baseline requirements for release builds
> though.  That pretty much requires use of a VM if the main development
> system of a release manager is aligned with different tools and
> dependencies.
> I don't find any requirement like this vis a vis building by the release
> manager per se. The release is voted on by the community. So, in a
> sense, building/testing is the responsibility of all who vote on a
> release.
> See:

That page is rather obsolete.  For example, we have two branches on, one of
which is for dev (and where we put release candidates) and the other is release where we move
any approved candidates.  The dist ... release contents are automatically mirrored to
which seems to be the proper place to refer to these (although there is mirroring to consider,
but not for 4.1.2-patch1).

The release page does not address binaries.  I saw the business about where official binaries
are to be built somewhere and must find it.

Since we put binaries through a form of this process (usually concurrently) there does need
to be some sort of provenance on those binaries.

> >
> > I am not so certain about putting up shared release-build VMs on non-
> ASF infrastructure though.
> Our "official", "required" release artifact is the source code for a
> release.
> >
> > One advantage to using ASF infrastructure is to bring code signing
> into the fold.  That seems rather important down the road.
> We have been signing ALL release artifacts -- including all the binaries
> -- since AOO 3.4. So code signing of everything we release is already
> part of this process.

The use of PGP signatures on our release artifacts is a different matter than code signing
that is recognized by the operating system and is part of the installer, not a detached signature
that users must check manually.  The signatures I meant are *embedded* in the artifacts, including
.msi, .dll, and .exe files.

I was thinking of this form of signed installs.  That is a big deal for Windows, where the
OS will check them automatically, and they are also reported in the Properties for the signed
artifact.  It also applies to all of the DLLs and such that are loaded with the install. 
I believe that Andrea has the private key that was issued for that but we have not managed
to use it to sign the code.  This is usually done as part of building distributable binaries.

That private key is precious and is not to be shared.  Ideally, it would belong to root@ but
I don't think we have a process for that.  

> We require a production environment accessible by the release manager
> and helpers because producing distribution binaries in another location
> (seperate developer machine), signing and then uploading ALL the
> binaries to SourceForce by individuals is a horrendous undertaking.
> Ariel Constenla-Haile provided binaries for the 3.4 release and I'm sure
> he can attest to this. If we can set up a production environment under
> ASF infrastructure, of course this would be ideal. But, I see no reason
> why this environment couldn't have shell access by AOO developers who
> are likely to do code signing.
[ ... ]

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message