Closed Bug 1235894 Opened 8 years ago Closed 8 years ago

investigate potential better way to deal with SHA-1 deprecation for XP SP2 users

Categories

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

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Unassigned)

References

Details

(Originally sent as e-mail, moving to a bug for better tracking.)

Some folks are very corcerned about 43.0.1 being served to XP users indefinitely, because it will quickly become vulnerable to security exploits. Because of that, they want to look at providing SHA-1 signed binaries for those users for as long as possible. My understanding of the plan is:
1) Proceed with 43.0.1 watershed for now.
2) In the new year, see how XP responds to a binary that is newly signed with a SHA-1 certificate. The thinking here is that because XP SP2 is so old, it won't pay attention to the SHA-1 deprecation.
3) If all looks good, build automation and website gunk that lets us sign & serve separate binaries for XP SP2. The RelEng parts of this were previously scoped in https://docs.google.com/document/d/1OAmJmTkKNH-QYYkViiBCGpvYCECLVVK66Ycp9THPiBs/edit# ("Option 2" section).

The document above talks about us possibly buying a new SHA-1 cert as the current one expires in September 2016. According to https://cabforum.org/2014/10/16/ballot-118-sha-1-sunset/, we should be able to get a new SHA-1 certificate that expires on January 1st, 2017 anytime up until January 15th, 2016. That would buy us 4 months on top of the current one.


Rail suggested that #3 we might be able to use partner repack infra to do the resigning if we end up doing this. It may break stub installer (do we care?). We should make sure that the timestamp server won't reject us, too.
In bug 1284484 we are going to refresh the installers (we don't serve stub installers to XP/Vista users anymore). It's not clear yet what we are going to do in the future (serve 48 forever, refresh them from time to time manually or automate using partner repacks)
See Also: → 1284484
(In reply to Rail Aliiev [:rail] from comment #1)
> ... It's not clear yet what we are going
> to do in the future (serve 48 forever, refresh them from time to time
> manually or automate using partner repacks)

Hi Rail,

Given the quotes below about expirations of SHA-1 certificate, it's my understanding that it won't be possible to create these sha1 repacks (at the latest) after Jan. 1st, 2017?

The authenticode certificate for signing the Fx China repack will also expire on Oct. 21st, 2016, please let us know how to get one with extended validaty if that's possible, thanks.

(In reply to Ben Hearsum (:bhearsum) from bug 1284484 comment #0)
> ... Our SHA-1 cert expires in September, ...

(In reply to Ben Hearsum (:bhearsum) from comment #0)
> ... The document above talks about us possibly buying a new SHA-1 cert as the
> current one expires in September 2016. According to
> https://cabforum.org/2014/10/16/ballot-118-sha-1-sunset/, we should be able
> to get a new SHA-1 certificate that expires on January 1st, 2017 anytime up
> until January 15th, 2016. That would buy us 4 months on top of the current
> one.
Actually we renewed the cert in bug 1296362 and it should be valid for another 3 years.
Let me know if you need a hand getting a new SHA-1 cert. DigiCert still sells them.
(In reply to Rail Aliiev [:rail] from comment #3)
> Actually we renewed the cert in bug 1296362 and it should be valid for
> another 3 years.

(In reply to Ben Hearsum (:bhearsum) from comment #4)
> Let me know if you need a hand getting a new SHA-1 cert. DigiCert still
> sells them.

Thanks! We'll try and talk to local resellers first.
(In reply to Ben Hearsum (:bhearsum) from comment #4)
> Let me know if you need a hand getting a new SHA-1 cert. DigiCert still
> sells them.

FYI, we renewed both of our sha1/sha2 authenticode certificates through a local reseller. Thanks.
We ship SHA1-signed installers to XP/Vista users now.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.