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 Fri, 29 Jan 2016 10:02:08 GMT

Re: repack earlier
Ah ok, the repack changes also the content of lined jars, right?
But this step also creates the pack.gz files. I think that the code
signing has to happen before that. I have to check this.

Re: artifacts.jar and content.jar
I forgot about both. I do not know if the need to be signed, but I would
assume it.

Re: avoid rebuilding
Sounds to me like a separate ant build, which is maybe a better choice
than to configure the maven build.

Re: artifactory
I  really should stop to use this term synonym for maven central, nexus
and all. Yes, was thinking about maven central and the staging repository.

Re: same folder
In the ruta update site build, toBePacked contains only the new plugins.
The folder eus-work contains all features and plugins. Well, it does not
really matter since we would need to change something anyway and then we
need to take care that the folders and their content are corrrect.

Re: hold up rc3
I could really need the 2.4.0 release right now for different reasons.
It blocks some other stuff which I need to get done before mid of Feb.
I'll start the vote today without code signing.



Am 28.01.2016 um 18:17 schrieb Marshall Schor:
> On 1/28/2016 3:56 AM, Peter Klügl wrote:
>> 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.
> Sounds right to me.
>> So the rough workflow building the update site would look like:
>> - (optional: isApacheRelease) checkout the previous update site
>> - collect the new features and plugins
> I think you need to do any pack/repacking here of the jars, because that changes
> the Jars' data, which the code signing is based on.
>> - (optional: isCodeSigning) call the code signing service for the new features and
> The repack has to be done earlier
>> - repack new plugins
>> - generate update site and p2 info
> This generates "artifacts.jar" and "content.jar".  My guess is that these might
> need to be code-signed, too?
>> - (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
> Probably better to avoid "rebuilding", and just take the unsigned artifacts from
> the RC site and code-sign them, and regenerate the signatures, too.
>> - test and vote code signing and signatures of the update site
> If the post RC vote process is only to add the code-signing and redo the
> signatures, I wonder if there can be an automatic validation that compares these
> with the RC site (the Jars should be the same other than the added code-signing,
> the .asd/md5/sha1 signatures should check as OK).  If we have that, then as long
> as the release manager runs the check, no additional voting would be necessary.
> If the RC artifacts were put into the dist.apache.org/repos/dist/dev/uima spot,
> it would be verifyable in the future, if need arises.
>> - if successful: release
>> (Another question is: do we need code signing for the jars in the
>> artifactory? I would say no.)
> Not sure what the "artifactory" is?  If you mean maven central, I would agree-
> not needed, but if both code-signed and code-unsigned versions are available, it
> would be nice to promote the signed versions, I think. 
>> 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.
> I think they're in the same folder because part of the process of creating the
> update-site "artifacts.jar" and "content.jar" needs this layout, I believe.
>>> 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).
> I would say that you don't need to hold up rc3 for all this - it may take some
> time to work out the kinks.
> Of course, on the other hand, this provides the incentive/motivation to work on
> this :-)
> -Marshall
>> Best,
>> Peter

View raw message