1205843 - maintenance service doesn't work with SHA-2 signed updater

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect)

Description

[[e-mail] (:bhearsum)]

I discovered this while testing our upgrade to a SHA-2 Authenticode cert in bug 1079858. It looks like the issue is that the maintenance service requires the updater binary's signature to match an issuer that is stored in the registry. This is only updated on first install, so even if we change the pinning in tree, it still relies on the old issuer.

The way things stand now, background updates will break on at least Windows 7 when we upgrade to SHA-2. Curiously, they seem to work fine with on XP (SP2 or 3) even with the SHA-2 signed updater. I haven't tested other platforms yet.

Perhaps it's time we get rid of cert pinning entirely here? Or if we need to keep it, perhaps hard code it in the maintenance service binary instead of the registry. I put together a hacky attempt at the latter in this try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6a5130b2520e

Comment 1

[[e-mail] (:bhearsum)]

[Tracking Requested - why for this release]: We need to upgrade to SHA-2 before the end of the year, otherwise Firefox will cease to work on Windows 7 and higher (and certain versions of XP and Vista).

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

Matt, this may be of interest to you based on our talking yesterday about Windows install and update work. Want to take a look?  I can fill you in on some more of the background if you like.

Comment 3

[Rail Aliiev [:rail]]

Any progress here? This bug is critical and has to be shipped with Firefox 43 in order to be in time before EOY, when SHA1 will be deprecated by Windows.

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

Benjamin or Robert, can you help us find an owner for this bug? We have to ship this in 43.

Comment 5

[Molly Howell (she/her) (no longer active)]

Finally had a chance to start looking at this, sorry it took me so long.

Someone may have to correct me if I've missed something, but by my reading of our NSIS code in shared.nsh, it looks like we set the certificate pinning keys during every update, not just on the initial install of the maintenance service. The keys are set based on the macros in defines.nsi, and the patch in bug 1079858, comment 66 includes the necessary change there, so as far as I can tell (without actually testing it) that patch should take care of this.

Comment 6

[Rail Aliiev [:rail]]

AFAIK, the installer is used only once, on first install.

Existing Firefox installs (without the fix you mentioned) use MAR files and updater.exe to update Firefox. And the maintenance service verifies the updater.exe's signature before running updater.exe. This service compares the signature with the value in the registry, which is set only once, on the first install.

Let me describe this with and example:

* A user has Firefox 39.0 installed, updater.exe signed with sha1
* We ship Firefox 43, signed with sha2
* the maintenance service checks the signature of existing updater.exe (39.0) and compares the signature to whatever it has in the registry. All look good.
* updater.exe updates Firefox to 43.0 *without touching the signature in the registry*
* Next time, when the maintenance service checks the signature and compares it to the one in the registry, it fails.
* No more updates can be shipped to 43, everybody is sad :)

That is my understanding of the issue here.

To fix this behaviour, we should fix the maintenance service as a part of 43.0 update to accept the new signature.

Comment 7

[Molly Howell (she/her) (no longer active)]

