Opened 2 years ago

Closed 2 years ago

Last modified 21 months ago

#17917 closed defect (fixed)

Changelog after update is empty if JS is disabled

Reported by: gk Owned by: mcs
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-5.5, TorBrowserTeam201601R
Cc: brade, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

There is no changelog shown after the update to 5.5a5-hardened and no link to the changelog on our blog either. I think this happens because it was the first changelog ever in this series. We might want to be a bit more lenient in this case to have a future-proof mechanism for displaying the latest changes.

Child Tickets

Attachments (1)

tb-5.5a5-hardened.png (359.4 KB) - added by mcs 2 years ago.
5.5a5-hardened after update

Download all attachments as: .zip

Change History (29)

comment:1 Changed 2 years ago by mcs

I am unable to reproduce this problem. I downloaded a fresh copy of 5.5a4-hardened on a Ubuntu 14.04 LTS system and used the updater to upgrade to 5.5a5-hardened. After restart, the about:tbupdate tab with the changelog and a link to the blog post was opened, as I would expect. I will attach a screenshot.

I wonder if it sometimes works or what is going on.
gk - Did the about:tbupdate tab open at all?

Changed 2 years ago by mcs

Attachment: tb-5.5a5-hardened.png added

5.5a5-hardened after update

comment:2 Changed 2 years ago by mcs

Screenshot:

5.5a5-hardened after update

comment:3 Changed 2 years ago by cypherpunks

Same thing happened to me on 5.5a5 not hardened. See ticket:16940#comment:15

comment:4 Changed 2 years ago by mikeperry

I also experienced this issue. For me, it was because my security level blocked Javascript on this page. Enabling Javascript caused the changelog to load.

comment:5 Changed 2 years ago by mikeperry

Hrmm. Odd, though, since all 'about:' URLs should be whitelisted by NoScript. Maybe whatever we are doing to hide the URL bar is causing NoScript to fail to realize the page should be whitelisted?

comment:6 in reply to:  5 ; Changed 2 years ago by mcs

Summary: Changelog after the update to 5.5a5-hardened is emptyChangelog after update is empty if JS is disabled

Replying to mikeperry:

Hrmm. Odd, though, since all 'about:' URLs should be whitelisted by NoScript. Maybe whatever we are doing to hide the URL bar is causing NoScript to fail to realize the page should be whitelisted?

Ah ha! Do you know where NoScript gets its list of whitelisted URLs? I do not see about:tbupdate there, but I think it needs to be.

comment:7 in reply to:  6 Changed 2 years ago by mikeperry

Replying to mcs:

Replying to mikeperry:

Hrmm. Odd, though, since all 'about:' URLs should be whitelisted by NoScript. Maybe whatever we are doing to hide the URL bar is causing NoScript to fail to realize the page should be whitelisted?

Ah ha! Do you know where NoScript gets its list of whitelisted URLs? I do not see about:tbupdate there, but I think it needs to be.

The whitelists are in extension-overrides.js in the gitian repo, under Bundle-Data. There's one for each platform. Ex: Bundle-Data/linux/Data/Browser/profile.default/preferences/extension-overrides.js

However, if you list just the scheme in there, it is supposed to cover every single page that is a part of that scheme. And we list 'about:', which should cover about:tbupdate. I think maybe something else (the url bar being blank? just a guess though) is causing scripts to still get blocked on this page.

comment:8 Changed 2 years ago by cypherpunks

I'm from comment:3

My javascript was also off. However turning on javascript didn't make the changelog to load for me.

comment:9 in reply to:  8 Changed 2 years ago by mcs

Replying to cypherpunks:

My javascript was also off. However turning on javascript didn't make the changelog to load for me.

You must be experiencing a different problem. What happens if no changelog is displayed, please use the page inspector (ctrl/right click and choose "Inspect Element") to check for console messages. Thanks!

comment:10 Changed 2 years ago by cypherpunks

