Path: csiph.com!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: Richmond Newsgroups: alt.comp.software.firefox Subject: Re: Unwanted update to 150 just happened Date: Thu, 30 Apr 2026 14:23:39 +0100 Organization: Frantic Message-ID: <82ecjwintw.fsf@example.com> References: <10sinht$tpvi$1@dont-email.me> <10sisme$vqg1$1@dont-email.me> <10sivi0$10uuo$1@dont-email.me> <10sptp2$311i3$1@dont-email.me> <10sr2ep$3c77i$1@dont-email.me> <10sr8ck$3f3pq$1@dont-email.me> <10srqs8$3jk6e$1@dont-email.me> <82jytp6a67.fsf@example.com> <10stlmh$51ep$1@dont-email.me> <10suick$c4n8$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: solani.org; logging-data="1243973"; mail-complaints-to="abuse@news.solani.org" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:MJjLBSyoIrZC/onLsxV1jeZ2dfs= sha1:zL3AphZCN45Yc3tlyohri3W4NdM= X-User-ID: eJwFwYEBwCAIA7CXQGkd5yDY/09Ygk1nnyAYELSuP8zKT8jwHETYrY6zJbm9GSZr+rKsYfwBHGwRYA== Xref: csiph.com alt.comp.software.firefox:16972 dillinger writes: > On 30/04/2026 05:30, The Real Bev wrote: >> On 4/29/26 12:20, Dave Royal wrote: >>> dillinger Wrote in message: >>> >>>> On 29/04/2026 17:47, Richmond wrote: >>>>> dillinger writes: >>>>> >>>>>> Op 29-04-2026 om 04:36 schreef The Real Bev: >>>>>>> On 4/28/26 14:21, Dave Royal wrote: >>>>>>>> The Real Bev Wrote in message: >>>>>>>> >>>>>>>>> On 4/28/26 02:14, Dave Royal wrote: >>>>>>>>>> The Real Bev Wrote in message: >>>>>>>>>> >>>>>>>>>>> On 4/25/26 10:26, Nobody wrote: >>>>>>>>>>>> On Sat, 25 Apr 2026 18:18:07 +0100, Andy Burns >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Retirednoguilt wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I've never had FF update me autonomously. >>>>>>>>>>>>> >>>>>>>>>>>>> I have it set for "Check for updates but let you choose to >>>>>>>>>>>>> install them" >>>>>>>>>>>>> and as best as I can remember, its never disobeyed ... >>>>>>>>>>>> >>>>>>>>>>>> Should a user (for whatever reason) 'uninstall/re-install' >>>>>>>>>>>> then that >>>>>>>>>>>> radio button changes to 'automatically install/recommended'. >>>>>>>>>>>> >>>>>>>>>>>> Semi-OT, Thunderbird conversely holds the 'check for updates but >>>>>>>>>>>> lemme >>>>>>>>>>>> do the work' setting. >>>>>>>>>>> >>>>>>>>>>> I have had that setting for decades -- and still do.  Some years >>>>>>>>>>> ago it stopped working and some kind person posted the >>>>>>>>>>> policies.json fix -- which worked until today.  Posted herewith: >>>>>>>>>>> >>>>>>>>>>> Make a new firefox/distribution/ subdirectory which will contain >>>>>>>>>>> the file policies.json which contains >>>>>>>>>>> { >>>>>>>>>>>     "policies": { >>>>>>>>>>>       "DisableAppUpdate": true >>>>>>>>>>>     } >>>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Did that 'kind person' provide a policies.json file for you to >>>>>>>>>>    download, or did you create one - on Linux? >>>>>>>>> >>>>>>>>> Someone posted about that file long ago, and the one I created with >>>>>>>>> pico worked for years. >>>>>>>>>> Just wondering how these Windows line endings - if that was the >>>>>>>>>>    problem - got there. >>>>>>>>> They appeared when Firefox chose to update itself against my >>>>>>>>> express >>>>>>>>> wishes.  I suspect that Firefox did it of its own volition -- or >>>>>>>>> simple clumsiness.  Core dump complete. >>>>>>>> >>>>>>>> You /found/ them after the unwanted update. Were they responsible >>>>>>>>    for it? I doubt it: line endings - of either type - are ignored >>>>>>>>    in a json file. >>>>>>> >>>>>>> The windows endings damaged the file such that it no longer >>>>>>> served the >>>>>>> purpose.  Fixing it worked. >>>>>>> >>>>>> >>>>>> Firefox doesn't care about line endings. >>>>>> >>>>>> Just for the sake of it I tested it for you, I created a policies.json >>>>>> which blocks about:config and tested it with both CRLF (windows) >>>>>> and LF >>>>>> (unix) line endings. >>>>>> >>>>>> The result are the same for both, it works: >>>>>> Blocked Page, Firefox can’t connect to the server at about:config >>>>>> >>>>>> ^M is not a corruption, this is how cat -A shows CR, your AI needs an >>>>>> update. >>>>>> >>>>>> CRLF (windows): >>>>>> cat -A policies.json >>>>>> {^M$ >>>>>>    "policies": {^M$ >>>>>>      "BlockAboutConfig": true^M$ >>>>>>    }^M$ >>>>>> }^M$ >>>>>> >>>>>> LF (unix): >>>>>> cat -A policies.json >>>>>> {$ >>>>>>    "policies": {$ >>>>>>      "BlockAboutConfig": true$ >>>>>>    }$ >>>>>> }$ >>>>> >>>>> You tested whether it blocked about:config, but you didn't test whether >>>>> it blocked an update, or if the update altered the json file. >>>> >>>> I tested policies.json, which was reported corrupted, with both >>>> CRLF and LF, any policy will do, we don't need to wait for the >>>> next update. >>>> Policies.json is not included by default, updates will either not >>>> touch it at all or remove it completely, depending on how you >>>> update. >>>> Since we can't see the original file there is no way to tell how >>>> it was changed. >>> >>> Why might an update remove policies.json? I assume that the >>>   firefox updater will read it if it's there but never write to it. >>>   The point of it is that it's user, or organisation, >>>   controlled. >>> >>> I did wonder if updates might /update/ policies.json, for changes >>>   in format say, in the way they update a profile. But I doubt >>>   it. >>> >>> On Debian I have tarballs of Fx nightly and TB beta, in addtion to >>>   packaged versions for regular use. They do not include a >>>   distribution/ directory or a template policies.json. >> No, they're not included with the tarball.  "Some kind person" >> posted the fix at some point in the past (earliest I have is Firefox >> 72, July 7,2020) posted how to do it.  If I want to use a newer >> version I don't update.  I download the tarball, untar it into its >> own subdirectory and run it from within that subdirectory >> (/blabla/firefox/firefox -P &). After running it once I exit and >> copy over (cp -rf *) my previous profile into the newly created >> profile.  Accordingly, I have at least a dozen fully functional >> firefoxes.  TMI, but there it is. >> Worked fine until somebody said that FF148 had some sort of security >> problem, at which point I did an update to 149 rather than building >> a whole new installation.  I think I renamed the policies.json file, >> which would have been the simplest thing. Sorry I can't be more >> certain.  Then I would have renamed it back.  And then I got the >> unwanted surprise of the 150 update.  I turned the problem over to >> Perplexity, which provided the solution.  If anyone is interested I >> can have Perplexity generate a nice pdf file of the entire >> interchange. >> I assume that firefox does some variant of cp -rf * when it updates >> and then does some profile-creation stuff and god knows what else.  >> It must also use some touch-like command, becuase the date of the >> policies.json file was the same as the date on all the other FF 150 >> subdirectories and files. I don't remember looking at the >> FF149/firefox files because I would have had no reason to. And that >> must be when the mischief occurred. >> AH-HAH!  At some point when I first heard about the policies.json >> thing I was unsure about where to put it, so I put one in the >> /firefox subdirectory.  It's still there, and contains the ^M >> characters. They seem to be M- instead of ^M, for what it's >> worth. Its date is the same as all the others -- April 24 19:37. >> cat -A policies.json >> {$ >> M-  "policies": {$ >> M-  M-  "DisableAppUpdate": true$ >> M-  }$ >> }$ >> $ >> > > Why cat -A? Check man cat. > In the output of cat -A "M-" is a tab, "^M" is a CR and "$" is a LF > If you copy those literally into a script it will very likely produce > an error. My manual didn't say that. I tested: hexdump -C tab.txt 00000000 09 0a |..| 00000002 cat -A tab.txt ^I$ So, tab is ^I, as you would expect if carriage return is ^M I am starting to suspect that all this is a wild goose chase.