On Feb 17, 2007, at 3:05 PM, Nicko Cadell wrote:
1. Build should be reproducible (other than timestamps and
other trivia)
I'm not sure how you are handling strong naming in your
releases. If you have a signing key, we may want to find a
way to securely share the key. Perhaps have it gpg encrypted
for multiple private keys (Nicko, Ron and I?) and placed in
the SVN repo, so that any one of us could produce a bug fix
version. If we need to add a new person to the build
community, one of the current holders could decrypt and reencrypt.
The strong name key is a big issue. We strong name sign all release
assemblies. Currently I hold the only copy of the key, a situation
that
I am not happy with. This means that identical builds cannot be
produced
by other committers.
I believe that Apache iBatis.NET distributes its strong name
private key
with their build so that anyone may reproduce the build. I don't think
that this is necessarily the best option for log4net. I am not
aware of
any Apache guidance on this specific issue. I think that our
enterprise
users do not expect our strong name key to be public.
Only official releases of log4net require the official strong name
key.
Official releases must be authorised by the PMC. Perhaps there is a
role
for the PMC to hold the strong name key and distribute it to the
release
manager. I don't exactly know where the PMC can securely hold the key,
other than doing as you suggest and storing encrypted versions of the
file. Should this be in the log4net repository or perhaps in the
committers repository?
I should be able to encrypt the key file with Ron and Curt's public
keys, so that only they can decrypt them. I think that I would need to
create I file per person.
I agree that the existing strong key should not be made public as
there was an expectancy of secrecy of the key from previous
releases. I do believe that you can encrypt the document so it can
be decrypted by multiple recipients by specifying multiple --
recipient options (see http://www.gnupg.org/gph/en/
manual.html#AEN111). I'm guessing that each additional recipient
will increase the file size proportionately, but log4net.snk should
be relatively small as will be the number of potential recipients.
I'd suggest:
Encrypting the existing log4net.snk to log4net.snk.gpg for you, Ron
and I as recipients.
Examine the file to see that it is encrypted and test that you can
decrypt it.
Commit the encrypted private key into the SVN
Modify log4net.build so that when it is building a signed release, it
decrypts log4net.snk.gpg and uses it for signing the assemblies. The
build should stop with an appropriate message if the user does not
have a matching private key installed (which should be everyone other
than Ron, you, and me.
The remaining question is how to handle Gump builds and other
insecure builds. Either we could have a public .snk which is used
for all unofficial builds which should not be trusted or use delay
signing and disable verification when running the tests.
Reproducible builds will likely mean a pretty detailed list
of O/S and software versions used in the build should be
published. Ideally kept on a separate VM just used for
builds so that an inadvertent update doesn't tweak the
process. If we could get the build done using Mono, then you
could consider the VMWare Mono image at http://
www.mono-project.com/Downloads as the build environment.
Currently our release package includes builds for Mono 1, Mono 2, .NET
1.0, .NET 1.1, .NET 2.0, .NET CF 1.0, .NET CF 2.0, SSCLI 1.0, CLI 1.0.
We won't have a build for .NET 3.0 as the framework libraries have not
bee updated in this version (really just a marketing label rather
than a
release).
We can build all these only on the Windows platform. I think that a VM
may be the right way to go with respect to building a stable secure
release environment, however we would run into licensing issues if I
tried o share/distribute the VM image.
Yep, have the same issue with log4j since log4j builds a Windows DLL
for the NTEventLogAppender. That and the redistribution license for
Java made creating a re-distributable build environment too hard for
log4j. Pretty clear that is not achievable for log4net.
Having a well-backed up VM for log4net builds should be very
helpful. To make sure that the build is reproducible, you should
clearly document how you built your VM.
2. Distribution files should be named apache-log4net-whatever.zip
I think we nearly do this, just need to replace the word 'incubating'
with 'apache'.
3. NOTICE.txt and LICENSE.txt should be NOTICE and LICENSE
I understand the motivation to put the .txt on the files, but
the ASL talks about NOTICE file.
Ok, not much trouble.
4. NOTICE and LICENSE should be in assemblies
Since apache-log4cxx-whatever.dll is likely to be
redistributed separately from the entire package, it should
include the NOTICE and LICENSE file in the assembly. See
last item on http://www.apache.org/dev/release.html.
This talks about distribution of raw artefacts, which we would like to
avoid, but accept that it may happen if distributed outside of the
ASF's
control. We can embed the files as resources within the assemblies.
I'm
not sure how useful that will be in practice as individuals receiving
the DLL file can easily argue that they did not know it contains a set
of licensing resources.
One other point here relates to the name of the DLL. Currently this is
log4net.dll. We cannot change this without breaking backward
compatibility.
http://incubator.apache.org/guides/releasemanagement.html#best-
practice-
unique-names
This section says that all release artefacts should have unique names,
preferably prefixed with 'apache'. The last package we build (1.2.10)
contains 15 different assemblies all called 'log4net.dll'. While
this is
confusing it seems to be the only way to maintain runtime
compatibility
between builds, which is essential if 3rd party DLLs are to link to
log4net assemblies.
I think placing the NOTICE and LICENSE in the .dll files should be
done. Maybe we don't redistribute them, but they will be
redistributed. You do have to go out of your way to find the NOTICE
and LICENSE file in the log4j.jar files, but they are there.
Does the version info for the .dll's identify which variant each file
is? Likely it should either have an Apache copyright or license
notice in the version info.
There is a case for keeping the log4net.dll name, so I would not
worry about the apache- prefix for it.
