Changelog after update is empty if JS is disabled
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.
Activity
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?
-
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.
Trac:
Summary: Changelog after the update to 5.5a5-hardened is empty to Changelog after update is empty if JS is disabled 
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.
-
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!
-
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?
-
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 (moved) to track that issue.
-
I resolved #18059 (moved) as a duplicate of this ticket.
-
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.
Trac:
Status: assigned to needs_review
Keywords: TorBrowserTeam201601 deleted, TorBrowserTeam201601R added 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
-
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.
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.
Trac:
Reviewer: N/A to N/A
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.
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.
-
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...
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 (moved): 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.
mentioned in issue #18059 (moved)
mentioned in issue #18064 (moved)
mentioned in issue tpo/applications/tor-browser#18064 (closed)
