Closed Bug 554321 Opened 11 years ago Closed 11 years ago

3.6 partner repack signing is busted

Categories

(Release Engineering :: General, defect, P5)

All
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: salbiz)

References

Details

(Whiteboard: [q2goal][signing][partner-repacks])

Attachments

(1 file, 1 obsolete file)

Our current partner repack process is busted. We cannot produce properly signed partner builds without much manual hackery. Right now, we wait until *after* all of the regular builds are signed, and then generate partner builds from *unsigned* builds. This doesn't work, because when we sign the partner builds we end up with different sums on the internal dlls/exes, which breaks partial updates in the next release.

There's two possible solutions here:
1) Generate partner builds with already signed builds; sign the installers separately
Pros:
* Easy to kick-off
* Doesn't add lead time to signing
Cons:
* Requires repacking win32 builds a second time (because signcode refuses to the sign them otherwise)
* Requires an entirely separate signing for partner builds

2) Generate partner builds with fully unsigned builds; sign them at the same time as the others
Pros:
* Signing will be fully integrated with existing signing process
* No need to repack win32 builds a second time
* Seems "cleaner"
Cons:
* Don't yet have a way to fire the builder after all l10n builds complete
* Adds lead time to having signed builds (because partner builds can't run until all l10n builds are done, and signing can't start until partner builds are done)

I lean towards 2) mainly because it integrates the signing process fully. Which do other people prefer?
(In reply to comment #0)
> 1) Generate partner builds with already signed builds; sign the installers
> separately
> Pros:
> * Easy to kick-off
> * Doesn't add lead time to signing
> Cons:
> * Requires repacking win32 builds a second time (because signcode refuses to
> the sign them otherwise)
> * Requires an entirely separate signing for partner builds

Filed bug 558800 to cover this part.
Whiteboard: [q2goal][signing][partner-repacks]
Depends on: 560883
After bug 560883 is fixed we can update the signing scripts to sign partner builds at the same time as the rest. Here's an idea of how to do that:
Overall, the identity of a file needs to change from platform+locale to platform+locale+leading directory. I may be oversimplifying the problem but it doesn't look like we need to do much to do that. The following will need to be done:
* signing.fileInfo needs to add an attribute to dict it returns to indicate leading directory or root directory of each file. For existing files this would be None or empty, for partner builds it would be 'partner-repacks'
* the sorting done here (http://hg.mozilla.org/build/tools/file/99c8fb371499/release/signing/sign-release.py#l271) needs to never use a file with a leading path for firstLocale or the decision of which locale to use needs to be changed to include leading path. the latter would be preferable.

Overall, I don't think this is a big chunk of work.
Due to Q3 goals I won't be getting to this until Q4.
Priority: -- → P5
Syed is going to be working on this.
Assignee: bhearsum → salbiz
Implemented the approach described in bhearsum's comment. Since staging keymaster is currently unavailable, I have so far only been able to test that it does attempt to process the partner-repacks on my local machine.
Tested on keystage with target `sign-files`. A bit concerned about the robustness of the regex change, since the partner-repack names I've seen just on staging-stage don't really follow a simple pattern.
Attachment #483639 - Attachment is obsolete: true
Attachment #484012 - Flags: feedback?(catlee)
Attachment #484012 - Flags: feedback?(bhearsum)
Comment on attachment 484012 [details] [diff] [review]
add leading path to signing to identify partner-repacks

What verification have you done on a group of files signed with this patch? At the very least, we need to make sure that the checksums are the same for all of:
win32 en-US
a win32 locale
a win32 en-US partner repack
a win32 localized partner repack
Attachment #484012 - Flags: feedback?(catlee) → feedback+
Completed a test on all locales using 3.6.11, apart from setup.exe and helper.exe differing per locale and some extensions in the partner-repacks, there were no other differences among binaries to report within the group.
Comment on attachment 484012 [details] [diff] [review]
add leading path to signing to identify partner-repacks

This seems fine to me! I'm glad it was fairly simple.
Attachment #484012 - Flags: feedback?(bhearsum) → feedback+
Completed a spot-check of ~10-15 different repacks and locales to ensure that all binaries (excepting those with .chk files gnereated, as expected) had digital signatures.
Attachment #484012 - Flags: review?(catlee)
Attachment #484012 - Flags: review?(bhearsum)
Attachment #484012 - Flags: checked-in?
Attachment #484012 - Flags: review?(catlee) → review+
Comment on attachment 484012 [details] [diff] [review]
add leading path to signing to identify partner-repacks

I had a look at the verifications you did, looks great to me.
Attachment #484012 - Flags: review?(bhearsum) → review+
Comment on attachment 484012 [details] [diff] [review]
add leading path to signing to identify partner-repacks

I don't see any reason this can't land now:
changeset:   942:6bc0d93169c9
Attachment #484012 - Flags: checked-in? → checked-in+
With this patch landed we're capable of signing partner builds that were generated from unsigned builds. When bug 560883 is fixed we'll be generating & signing them as a normal part of the automation.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
I must've lost a push race when I tried to push this. It only landed just now as:
changeset:   955:0b3ad37632cf
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.