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 plugins
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
>
>
>
>
