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)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mtabara, Assigned: mtabara)

References

Details

(Whiteboard: [releaseduty])

Attachments

(1 file)

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
@nthomas: does the above sound accurate to you?
Flags: needinfo?(nthomas)
Whiteboard: [releaseduty]
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)
(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)
(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
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.
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.
@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)
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)
(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.
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)
Attachment #8992005 - Flags: review?(rail) → review+
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Attachment #8992005 - Flags: feedback?(nthomas)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: