NoScript could not be verified and gets disabled after restart

We have at least two bug reports about NoScript getting disabled (presumably after an extension update happened) because it could not get verified. It might be related to #19491 (moved) but that is not known.

added component::applications/tor browser noscript owner::tbb-team priority::very high resolution::fixed severity::major status::closed tbb-security type::defect labels

Thanks to a user on IRC (femme) we did try to debug this a bit but enabling extensions.logging.enabled does not shine any light on this issue. I wonder if anybody could come up with a good idea to debug this. Maybe we should ship with extra debugging code for this case until we tracked the thing down?

I also wonder whether Mozilla has heard from this and has any ideas given that we do not change any code with respect to NoScript's signing state..

Trac:
Owner: N/A to tbb-team
Component: - Select a component to Applications/Tor Browser

The extension is fine it is just that the signature verification fails in rare cases for some reason and NoScript is then stuck in the "disabled" bucket.

Maybe we could trigger a signature re-check at every start somehow?

Replying to gk:

The extension is fine it is just that the signature verification fails in rare cases for some reason and NoScript is then stuck in the "disabled" bucket.

Is this affecting other extensions (e.g., for Firefox users)? It seems like even a rare "false failure" will cause a lot of problems.

As you pay much attention to this issue (dunno why), here are some thoughts on the topic: What really should be done is a warning about that some component has failed to initialize. As reports about NoScript started to appear more often, last updates of NoScript could be the reason. The scenario is: user starts TBB and NoScript prepares to update, say .13 to .14; then TBB finds its new version and prepares to update; user restarts TBB and Check Add-on for Compatibility is invoked by NoScript update, but there is no Tor connection ready to check the signature (plus some bugs with early network connections might exist), so initialization fails. (The same is for HTTPSE) Firefox users are not affected, because of existed connection or no bugs with handling of it.

Thanks for marking this with usability keyword. The UX team triaged the ticket and realize that the fix does not require our assistance, so we are removing the keyword as part of our triage.

Trac:
Keywords: tbb-usability deleted, N/A added

It's not mentioned above but according to the TB's Changelog very old versions (6.5 and earlier) were affected and it did not happen since (at least it wasn't reported here). Does it happen regularly or can we close this and reopen if it happens again?

(i found here reading security issue and it doesn't seem to have very high priority anymore)

Trac:
Status: new to needs_information
Keywords: N/A deleted, noscript added

Trac:
Username: gapegas7uftp

image of noscript could not be verified for use with tor browser and has been disabled

Trac:
Username: gapegas7uftp

Just got this with a new install of TB linux64-8.0.8_en-US.

This is the first time I have seen this.

Attached a pic (no_script_10.2.4_disabled.png)

Trac:
Username: gapegas7uftp

There is a workaround in ticket:30388 to disable xpinstall.signatures.required in !about:config

Probably a signature certificate expired.

Trac:
Username: gapegas7uftp

The original issue that this ticket was opened for 3 years ago may have been triggered by https://bugzilla.mozilla.org/show_bug.cgi?id=1267318 which also happened 3 years ago.

Closing as a duplicate of #30388 (moved)

Trac:
Status: needs_information to closed
Resolution: N/A to duplicate

I also have this problem now. I reinstalled three times the tor browser. I also tried install 8.0.7. How to do, to force NoScript to activate and stay active?

Why I see "Explore Privately" if NoScript doesn't work???

Is there any workaround to force enable NoScript?

Trac:
Username: Crissy2

Replying to cypherpunks:

The original issue that this ticket was opened for 3 years ago may have been triggered by https://bugzilla.mozilla.org/show_bug.cgi?id=1267318 which also happened 3 years ago.

Nice find. That could be it. Let's mark this ticket as fixed then.

Trac:
Status: closed to reopened
Resolution: duplicate to N/A

Trac:
Status: reopened to closed
Resolution: N/A to fixed

closed

mentioned in issue #30388 (moved)

moved to tpo/applications/tor-browser#19907 (closed)