When I choose "Inspect Element" nothing shows up in the console

Last edited 2 years ago by cypherpunks (previous) (diff)

comment:11 Changed 2 years ago by cypherpunks

I also disabled NoScript and TorButton in addons and the problem still persists. Must be something else

comment:12 Changed 2 years ago by gk

Keywords: tbb-5.5 added

comment:13 Changed 2 years ago by gk

Keywords: TorBrowserTeam201601 added

comment:14 Changed 2 years ago by mikeperry

I again hit this on the 5.5a6 upgrade. Scripts were disabled because I was on high security level. Clicking NoScipt to allow all scripts caused the notes to load. Not sure if they would not have loaded anyway, or if clicking reload was all I needed, though.

comment:15 Changed 2 years ago by mcs

Owner: changed from tbb-team to mcs
Status: newassigned

comment:16 Changed 2 years ago by mcs

This problem disappears if I add about:tbupdate to the noscript.mandatory pref value. The value we use (set via the extension-overrides.js file) is:

about: chrome: resource: blob: mediasource: moz-safe-about:

I do not know a lot about NoScript, but the default value for that pref is:

chrome: blob: mediasource: moz-safe-about: about: about:addons about:blocked about:crashes about:home about:config about:neterror about:certerror about:memory about:plugins about:preferences about:privatebrowsing about:sessionrestore about:support resource: about:srcdoc

Maybe NoScript's behavior was modified at some point and we need to list the full URL for each about:... page. Should I ask Giorgio Maone?

comment:17 in reply to:  11 Changed 2 years ago by mcs

Replying to cypherpunks:

I also disabled NoScript and TorButton in addons and the problem still persists. Must be something else

Indeed. I just experienced the same problem on Windows 7 with a TB 5.5a5 -> 5.5a6 update. There is a a problem with the code that reads the ChangeLog.txt file. I opened #18064 to track that issue.

comment:18 Changed 2 years ago by mcs

I resolved #18059 as a duplicate of this ticket.

comment:19 Changed 2 years ago by mcs

Keywords: TorBrowserTeam201601R added; TorBrowserTeam201601 removed
Status: assignedneeds_review

There may be a better way to address this in NoScript, but here is a simple fix (whitelist about:tbupdate):
https://gitweb.torproject.org/user/brade/tor-browser-bundle.git/commit/?h=bug17917-01&id=07a3675f06ee1a0345e9d9c3e68fee9613ae0f9f

Please review.

comment:20 Changed 2 years ago by cypherpunks

Do you need to put it in those 3 prefs? Isn't it enough with "mandatory"?

Do you actually know what you are doing here? Serious question because NoScript is so wonderfully documented that I certainly find it hard to understand, specially now that it has grown into the spaghetti monster's younger sibling.

I wonder if this is really the "preferred form of the work for modification" for Maone.

/rant off

comment:21 in reply to:  20 ; Changed 2 years ago by mcs

Replying to cypherpunks:

I wonder if this is really the "preferred form of the work for modification" for Maone.

To be honest, I do not know if this is the preferred solution. It is *a* solution and I do not believe it will introduce a new problem or otherwise cause side effects.

comment:22 in reply to:  21 Changed 2 years ago by cypherpunks

Not him, but I think you misunderstood. That is a GPL quote part of the definition for source code, he's implying that Giorgio Maone might have a private "source" because how badly documented the code in the xpi is.

comment:23 Changed 2 years ago by gk

Resolution: fixed
Status: needs_reviewclosed

Looks okay. Applied to master (16b935d869a8673ceac199e3617873db34ae8f0b) and hardened.builds (69c12f1a8817c35d2e815d3bd3ab090c2434f067).

comment:24 in reply to:  16 ; Changed 22 months ago by bugzilla

Replying to mcs:

I do not know a lot about NoScript, but the default value for that pref is:

