in ...firefox/distribution did NOT stop FF/linux from updating from 149
to 150 today. WTF?
On 4/25/26 11:37 AM, The Real Bev wrote:
in ...firefox/distribution did NOT stop FF/linux from updating from 149In Linux you go into update manager and see FF is being updated, you right click on it and
to 150 today. WTF?
mark it to not update. You have two choices, don't update this version only, or don't
update at all.
Not sure if you can do that in synaptic but you could look.
Alan K. wrote:
The Real Bev wrote:
in ...firefox/distribution did NOT stop FF/linux from updating from 149In Linux you go into update manager and see FF is being updated, you right click on it and
to 150 today. WTF?
mark it to not update. You have two choices, don't update this version only, or don't
update at all.
That depends on the used Distribution. There is no general "Linux".
Not sure if you can do that in synaptic but you could look.
Yes you can mark a version of a packet as "hold" or "lock".
(Dunno how it's called correctly in English.)
Frank Miller wrote:
Alan K. wrote:
The Real Bev wrote:
in ...firefox/distribution did NOT stop FF/linux from updating from 149 >>>> to 150 today. WTF?In Linux you go into update manager and see FF is being updated, you right click on it and
mark it to not update. You have two choices, don't update this version only, or don't
update at all.
That depends on the used Distribution. There is no general "Linux".
Not sure if you can do that in synaptic but you could look.
Yes you can mark a version of a packet as "hold" or "lock".
(Dunno how it's called correctly in English.)
Synaptic: lock version available
LM software manager; no such option exists
LM Firefox settings (such as 134.0) updates disabled by your organization (Your browser is being managed by your organization)
Personally I prefer such as synaptic over a software manager for my
updating, as it provides me more info. Sometimes the manager is useful, 'tho'.
in ...firefox/distribution did NOT stop FF/linux from updating from 149
to 150 today. WTF?
This is a very odd thread to me. Judging by the mention of synaptic its
a debian based distribution. But Debian ships with ESR which won't be on
150. So it could be some other distribution, or maybe firefox wasn't installed from the repository. But you need to know all these things to
make sense of it.
On 4/25/26 13:03, Richmond wrote:
This is a very odd thread to me. Judging by the mention of synaptic
its a debian based distribution. But Debian ships with ESR which
won't be on 150. So it could be some other distribution, or maybe
firefox wasn't installed from the repository. But you need to know
all these things to make sense of it.
Perhap, but maybe not. Slackware 14.2 (I think;15 wouldn't install)
and the 149 tarball from mozilla. No idea about the debian stuff.
On 4/25/26 13:03, Richmond wrote:
This is a very odd thread to me. Judging by the mention of synaptic its
a debian based distribution. But Debian ships with ESR which won't be on
150. So it could be some other distribution, or maybe firefox wasn't
installed from the repository. But you need to know all these things to
make sense of it.
Perhap, but maybe not. Slackware 14.2 (I think;15 wouldn't install) and
the 149 tarball from mozilla. No idea about the debian stuff.
The Real Bev wrote:
On 4/25/26 13:03, Richmond wrote:
This is a very odd thread to me. Judging by the mention of synaptic its
a debian based distribution. But Debian ships with ESR which won't be on >>> 150. So it could be some other distribution, or maybe firefox wasn't
installed from the repository. But you need to know all these things to
make sense of it.
Perhap, but maybe not. Slackware 14.2 (I think;15 wouldn't install) and
the 149 tarball from mozilla. No idea about the debian stuff.
So after hours of hinting and discussing your topic you come out with
your used distribution Slackware. And you reveal that you installed a
tarball from Mozilla.
Thanks for nothing.
Yeah, I should have mentioned that at the beginning, but do Debian and
Redhat and the others really use something signifcantly different?
My son just makes his entire firefox subdirectory read-only. Even
simpler, but I was satisfied with the policy method -- until FF
appeared to have sabotaged it.
In update manager, when you finally get an update, which means you have
to check every set of updates looking for Firefox, and when it comes due then you have a choice to freeze the update.-a If you fall asleep and
just click 'go' or you have update manager set to do it without
asking... well in bad luck.
This is a very odd thread to me. Judging by the mention of synaptic its
a debian based distribution. But Debian ships with ESR which won't be on
150. So it could be some other distribution, or maybe firefox wasn't installed from the repository. But you need to know all these things to
make sense of it.
The Real Bev <bashley101@gmail.com> writes:
Yeah, I should have mentioned that at the beginning, but do Debian and
Redhat and the others really use something signifcantly different?
My son just makes his entire firefox subdirectory read-only. Even
simpler, but I was satisfied with the policy method -- until FF
appeared to have sabotaged it.
If you are installing from a linux distribution's repository nothing is
going to look at the policy file, the package manager will simply update firefox. As far as I remember Slackware has a package manager too. But
maybe firefox isn't included in it.
OpenSUSE has Firefox ESR in the repo. I am using Firefox Beta so I let firefox update itself when I am ready.
cat -A distribution/policies.json ;reveals ^M corruption
echo '{"policies":{"DisableAppUpdate":true}}' > policies.json ;fixes it about:policies ;confirms "Active"
I did the same for Thunderbird and then marked both files read-only.
On 4/26/2026 4:07 AM, The Real Bev wrote:
You can also use command "chattr" (and lsattr BTW) to make the file immutable, as extra counter-measure.
cat -A distribution/policies.json ;reveals ^M corruption
echo '{"policies":{"DisableAppUpdate":true}}' > policies.json ;fixes it
about:policies ;confirms "Active"
I did the same for Thunderbird and then marked both files read-only.
On 4/26/26 09:51, Mr. Man-wai Chang wrote:
You can also use command "chattr" (and lsattr BTW) to make the file
immutable, as extra counter-measure.
Is chattr any less opaque than chmod?
I finally found a handy table which is much easier than reading the
man page.
... I really do not trust the package manager.
On Sun, 26 Apr 2026 12:17:43 -0700, The Real Bev wrote:
Is chattr any less opaque than chmod?
I would recommend you donrCOt mess about with those esoteric attributes unless you know what yourCOre doing.
On Sun, 26 Apr 2026 12:17:43 -0700, The Real Bev wrote:
On 4/26/26 09:51, Mr. Man-wai Chang wrote:
You can also use command "chattr" (and lsattr BTW) to make the file
immutable, as extra counter-measure.
Is chattr any less opaque than chmod?
I would recommend you donrCOt mess about with those esoteric attributes unless you know what yourCOre doing.
I finally found a handy table which is much easier than reading the
man page.
Fun fact: the chmod(1) command accepts symbolic mode flags, which is
easier than trying to remember octal bit masks.
On Sat, 25 Apr 2026 21:49:17 -0700, The Real Bev wrote:
... I really do not trust the package manager.
Why not? What kind is it? Debian and derivatives use .deb files, Red
Hat and offshoots like SUSE and Mageia use .rpm, the Arch family has
its own one, Gentoo builds from source ...
On 4/26/26 19:06, Lawrence DrCOOliveiro wrote:
On Sat, 25 Apr 2026 21:49:17 -0700, The Real Bev wrote:
... I really do not trust the package manager.
Why not?
I don't like things that sprinkle files all over hell and gone or
install executables in a path automatically.
The deb2tgz etc. commands don't necessarily work.
For instance: hubby installed slack 15 in half an hour or so on his
machine. He spent all day on my identical machine and it never
installed. Twice. No reason. Just weirdness.
On 4/26/26 17:24, Lawrence DrCOOliveiro wrote:
Fun fact: the chmod(1) command accepts symbolic mode flags, which
is easier than trying to remember octal bit masks.
777 and 444 are pretty much sufficient.
On Sun, 26 Apr 2026 21:40:31 -0700, The Real Bev wrote:
On 4/26/26 19:06, Lawrence DrCOOliveiro wrote:
On Sat, 25 Apr 2026 21:49:17 -0700, The Real Bev wrote:
... I really do not trust the package manager.
Why not?
I don't like things that sprinkle files all over hell and gone or
install executables in a path automatically.
ThatrCOs how package managers work. Each package specifies stuff that
goes in /usr/bin and /usr/lib and /usr/share and /etc and so on, and
the package manager keeps track of all that so it knows what to
remove when you tell it to get rid of a package.
Tip: config files (in /etc) are treated specially: In Debian, for
example, rCLapt-get removerCY removes everything except the config files,
you need to use rCLapt-get purgerCY to delete those as well. The reason is
in case you change your mind and put the package back later, the
assumption is you are likely to want to reuse the same config as
before. If not, then you know what to do.
No idea what those are. CanrCOt find any utility by that name on myNo reason you should. There's also an rpm2tgz and probably others. They convert .deb or .rpm files to the .tgz files that slackware needs. And dependencies are a real bitch sometimes. I stop at the second layer.
Debian system.
For instance: hubby installed slack 15 in half an hour or so on his
machine. He spent all day on my identical machine and it never
installed. Twice. No reason. Just weirdness.
With Linux, thererCOs no such thing as rCLno reasonrCY. There are (nearly) always log files you can look at to find out what the errors were.
On Sun, 26 Apr 2026 21:30:33 -0700, The Real Bev wrote:
On 4/26/26 17:24, Lawrence DrCOOliveiro wrote:
Fun fact: the chmod(1) command accepts symbolic mode flags, which
is easier than trying to remember octal bit masks.
777 and 444 are pretty much sufficient.
775 and 755 are probably more the kind you want to use, instead of
either of those. Also 711 and 700 have their uses.
Giving rCLreadrCY access to a directory without corresponding rCLexecuterCY access ... not sure thatrCOs something you want very often ...
BUT the slackware equivalents aren't quite as reliable.
Use the distribution the person who is going to help you uses.
[Hubby] is a real programmer and uses text-only stuff by choice and
I have to help HIM with GUI stuff ...
On 4/26/26 21:55, Lawrence DrCOOliveiro wrote:
Giving rCLreadrCY access to a directory without corresponding rCLexecuterCY >> access ... not sure thatrCOs something you want very often ...
If it's not an executable, why would it make a difference?
On 4/26/26 09:51, Mr. Man-wai Chang wrote:
On 4/26/2026 4:07 AM, The Real Bev wrote:
cat -A distribution/policies.json ;reveals ^M corruption echoYou can also use command "chattr" (and lsattr BTW) to make the file
'{"policies":{"DisableAppUpdate":true}}' > policies.json ;fixes it
about:policies ;confirms "Active" I did the same for Thunderbird and
then marked both files read-only.
immutable, as extra counter-measure.
Is chattr any less opaque than chmod? I finally found a handy table
which is much easier than reading the man page. I KNOW the people who
write man pages just do it for spite :-(
The Real Bev <bashley101@gmail.com> writes:
On 4/26/26 09:51, Mr. Man-wai Chang wrote:
On 4/26/2026 4:07 AM, The Real Bev wrote:
cat -A distribution/policies.json ;reveals ^M corruption echoYou can also use command "chattr" (and lsattr BTW) to make the file
'{"policies":{"DisableAppUpdate":true}}' > policies.json ;fixes it
about:policies ;confirms "Active" I did the same for Thunderbird and
then marked both files read-only.
immutable, as extra counter-measure.
Is chattr any less opaque than chmod? I finally found a handy table
which is much easier than reading the man page. I KNOW the people who
write man pages just do it for spite :-(
There is some irony here. The json file is being used to prevent firefox being updated. And now we look for a way to prevent the json file being updated. Would it not make more sense directly prevent firefox being
updated? Afterall it may be that the expected format of the json file changes,
then it would be necessary to change the file itself as part of an
update.
So, a more sensible solution is to prevent firefox being updated. And
you don't even need to use chmod, you can simple change the owner of
firefox to a user who is not usually running it. This makes it more
secure from attack through the browser itself.
If you had installed firefox from a package manager the owner would be
root I think. Even Windows would put it in "Program Files" where it
cannot be updated except by a system update process.
On Sun, 26 Apr 2026 22:55:04 -0700, The Real Bev wrote:
BUT the slackware equivalents aren't quite as reliable.
Too bad. IrCOve never used Slackware, but I thought it was an old,
reliable distro dating from the earliest days of Linux geekdom. I knew
that major version updates came out slowly, but I thought that was
because old Mr Volkerding was making sure everything absolutely worked properly before he would sign off on it. rCLGood cooking takes timerCY
etc.
From what yourCOre saying, perhaps that impression of mine is a little
... na|>ve ...
Use the distribution the person who is going to help you uses.
Maybe Slackware is a little bit too extreme as an application of this
rule. ;)
I would recommend something more like Linux Mint. I have set up two
different Linux-noob friends with this, with good results so far.
Perhaps, given your Linux experience so far, itrCOs something you could
try installing for yourself.
[Hubby] is a real programmer and uses text-only stuff by choice and
I have to help HIM with GUI stuff ...
Has he heard of GUI-based terminal emulators? Does he know you can
have dozens of these open at once, and copy and paste between them
(and between them and a text editor)? Saves a whole *heap* of typing
that way.
GUI-based command line: the best of both worlds.
On Sun, 26 Apr 2026 22:59:08 -0700, The Real Bev wrote:
On 4/26/26 21:55, Lawrence DrCOOliveiro wrote:
Giving rCLreadrCY access to a directory without corresponding rCLexecuterCY >>> access ... not sure thatrCOs something you want very often ...
If it's not an executable, why would it make a difference?
ldo@theon:hack> mkdir test_dir
ldo@theon:hack> echo 1 >test_dir/file_1
ldo@theon:hack> echo 2 >test_dir/file_2
ldo@theon:hack> ls -l test_dir
total 8
-rw-r--r-- 1 ldo users 2 Apr 27 20:00 file_1
-rw-r--r-- 1 ldo users 2 Apr 27 20:00 file_2
ldo@theon:hack> ls -ld test_dir
drwxr-xr-x 2 ldo users 4096 Apr 27 20:00 test_dir
ldo@theon:hack> chmod -x test_dir
ldo@theon:hack> ls -ld test_dir
drw-r--r-- 2 ldo users 4096 Apr 27 20:00 test_dir
ldo@theon:hack> ls -l test_dir
ls: cannot access 'test_dir/file_1': Permission denied
ls: cannot access 'test_dir/file_2': Permission denied
total 0
-????????? ? ? ? ? ? file_1
-????????? ? ? ? ? ? file_2
ldo@theon:hack> cat test_dir/file_1
cat: test_dir/file_1: Permission denied
ldo@theon:hack> chmod u+x test_dir
ldo@theon:hack> chmod u-r test_dir
ldo@theon:hack> ls -ld test_dir
d-wxr--r-- 2 ldo users 4096 Apr 27 20:00 test_dir
ldo@theon:hack> ls -l test_dir
ls: cannot open directory 'test_dir': Permission denied
ldo@theon:hack> cat test_dir/file_1
1
ldo@theon:hack> cat test_dir/file_2
2
I am root and have been so since 1995 with no problems.
The Real Bev <bashley101@gmail.com> writes:
I am root and have been so since 1995 with no problems.
None that you know about. Perhaps malware updated your json file.
Richmond wrote:
The Real Bev writes:
I am root and have been so since 1995 with no problems.
None that you know about. Perhaps malware updated your json file.
Unlikely that anyone would bother doing such a thing, but I guess it
could happen.-a Those mozillas are sneaky bastards.
The Real Bev wrote:
Richmond wrote:I would consider the action of the update to be a form of Moz 'malware'
The Real Bev writes:
I am root and have been so since 1995 with no problems.
None that you know about. Perhaps malware updated your json file.
Unlikely that anyone would bother doing such a thing, but I guess it
could happen.-a Those mozillas are sneaky bastards.
-- and I do NOT believe that some kind of 'extraneous' non-Moz malware
did such a thing.
I support TRB in her opinion. Moz did 'wrong'/bad/mal-.
The alternative is some kind of 'spontaneous combustion' errr
spontaneous corruption.
So far I seem to be the only person complaining.-a This happens a lot.-a I wonder if this is because I do a LOT of personalization on the software
I use and that reveals problems.-a I know people who don't even know that there are options, much less .css tweaks.
So far I seem to be the only person complaining.-a This happens a lot.-a I wonder if this is because I do a LOT of personalization on the software
I use and that reveals problems.-a I know people who don't even know that there are options, much less .css tweaks.
The Real Bev wrote:
So far I seem to be the only person complaining.-a This happens a lot.-a I >> wonder if this is because I do a LOT of personalization on the software
I use and that reveals problems.-a I know people who don't even know that >> there are options, much less .css tweaks.
Well; you hammer and chisel people live in a different world; so you
have to expect that things are going to be different for you :-)
cat -A distribution/policies.json ;reveals ^M corruption
echo '{"policies":{"DisableAppUpdate":true}}' > policies.json ;fixes it about:policies ;confirms "Active"
I did the same for Thunderbird and then marked both files read-only.
The Real Bev wrote:Except the json spec specifically states that no whitespace characters
cat -A distribution/policies.json-a-a-a-a-a-a-a-a ;reveals ^M corruption
echo '{"policies":{"DisableAppUpdate":true}}' > policies.json ;fixes it
about:policies-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a ;confirms "Active"
I did the same for Thunderbird and then marked both files read-only.
I think it's those carriage return and line feed characters thing. Linux *TEXT* file format is a bit different from WinDOS.
Mr. Man-wai Chang wrote:
The Real Bev wrote:Except the json spec specifically states that no whitespace characters
cat -A distribution/policies.json-a-a-a-a-a-a-a-a ;reveals ^M corruption >>> echo '{"policies":{"DisableAppUpdate":true}}' > policies.json ;fixes itI think it's those carriage return and line feed characters
about:policies-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a ;confirms "Active" >>>
I did the same for Thunderbird and then marked both files read-only.
thing. Linux *TEXT* file format is a bit different from WinDOS.
are significant (outside of quote marks).
Andy Burns writes:
Except the json spec specifically states that no whitespace characters
are significant (outside of quote marks).
If anyone had the patience they could test this theory (that an update
to firefox caused LF to be replaced with CRLF, by creating a new linux
user, downloading the previous version of firefox, unpacking it locally, creating a json file, creating a backup of it, then allowing firefox to update itself, then comparing the json files. Then, if necessary, report
the results on Bugzilla.
Note that linux line terminator is LF not CR (as someone said upthread).
Mr. Man-wai Chang wrote:
The Real Bev wrote:Except the json spec specifically states that no whitespace characters
cat -A distribution/policies.json-a-a-a-a-a-a-a-a ;reveals ^M corruption >>> echo '{"policies":{"DisableAppUpdate":true}}' > policies.json ;fixes it
about:policies-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a ;confirms "Active" >>>
I did the same for Thunderbird and then marked both files read-only.
I think it's those carriage return and line feed characters thing. Linux
*TEXT* file format is a bit different from WinDOS.
are significant (outside of quote marks).
On 4/29/2026 5:59 PM, Andy Burns wrote:
Mr. Man-wai Chang wrote:
The Real Bev wrote:Except the json spec specifically states that no whitespace characters
cat -A distribution/policies.json-a-a-a-a-a-a-a-a ;reveals ^M corruption >>>> echo '{"policies":{"DisableAppUpdate":true}}' > policies.json ;fixes it >>>> about:policies-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a ;confirms "Active" >>>>
I did the same for Thunderbird and then marked both files read-only.
I think it's those carriage return and line feed characters thing. Linux >>> *TEXT* file format is a bit different from WinDOS.
are significant (outside of quote marks).
I suspect just a ";" after reach parameter would help?
{"policies":{"DisableAppUpdate":true;}}
Sorry! Not semi-color, but "\n"??
the entire json file could be on a single line with no \n at all
or each element could be separated by spaces or tabs
or with extra \n before and after every squiggly bracket and colon
or without any extra whitespace
it should make no difference at all, the content should be treated the same. have a play with 'jq' as suggested, see how unreadable you can make a
json file look, yet still be functional :-)
Mr. Man-wai Chang wrote:
The Real Bev wrote:Except the json spec specifically states that no whitespace characters
cat -A distribution/policies.json-a-a-a-a-a-a-a-a ;reveals ^M corruption >>> echo '{"policies":{"DisableAppUpdate":true}}' > policies.json ;fixes it
about:policies-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a ;confirms "Active" >>>
I did the same for Thunderbird and then marked both files read-only.
I think it's those carriage return and line feed characters thing. Linux
*TEXT* file format is a bit different from WinDOS.
are significant (outside of quote marks).
BUT linux (or maybe just MY version of it) is snotty about(and some other characters) in filenames and god knows
whitespace
what else andinsists that they be backslashed: (john\ jones). A
monumental nuisance.
On Wed, 29 Apr 2026 20:38:28 -0700, The Real Bev wrote:
BUT linux (or maybe just MY version of it) is snotty about(and some other characters) in filenames and god knows
whitespace
what else andinsists that they be backslashed: (john\ jones). A
monumental nuisance.
ldo@theon:~> touch 'john jones.txt'
ldo@theon:~> ls -l j*
-rw-r--r-- 1 ldo users 0 Apr 30 17:50 'john jones.txt'
touch 'john jones.txt'
-rw-r--r-- 1 root 0 Apr 29 23:31 john\ jones.txt
Takes all kinds.
On 4/29/26 22:51, Lawrence DrCOOliveiro wrote:
On Wed, 29 Apr 2026 20:38:28 -0700, The Real Bev wrote:
BUT linux (or maybe just MY version of it) is snotty about(and some other characters) in filenames and god knows
whitespace
what else andinsists that they be backslashed: (john\ jones). A
monumental nuisance.ldo@theon:~> touch 'john jones.txt'
ldo@theon:~> ls -l j*
-rw-r--r-- 1 ldo users 0 Apr 30 17:50 'john jones.txt'
touch john jones.txt
-rw-r--r-- 1 root 0 Apr 29 23:29 john
-rw-r--r-- 1 root 0 Apr 29 23:29 jones.txt
touch 'john jones.txt'
-rw-r--r-- 1 root 0 Apr 29 23:31 john\ jones.txt
Takes all kinds.
I believe this is called obfuscation, as for example, Javascript and
maybe C! EfOe
You aren't going to have an end-of-line in the middle of a file name,
are you?
On 4/26/26 19:06, Lawrence DrCOOliveiro wrote:
On Sat, 25 Apr 2026 21:49:17 -0700, The Real Bev wrote:
... I really do not trust the package manager.
Why not? What kind is it? Debian and derivatives use .deb files, Red
Hat and offshoots like SUSE and Mageia use .rpm, the Arch family has
its own one, Gentoo builds from source ...
I don't like things that sprinkle files all over hell and gone or
install executables in a path automatically.-a When I want to delete something I want to delete ALL of it and know that it's gone.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 65 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 06:09:58 |
| Calls: | 862 |
| Files: | 1,311 |
| D/L today: |
921 files (14,318M bytes) |
| Messages: | 264,697 |