This seems to break add-on install in Firefox. Note the "Installation aborted because the add-on appears to be corrupt" error. I don't think this is an issue with the add-on itself, because the same test passed on other earlier and later F33 updates. It really seems to be an issue caused by the newer NSS.
OK, the issue is add-ons appear to be using sha1 signatures, which are not disabled by policy. NSS 3.59 is now enforcing general signatures. If you use update-crypto-policies -set LEGACY add-ons work will work.
The question is how we should deal with this. We shouldn't back out the enforcement in NSS. I'm not sure if we should hack around it in Firefox until add-ons update, or if we should just require LEGACY crypto policies if you want to load add-ons. Does anyone know if firefox is moving to using SHA-2 for add-ons anytime soon?
To turn SHA1 on for non-certificate signatures:
/ Sets the NSS_USE_ALG_IN_ANY_SIGNATURE bit. does not change NSS_USE_ALG_IN_CERT_SIGNATURE /
rv = NSS_SetAlgorithmPolicy(SEC_OID_SHA1, NSS_USE_ALG_IN_ANY_SIGNATURE, 0);
/ checking rv is optional here, more likely to give a nice error message if policy is
* locked /
To temporarily turn policy on for one function:
/ Get the previous state of the signature policy bit /
policy=0;
policy_rv = NSS_GetAlgorithmPolicy(SEC_OID_SHA1, &policy);
if (policy_rv == SECSuccess) {
/ this sets policy to NSS_USE_ALG_IN_ANY_SIGNATURE if that bit was off, We'll use it to clear
* that bit after we complete our command /
policy = (~policy & NSS_USE_ALG_IN_ANY_SIGNATURE) ;
/ turn on policy /
policy_rv = NSS_SetAlgorithmPolicy(SEC_OID_SHA1, NSS_USE_ALG_IN_ANY_SIGNATURE, 0);
}
/ do function here /
if (policy_rv == SECSuccess) {
/ clear the policy bit again if it was off before /
NSS_SetAlgorithmPolicy(SEC_OID_SHA1, 0, policy);
}
Probably the easiest is have a pref that enables sha1 signatures for add-ons and is it's set just flip the policy bit and not worry about saving and clearing it, since it only affects policy for firefox.
"if we should just require LEGACY crypto policies if you want to load add-ons"
No, that would be completely unacceptable. We can't just start breaking people's add-ons in a stable release update and telling them to do cryptic stuff to fix them. After the update Firefox add-ons should work as they did before, with no manual intervention required. If the policy is too far ahead of the real world the policy needs to be adjusted.
We should probably unpush this update until this is figured out, also.
So for rawhide, I don't think we should be backing out the sha1-signature restrictions. It's probably reasonable for f32 and f33. though. I'll create new builds with those. I think we'll need a firefox work around until mozilla changes your addon-signing scheme.
I don't really see any benefit to keeping the restriction in Rawhide. People are going to want to run Firefox add-ons. I mean, the two most prominent people using Rawhide on the desktop are probably me and @kevin and we both want to run Firefox add-ons. :)
All the restriction will do is cause people to set the entire system-wide policy to LEGACY (which reduces their security in all sorts of other areas) or try and hand-craft an exception for this specific case and possibly get it wrong and break stuff. There's no benefit for anyone there.
If Mozilla re-signs add-ons, great. Until then our default policy should accept SHA-1 signatures for Firefox add-ons, using as finely-grained as possible a policy exception for that purpose.
Guys, this update needs to be pulled immediately - it simply isn't acceptable to delay and have a discussion about it. It's wreaking havoc. It is completely unacceptable to have something causing such disruption still in updates-testing going on 48 hours now.
This update has been submitted for testing by rrelyea.
This update's test gating status has been changed to 'ignored'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'ignored'.
This seems to break add-on install in Firefox. Note the "Installation aborted because the add-on appears to be corrupt" error. I don't think this is an issue with the add-on itself, because the same test passed on other earlier and later F33 updates. It really seems to be an issue caused by the newer NSS.
@mstransky for info.
I'm able to reproduce the issue with the 3.59-2 build
This update has been pushed to testing.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
I'll test that.
Works here (no addons).
I rebuilt Firefox 84 with in-tree nss and it works a expected. With nss-3.59 from this update the add-ons are broken.
Add-on bug also appeared in Rawhide.
OK, the issue is add-ons appear to be using sha1 signatures, which are not disabled by policy. NSS 3.59 is now enforcing general signatures. If you use update-crypto-policies -set LEGACY add-ons work will work.
The question is how we should deal with this. We shouldn't back out the enforcement in NSS. I'm not sure if we should hack around it in Firefox until add-ons update, or if we should just require LEGACY crypto policies if you want to load add-ons. Does anyone know if firefox is moving to using SHA-2 for add-ons anytime soon?
To turn SHA1 on for non-certificate signatures: / Sets the NSS_USE_ALG_IN_ANY_SIGNATURE bit. does not change NSS_USE_ALG_IN_CERT_SIGNATURE / rv = NSS_SetAlgorithmPolicy(SEC_OID_SHA1, NSS_USE_ALG_IN_ANY_SIGNATURE, 0); / checking rv is optional here, more likely to give a nice error message if policy is * locked /
To temporarily turn policy on for one function: / Get the previous state of the signature policy bit / policy=0; policy_rv = NSS_GetAlgorithmPolicy(SEC_OID_SHA1, &policy); if (policy_rv == SECSuccess) { / this sets policy to NSS_USE_ALG_IN_ANY_SIGNATURE if that bit was off, We'll use it to clear * that bit after we complete our command / policy = (~policy & NSS_USE_ALG_IN_ANY_SIGNATURE) ; / turn on policy / policy_rv = NSS_SetAlgorithmPolicy(SEC_OID_SHA1, NSS_USE_ALG_IN_ANY_SIGNATURE, 0); } / do function here / if (policy_rv == SECSuccess) { / clear the policy bit again if it was off before / NSS_SetAlgorithmPolicy(SEC_OID_SHA1, 0, policy); }
Probably the easiest is have a pref that enables sha1 signatures for add-ons and is it's set just flip the policy bit and not worry about saving and clearing it, since it only affects policy for firefox.
The issue is in F32, F33, and rawhide.
strasky: The in tree NSS doesn't use the system-policy, so that is expected.
When I said 'not disabled' I really meant 'not enabled'.
I can confirm that this update breaks addons in firefox completely.
"if we should just require LEGACY crypto policies if you want to load add-ons"
No, that would be completely unacceptable. We can't just start breaking people's add-ons in a stable release update and telling them to do cryptic stuff to fix them. After the update Firefox add-ons should work as they did before, with no manual intervention required. If the policy is too far ahead of the real world the policy needs to be adjusted.
We should probably unpush this update until this is figured out, also.
works for me
So for rawhide, I don't think we should be backing out the sha1-signature restrictions. It's probably reasonable for f32 and f33. though. I'll create new builds with those. I think we'll need a firefox work around until mozilla changes your addon-signing scheme.
Mozilla has create a bugzilla for their end.:https://bugzilla.mozilla.org/show_bug.cgi?id=1682613
I don't really see any benefit to keeping the restriction in Rawhide. People are going to want to run Firefox add-ons. I mean, the two most prominent people using Rawhide on the desktop are probably me and @kevin and we both want to run Firefox add-ons. :)
All the restriction will do is cause people to set the entire system-wide policy to LEGACY (which reduces their security in all sorts of other areas) or try and hand-craft an exception for this specific case and possibly get it wrong and break stuff. There's no benefit for anyone there.
If Mozilla re-signs add-ons, great. Until then our default policy should accept SHA-1 signatures for Firefox add-ons, using as finely-grained as possible a policy exception for that purpose.
Guys, this update needs to be pulled immediately - it simply isn't acceptable to delay and have a discussion about it. It's wreaking havoc. It is completely unacceptable to have something causing such disruption still in updates-testing going on 48 hours now.
Let's track this as https://bugzilla.redhat.com/show_bug.cgi?id=1908018 as update system isn't suitable for it.
Addons broken
+1 for broken addons.
This update has been obsoleted.
One more thing: for me it also broke Widevine streams because some key verification failed - just as a reminder for something to test.
Wow, finally found the reason all my Firefox addons all broke on my fedora machine, while still working on Manjaro.