chrome: blob: mediasource: moz-safe-about: about: about:addons about:blocked about:crashes about:home about:config about:neterror about:certerror about:memory about:plugins about:preferences about:privatebrowsing about:sessionrestore about:support resource: about:srcdoc

Maybe NoScript's behavior was modified at some point and we need to list the full URL for each about:... page. Should I ask Giorgio Maone?

You really should. Because about:cache is broken the same way, and who knows what else.

comment:25 in reply to:  24 ; Changed 21 months ago by ma1

Replying to bugzilla:

Replying to mcs:

Maybe NoScript's behavior was modified at some point and we need to list the full URL for each about:... page. Should I ask Giorgio Maone?

You really should. Because about:cache is broken the same way, and who knows what else.

At a certain point Mozilla phased out CAPS, which was the original declarative subsystem which NoScript relied upon for script blocking, and which automatically "knew" about internal about:xyz URIs marked as privileged, leaving them alone even if they were not whitelisted. In that context, an about URI not matching NoScript's whitelist was still capable of running scripts if privileged (e.g. about:addons), causing only a cosmetic UI mismatch (you would see it as forbidden in NoScript's UI while it worked anyway).
Once CAPS has been removed, I had to switch to a completely different script-blocking approach, which programmatically checks each page's URL just before HTML parsing (and therefore script execution) starts and set "script blocked" flag at the window level. This flag is not overridden by "privileged" about: URIs, therefore if they're not whitelisted in NoScript they won't run scripts.
From then on, whatever the UI says is in sync with the actual page status, but on the other hand if Mozilla adds new about: pages which require scripts (or starts requiring scripts for an existent about: page which could previously work without) it either needs to be manually whitelisted or, since we generally trust privileged browser code, it's preferably added to noscript.mandatory. Which, as you noticed, is not always up to date.
As soon as I'm done with my current top priorities (e10s full compatibility and WebExtensions migration) I'll try to figure out a way to automatically keep in sync privileged about: URIs, if possible.

comment:26 in reply to:  25 ; Changed 21 months ago by bugzilla

Replying to ma1:
Hmm, your reply is disappointing. Instead of putting security first, you preferred to fight with Mozilla's bells and whistles (e10s full compatibility and WebExtensions migration) that were buggy as hell and continued to be a crap until ESR52 definitely (maybe, they are payable for and that's the case). You haven't answered my emails to giorgio at maone.net, but I ask here: is there any hope that TBB-related tickets like https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~noscript gain more priority? Thx.

comment:27 in reply to:  26 ; Changed 21 months ago by ma1

Replying to bugzilla:

is there any hope that TBB-related tickets like https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~noscript gain more priority? Thx.

Yes, definitely, but no matter how disappointed you are for me prioritizing "Mozilla's bells and whistles", if NoScript doesn't comply first of all with Firefox's roadmap, which is already phasing out not-e10s compatible extensions, and then is going after legacy add-ons (i.e. all those which are not WebExtensions) there will be no NoScript to be fixed at all...

comment:28 in reply to:  27 Changed 21 months ago by bugzilla

Replying to ma1:

Replying to bugzilla:

is there any hope that TBB-related tickets like https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~noscript gain more priority? Thx.

Yes, definitely, but no matter how disappointed you are for me prioritizing "Mozilla's bells and whistles", if NoScript doesn't comply first of all with Firefox's roadmap, which is already phasing out not-e10s compatible extensions, and then is going after legacy add-ons (i.e. all those which are not WebExtensions) there will be no NoScript to be fixed at all...

Well, it seems you were frightened by Mozilla. Look how TBB Team solved that in #17248:

This is done and Mozilla should be aware of our needs by now.

One sentence was removed from my message, but it had sense: it's a Mozilla's responsibility to port (or make it trivial to port) security/popular add-ons to their bells and whistles, and yours - only to review that. You can show them this message. But the main thought is that this activity shouldn't stall the security-related development.

Note: See TracTickets for help on using tickets.