Closed Bug 1290179 Opened 8 years ago Closed 8 years ago

Automate SHA1 repacks


(Release Engineering :: Release Automation: Other, defect)

Not set


(Not tracked)



(Reporter: rail, Assigned: rail)




(3 files) gives some idea how to run them.

* Modify the repack script to accept a config variable which allows skipping the following steps:

* create repack configs

* schedule the repacks similar to

* make sure to exclude them from the main push similar to eme-free in (they will be copied by

* Create aliases for installers (Firefox-{,beta,esr}-sha1?) aliases in bouncer

* add new bouncer product in and friends, make sure to use the alias, so we update it automatically.

Updating the alias may lead to a race condition, especially for betas, when we have repacks still in progress, but we publish to beta. Not sure how to prevent this... I don't really want to block publishing a release on partner repacks. Maybe we can split the update aliases step into 2 and make the second depend on partner repacks.

Before we go down this path, is it actually worthwhile to do an SHA1 signed installed based off an installer for a Firefox version that requires SSE2?


* User goes to to download the browser, on windows, in a system that we can't detect if they are new enough for SHA2 (and thus also can't presumably detect SSE2 support)
* User needs to download a Firefox that doesn't require SSE2 (Firefox 48 being the last in that set)
* User can then update to a newer Firefox that is signed without SHA1 via our updater code, AND Firefox+Balrog will also detect if the user can download/run a Firefox with SSE2 as a requirement.

If however, we don't deem lack of SSE2 Support to be a blocker to detect on the website front, we certainly can do this [SHA1] with newer versions on the download page itself.

I'm not sure who makes that call, on the user facing clickthrough paths, but I think it makes sense to get that call before investing in this work.
Depends on: 1290737
Comment on attachment 8782477 [details]
Bug 1290179 - Automatically update SHA1 bouncer aliases  a=release DONTBUILD
Attachment #8782477 - Flags: review?(bugspam.Callek) → review+
Keywords: leave-open
Pushed by
Add bouncer products for SHA1 installers r=Callek a=release DONTBUILD
I'll keep an eye on this
Assignee: nobody → rail
Attached file PR
Let's try mkaply this time ;)
Attachment #8784911 - Flags: review?(mozilla)
Comment on attachment 8784911 [details] [review]

reviewed and merged.
Attachment #8784911 - Flags: review?(mozilla) → review+
Attached file PR for releasetasks
Attachment #8785342 - Flags: review?(jlund)
Attachment #8784911 - Flags: checked-in+
Attachment #8785342 - Flags: review?(jlund) → review+
Worked fine in Firefox 49.0b8. Still need to enable aliases ( and friends) after bug 1295275 is live
Depends on: 1295275
Comment on attachment 8782477 [details]
Bug 1290179 - Automatically update SHA1 bouncer aliases  a=release DONTBUILD
Attachment #8782477 - Flags: review?(jlund) → review+
Pushed by
Automatically update SHA1 bouncer aliases r=jlund a=release DONTBUILD
See Also: → 1300060
Worked fine in 49.0b9
Closed: 8 years ago
Resolution: --- → FIXED
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
You need to log in before you can comment on or make changes to this bug.