Re: [jakarta.ee-spec.committee] [jakartaee-spec-project-leads] TCK file

[David Blevins <dblevins@xxxxxxxxxxxxx>]

Thank you so for much for the review!


> On Aug 20, 2019, at 1:43 PM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
> 
> David Blevins wrote on 8/16/19 10:08 PM:
>> Behold the awesomeness of our glorious new binary signing and promotion setup:
>> 
>> - https://github.com/jakartaee/specification-tools/tree/master/promotion
> 
> In the description of the parameters, "scrubbed" means "validated", and the
> job fails if the validation fails, right?  "Scrubbed" sounds more like you
> clean it up and keep going.
> 
> The regex for the version could be "[1-9][0-9]*(\.[0-9]+)?" if you want to
> be more precise.  (Yes, that's probably excessive.  :-))

I was going for excessive, so of course I like it :)  Change made:

 - https://github.com/jakartaee/specification-tools/commit/ee8bf41a7e69d0026d0b081d77893c68d29f8c3c

Also changed the phrasing to use "validated."

> If the key is ever "rotated", would you expect to re-sign all the existing
> artifacts?  Should there be a job to do that?

We would not need to re-sign the artifacts for a routine rotation.

If a key was compromised, then we would need to re-sign.  However, if we rotated say every year, we'd have to resign only one year's worth of binaries.

Rotating annually is something we should probably do.  The script is already setup to make that a 5-minute task on our end, so there's no real reason not to do it.

Best time to do it would be just after everyone renews (or does not renew) their memberships.

>> Sample run:
>> 
>> - https://download.eclipse.org/jakartaee/wombat/2.0/
> 
> My browser thinks the *.sha256 files are zip files.  Does something need
> to be done on the server to make sure they're advertised as text/plain files?

That one I do not know.  I'll file a bugzilla to ask the infra team for guidance.  They might simply suggest a .txt extension, but we'll see.

> I'm not a PGP expert but the signatures seem a bit weird.  It looks like the
> data is base64 encoded, yet the last line of the data *start* with "=".
> Usually base64 data will use "=" at the end to pad out the data.  Is there
> some different use of "=" in PGP signatures?

I'm not an expert on that one either, but I do know the "ascii armor" as they call it is many fields, so that might have something to do with it.

> Should the signatures of two files with identical SHA-256 hash codes also
> be identical?  Or do the signatures incorporate some time or random element?

PGP signatures are specifically designed to not be identical so the key is hard to imply.  The hashes will be identical, so that's the only way to really "eyeball" if file we expected was actually published.

>> - https://ci.eclipse.org/jakartaee-spec-committee/job/promote-release/31/artifact/wombat-2.0.html
> 
> I get a 404 when trying to access this page.  Looks like that job has
> rolled off the bottom of the list of saved jobs.  I was able to look
> at a newer job however and it looks fine.
> 
>> For some reason the lovely CSS on the html page doesn't render.  Not really important, that page is just for an audit trail.
> 
> If these are an audit trail they should be saved somewhere else more permanent.

The Eclipse team recommended we save the reports somewhere in our download area, which I think is a good idea.  Fixes the CSS issue and the lost build issue.

> And it would be nice if they recorded who started the job.

There's a specific plugin we need installed in our Jenkins instance so we can have that information in our job and use it in the report.  When we get that, I'll add this and the above improvement.

Filed them both so we can track:

 - https://github.com/jakartaee/specification-tools/issues/2
 - https://github.com/jakartaee/specification-tools/issues/3


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com