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

VERIFIED FIXED in Firefox 43, Firefox OS v2.5

Status

()

Toolkit
Application Update
VERIFIED FIXED
2 years ago
2 months ago

People

(Reporter: bhearsum, Assigned: mhowell)

Tracking

unspecified
mozilla45
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox43+ fixed, firefox44+ fixed, firefox45+ verified, b2g-v2.5 fixed, relnote-firefox 44+)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

2 years ago
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
(Reporter)

Comment 1

2 years ago
[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).
tracking-firefox43: --- → ?
tracking-firefox43: ? → +
status-firefox43: --- → affected
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.
Flags: needinfo?(mhowell)
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.
Benjamin or Robert, can you help us find an owner for this bug? We have to ship this in 43.
Flags: needinfo?(robert.strong.bugs)
Flags: needinfo?(benjamin)
(Assignee)

Comment 5

2 years ago
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.
Flags: needinfo?(mhowell)
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.
(Assignee)

Comment 7

2 years ago
(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.
Oh, this is great news!

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

Comment 9

2 years ago
(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.
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.
Assignee: nobody → mhowell
Flags: needinfo?(robert.strong.bugs)
Flags: needinfo?(benjamin)
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?
(Assignee)

Comment 12

2 years ago
(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.
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?
(Assignee)

Comment 14

2 years ago
(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.
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)]:
relnote-firefox: --- → ?
(Assignee)

Comment 16

2 years ago
Created 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.
Attachment #8677587 - Flags: review?(robert.strong.bugs)
(Assignee)

Comment 17

2 years ago
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.
(Assignee)

Comment 18

2 years ago
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.
Attachment #8677587 - Attachment description: MozReview Request: Bug 1205843 - Part 1: Use NSS to verify MAR signatures on Windows - r?rstrong → MozReview Request: Bug 1205843 - Part 2: Disable maintenance service on Windows XP - r?rstrong
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.
Attachment #8677587 - Flags: review?(robert.strong.bugs)
(Assignee)

Comment 20

2 years ago
(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.
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?
(Assignee)

Comment 22

2 years ago
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/
Here is an example of getting service pack information
http://mxr.mozilla.org/mozilla-central/source/toolkit/modules/UpdateUtils.jsm#307
(Assignee)

Comment 24

2 years ago
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.
Attachment #8677587 - Attachment description: MozReview Request: Bug 1205843 - Part 2: Disable maintenance service on Windows XP - r?rstrong → MozReview Request: Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong
Attachment #8677587 - Flags: review?(robert.strong.bugs)
Attachment #8677587 - Flags: review?(robert.strong.bugs)
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?
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?
(Assignee)

Comment 27

2 years ago
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.
(Assignee)

Updated

2 years ago
Attachment #8677587 - Attachment is obsolete: true
(Assignee)

Updated

2 years ago
Attachment #8677587 - Attachment description: MozReview Request: Bug 1205843 - Part 2: Disable maintenance service on WinXP < SP3 - r?rstrong → MozReview Request: Bug 1205843 - Part 1: Use NSS to verify MAR signatures on Windows - r?rstrong
Attachment #8677587 - Attachment is obsolete: false
Attachment #8677587 - Flags: review?(robert.strong.bugs)
(Assignee)

Comment 28

2 years ago
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.
(Assignee)

Comment 29

2 years ago
Created 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.
Attachment #8679566 - Flags: review?(robert.strong.bugs)
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?
Flags: needinfo?(ryanvm)
Flags: needinfo?(rail)
Flags: needinfo?(nthomas)
Flags: needinfo?(kjozwiak)
Flags: needinfo?(florin.mezei)
Flags: needinfo?(ryanvm)
either email or separate bug wfm
Flags: needinfo?(rail)
(Assignee)

Comment 32

2 years ago
Created attachment 8679631 [details]
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
Attachment #8679631 - Flags: review?(robert.strong.bugs)
(Assignee)

Comment 33

2 years ago
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.
(Assignee)

Updated

2 years ago
Attachment #8679631 - Attachment is obsolete: true
Attachment #8679631 - Flags: review?(robert.strong.bugs)
(In reply to Rail Aliiev [:rail] from comment #31)
> either email or separate bug wfm

+1 works me as well..
Flags: needinfo?(kjozwiak)
I defer to rail on this, but he can twist my arm if he needs some help.

Updated

2 years ago
Flags: needinfo?(nthomas)
(Assignee)

Comment 36

2 years ago
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.
(Assignee)

Comment 37

2 years ago
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 hidden (obsolete)
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 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
(Assignee)

Comment 41

2 years ago
(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 hidden (obsolete)
(Assignee)

Comment 43

2 years ago
https://treeherder.mozilla.org/#/jobs?repo=try&revision=38042c0d7947
(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.
Flags: needinfo?(florin.mezei) → needinfo?(andrei.vaida)
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.
Attachment #8679566 - Flags: review?(robert.strong.bugs) → review+
(Assignee)

Updated

2 years ago
Attachment #8677587 - Attachment is obsolete: true
Attachment #8677587 - Flags: review?(robert.strong.bugs)
(Assignee)

Comment 46

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

Comment 47

2 years ago
https://hg.mozilla.org/integration/fx-team/rev/46dc0b2f7dce
Keywords: checkin-needed

Comment 48

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/46dc0b2f7dce
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox45: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla45

Comment 49

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/46dc0b2f7dce
status-b2g-v2.5: --- → fixed
removing the b2g 2.5 flag since this commit has been reverted due to an incorrect merge, sorry for the confusion
status-b2g-v2.5: fixed → ---
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?
Flags: needinfo?(mhowell)
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.
Flags: needinfo?(kjozwiak)
Flags: needinfo?(florin.mezei)
(Assignee)

Updated

2 years ago
Flags: needinfo?(mhowell)
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.
Flags: needinfo?(kjozwiak)
(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.
Flags: needinfo?(florin.mezei)
Flags: needinfo?(cornel.ionce)
Flags: needinfo?(andrei.vaida)
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.
Status: RESOLVED → VERIFIED
status-firefox45: fixed → verified
Flags: needinfo?(cornel.ionce)
QA Contact: cornel.ionce
Such a relief! Thank you very much!
Adding affected and tracking flags for 43+ versions since we need work to land on 44 as well.
status-firefox44: --- → affected
tracking-firefox44: --- → +
tracking-firefox45: --- → +
(Assignee)

Comment 58

2 years ago
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
Attachment #8679566 - Flags: approval-mozilla-beta?
Attachment #8679566 - Flags: approval-mozilla-aurora?
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.
Attachment #8679566 - Flags: approval-mozilla-beta?
Attachment #8679566 - Flags: approval-mozilla-beta+
Attachment #8679566 - Flags: approval-mozilla-aurora?
Attachment #8679566 - Flags: approval-mozilla-aurora+

Comment 60

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-aurora/rev/f0994dcc4d03
status-firefox44: affected → fixed

Comment 61

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/56e1eb5024d1
status-firefox43: affected → fixed

Comment 62

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/f0994dcc4d03
status-b2g-v2.5: --- → fixed
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!
Flags: needinfo?(rail)
Flags: needinfo?(mhowell)
(Assignee)

Comment 64

2 years ago
(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.
Flags: needinfo?(mhowell)
Flags: needinfo?(rail)
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"

Updated

2 years ago
relnote-firefox: ? → 44+
Depends on: 1359536
You need to log in before you can comment on or make changes to this bug.