Status

defect
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: rail, Assigned: rail)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

https://bugzilla.mozilla.org/show_bug.cgi?id=1284484#c5 gives some idea how to run them.

* Modify the repack script to accept a config variable which allows skipping the following steps:
  self.copyFiles()
  self.addPadding()
  self.internallySignBuild()
  self.repackBuild()

* create repack configs

* schedule the repacks similar to https://github.com/rail/releasetasks/blob/master/releasetasks/templates/firefox/partner_repacks.yml.tmpl#L47-L88

* make sure to exclude them from the main push similar to eme-free in https://github.com/rail/releasetasks/blob/master/releasetasks/templates/firefox/push_to_releases.yml.tmpl#L81 (they will be copied by https://github.com/rail/releasetasks/blob/master/releasetasks/templates/firefox/partner_repacks.yml.tmpl#L129)

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

* add new bouncer product in https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/releases/bouncer_firefox_release.py 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.
Rail,

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?

Specifically-->

* User goes to firefox.com 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

https://reviewboard.mozilla.org/r/72642/#review70282
Attachment #8782477 - Flags: review?(bugspam.Callek) → review+
Keywords: leave-open
Pushed by raliiev@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2c239b4efab7
Add bouncer products for SHA1 installers r=Callek a=release DONTBUILD
I'll keep an eye on this
Assignee: nobody → rail
Posted file PR
Let's try mkaply this time ;)
Attachment #8784911 - Flags: review?(mozilla)
Comment on attachment 8784911 [details] [review]
PR

reviewed and merged.
Attachment #8784911 - Flags: review?(mozilla) → review+
Posted 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 (https://hg.mozilla.org/integration/mozilla-inbound/rev/2c239b4efab7#l1.16 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

https://reviewboard.mozilla.org/r/72642/#review73292
Attachment #8782477 - Flags: review?(jlund) → review+
Pushed by raliiev@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/64b21c1e7b92
Automatically update SHA1 bouncer aliases r=jlund a=release DONTBUILD
Worked fine in 49.0b9
Status: NEW → RESOLVED
Closed: 3 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.