FEDORA-2020-44d771d0ef created by rrelyea 10 months ago for Fedora 33
obsolete

Rebase of NSS to 3.59 for Firefox.

This update has been submitted for testing by rrelyea.

10 months ago

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

10 months ago

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

10 months ago

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

10 months ago
User Icon adamwill commented & provided feedback 10 months ago
karma

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.

10 months 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.

10 months ago

I'll test that.

User Icon bojan commented & provided feedback 10 months ago
karma

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 10 months ago
karma

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 10 months ago
karma

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 10 months ago
karma

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 10 months ago
karma

Addons broken

User Icon treba commented & provided feedback 10 months ago
karma

+1 for broken addons.

This update has been obsoleted.

10 months 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 10 months ago
karma

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.

Metadata
Type
enhancement
Severity
medium
Karma
-4
Signed
Content Type
RPM
Test Gating
Settings
Unstable by Karma
-3
Stable by Karma
disabled
Stable by Time
disabled
Dates
submitted
10 months ago
in testing
10 months ago

Automated Test Results