Closed
Bug 1105689
Opened 9 years ago
Closed 7 years ago
Support stronger hash algorithms than SHA1 for signing certificates
Categories
(Toolkit :: Application Update, defect, P1)
Toolkit
Application Update
Tracking
()
VERIFIED
FIXED
mozilla56
People
(Reporter: gk, Assigned: robert.strong.bugs)
References
Details
(Keywords: sec-want, Whiteboard: [fce-active-legacy][adv-main56-])
Attachments
(6 files, 15 obsolete files)
12.47 KB,
patch
|
robert.strong.bugs
:
review+
|
Details | Diff | Splinter Review |
7.99 KB,
patch
|
robert.strong.bugs
:
review+
|
Details | Diff | Splinter Review |
1.01 KB,
patch
|
robert.strong.bugs
:
review+
|
Details | Diff | Splinter Review |
36.60 KB,
patch
|
robert.strong.bugs
:
review+
|
Details | Diff | Splinter Review |
208.00 KB,
patch
|
robert.strong.bugs
:
review+
|
Details | Diff | Splinter Review |
7.06 KB,
patch
|
robert.strong.bugs
:
review+
|
Details | Diff | Splinter Review |
SHA1 is not acceptable anymore for signature generation for a while now (see e.g. http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf page 14) but the certificates used for signing are not allowed to user other hash algorithms (e.g. from the SHA 2 family): https://wiki.mozilla.org/Software_Update:MAR (section SIGNATURE_ENTRY.SignatureAlgorithmID) This bug is about adding support for stronger hash algorithms.
Assignee | ||
Comment 1•9 years ago
|
||
Our choices are to either only support Winxp so3 and above or to use nss or similar to verify the certificate which was not an option when update Mar signing was implemented. If winxp sp3 was the minimum windows version supported nothing would need to be done to app update though a releng bug would be needed to sign with the new certificate. Note: platforms other than Windows don't support Mar signing yet though that should be completed soon. Another option would be to serve mars signed with a sha1 certificate to the systems that don't support sha2 etc. and serve mars signed with sha2 or above to systems that support those algorithms. Have you also filed a bug to change the certificate algorithm when signing the binaries on Windows?
Reporter | ||
Comment 2•9 years ago
|
||
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #1) > Our choices are to either only support Winxp so3 and above or to use nss or > similar to verify the certificate which was not an option when update Mar > signing was implemented. If winxp sp3 was the minimum windows version > supported nothing would need to be done to app update though a releng bug > would be needed to sign with the new certificate. What do you mean with "nothing would need to be done to app update"? I was under the impression that at least https://mxr.mozilla.org/mozilla-central/source/modules/libmar/verify/mar_verify.c#330 and https://mxr.mozilla.org/mozilla-central/source/modules/libmar/sign/mar_sign.c#98 prevent other signature algorithms from getting used? > Note: platforms other than Windows don't support Mar signing yet though that > should be completed soon. Yeah, we plan to ship update signing on Linux, Mac and Windows either next week or with the ESR 31 release afterwards. And we use NSS on all platforms. I know, there might be pitfalls with that approach but trusting a binary blob we can't audit was a bit too much to swallow... We'll see how it goes. > Another option would be to serve mars signed with a sha1 certificate to the > systems that don't support sha2 etc. and serve mars signed with sha2 or > above to systems that support those algorithms. Sounds like a way to go for me. > Have you also filed a bug to change the certificate algorithm when signing > the binaries on Windows? No, just that generic one.
Comment 3•9 years ago
|
||
Yes we'll need some libmar enhancements to support it. We should check with the security team to see if this is something important that they want us to make a priority or not. For example, are we already compromised in other areas in terms of signatures? At the time this was implemented, we were already using sha-1 for authenticode checks, I'm not sure if that changed or not since then. See here for some context on why SHA1 was used for MAR signing originally: https://bugzilla.mozilla.org/show_bug.cgi?id=699700#c40 Note that we'd also need a new stop-gate upgrade path. Upgrading from X -> Y where Y is signed with the new signature ID wouldn't be possible directly because no old updater would know what to do with a signature id of 2, so it would have to first be upgrade from X -> X2(signed with sigid1, build has support for sig id2) -> Y(new mars with sig id2).
Comment 4•9 years ago
|
||
(In reply to Brian R. Bondy [:bbondy] from comment #3) > Yes we'll need some libmar enhancements to support it. > > We should check with the security team to see if this is something important > that they want us to make a priority or not. For example, are we already > compromised in other areas in terms of signatures? > > At the time this was implemented, we were already using sha-1 for > authenticode checks, I'm not sure if that changed or not since then. > > See here for some context on why SHA1 was used for MAR signing originally: > https://bugzilla.mozilla.org/show_bug.cgi?id=699700#c40 > > Note that we'd also need a new stop-gate upgrade path. Upgrading from X -> Y > where Y is signed with the new signature ID wouldn't be possible directly > because no old updater would know what to do with a signature id of 2, so it > would have to first be upgrade from X -> X2(signed with sigid1, build has > support for sig id2) -> Y(new mars with sig id2). Does that apply even if we include both the SHA-1 and SHA-2 based signatures?
Comment 5•9 years ago
|
||
We do have support for multiple signatures in the MAR file, and the docs indicate that that we currently use OR semantics. But this was added for b2g where each one was going to use the same algorithm id, but it was just different parties signing each one. It looks to me like a new MAR file would be rejected with a new signature ID that contained 2 signatures: See the last if blog below in the C code for mar_extract_and_verify_signatures_fp: > for (i = 0; i < signatureCount; i++) { > /* Get the signature algorithm ID */ > if (fread(&signatureAlgorithmIDs[i], sizeof(uint32_t), 1, fp) != 1) { > fprintf(stderr, "ERROR: Could not read signatures algorithm ID.\n"); > return CryptoX_Error; > } > signatureAlgorithmIDs[i] = ntohl(signatureAlgorithmIDs[i]); > > if (fread(&signatureLen, sizeof(uint32_t), 1, fp) != 1) { > fprintf(stderr, "ERROR: Could not read signatures length.\n"); > return CryptoX_Error; > } > signatureLen = ntohl(signatureLen); > > /* To protected against invalid input make sure the signature length > isn't too big. */ > if (signatureLen > MAX_SIGNATURE_LENGTH) { > fprintf(stderr, "ERROR: Signature length is too large to verify.\n"); > return CryptoX_Error; > } > > extractedSignatures[i] = malloc(signatureLen); > if (!extractedSignatures[i]) { > fprintf(stderr, "ERROR: Could allocate buffer for signature.\n"); > return CryptoX_Error; > } > if (fread(extractedSignatures[i], signatureLen, 1, fp) != 1) { > fprintf(stderr, "ERROR: Could not read extracted signature.\n"); > for (i = 0; i < signatureCount; ++i) { > free(extractedSignatures[i]); > } > return CryptoX_Error; > } > > /* We don't try to verify signatures we don't know about */ > if (signatureAlgorithmIDs[i] != 1) { > fprintf(stderr, "ERROR: Unknown signature algorithm ID.\n"); > for (i = 0; i < signatureCount; ++i) { > free(extractedSignatures[i]); > } > return CryptoX_Error; > } > }
Comment 6•9 years ago
|
||
<strike>See the last if blog below in the C code for mar_extract_and_verify_signatures_fp:</strike> See the last "if" block below in the C code for mar_extract_and_verify_signatures_fp:
Comment 7•9 years ago
|
||
(In reply to Brian R. Bondy [:bbondy] from comment #5) > We do have support for multiple signatures in the MAR file, and the docs > indicate that that we currently use OR semantics. I think the current code requires that all signatures be verified ("AND" semantics). From the end of mar_extract_and_verify_signatures_fp: > if (numVerified == signatureCount && keyCount == numVerified) { > return CryptoX_Success; > } > > if (numVerified == 0) { > fprintf(stderr, "ERROR: Not all signatures were verified.\n"); > } else { > fprintf(stderr, "ERROR: Only %d of %d signatures were verified.\n", > numVerified, signatureCount); > } > return CryptoX_Error; > }
Assignee | ||
Comment 8•9 years ago
|
||
(In reply to Brian R. Bondy [:bbondy] from comment #3) > Yes we'll need some libmar enhancements to support it. Besides tooling changes to generate mar files and possibly checking multiple certificates are there app update client changes required to support verifying sha2 and above?
Flags: needinfo?(netzen)
Comment 9•9 years ago
|
||
> I think the current code requires that all signatures be verified ("AND" semantics) Agreed. Same argument holds for needing the upgrade path to go through a specific version though. > Besides tooling changes to generate mar files and possibly checking multiple > certificates are there app update client changes required to support verifying sha2 and above? I was speaking more towards libmar changes being needed. I don't think there's any changes beyond that.
Flags: needinfo?(netzen)
Assignee | ||
Comment 10•9 years ago
|
||
So I can plan out this work will the libmar changes only apply to the tools for creating mars or will these changes also apply to client app update code?
Comment 11•9 years ago
|
||
If we're going the 2 MAR route, we'll need to: i) Detect which type of hash check will happen, we'll just only do a sha1 if that's all that's avail on xp sp2. ii) Add code to always verify only the stronger hash when more than one hash is available. iii) Specify from updater code which hash to use for the verify iv) Change libmar to accept only the matching "hash / sign" algorithm ID passed in v) Possibly add some tooling to support signing / hashing in different ways
Comment 12•9 years ago
|
||
s/ If we're going the 2 MAR route, we'll need to: / If we're going the 2 signature and hash route, we'll need to:
Assignee | ||
Comment 13•9 years ago
|
||
It is my understanding that if we continue to support WinXP SP2 there will be an installer with the binaries signed with a SHA1 cert and systems greater than WinXP SP2 will have an installer with the binaries signed with a SHA2 cert. If this ends up being the case there will need to be separate MAR files for the clients with the binaries signed with a SHA1 cert and the clients with the binaries signed with a SHA2 cert. With that in mind I think the 2 MAR route is the way to go.
Comment 14•9 years ago
|
||
If you go with two separate MARs then you have to make sure that you can't feed the "weak" one to systems that are capable of understanding the stronger one. "SHA1? nice try, no update for you."
Comment 16•8 years ago
|
||
Is bug 1079858 work basically fixing this bug here?
Assignee | ||
Comment 17•8 years ago
|
||
No
Comment 18•8 years ago
|
||
The current plan to move XP users to ESR 52 (bug 1303827) would take care of the need for two sets of MAR files as discussed above; all supported systems as of 53 would support SHA2 natively if that plan does get used. That doesn't necessarily raise the priority of this bug, but it does make the implementation effort an awful lot smaller.
Assignee | ||
Comment 19•8 years ago
|
||
Matt's statement in comment #18 is what I had planned on.
Priority: -- → P2
Target Milestone: --- → mozilla53
Assignee | ||
Comment 20•7 years ago
|
||
Just started on this and the patches are no where near complete. I am going to try to include backwards compatibility so an update watershed won't be necessary. When we have to have an update watershed the backwards compatibility can be removed. So far I've gotten the libmar tests passing on Windows.
Assignee: nobody → robert.strong.bugs
Status: NEW → ASSIGNED
Assignee | ||
Comment 21•7 years ago
|
||
Assignee | ||
Comment 22•7 years ago
|
||
Assignee | ||
Comment 23•7 years ago
|
||
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #20) > Created attachment 8815637 [details] [diff] [review] > patch libmar data files > > Just started on this and the patches are no where near complete. I am going > to try to include backwards compatibility so an update watershed won't be > necessary. When we have to have an update watershed the backwards > compatibility can be removed. Since the cert verification was changed to AND semantics chances are this will require an update watershed. :(
Assignee | ||
Comment 24•7 years ago
|
||
Dan and Al, I'm planning on going with SHA384 since it is less vulnerable to a length extension attack. I am also considering changing the key size from 2048 to 4096. Can I get your input or the input from someone else on the security team on both of these choices? Thanks!
Flags: needinfo?(dveditz)
Flags: needinfo?(abillings)
Assignee | ||
Comment 25•7 years ago
|
||
Talked with dveditz and got his go ahead with using SHA384 since it is less vulnerable to length attacks than SHA512 and a key size of 4096.
Flags: needinfo?(dveditz)
Flags: needinfo?(abillings)
Assignee | ||
Comment 26•7 years ago
|
||
Dan, we changed the requirement to only validate with one of the certificates to requiring all certificates to validate for B2G. Would you have a problem with reverting to the original requirement to only validating with one of the certificates?
Flags: needinfo?(dveditz)
Assignee | ||
Comment 27•7 years ago
|
||
Attachment #8815637 -
Attachment is obsolete: true
Attachment #8815638 -
Attachment is obsolete: true
Attachment #8815639 -
Attachment is obsolete: true
Assignee | ||
Comment 28•7 years ago
|
||
Assignee | ||
Comment 29•7 years ago
|
||
Attachment #8818427 -
Attachment is obsolete: true
Assignee | ||
Comment 30•7 years ago
|
||
Assignee | ||
Comment 31•7 years ago
|
||
Pushed to try https://treeherder.mozilla.org/#/jobs?repo=try&revision=d6e56372c1fe119323fb495f14b36db8b8738069
Assignee | ||
Comment 32•7 years ago
|
||
Comment on attachment 8818707 [details] [diff] [review] patch - libmar client code Stephen, can I get you to do a review of this... especially the changes to MacVerifyCrypto.cpp? Thanks!
Attachment #8818707 -
Flags: review?(spohl.mozilla.bugs)
Assignee | ||
Comment 33•7 years ago
|
||
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #31) > Created attachment 8818711 [details] [diff] [review] > patch - update tests > > Pushed to try > https://treeherder.mozilla.org/#/ > jobs?repo=try&revision=d6e56372c1fe119323fb495f14b36db8b8738069 Try run looks good
Assignee | ||
Comment 34•7 years ago
|
||
Note to self: the following wiki will need to be updated https://wiki.mozilla.org/Software_Update:MAR
Comment 35•7 years ago
|
||
Comment on attachment 8818707 [details] [diff] [review] patch - libmar client code Review of attachment 8818707 [details] [diff] [review]: ----------------------------------------------------------------- This looks mostly fine to me. I'd like to take another look at the next patch. Thanks! ::: modules/libmar/sign/mar_sign.c @@ +94,5 @@ > XP_MIN_SIGNATURE_LEN_IN_BYTES); > return -1; > } > > + *ctx = SGN_NewContext (SEC_OID_PKCS1_SHA384_WITH_RSA_ENCRYPTION, *privKey); nit: drop the space between SGN_NewContext and ( ::: modules/libmar/verify/MacVerifyCrypto.cpp @@ +156,5 @@ > signatureData, > &error); > if (!verifier || error) { > CFRelease(signatureData); > return CryptoX_Error; I just realized that we should be releasing |error| when not NULL. It would be great to do this throughout this function while we're here. See https://developer.apple.com/reference/security/1393861-sectransformsetattribute?language=objc @@ +161,5 @@ > } > > SecTransformSetAttributePtr(verifier, > + kSecDigestTypeAttribute, > + kSecDigestSHA2, &error); nit: place &error on separate line to keep with existing style in this function. @@ +169,5 @@ > + return CryptoX_Error; > + } > + > + int digestLength = 384; > + CFNumberRef dLen = CFNumberCreate(kCFAllocatorDefault, kCFNumberIntType, &digestLength); dLen would need to be released when we're done with it. See https://developer.apple.com/library/content/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc/uid/20001148-103029 It might be easier to just pass the following to SecTransformSetAttributePtr instead of dLen: (__bridge CFNumberRef)@384
Attachment #8818707 -
Flags: review?(spohl.mozilla.bugs)
Assignee | ||
Comment 36•7 years ago
|
||
Pushed to try https://treeherder.mozilla.org/#/jobs?repo=try&revision=1c75b8ae1ccfd0562c74f7b511dd5be0419d97de
Attachment #8818707 -
Attachment is obsolete: true
Assignee | ||
Comment 37•7 years ago
|
||
Pushed to try https://treeherder.mozilla.org/#/jobs?repo=try&revision=4e5a3c17a05be1b47abdff870a840971ba134ccf
Attachment #8819027 -
Attachment is obsolete: true
Assignee | ||
Comment 38•7 years ago
|
||
Comment on attachment 8819067 [details] [diff] [review] patch - libmar client code __bridge isn't already available (see previous try push) so I just went with releasing it.
Attachment #8819067 -
Flags: review?(spohl.mozilla.bugs)
Assignee | ||
Comment 39•7 years ago
|
||
Rail, heads up that we're going to need SHA384 certificates with a key size of 4096 for this bug just as was done for the SHA1 certificates with a key size of 2048 that you created for bug 720777. It will likely be a month or so before we need them.
Flags: needinfo?(rail)
Assignee | ||
Comment 40•7 years ago
|
||
The reason it will likely be a month or so is because I want to land bug 641212 at the same time. Since this will require a watershed since the cert check requires all certs to validate and this will allow for a simpler approach where we only support lzma in bug 641212.
Comment 41•7 years ago
|
||
Comment on attachment 8819067 [details] [diff] [review] patch - libmar client code Review of attachment 8819067 [details] [diff] [review]: ----------------------------------------------------------------- Thank you!
Attachment #8819067 -
Flags: review?(spohl.mozilla.bugs) → review+
Assignee | ||
Comment 42•7 years ago
|
||
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #39) > Rail, heads up that we're going to need SHA384 certificates with a key size > of 4096 for this bug just as was done for the SHA1 certificates with a key > size of 2048 that you created for bug 720777. It will likely be a month or > so before we need them. Rail, can the new certificates you create be used on oak first so this can be tested on oak before landing for nightly?
Assignee | ||
Updated•7 years ago
|
Attachment #8818426 -
Flags: review?(mhowell)
Assignee | ||
Updated•7 years ago
|
Attachment #8818711 -
Flags: review?(mhowell)
Assignee | ||
Updated•7 years ago
|
Attachment #8819067 -
Flags: review?(mhowell)
Assignee | ||
Comment 43•7 years ago
|
||
Comment on attachment 8818708 [details] [diff] [review] patch - update data files Matt, I don't plan on landing this on m-c until after the lzma work is done. I am going to try to get this landed on oak as soon as releng can get the certs and mar signing set up.
Attachment #8818708 -
Flags: review?(mhowell)
Comment 44•7 years ago
|
||
I'm going to look at this either today or on Monday. Let me know if this is urgent.
Assignee | ||
Comment 45•7 years ago
|
||
(In reply to Rail Aliiev [:rail] ⌚️ET from comment #44) > I'm going to look at this either today or on Monday. Let me know if this is > urgent. Definitely not urgent... in a week or two should suffice
Updated•7 years ago
|
Attachment #8819067 -
Flags: review?(mhowell) → review+
Updated•7 years ago
|
Attachment #8818711 -
Flags: review?(mhowell) → review+
Updated•7 years ago
|
Attachment #8818708 -
Flags: review?(mhowell) → review+
Updated•7 years ago
|
Attachment #8818426 -
Flags: review?(mhowell) → review+
Comment 46•7 years ago
|
||
It sounds like we need to support 2 mar signing in parallel. It's going to be a combination of bug 1186425 (new signing format support) and bug 869498 (need to package and deploy the new signmar binary, installed in parallel). I'll file a separate releng bug for this.
Comment 47•7 years ago
|
||
I filed bug 1324498 to track Releng work and hope I didn't miss anything.
Flags: needinfo?(rail)
Comment 48•7 years ago
|
||
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #26) > Dan, we changed the requirement to only validate with one of the > certificates to requiring all certificates to validate for B2G. Would you > have a problem with reverting to the original requirement to only validating > with one of the certificates? Do you mean signatures rather than certificates? Each signature probably has a couple of certs in a chain. Why would we have multiple signatures, some of which are invalid? If they're different kinds of signatures, and there's some way to know ones that don't meet our current requirements it would be OK to pretend those don't exist and validate the ones that do meet the requirement.
Flags: needinfo?(dveditz) → needinfo?(robert.strong.bugs)
Assignee | ||
Comment 49•7 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #48) > (In reply to Robert Strong [:rstrong] (use needinfo to contact me) from > comment #26) > > Dan, we changed the requirement to only validate with one of the > > certificates to requiring all certificates to validate for B2G. Would you > > have a problem with reverting to the original requirement to only validating > > with one of the certificates? > > Do you mean signatures rather than certificates? Each signature probably has > a couple of certs in a chain. Signatures created using different certificates. Per the security review the certificates are self signed. Note: the signatures are checked using native API's on Windows and Mac and with NSS on Linux also per the security review. > > Why would we have multiple signatures, some of which are invalid? I don't recall why exactly it was decided during the security review to support multiple certificates and succeed if only one succeed but iitc it was so if we change certificate formats as we are doing in this bug we could fail on the old cert, succeed with the new cert, and thereby not have to perform an update watershed. > > If they're different kinds of signatures, and there's some way to know ones > that don't meet our current requirements it would be OK to pretend those > don't exist and validate the ones that do meet the requirement. That is what I am hoping for though I'm not sure how valuable it will be over time since they shouldn't change often.
Flags: needinfo?(robert.strong.bugs) → needinfo?(dveditz)
Comment 50•7 years ago
|
||
The typical risk of ignoring bad signatures in a case like this is a scenario like * good package signed correctly by signature "A" * it gets tampered with, invalidating "A" * it gets resigned with signature "B" that the bad guys got somehow Bad signature A can be a warning sign that something funny is going on, though I guess the bad guy could just remove the old signature in that case. There's a difference between an unknown cert and a tampered package, and in a PKI situation you'd get an error about the signature failing vs. a bad cert. That doesn't match this case because we're not using publicly issued certs, we're requiring the package to be signed by the one and only known good cert. If we ever supported _two_ certs in the downloader (a primary and a backup?) then we'd have to validate both signatures if we found both certs just in case. Then bad guys could just remove one, so don't do that -- just support one cert. Then it's OK to ignore signatures by certs you don't know.
Flags: needinfo?(dveditz)
Comment 51•7 years ago
|
||
I'd like CryptoEng to have a look at this and also briefly look at our SHA-2 implementations elsewhere for comparison. Adding JC.
Assignee | ||
Comment 52•7 years ago
|
||
Keep in mind that the implementation design that was created with the security team for this required that we use the system provided crypto instead of NSS if at all possible.
Comment 53•7 years ago
|
||
The patches looks good to me. They use SHA384 from openssl, which is fine. According to the comments differences between SHA512 and SHA384 were discussed (and in this case 384 is the better options).
Assignee | ||
Comment 54•7 years ago
|
||
jc and dveditz, can both of you provide feedback in regards to whether we can move forward with using SHA-384 or if a different algorithm should be used? Thanks!
Flags: needinfo?(jjones)
Flags: needinfo?(dveditz)
Comment 55•7 years ago
|
||
Robert: Franziskus' analysis matches mine. SHA384 is a good choice.
Flags: needinfo?(jjones)
Assignee | ||
Comment 56•7 years ago
|
||
Removing the needinfo for dveditz since he already ok'd the use of SHA384
Flags: needinfo?(dveditz)
Assignee | ||
Updated•7 years ago
|
Target Milestone: mozilla53 → mozilla56
Updated•7 years ago
|
QA Contact: amasresha
Assignee | ||
Comment 57•7 years ago
|
||
This patch applies on top of the patches in bug 641212
Attachment #8818426 -
Attachment is obsolete: true
Attachment #8885612 -
Flags: review+
Assignee | ||
Comment 58•7 years ago
|
||
Attachment #8885615 -
Flags: review+
Assignee | ||
Comment 59•7 years ago
|
||
This patch applies on top of the patches in bug 641212
Attachment #8818711 -
Attachment is obsolete: true
Attachment #8885616 -
Flags: review+
Assignee | ||
Comment 60•7 years ago
|
||
This patch applies on top of the patches in bug 641212
Attachment #8818708 -
Attachment is obsolete: true
Attachment #8885617 -
Flags: review+
Assignee | ||
Updated•7 years ago
|
Priority: P2 → P1
Assignee | ||
Comment 61•7 years ago
|
||
Patches are ready to land on oak for manual testing after the releng bugs are ready and the changes from bug 641212 that are already on oak have been manually tested. So, hopefully soon. After that both bug 641212 and this bug will land on m-c.
Assignee | ||
Updated•7 years ago
|
Whiteboard: [fce-active]
Assignee | ||
Comment 62•7 years ago
|
||
Removed adding tags = libmar to xpcshell.ini. Carrying forward r+
Attachment #8819067 -
Attachment is obsolete: true
Attachment #8889281 -
Flags: review+
Assignee | ||
Comment 63•7 years ago
|
||
Updated after recent lzma changes
Attachment #8885612 -
Attachment is obsolete: true
Attachment #8889557 -
Flags: review+
Assignee | ||
Comment 64•7 years ago
|
||
Attachment #8885616 -
Attachment is obsolete: true
Attachment #8889558 -
Flags: review+
Assignee | ||
Comment 65•7 years ago
|
||
Landed on oak along with bug 641212
Attachment #8885617 -
Attachment is obsolete: true
Attachment #8889559 -
Flags: review+
Assignee | ||
Comment 66•7 years ago
|
||
I had to update the data files for bug 641212. Carrying forward r+
Attachment #8889557 -
Attachment is obsolete: true
Attachment #8891230 -
Flags: review+
Assignee | ||
Comment 67•7 years ago
|
||
Attachment #8889559 -
Attachment is obsolete: true
Attachment #8891231 -
Flags: review+
Assignee | ||
Comment 68•7 years ago
|
||
I put these in their own patch since they intentionally have windows line endings.
Attachment #8891234 -
Flags: review+
Comment 69•7 years ago
|
||
Pushed by rstrong@mozilla.com: https://hg.mozilla.org/mozilla-central/rev/f72832cc0480 use SHA384 certificates to sign app update mar files. Part 1 - convert the libmar code from SHA1 to SHA384. r=mhowell, r=spohl, a=app_update_sha384 https://hg.mozilla.org/mozilla-central/rev/a0469afc3098 use SHA384 certificates to sign app update mar files. Part 2 - libmar test mar files signed with a SHA384 cert. r=mhowell, a=app_update_sha384 https://hg.mozilla.org/mozilla-central/rev/0fcbe72581bc use SHA384 certificates to sign app update mar files. Part 3 - libmar test extracted SHA384 signatures from the test mar files. r=mhowell, a=app_update_sha384 https://hg.mozilla.org/mozilla-central/rev/92f6879a8f9f use SHA384 certificates to sign app update mar files. Part 4 - app update SHA384 DER encoded certtificates. r=mhowell, a=app_update_sha384 https://hg.mozilla.org/mozilla-central/rev/23d91b010a0e use SHA384 certificates to sign app update mar files. Part 5 - app update test change for the new test mar file size. r=mhowell, a=app_update_sha384 https://hg.mozilla.org/mozilla-central/rev/a6c502679d44 use SHA384 certificates to sign app update mar files. Part 6 - app update test mar files signed with a SHA384 certificate. r=mhowell, a=app_update_sha384
Assignee | ||
Updated•7 years ago
|
status-firefox56:
--- → fixed
Flags: in-testsuite+
Assignee | ||
Updated•7 years ago
|
status-firefox54:
--- → wontfix
status-firefox55:
--- → wontfix
status-firefox-esr52:
--- → wontfix
status-thunderbird_esr52:
--- → wontfix
Assignee | ||
Updated•7 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Comment 70•7 years ago
|
||
Verified as fixed. Test runs are available here: https://testrail.stage.mozaws.net/index.php?/reports/view/494
Status: RESOLVED → VERIFIED
Comment 71•7 years ago
|
||
bugherder uplift |
This was backed out from Beta prior to the creation of 56b1 by way of bug 1387231. https://hg.mozilla.org/releases/mozilla-beta/rev/c495c07bdff0 It has now been re-landed for 56b3 by way of bug 1387238. https://hg.mozilla.org/releases/mozilla-beta/rev/cc8a7c1b2679 https://hg.mozilla.org/releases/mozilla-beta/rev/b848a13d3e9a https://hg.mozilla.org/releases/mozilla-beta/rev/a8873e18732b https://hg.mozilla.org/releases/mozilla-beta/rev/482eab1435c1 https://hg.mozilla.org/releases/mozilla-beta/rev/791e46c5e45e https://hg.mozilla.org/releases/mozilla-beta/rev/8b3ea08178d1
Updated•7 years ago
|
Whiteboard: [fce-active] → [fce-active][adv-main52-]
Updated•7 years ago
|
Whiteboard: [fce-active][adv-main52-] → [fce-active][adv-main56-]
Comment 72•7 years ago
|
||
When updating Fx 56.0 to 56.0.1 using the partial.mar or complete.mar files, updates fail. D/L files from https://ftp.mozilla.org/pub/firefox/releases/56.0.1/update/linux-x86_64/en-US/ The error in Linux terminal is: "ERROR: Unknown signature algorithm ID." That error is shown in code from comment 5, above. Same error when installing firefox-56.0-56.0.1.partial.mar, and firefox-56.0.1.complete.mar I didn't see an error or have problem installing firefox-55.0.3-56.0.partial.mar. The Mozilla Firefox version is installed in /opt. Only SHA256, 512 are listed on the v56.0.1 D/L page (above) - and those check out on the downloaded files. I also verified signatures on the two 56.0.1 update files. No idea what the problem is, except a change for checksums used in Fx landed in v56 & that's the 1st one I saw this error or had a problem installing updates. After updating 55.0.3 to 56.0, rechecking for updates should show another is available (56.0.1), but shows "up to date." In about:preferences, it lists Version 56.0 (64-bit), but Update History shows last update was 55.0.3.
Depends on: 1407685
Ben - I filed bug 1407685 to track the issue.
Updated•6 years ago
|
Whiteboard: [fce-active][adv-main56-] → [fce-active-legacy][adv-main56-]
You need to log in
before you can comment on or make changes to this bug.
Description
•