(In reply to Rail Aliiev [:rail] from comment #6)
> AFAIK, the installer is used only once, on first install.

From looking at the source for updater.exe, it looks like after it's finished updating files, it invokes a "helper" program. helper.exe is an NSIS program (actually it's just the uninstaller) that runs an NSIS macro called PostUpdate (see https://dxr.mozilla.org/mozilla-central/source/browser/installer/windows/nsis/shared.nsh#26) that destroys and rebuilds all of the application registry keys and then also rewrites the maintenance service cert check keys using definitions that are compiled into the helper.exe binary. So those keys are rewritten on every update, not just at the initial install. But if helper.exe itself doesn't change, it just rewrites exactly the same issuer name every time.
So, for your example, what we need to do is make sure that the update to 42 updates helper.exe to contain the new issuer (which is taken from defines.nsi.in, and the patch I linked to earlier includes that change), but once we've done that, it should update the registry with the new issuer and the maintenance service's cert check for the next update to 43 should work fine. I don't think we need to touch the maintenance service itself, just that one string.

Comment 8

[Rail Aliiev [:rail]]

Oh, this is great news!

It would be great if someone can verify this on a real machine...

Comment 9

[Molly Howell (she/her) (no longer active)]

(In reply to Rail Aliiev [:rail] from comment #8)
> Oh, this is great news!
> 
> It would be great if someone can verify this on a real machine...

All right, hint taken. ;)

I generated a MAR file containing the change to helper.exe that I mentioned in comment 7, invoked updater.exe manually to apply that MAR, and observed that, once updater.exe was done, the registry had been updated such that the old issuer string was removed and the new one added. Therefore, the maintenance service would use the new issuer to validate subsequent updates.

Comment 10

[Benjamin Smedberg]

The install/update team talked about this at our meeting. Matthew Howell is going to take this bug, but this is at serious risk for Firefox 43, so I encourage you to make alternate plans to keep using the old certificates (with backdating).

The major complications are that the new certificates (SHA2) will not be recognized by older versions of Windows: we believe that this includes XP SP2 and Vista and Windows 7 with no service pack. This means that even if we update the registry key, the installs will not work properly.

To fix that, we will need to have the updater use NSS instead of Windows certificate verification. This is what we already do on Linux, but it's still a risky change and something that we'd normally want to test carefully and ride the trains.

Comment 11

[Chris AtLee [:catlee]]

I don't think we can backdate signatures since we used a signed timestamp service (https://en.wikipedia.org/wiki/Trusted_timestamping) in our signatures to prevent exactly this sort of thing.

I think it's the maintenance service that needs to be taught to validate SHA2 signatures rather than the updater itself?

Comment 12

[Molly Howell (she/her) (no longer active)]

(In reply to Chris AtLee [:catlee] from comment #11)
> I think it's the maintenance service that needs to be taught to validate
> SHA2 signatures rather than the updater itself?

The maintenance service is the bigger problem, but the updater is involved as well because it's responsible for validating signatures in the actual update files (the MAR files). It's not clear to me whether those would be subject to the same SHA-1 deprecation policy because Windows doesn't see them as code signatures. However, in this case, code using NSS already exists and is always used on platforms other than Windows and Mac, so I plan on switching Windows over to use that code path, just to be safe.

Comment 13

[Chris AtLee [:catlee]]

AIUI, the MAR signatures are not affected by the SHA-1 deprecation. That's our own signature format defined here: https://wiki.mozilla.org/Software_Update:MAR#SIGNATURE_blocks.

Or, are you saying that the updater validates authenticode signatures of files inside the MARs?

Comment 14

[Molly Howell (she/her) (no longer active)]

(In reply to Chris AtLee [:catlee] from comment #13)
> AIUI, the MAR signatures are not affected by the SHA-1 deprecation. That's
> our own signature format defined here:
> https://wiki.mozilla.org/Software_Update:MAR#SIGNATURE_blocks.
> 
> Or, are you saying that the updater validates authenticode signatures of
> files inside the MARs?

No, you have it right, I'm just not sure how the deprecation policy applies to the Windows API that we're using for those signatures. It's not immediately obvious from looking at MSDN.

Comment 15

[Sylvestre Ledru [:Sylvestre]]

Release Note Request (optional, but appreciated)
[Why is this notable]: sha-1 is dead
[Suggested wording]: not sure how to phrase that
[Links (documentation, blog post, etc)]:

Comment 16

[Molly Howell (she/her) (no longer active)]

Attachment: MozReview Request: Bug 1205843 - Part 1: Use NSS to verify MAR signatures on Windows - r?rstrong

Bug 1205843 - Part 1: Use NSS to verify MAR signatures on Windows - r?rstrong

This patch replaces use of the Windows crypto API for MAR file signature
verification in the Windows builds of the updater executable and the tools for
working with MAR files, converting them over to use NSS for that task instead.

The purpose of this change is to facilitate using SHA-2 for those signatures.
We can't use the Windows crypto API if we want to bring in SHA-2, because
unpatched WinXP, Vista, and Win7 installations do not have SHA-2 support
available in that API. NSS is the only readily available alternative, so we
switch to it as our workaround for this Windows API shortcoming.

Comment 17

[Molly Howell (she/her) (no longer active)]

To clarify for everyone watching this bug, the above patch covers the validation of MAR files performed by the updater, but it does *not* do anything to convert the maintenance service itself to NSS - that's part 2, and it turns out to be a lot harder than part 1 (because it requires re-implementing Microsoft's Authenticode verification algorithm). As an optimistic guess, I might have the second patch posted here as soon as a week from now, but that's a pretty low-confidence estimate because I don't have a 100% understanding of the details of what needs to be done right now.

Comment 18

[Molly Howell (she/her) (no longer active)]

Comment on attachment 8677587 [details]
MozReview Request: Bug 1205843 - Part 1: Use NSS to verify MAR signatures on Windows - r?rstrong

Bug 1205843 - Part 2: Disable maintenance service on Windows XP - r?rstrong

Attempt to get around the fact that XP SP2 systems won't be able to handle
Authenticode signatues with SHA-2 digests by disabling the maintenance service,
the only thing on our update path that uses Authenticode, on WinXP.

This patch both prevents the service from being included in new installations,
and prevents the service from being used where it is already installed.

Comment 19

[Robert Strong (they/them - no direct email)]

Comment on attachment 8677587 [details]
MozReview Request: Bug 1205843 - Part 1: Use NSS to verify MAR signatures on Windows - r?rstrong

https://reviewboard.mozilla.org/r/22965/#review20755

This needs to detect whether or not the capability to validate sha2 is available and not just skip Win XP since it is used to get around runas elevation on XP.

Comment 20

[Molly Howell (she/her) (no longer active)]

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #19)
> Comment on attachment 8677587 [details]
> MozReview Request: Bug 1205843 - Part 2: Disable maintenance service on
> Windows XP - r?rstrong
> 
> https://reviewboard.mozilla.org/r/22965/#review20755
> 
> This needs to detect whether or not the capability to validate sha2 is
> available and not just skip Win XP since it is used to get around runas
> elevation on XP.

That would mean checking the installed service pack; do we have good ways to do that? I can't immediately find any.

Comment 21

[Robert Strong (they/them - no direct email)]

There is code that does that already in the tree but it might be better to check file version in case there is a hotfix to add this support. This can be done with c-types. There has also been discussion of this not working on some other windows versions... has it been verified that other windows versions are not going to also to suffer from this?

Comment 22

[Molly Howell (she/her) (no longer active)]

According to the XP SP3 documentation [1], SHA-2 was one of the handful of included features that has not shipped as a previous hotfix. It also isn't in the knowledge base article [2] that lists all previously existing hotfixes which were included in SP3, and I can't find any evidence of any hotfix released later. We could check specific file versions anyway, but without separate hotfix release notes, I don't know how to find out which files or versions to check. So I think the only indicator of the presence of SHA-2 functionality on XP is that SP3 is installed.

There are multiple sources ([3], [4], [5], [6]) either claiming directly or implying that the issues with SHA-2 in unpatched Vista and 7 only relate to kernel drivers, not user-mode executables. I haven't found a Microsoft source that says that directly enough to be satisfying, so some testing is required.

[1] http://www.microsoft.com/en-us/download/details.aspx?id=10767
[2] https://support.microsoft.com/en-us/kb/946480

[3] http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx
[4] https://www.digicert.com/sha-2-compatibility.htm
[5] https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility
[6] https://support.servertastic.com/sha2-sha256-compatibility/

Comment 23

[Robert Strong (they/them - no direct email)]

Here is an example of getting service pack information
http://mxr.mozilla.org/mozilla-central/source/toolkit/modules/UpdateUtils.jsm#307

Comment 24

[Molly Howell (she/her) (no longer active)]

Comment on attachment 8677587 [details]
MozReview Request: Bug 1205843 - Part 1: Use NSS to verify MAR signatures on Windows - r?rstrong

Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong

Attempt to get around the fact that XP SP2 (and below) systems won't be able to
handle Authenticode signatues with SHA-2 digests by disabling the maintenance
service, the only thing on our update path that uses Authenticode, on systems
running WinXP below SP3.

This patch both prevents the service from being included in new installations,
and prevents the service from being used where it is already installed.

Comment 25

[Robert Strong (they/them - no direct email)]

Comment on attachment 8677587 [details]
MozReview Request: Bug 1205843 - Part 1: Use NSS to verify MAR signatures on Windows - r?rstrong

https://reviewboard.mozilla.org/r/22965/#review20889

We haven't used IfNot and AndIfNot in the past in this code. I don't recall if it was due to bugs in their implementation or if it was due to them not always being available. Would it be possible to rewrite this to only use the other available LogicLib implementations?

Comment 26

[Robert Strong (they/them - no direct email)]

https://reviewboard.mozilla.org/r/22965/#review20891

We haven't used IfNot and AndIfNot in the past in this code. I don't recall if it was due to bugs in their implementation or if it was due to them not always being available. Would it be possible to rewrite this to only use the other available LogicLib implementations?

Comment 27

[Molly Howell (she/her) (no longer active)]

Looks like I can do it without any IfNot's if I use a couple of Goto's instead; not a problem.

I'm also going to discard the MozReview request and make a new one; I messed up when I added the second part and now it thinks part 2 replaced part 1. Still getting the hang of that.

Comment 28

[Molly Howell (she/her) (no longer active)]

Comment on attachment 8677587 [details]
MozReview Request: Bug 1205843 - Part 1: Use NSS to verify MAR signatures on Windows - r?rstrong

Bug 1205843 - Part 1: Use NSS to verify MAR signatures on Windows - r?rstrong

This patch replaces use of the Windows crypto API for MAR file signature
verification in the Windows builds of the updater executable and the tools for
working with MAR files, converting them over to use NSS for that task instead.

The purpose of this change is to facilitate using SHA-2 for those signatures.
We can't use the Windows crypto API if we want to bring in SHA-2, because
unpatched WinXP, Vista, and Win7 installations do not have SHA-2 support
available in that API. NSS is the only readily available alternative, so we
switch to it as our workaround for this Windows API shortcoming.

Comment 29

[Molly Howell (she/her) (no longer active)]

Attachment: MozReview Request: Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong

Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong

Attempt to get around the fact that XP SP2 (and below) systems won't be able to
handle Authenticode signatues with SHA-2 digests by disabling the maintenance
service, the only thing on our update path that uses Authenticode, on systems
running WinXP below SP3.

This patch both prevents the service from being included in new installations,
and prevents the service from being used where it is already installed.

Comment 30

[Liz Henry (:lizzard) (relman/hg->git project)]

Once we have r+ on this, we should try to test it as soon as possible. We may need to coordinate that across different teams to make sure that we test from all the correct windows versions. 
 
Ryan, Kamil, Florin (and rail/nthomas for any new update server infrastructure) is this something you can coordinate over email, or maybe in a new dependent bug?

Comment 31

[Rail Aliiev [:rail]]

either email or separate bug wfm

Comment 32

[Molly Howell (she/her) (no longer active)]

Attachment: MozReview Request: Bug 1205843 - Part 2 Rev 2: Improve NSIS OS detection logic; r?rstrong

Bug 1205843 - Part 2 Rev 2: Improve NSIS OS detection logic; r?rstrong

Comment 33

[Molly Howell (she/her) (no longer active)]

Comment on attachment 8679566 [details]
MozReview Request: Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong

Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong

Attempt to get around the fact that XP SP2 (and below) systems won't be able to
handle Authenticode signatues with SHA-2 digests by disabling the maintenance
service, the only thing on our update path that uses Authenticode, on systems
running WinXP below SP3.

This patch both prevents the service from being included in new installations,
and prevents the service from being used where it is already installed.

Comment 34

[Kamil Jozwiak [:kjozwiak]]

(In reply to Rail Aliiev [:rail] from comment #31)
> either email or separate bug wfm

+1 works me as well..

Comment 35

[Nick Thomas [:nthomas] (UTC+12)]

I defer to rail on this, but he can twist my arm if he needs some help.

Comment 36

[Molly Howell (she/her) (no longer active)]

Comment on attachment 8679566 [details]
MozReview Request: Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong

Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong

Attempt to get around the fact that XP SP2 (and below) systems won't be able to
handle Authenticode signatues with SHA-2 digests by disabling the maintenance
service, the only thing on our update path that uses Authenticode, on systems
running WinXP below SP3.

This patch both prevents the service from being included in new installations,
and prevents the service from being used where it is already installed.

Comment 37

[Molly Howell (she/her) (no longer active)]

Comment on attachment 8679566 [details]
MozReview Request: Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong

Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong

Attempt to get around the fact that XP SP2 (and below) systems won't be able to
handle Authenticode signatues with SHA-2 digests by disabling the maintenance
service, the only thing on our update path that uses Authenticode, on systems
running WinXP below SP3.

This patch both prevents the service from being included in new installations,
and prevents the service from being used where it is already installed.

Comment 38

[Molly Howell (she/her) (no longer active)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=06c432c853b8

Comment 39

[Robert Strong (they/them - no direct email)]

Comment on attachment 8679566 [details]
MozReview Request: Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong

Current status

I went over this patch over irc with Matt and it is in good shape. I am also pushing it to oak. I'll r+ it if the try push passes the tests and minimal testing has been done on oak.

It isn't clear yet whether the other patch will be necessary and Matt will investigate whether it is.

Comment 40

[Robert Strong (they/them - no direct email)]

Comment on attachment 8679566 [details]
MozReview Request: Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong

Pushed to oak
https://treeherder.mozilla.org/#/jobs?repo=oak&revision=e2ffa9afadd2

This should generate a nightly build tonight and we'll generate an additional nightly build tomorrow for testing

Comment 41

[Molly Howell (she/her) (no longer active)]

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #39)
> It isn't clear yet whether the other patch will be necessary and Matt will
> investigate whether it is.

The answer to this question appears to be no, converting the updater to NSS as in part 1 of my patch is not necessary to avoid being hit by SHA-1 deprecation.

The reason why is that SHA-1 deprecation is being implemented by having the Microsoft API's for certificate trust verification begin to reject noncompliant certificates, but in the updater we do not use any Microsoft API to perform certificate trust verification. In fact we don't verify certificate trust at all; MAR files do not carry their own signing certificate as Authenticode-signed files do, they contain only the actual signature (the encrypted hash of the file contents). The certificate that is always used to validate the signature is one that's been compiled into the updater binary and is inherently trusted.

So the bottom line is that I don't have any evidence that my part 1 patch is needed at this time. I submitted it because it was easy enough to write and I wanted to cover every base, but since it doesn't seem necessary I'm fine with it not getting landed.

Comment 42

[Molly Howell (she/her) (no longer active)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a301268578cb

Comment 43

[Molly Howell (she/her) (no longer active)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=38042c0d7947

Comment 44

[Andrei Vaida [:avaida]]

(In reply to Kamil Jozwiak [:kjozwiak] from comment #34)
> (In reply to Rail Aliiev [:rail] from comment #31)
> > either email or separate bug wfm
> 
> +1 works me as well..

Sounds good, we'll keep this on our radar and see how we can help. I'm moving the ni? to myself as a reminder.

Comment 45

[Robert Strong (they/them - no direct email)]

Comment on attachment 8679566 [details]
MozReview Request: Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong

https://reviewboard.mozilla.org/r/23479/#review21303

Part 2 looks good. Please verify everything works on oak before landing and obsolete the NSS patch. If / when we decide to do that it will be in a different bug.

Comment 46

[Molly Howell (she/her) (no longer active)]

Per comment 45, checkin-needed applies only to the Part 2 patch; the obsoleted Part 1 patch should not get landed.

Comment 47

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/46dc0b2f7dce

Comment 48

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/46dc0b2f7dce

Comment 49

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/46dc0b2f7dce

Comment 50

[Carsten Book [:Tomcat]]

removing the b2g 2.5 flag since this commit has been reverted due to an incorrect merge, sorry for the confusion

Comment 51

[Rail Aliiev [:rail]]

Matt, I think we need to uplift the patch to aurora and beta. Otherwise it'll be riding the trains and will be available only with Gecko 45.

Can you ask the release management team to approve the patches?

Comment 52

[Liz Henry (:lizzard) (relman/hg->git project)]

We should test this before uplifting. 

From talking with Matt, sounds like we need to test:
Windows XP, with service pack 2 and also with service pack 3 (separately)

Also, testing on unpatched installs of Vista and Windows 7, to make sure that we're correct that no changes are needed there.

Comment 53

[Kamil Jozwiak [:kjozwiak]]

Removing myself as it appears like SV have been testing this. Let me know if you need my help but it looks like SV is handling this.

Comment 54

[Andrei Vaida [:avaida]]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #52)
> We should test this before uplifting. 
> 
> From talking with Matt, sounds like we need to test:
> Windows XP, with service pack 2 and also with service pack 3 (separately)
> 
> Also, testing on unpatched installs of Vista and Windows 7, to make sure
> that we're correct that no changes are needed there.

We coordinated with Matt on this matter and Cornel made sure things work as expected. Per Rail and Catlee's request, the following items are still pending on Windows XP SP2:
* Check if the Maintenance service is installed with the current builds
* Firefox with maintenance service already installed and then, check for update

Cornel will follow up here as soon as soon as possible. Detailed test results were posted in the following etherpad: https://public.etherpad-mozilla.org/p/sha2-updater.

Comment 55

[Cornel Ionce [:noni] [Hubs QA]]

I've completed the extra testing here and everything looks fine.
The *etherpad was properly updated with the latest results.

Marking this issue verified.

*https://public.etherpad-mozilla.org/p/sha2-updater.

Comment 56

[Rail Aliiev [:rail]]

Such a relief! Thank you very much!

Comment 57

[Liz Henry (:lizzard) (relman/hg->git project)]

Adding affected and tracking flags for 43+ versions since we need work to land on 44 as well.

Comment 58

[Molly Howell (she/her) (no longer active)]

Comment on attachment 8679566 [details]
MozReview Request: Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong

Approval Request Comment
[Feature/regressing bug #]:
Bug 1079858

[User impact if declined]:
Users of Windows XP Service Pack 2 will be unable to install updates generated after bug 1079858 is fixed due to our changes to comply with Microsoft's SHA-1 deprecation policy. Since that policy applies starting at the beginning of 2016, this change needs to be released before then.

[Describe test coverage new/current, TreeHerder]:
See comment 43 for TreeHerder link.

[Risks and why]: 
Low risk because of extensive testing, see previous comments here.

[String/UUID change made/needed]:
None

Comment 59

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8679566 [details]
MozReview Request: Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong

Feature planned for 43, extensive manual testing, please uplift to aurora and beta.

Comment 60

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/f0994dcc4d03

Comment 61

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-beta/rev/56e1eb5024d1

Comment 62

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/f0994dcc4d03

Comment 63

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Matt, Rail: Would you be able to suggest a one-liner that we can add to Beta44 release notes about sha-1 deprecation? Thanks!

Comment 64

[Molly Howell (she/her) (no longer active)]

(In reply to Ritu Kothari (:ritu) from comment #63)
> Hi Matt, Rail: Would you be able to suggest a one-liner that we can add to
> Beta44 release notes about sha-1 deprecation? Thanks!

I'll take a stab at it:
"Use a SHA-256 signing certificate for Windows builds, to meet new Microsoft security requirements"
where "Microsoft security requirements" is a link to http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx

Some discussion about whether this should be in the release notes at all seems warranted though, unless maybe it's already happened somewhere else; this is not really a change that either users or developers should notice, except for any bugs.

Comment 65

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Thanks Matt for the suggested wording. Added to Beta44 release notes as "Use a SHA-256 signing certificate for Windows builds, to meet new Microsoft signing requirements"