On Apr 17, 2007, at 5:27 AM, Paul Smith wrote:
The ant build.xml can has a 'webstart-dist' target and an 'iOrb'
type target. They generate and sign the jar files (it prompts
you for a local keystore and certificate passwords during the
signing process; I have my thawte certificate loaded in a
keystore locally). I think I had a target that uploads those
signed stuff to the area where the Webstart bundle is kept, but
due to symlink weirdness with Webstart, there's still a bit of
hand moving of files around during the deployment.
log4net requires signed assemblies and until recently only Nicko
was able to produce them. He has recently placed an encrypted
signing key in the SVN so that Ron or I can also produce builds of
log4net. Would we'd want to do the same type of thing for Chainsaw?
The main problem here is that the signature being signed with is my
own personal one containing my @apache.org email address. To get
the email certificate properly certified, I had to get 2 Thawte
signatories to meet me in person and check documentation. I'm not
sure how one gets around that for a generic 'log4j' certificate.
I'm not sure I'd like to upload my signature that anyone could sign
it with.
Having said that, if we can work out how we can generate a
certificate that all the logging services people can use, I'd vote
for that. Can you explain exactly how the certificate was
generated for log4net?
The public/private key pair was (most likely) generated by Nicko
using the Strong Name tool (sn.exe) before log4cxx moved to Apache.
There is no web-of-trust or other third-party validation for the
public key and the key is not explicitly tied to a person or entity.
Any change in the key used to sign the assembly would however result
in the new assembly not being recognized as an acceptable replacement
for the old assembly, so drop-in replacement requires the same key be
used regardless of who builds the package. However, you don't just
want anyone having access to the key or spoofed implementations can
get in the wild and would be assumed to be legitimate. The private
key is in the SVN but encrypted so it can be decrypted using Nicko,
Ron and my GPG private key. Any one of the three of us can add
additional individuals who can decrypt the file.
Different GPG keys can be used to sign ASF releases and the keys are
tied to a particular individual. It doesn't matter who signs the
release, just that the validity of the key can be confirmed by the
web of trust. So Mark could sign one release of log4j and I could
sign the next. If someone cares, they could check that Mark and I
have signed the others keys, so our identities are equally trustworthy.
The WebStart model appears to use X.509 certificates which route back
to a Certificate Authority, hence dealing with Thawte signatories.
Doesn't seem to be any bridge between the GPG model and the X.509
model which would allow us to use our existing GPG code signing
keys. The keys are tied to personal identities, so sharing signing
keys as required by the log4net is inappropriate. It should not
matter however if Paul signs one release and I sign the next (though
my Thawte key is just the freemail variety).
I'm getting dizzy and maybe can find some way to reconcile all this.
I think we have to have our primary distribution means a
classic .tar.gz and .zip going through the standard release process.
Whether or how we make a WebStart version available after that is a
separate issue.
I'm going to sleep now. I may take a run at
LogFilePatternReceiver tomorrow unless you want to take it.
I thought you were going to sleep! Are you still in US Central TZ?
Still here in Houston. Was a late night.
I've got the source file change tool down, so I'll take a pass at
applying the tool to the chainsaw code base tomorrow unless
someone calls me off (for example, if you have a lot of
uncommitted changes).
Nothing local changed at all, save for the application of that
patch you sent to change the log4j 1.3->1.2 dependency, which can
be easily redone if need be.
Paul
Will commit shortly.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
