Stop serving stub installer to XP SP2 users when full installers are re-signed with SHA1 cert

RESOLVED INVALID

Status

Release Engineering
Release Requests
RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: rail, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Copy paste from https://bugzilla.mozilla.org/show_bug.cgi?id=1284484#c12:

We probably want to stop serving stub installers for these users, because the stub installer checks the signature of the full installer against a pinned value [1][2]  and it won't be able to verify the SHA1 cert.

I'll file a bug to change bouncer [3] code serving stub for XP and Co.

1. https://dxr.mozilla.org/mozilla-central/source/browser/branding/official/branding.nsi#28
2. https://dxr.mozilla.org/mozilla-central/source/browser/installer/windows/nsis/stub.nsi#1566
3. https://github.com/mozilla-services/go-bouncer/blob/master/handlers.go#L118-L121

Assigning to myself for now to figure out if this is the proper strategy.
Mat, can you confirm my assumption that our stub installers check the signature of downloaded full installers?
Flags: needinfo?(mhowell)
(In reply to Rail Aliiev [:rail] from comment #1)
> Mat, ...

Of course, it's Matt. Apologies. :)
(In reply to Rail Aliiev [:rail] from comment #0)
> Copy paste from https://bugzilla.mozilla.org/show_bug.cgi?id=1284484#c12:
> 
> We probably want to stop serving stub installers for these users, because
> the stub installer checks the signature of the full installer against a
> pinned value [1][2]  and it won't be able to verify the SHA1 cert.

I think that's already the case? See https://github.com/mozilla-services/go-bouncer/commit/0da12366
(In reply to Rail Aliiev [:rail] from comment #1)
> Mat, can you confirm my assumption that our stub installers check the
> signature of downloaded full installers?

Yes, the stub does check the downloaded full installer against a pinned name and issuer (the same ones used to verify updates), and it uses the Windows crypto API's to do that.

I did seem to remember that we had already done this though, and comment 3 seems to confirm that.
Flags: needinfo?(mhowell)
(In reply to Hector Zhao [:hectorz] from comment #3)
> I think that's already the case? See
> https://github.com/mozilla-services/go-bouncer/commit/0da12366

Oh, I see the hack now! :)

Maybe we should modify sha1Product() to return no stub instead?
(In reply to Matt Howell [:mhowell] from comment #4)
> (In reply to Rail Aliiev [:rail] from comment #1)
> > Mat, can you confirm my assumption that our stub installers check the
> > signature of downloaded full installers?
> 
> Yes, the stub does check the downloaded full installer against a pinned name
> and issuer (the same ones used to verify updates), and it uses the Windows
> crypto API's to do that.

Thanks! Now it's much clearer to me.
Resolving as INVALID, because it's not an issue.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.