Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 489326

Summary: Improve "update pack.properties" function
Product: [Technology] CBI Reporter: David Williams <david_williams>
Component: signingAssignee: David Williams <david_williams>
Status: CLOSED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: mikael.barbero
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Mac OS X   
See Also: https://git.eclipse.org/r/69792
https://git.eclipse.org/c/cbi/org.eclipse.cbi.git/commit/?id=1f1bbad1d8cd7d70413f6a4cd905cdffc37ef436
Whiteboard:

Description David Williams CLA 2016-03-09 18:10:10 EST
These are some follow-up work from bug 487857. 

Technically 2 enhancements in one bugzilla entry ... but ... didn't want to lose them. 

1. We currently "unzip" and "re-zip" the supplied zip file. There should be an easy way to simply 'add' the pack.properties file, instead of re-zipping everything. At a minimum, this will probably be more efficient, and more important, in comment 57 I mention that with some "bugs" that existed in our code, we can actually "zip up" the incorrect "zip entry names". So, best not to mess with raw entries, unless we have to. 

2. We currently use simple heuristic to check "if signed", by checking for files such as "ECLIPSE_.SF" but technically speaking in some future version, it might not literally be that exact name so we should check for ECLIPSE[legalcharacters].SF. We might also want to make a property of what permissible names are ("ECLIPSE" being the default). We might also want to print warnings if some other signature found. In addition, we *might* want to do more of a "validity" check too, that the file is truly "legally signed" though that would take longer.
Comment 1 Mikaël Barbero CLA 2016-03-10 07:58:38 EST
We may want to reduce the verbosity of the log too ;) (See bug 487857 comment 77)
Comment 2 David Williams CLA 2016-03-10 08:36:55 EST
(In reply to Mikael Barbero from comment #1)
> We may want to reduce the verbosity of the log too ;) (See bug 487857
> comment 77)

I think that's fine once we know it is working well. You can "fix" when you invoke ant, with -Dverbose=false

Or ... we could fix default in the Java code, if you would prefer? 

I would recommend doing in the ant script if you want to do it "now", and I'll fix the default once I make the other enhancements mentioned in this bug.
Comment 3 Mikaël Barbero CLA 2016-03-10 08:49:53 EST
(In reply to David Williams from comment #2)
> (In reply to Mikael Barbero from comment #1)
> > We may want to reduce the verbosity of the log too ;) (See bug 487857
> > comment 77)
> 
> I think that's fine once we know it is working well. You can "fix" when you
> invoke ant, with -Dverbose=false

Sure, it's fine to me like this. I already forgot the option was already there ;)
Comment 4 Mikaël Barbero CLA 2016-03-10 08:58:56 EST
(In reply to Mikael Barbero from comment #3)
> (In reply to David Williams from comment #2)
> > (In reply to Mikael Barbero from comment #1)
> > > We may want to reduce the verbosity of the log too ;) (See bug 487857
> > > comment 77)
> > 
> > I think that's fine once we know it is working well. You can "fix" when you
> > invoke ant, with -Dverbose=false

Done and deployed.
Comment 5 David Williams CLA 2016-03-31 14:46:24 EDT
Reminder to turn verbose default "off" soon. See bug 489890 comment 54. 

Also, I would be interested if there is a way to "pipe" such output to the same place as the rest of the "signing queue" output (or, somewhere else) instead of the "users output". The "verbose" mode is more to assist with debugging a problem with the code or a particular zip file, which most users of the signing service should not have to be concerned with. But, we should do this 'piping' only if easy, since by default it will be off nearly all the time.
Comment 6 David Williams CLA 2016-03-31 14:59:13 EDT
Along with item 1 in comment 0, we should consider having a *copy* of the original file that we modify, and then pass that copy of the file to the jar signer. The jar signer would still produce the right output. 

After seeing some of the problems in bug 489890 it made me realize that "touching" the users input is not a good practice. We do not, after all, 
know what their intent is. And while they *can* specify their original input be "overwritten", that is not always the case and as far as we know they may re-fetch that copy and do something else with it, in which case an "extra file" in the zip might interfere with whatever they are doing. In theory. So just seems like a better practice to copy it first -- or, perhaps make a 'backup' of their original input? Though now that I think of it, we were making a backup originally and even that can "interfere" unless in a "hidden" location -- and then we'd have to be sure not to overwrite the signed zip, if they choose to overwrite their original with the signed version ... so this sounds too complicated unless we know it causes a problem. 

File under "notes to self". :/
Comment 7 David Williams CLA 2016-03-31 15:06:33 EDT
And, while I am making notes to myself, in bug 489890 we got around "name collisions" in a fairly good (i.e. "bulletproof") way, but I think we are (still) ignoring the original "path" that the original zip file is in. To take advantage of that should have been "common sense". (But, once item 1 in comment 0 is done, we may need 'tmp' a lot less -- unless it is to save a backup copy of original input :)
Comment 8 Eclipse Genie CLA 2016-04-03 15:58:07 EDT
New Gerrit change created: https://git.eclipse.org/r/69792
Comment 9 David Williams CLA 2016-04-03 16:01:57 EDT
(In reply to Eclipse Genie from comment #8)
> New Gerrit change created: https://git.eclipse.org/r/69792

This change set's the verbose attribute to false in the ant invocation file. 
I was under the impression that ant script was not literally used in the signing system but am not sure. And, even if it was, the setting on the command line should still "override" it. 

Also made minor improvements to error checking and messages. (None especially important to issues people have seen, though I did put the word "ERROR:" in some of the messages.)
Comment 11 Mikaël Barbero CLA 2022-01-13 11:50:14 EST
I'm considering this one as fixed.