NSS-3.59 rebase

FEDORA-2020-44d771d0ef created by rrelyea 3 years ago for Fedora 33

Rebase of NSS to 3.59 for Firefox.

This update has been submitted for testing by rrelyea.

3 years ago

This update's test gating status has been changed to 'ignored'.

3 years ago

This update's test gating status has been changed to 'waiting'.

3 years ago

This update's test gating status has been changed to 'ignored'.

3 years ago
User Icon adamwill commented & provided feedback 3 years ago

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.

I'm able to reproduce the issue with the 3.59-2 build

This update has been pushed to testing.

3 years ago

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.

3 years ago

I'll test that.

User Icon bojan commented & provided feedback 3 years ago

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'.

User Icon decathorpe commented & provided feedback 3 years ago

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.

User Icon cserpentis commented & provided feedback 3 years ago

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.

User Icon gbcox commented & provided feedback 3 years ago

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.

User Icon lupinix commented & provided feedback 3 years ago

Addons broken

User Icon treba commented & provided feedback 3 years ago

+1 for broken addons.

This update has been obsoleted.

3 years ago

One more thing: for me it also broke Widevine streams because some key verification failed - just as a reminder for something to test.

User Icon agurenko commented & provided feedback 3 years ago

Wow, finally found the reason all my Firefox addons all broke on my fedora machine, while still working on Manjaro.

Please login to add feedback.

Content Type
Test Gating
Unstable by Karma
Stable by Karma
Stable by Time
3 years ago
in testing
3 years ago

Automated Test Results