Closed earthlng closed 5 years ago
@earthlng @tartpvule @Thorin-Oakenpants I am trying to install the patch with no sucess.
Seted -> general.config.filename to "monkey_Bug1421725_WebRequest.cfg" Steed -> general.config.sandbox_enabled to false
user_pref("general.config.filename", "monkey_Bug1421725_WebRequest.cfg"); user_pref("general.config.sandbox_enabled", false);
Put monkey_Bug1421725_WebRequest.cfg in root Profile Path put monkey_Bug1421725_WebRequest.cfg in root Firefox path
Dont work! what i am losing?
Firefox Version: 66.0.2 OS: Windows 10
If anyone can help, thanks.
You'll have to ask tartpvule - create an issue at his repo where everything in the one place
@Thorin-Oakenpants
You'll have to ask tartpvule - create an issue at his repo where everything in the one place
I already created with no awaser yet, i will wait. i asked here too because i see the conversation about this and maybe anyone here can help with this.
@Renan19
Hi,
@tartpvule wrote the patch based on the ESR code and it might not necessarily work in newer versions, or the underlying code could have changed in subtle ways or it might break with any future release. If you want to use it, you should best check if the modified code is still somewhat the same. If you just want to use it as is and hope for the best, then here's how you enable it:
create a file autoconfig.js
in <install-dir>\defaults\pref\
with this content:
// Any comment. You must start the file with a single-line comment!
pref("general.config.sandbox_enabled", false);
pref("general.config.filename", "monkey_Bug1421725_WebRequest.cfg");
pref("general.config.obscure_value", 0);
and place the monkey_Bug1421725_WebRequest.cfg file in the root Firefox path (where firefox.exe is located).
FYI disabling the autoconfig sandbox with general.config.sandbox_enabled
seems to still be allowed in Release at the moment but they already said that they only want to keep allowing it to be disabled in ESR in the future.
hope that helps :)
@Renan19 see the issue in my repo.
@earthlng About monkey_AddonSettings.cfg
that you tried, have you set xpinstall.signatures.required
to false
? What is the result of Components.utils.import("resource://gre/modules/addons/AddonSettings.jsm", {}).AddonSettings.REQUIRE_SIGNING
in Scratchpad in about:config
with and without the monkeypatch?
@earthlng @tartpvule Thanks, tested and it is working fine now on firefox lastest version.
@tartpvule
have you set xpinstall.signatures.required to false?
I don't remember but I'm pretty sure I did. I had also tested it with a modified version of your script that didn't read the prefs and instead used hardcoded values but that didn't work either.
What is the result of ...
I just tested it again and REQUIRE_SIGNING is false with the patch and true w/o it. Ran it on both about:config and about:addons and the values are the same ie it should theoretically allow me to install unsigned extensions but it doesn't and IDK why. Maybe something to do with lazy loading of components that they changed since ESR or FF somehow keeping a cache of the values, I have no idea.
@earthlng Thank you for pointing out the problem As it turns out, my monkey_AddonSettings.cfg has not been working for quite a while, even in ESR 60. The problem is that dependent modules like XPIProvider.jsm would have already acquired a reference to the old AddonSettings by the time the patch is applied (a race condition? I don't know). I have updated the file, though "no reliability guarantees", at least it seems to work on my ESR 60 enough and that's what I am focusing on.
from Jan 2018 https://github.com/ghacksuserjs/ghacks-user.js/issues/265#issuecomment-359462026
Pants... but please don't take this to ghacks! I still have enough faith in the mozilla devs to think that they'll do something about it when @gorhill is the one telling them how bad this is.
It wasn't me: https://www.ghacks.net/2019/05/23/firefox-csp-issue-may-cause-extension-conflicts/
But given that HTTPS-E are aware of the issue, and that extension is used in Tor Browser, and given that it finally got an issue at uBlock-issues, and some other external factors - it seems as if KM is considering doing something about it. Just watch the relevant bugzillas
I don't get it. WTF is wrong with people. A non-event such as a pref to control profile/chrome/
lookups, where nothing is lost, gets so much outrage and attention and yet this issue which actually breaks things and can compromise a user's security and privacy gets absolutely no comments or anything.
r/Firefox usually has some knowledgeable rational and well spoken people - but I can't understand why no-one has picked up on it. Are they all fixed fixated (edit) on looks over form?
why are you confused @gwarser, or is that just the best of a limited set of emojis you could choose ?
I don't expect everyone on r/Firefox to understand the ramifications of this bug, but not a single person has commented, and yet they're always happen to discuss in depth technical issues about other security issues. Isn't anyone there concerned that their extension can often not work as expected? Extensions that help security, tracking, FPing ...
I think I'll do a Wonko the Sane and build an inside out house called The Outside of the Asylum to house the world. I shall live inside it and any of you are welcome to come visit (if you are sane)
I don't get it. WTF is wrong with people. A non-event such as a pref to control
profile/chrome/
lookups, where nothing is lost, gets so much outrage and attention and yet this issue which actually breaks things and can compromise a user's security and privacy gets absolutely no comments or anything.r/Firefox usually has some knowledgeable rational and well spoken people - but I can't understand why no-one has picked up on it. Are they all ~fixed~ fixated (edit) on looks over form?
https://old.reddit.com/r/firefox/comments/btvixo/firefox_bug_causes_addons_ublock_origin_https/ this thread seems to be getting a bit more traction and has a more informative headline
Well, I kept track of that for all of 8 hrs. It trended up very quickly into second place on hot (after the PSA userChrome thing which I think is a sticky). 251 points, 35 comments. It was there when looking at new items in its right place. Now you can't find it unless you know it exists. It doesn't even show when looking at items in chronological order. r/Firefox, AFAIK, has demoted it so it doesn't show. And it has now died and nothing has changed for over an hour.
yup .. shadowbanned. I don't understand why? People are now asking why it's shadowbanned. FFS, do they not want a better product? Fucking jerks. For some reason they've always hated this repo and associated it with the Mozilla haters at ghacks itself
It just popped back up, but it was definitely shadowbanned for a few hours. Maybe there was disagreement among the mods of the sub. Still very disappointing to see that suppressing information about a bug is on the table at all.
I guess its par for the course (I don't hang around and read these sorts of things) but 2/3rds of the comments are off topic - I guess you get that with everyone wanting to chime in and bitch about something, and/or lack of knowledge
OMFG ... https://bugzilla.mozilla.org/show_bug.cgi?id=1462989#c24
Hey folks, we're getting a lot of advocacy chatter on this bug, so I'm going to close comments on it for the time being
First of all, only one comment was marked advocacy - five days ago. No-one has said anything on the bug for over 3 days. WTF? Way to win friends and influence people. Fucking bollocks. I don't care about looking backwards, I just want the problem addressed. But they seem to have their mind somewhere else right now. WTF?!
Instead of begging Mozilla on our knees wouldn’t it make more sense to
I know, it’s a tall order, but at least it seems a way forward.
I considered that idea a long time ago, but there would be more than a few problems with that, technically speaking... It can be done, but it wouldn't be easy for extension developers to adopt in the least. They would need to make pretty extreme changes to their respective extensions and, even then, that approach wouldn't allow them to do some of the things they can do now. It's not worthwhile.
I just developed a new experimental patch for Bug1421725 against mozilla-central, not yet extensively tested. This patch do what MDN says: "the second listener will see modifications made by the first listener". Anyone interested in checking it out?
https://github.com/tartpvule/my-firefox-patches/blob/master/Bug1421725_WebRequest_central.patch
@tartpvule: I've tested the monkey-patch version and it seems to work. I've got a relatively small test case that I used to verify it:
do you have intentions of submitting this patch to mozilla? (please do!)
@girst Thank you for your interest in my patch. https://bugzilla.mozilla.org/show_bug.cgi?id=1421725 The patch was rejected, as expected, citing performance reasons :( I don't see any performance regressions in my daily use, though.
Oh well, back to maintaining private patches and builds I guess. IMO: "merging" headers is a mess of glaringly obvious edge cases.
The patch was rejected, as expected, citing performance reasons :(
Yes, that is shame, I really don't know what is the hold reason at Mozilla... 😞
I don't see any performance regressions in my daily use, though.
... and performance for sure its not the real reason.
On Sat, Jul 27, 2019 at 09:58:46AM -0700, tartpvule wrote:
https://bugzilla.mozilla.org/show_bug.cgi?id=1421725 The patch was rejected, as expected, citing performance reasons :(
missed that, thanks! this sorta-WONTFIX is just the worst response--i can't even see any perf tests (they should have the infra) linked in the bug report, while multiple people have shown multiple problems this causes :|
Oh well, back to maintaining private patches and builds I guess.
I've gone to great length avoiding that--including patching omni.ja. recently, I've managed to confine my modifications into AutoConfig[1]
[1]: for reference to who else might need it: https://gir.st/blog/legacyfox.htm
@tartpvule Thanks for your work. Is this patch still valid for FF68? I'm doing my own builds anyway so I could easily apply it myself. I'm also staying on ESR so if it still works I'll be good for another year, which would be wonderful.
@M83tUt3
Use my Bug1421725_WebRequest_central.patch
from https://github.com/tartpvule/my-firefox-patches/blob/4dd8c06da18d2137d86ea43a2a4f936b5b100228/Bug1421725_WebRequest_central.patch, after patching in https://hg.mozilla.org/mozilla-central/rev/308ef98e6e4b (Bug 1450965)
After ESR68.1 is released and I finalized my private build, I will update my Firefox patches repo with updated instructions.
... aaaaand now they changed the docs
edit: FYI: @gorhill @gwarser @ublock-user
^^ lamest way to do it. 😢
@gorhill, I found a problem with uMatrix in that, depending on the order in which FF loads the addons, uMatrix "restores" the Content-Security-Policy header when another addon already changed it or removed it completely. Maybe other headers are affected as well, IDK. uBO doesn't have the same problem so I assume you already fixed it there.
Since you closed your Issue tracker for uMatrix I didn't know how else to contact you. If you're interested let me know, I have a simple example addon ready to share and the steps to reproduce. Thanks