Verify output of sign-release.pl on new keymaster

RESOLVED WONTFIX

Status

Release Engineering
General
RESOLVED WONTFIX
9 years ago
5 years ago

People

(Reporter: catlee, Assigned: catlee)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

9 years ago
Before doing official releases on the new keymaster, we need to be sure that the output it's generating is valid.

Signing the recent 3.0.11 build2, and 3.5b99 builds on the new keymaster, and then comparing against the ones produced on the old keymaster would be a good place to start.

Things to check:
- Same # of files produced
- Unpacked contents are the same, except for .exes and .dlls
- Signatures are valid on .exes and .dlls (can we done w/ checktrust)
- The installer files have appropriate logos, etc.
Assignee: nobody → lsblakk
Without meaning to be disrespectful here, we need someone with some signing experience to look at this. Chris AtLee and Ben H have been looking already, IIRC.
Assignee: lsblakk → nobody
Assignee: nobody → catlee
(Assignee)

Comment 2

9 years ago
The following test has passed for both files signed on the original keymaster, and those signed on the new keymaster:

- For each .exe / .mar file:
  - The list of files after unpacking is the same as the unsigned .exe / .mar
  - Every .exe and .dll has a valid signature (except for freebl3.dll and softokn3.dll)
  - The update.manifest has the same sorted contents between unsigned and signed files
  - All other files have the same SHA1 hash

The contents of .mar files have been bunzipped for comparison.  Should the compressed versions be identical as well?
(Assignee)

Comment 3

9 years ago
The .exe and .mar files generated on the new keymaster are consistently larger than those from the original keymaster by 2-10kb.  It would be great to know why!
(In reply to comment #3)
> The .exe and .mar files generated on the new keymaster are consistently larger
> than those from the original keymaster by 2-10kb.  It would be great to know
> why!

Random guess: is there a block size difference between the filesystems? I don't think that would cause it...but may as well throw it out there.
(Assignee)

Comment 5

9 years ago
Some relevant software versions:

        Old keymaster       New keymaster
bzip    1.0.5               1.0.5
7z      4.32                4.65
mar     e9c07943e883        e9c07943e883 (sha1sum)
upx     1.25 (0.84, 1.02)   3.01 (na, 1.03)
We have 7z 4.42 on the windows build slaves for moz2 pool and Fx3.0, and 3.12 on Tb 2.0 (*patrocles). In an ideal world, where nightlies are as close possible to releases, I think we'd use the same version of 7z everywhere (T'bird excepted). We may be relatively OK by having the self-extractor checked into the tree.
(Assignee)

Comment 7

9 years ago
Using 7z 4.32 from the old keymaster on the new one produces output that is more similar is size to the original packages.
(Assignee)

Comment 8

9 years ago
According to 7z's author, the increase in size is due to some changes that were made to optimize the compression speed.  And indeed, compression is much faster: 22 seconds for the old 7zip vs. 11 seconds for the new 7zip.
(Assignee)

Comment 9

9 years ago
Adding -m1fb=128 -m1lc=4 to the 7z call improves the output size quite a bit, both for the old 7z and the new 7z.

-m1fb=273 -m1lc=8 makes it even smaller.

How low can we go?
See also bug 409455 :)
(Assignee)

Comment 11

9 years ago
The new keymaster will be using the new signing scripts from bug 470146, which will be getting extra QA done on the builds at some point.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.