uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kl├╝gl <peter.klu...@averbis.com>
Subject Re: signing Jars
Date Thu, 28 Jan 2016 08:56:38 GMT
Hi

you are of course correct. It's even maybe a bit more problematic.

Let's distinguish the two signatures:
- the gpg signature in a separate file together with the checksum (I
call it signature)
- the code signing signature in the META-INF within the jar (I call it
code signing)

This means that the signature has to happen after the code signing since
the code signing signature changes the jar (independently of the
repacking). I think the features need also code signing but no repackaging.

So the rough workflow building the update site would look like:
- (optional: isApacheRelease) checkout the previous update site
- collect the new features and plugins
- (optional: isCodeSigning) call the code signing service for the new
features and plugins
- repack new plugins
- generate update site and p2 info
- (optional: isApacheRelease) sign (sha1, md5, asc) for new features and
plugin and their packed versions
- (optional: isApacheRelease) sign (sha1, md5, asc) the modified update
site info

There is of course a lot of copying in between.

If we want to avoid the code signing for every release candidate, then
we maybe need another stage in our release process:
- prepare rc (without code signing)
- test and vote as usual
- if successful: rebuild the update site with code signing with the same
artifacts
- test and vote code signing and signatures of the update site
- if successful: release

(Another question is: do we need code signing for the jars in the
artifactory? I would say no.)

Some further comments are inline below:

Am 27.01.2016 um 21:28 schrieb Marshall Schor:
> Re: when to do the signing:
>
> My understanding which might be incorrect is that the Jar "signature" is
> compared against on computed when the jar is downloaded.
>
> I suspect this compare will fail if you compute this **before** "Compress plugin
> Jars....", because the signature will be computed on the un-packed Jar, but will
> be verified using the packed Jar.
>
> Of course, this is something to test :-).   Since both packed and unpacked
> versions are part of the Eclipse update site (the packed ones are tried first,
> unless there's some older version of Eclipse (before packing) trying to use the
> update site), we might need to sign both versions.
> ------------------------------------------
> Re: signing features - these are tiny jars, and therefore not packed; Eclipse
> might required them to be unpacked; so it's probably not a good idea to copy
> these to ${toBePacked}.

Yes, we would copy them to a different folder or we would filter the jar
to be repacked.

> ------------------------------------
> Re: calling on all jars in the folder(s): There are a lot of jars, because the
> build process puts all the versions of them into the folder; I think some part
> of the process needs all of them to build some kind of metadata.

In that folder there are only the new ones right now, the older ones are
in a different folder I think. If that is not the situation right now,
we could easily change it.

> The older Jars will already have been signed (of course, once we get this whole
> process figured out :-) ), so they should not be re-signed, I think.
> ------------------------------------
> Re: delaying signing an RC until the vote passes: I too feel it might be
> wasteful to do this for multiple release candidates; on the other hand, it does
> "test" the signing.  I wonder if the RC's could do the build using the "test"
> signing service, and then have some (automated, foolproof (?)) post-vote process
> to switch over to the official signing?

I even would skip the test code signing. I sketched your idea of the
post-vote process above.

> ----------------------
> Re: updating the top-level parent pom for all of this, cancelling pending
> releases - I think we can do this another way :-)
> The idea would be to put the changes only into the Ruta parent pom for now. 
> Once it's worked out, then we can promote those to the overall build POM.

Would that not mean that I have to prepare the ruta-2.4.0-rc3 anew?
There is no release vote, but all other stuff is done already (staged
stuff and so on).

Best,

Peter




Mime
View raw message