Closed
Bug 1471223
Opened 6 years ago
Closed 6 years ago
firefox-sha1-ssl is not getting updated by automation
Categories
(Release Engineering :: Release Automation: Other, enhancement)
Release Engineering
Release Automation: Other
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mtabara, Assigned: mtabara)
References
Details
(Whiteboard: [releaseduty])
Attachments
(1 file)
1.47 KB,
patch
|
rail
:
review+
mtabara
:
checked-in+
|
Details | Diff | Splinter Review |
Randomly noticed `firefox-sha1-ssl` is still pointing to Firefox-52.7.3esr-sha1 while `firefox-sha1` is correctly updated by automation to Firefox-52.9.0esr-sha1. Since I only see the latter in the configs[1] used by releasetasks esr52 bouncer aliases tasks, I strongly suspect we never actually added it there. Solution to this long term: (well, long as in until 52 dies :p) * add corresponding entries for the `firefox-sha1-ssl` as we have for `firefox-sha1` and make sure that bouncer aliases gets fixed Solution to this short term: * manually update the `firefox-sha1-ssl` in bouncer to point to Firefox-52.9.0esr-sha1. Next release will be 60.2.0esr anyway so I guess ... we're done anyway with it. [1]: https://hg.mozilla.org/mozilla-central/file/tip/testing/mozharness/configs/releases/bouncer_firefox_esr.py#l64
Assignee | ||
Comment 1•6 years ago
|
||
@nthomas: does the above sound accurate to you?
Flags: needinfo?(nthomas)
Assignee | ||
Updated•6 years ago
|
Whiteboard: [releaseduty]
Comment 2•6 years ago
|
||
According to bug 1445688 firefox-sha1-ssl is not actually used. IIRC there's something hardcoded in bouncer which prevents us swapping without extra work there. Perhaps we should just remove firefox-sha1-ssl ?
Flags: needinfo?(nthomas)
Comment 3•6 years ago
|
||
(In reply to Nick Thomas [:nthomas] (UTC+12) from comment #2) > Perhaps we should just remove firefox-sha1-ssl ? mihai, nick, - any downside to this? mihai, not priority but can I assign this to you to resolve before we do our next esr release?
Flags: needinfo?(mtabara)
Assignee | ||
Comment 4•6 years ago
|
||
(In reply to Jordan Lund (:jlund) from comment #3) > (In reply to Nick Thomas [:nthomas] (UTC+12) from comment #2) > > Perhaps we should just remove firefox-sha1-ssl ? > > mihai, nick, - any downside to this? > > mihai, not priority but can I assign this to you to resolve before we do our > next esr release? Sure, was on my list to finish anyway but leaf-tasks took priority over everything. Will leave the NI here just to remind myself of this.
Assignee: nobody → mtabara
Status: NEW → ASSIGNED
Comment 5•6 years ago
|
||
I can't find any matches in bedrock for 'firefox-sha1-ssl' or 'sha1', so I'm pretty sure www.mozilla.org isn't using it at all. That leaves random requests from the internet, and given the lack of complaints about staleness I wouldn't be very concerned about that.
Comment 6•6 years ago
|
||
I'd also check https://github.com/rail/go-bouncer/blob/master/handlers.go for usage. Bouncer does some redirect logic depending on the UA.
Comment 7•6 years ago
|
||
https://github.com/rail/go-bouncer/blob/master/handlers_test.go#L158 should give you an idea about the usage.
Assignee | ||
Comment 8•6 years ago
|
||
@pmac: hey! from our releng side, it sounds like we have a hiccup in updating the `firefox-sha1-ssl` alias whenever we ship another 52.X.Y release (EOL soon!). My initial thought was to fix this but then digging in various resources that have been pointeed above shows no use of this alias anywhere. I was wondering if I can get your opinion here whether it makes sense to keep this at all anymore? Should we remove this or let it die according to 52 EOL? Thank you!
Flags: needinfo?(mtabara) → needinfo?(pmac)
Comment 9•6 years ago
|
||
It's true that we no longer use this alias on the website. Our sha1 TLS cert has expired and we're unable to get a new one and so if a user on Windows XP pre SP3 tries to access the site they won't be able to. See https://github.com/mozilla/bedrock/issues/5567 If a person with such a machine already has Firefox however they could get to the website and download another build. My understanding is that bouncer will detect the platform for such a request and serve them a redirect to a Firefox build signed with a sha1 cert so that it can be installed on that old XP, but I could be wrong about that. I'm also unsure if this alias is in any way related to the update mechanism for these older builds.
Flags: needinfo?(pmac)
Assignee | ||
Comment 10•6 years ago
|
||
(In reply to Paul [:pmac] McLanahan ⏰ET needinfo? me from comment #9) > It's true that we no longer use this alias on the website. Our sha1 TLS cert > has expired and we're unable to get a new one and so if a user on Windows XP > pre SP3 tries to access the site they won't be able to. See > https://github.com/mozilla/bedrock/issues/5567 > > If a person with such a machine already has Firefox however they could get > to the website and download another build. My understanding is that bouncer > will detect the platform for such a request and serve them a redirect to a > Firefox build signed with a sha1 cert so that it can be installed on that > old XP, but I could be wrong about that. I'm also unsure if this alias is in > any way related to the update mechanism for these older builds. Thanks for fast turnaround @pmac! Rather than adding some risk, even minimal, with removing this, it sounds like I could instead follow-up with a fix to ensure that we keep this alias up-to-date with the upcoming (and last) esr 52 release in September. And in the future, when we'll do a general cleanup at some point, we'll likely ditch this altogether.
Assignee | ||
Comment 11•6 years ago
|
||
This is not the best solution, however it should just work. (TM) * I've copy-pasted the configs for `sha1-installer` and turned off the uptake monitoring which we don't care about (we didn't so far) * rest of configs are similar with `sha1-installer` * bouncer submission will barf for `sha1-installer-ssl` as product will have existed[1] (since the product name is similar to `sha1-installer`, being set to `Firefox-%(version)-sha1` * if by any chance the dict picks up the `sha1-installer-ssl` first, it'll just work as the configs are identical to the `sha1-installer`. So in this case, the same configs would be pushed to bouncer, following which the `sha1-installer` would barf for [1]. * the bouncer aliases should work smoothly as it iterates[2] through the products and updates all the ones with "alias" present. This way it'll update the `sha1-installer-ssl` too Does this sound sane to you? [1]: https://hg.mozilla.org/releases/mozilla-esr52/file/tip/testing/mozharness/scripts/bouncer_submitter.py#l140 [2]: https://hg.mozilla.org/releases/mozilla-esr52/file/tip/testing/mozharness/scripts/release/postrelease_bouncer_aliases.py#l98
Attachment #8992005 -
Flags: review?(rail)
Attachment #8992005 -
Flags: feedback?(nthomas)
Updated•6 years ago
|
Attachment #8992005 -
Flags: review?(rail) → review+
Assignee | ||
Comment 12•6 years ago
|
||
Comment on attachment 8992005 [details] [diff] [review] [in-tree] add entry for firefox-sha1-ssl in bouncer configs https://hg.mozilla.org/releases/mozilla-esr52/rev/7aeac222129879d484ddf2b3899552a1226e0cdc
Attachment #8992005 -
Flags: checked-in+
Assignee | ||
Updated•6 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Attachment #8992005 -
Flags: feedback?(nthomas)
You need to log in
before you can comment on or make changes to this bug.
Description
•