[PLUG] Firefox Quantum 60.2.1.esr lost saved passwords

Discussion:

Keith Lofstrom

2018-10-01 01:53:06 UTC

Sometime in the last two days, automatic updates on my
older 32 bit laptops "upgraded" to Firefox Quantum
60.2.1.esr, and my saved logins stopped working. I have
backups, and I can restore a previous version of Firefox
and my old .mozilla configuration files, then turn off
updates, but perhaps there is a way to make this
"upgrade" work.

A more general question is whether Mozilla has some
marvelous way of testing the hell out of their new versions
of Firefox, or whether they are merely replacing old known
bugs with new unknown bugs, along with annoying interface
changes. If so, it is probably time to get off their
merry-go-round and find a safer, stable web browser.

Keith

--
Keith Lofstrom ***@keithl.com

John Jason Jordan

2018-10-01 05:46:31 UTC

Permalink

On Sun, 30 Sep 2018 18:53:06 -0700

Post by Keith Lofstrom
A more general question is whether Mozilla has some
marvelous way of testing the hell out of their new versions
of Firefox, or whether they are merely replacing old known
bugs with new unknown bugs, along with annoying interface
changes. If so, it is probably time to get off their
merry-go-round and find a safer, stable web browser.

I finally decided to bite the bullet and move from Firefox to to Chrome
(Chromium, actually). I knew it would take a while to get used to it
and that I would go through weeks of teeth-gnashing, but now I'm pretty
much over the pain.

Keith Lofstrom

2018-10-02 05:04:27 UTC

Permalink

Post by Keith Lofstrom
Sometime in the last two days, automatic updates on my
older 32 bit laptops "upgraded" to Firefox Quantum
60.2.1.esr, and my saved logins stopped working. I have
backups, and I can restore a previous version of Firefox
and my old .mozilla configuration files, then turn off
updates, but perhaps there is a way to make this
"upgrade" work.

I'm running an old 32 bit distro on the laptops, which
will get upgraded to a recent 64 bit distro Real Soon Now.
Then I will upgrade myself to Chromium as John suggested.

Meanwhile, I restored 60.2.0.esr firefox from a September
25 backup to a test laptop, and the .mozilla user files.
It's a bit annoying that I must do both. DELETING user
files with an update? That's barbaric. Nyet Kulturni.

I added "firefox" to the /etc/sysconfig/yum-autoupdate
exclusions list. We'll see how that goes.

I would be hosed without backups. I thought I needed
backups for security and for my bonehead mistakes, not for
protection from mozilla bonehead programmer mistakes.

Ah well. Linus Torvalds recently promised to be nicer to
Linux developers in the future. If that works out, I'll
try to be nicer as well. If not, I still have backups.
Sit here, behind this rear tire ...

Keith

--
Keith Lofstrom ***@keithl.com

Russell Senior

2018-10-02 05:14:42 UTC

Permalink

Did you report the bug?

Post by Keith Lofstrom

I'm running an old 32 bit distro on the laptops, which
will get upgraded to a recent 64 bit distro Real Soon Now.
Then I will upgrade myself to Chromium as John suggested.
Meanwhile, I restored 60.2.0.esr firefox from a September
25 backup to a test laptop, and the .mozilla user files.
It's a bit annoying that I must do both. DELETING user
files with an update? That's barbaric. Nyet Kulturni.
I added "firefox" to the /etc/sysconfig/yum-autoupdate
exclusions list. We'll see how that goes.
I would be hosed without backups. I thought I needed
backups for security and for my bonehead mistakes, not for
protection from mozilla bonehead programmer mistakes.
Ah well. Linus Torvalds recently promised to be nicer to
Linux developers in the future. If that works out, I'll
try to be nicer as well. If not, I still have backups.
Sit here, behind this rear tire ...
Keith
--
_______________________________________________
PLUG mailing list
http://lists.pdxlinux.org/mailman/listinfo/plug

Keith Lofstrom

2018-10-02 19:37:03 UTC

Permalink

Post by Keith Lofstrom

I'm running an old 32 bit distro on the laptops, which
will get upgraded to a recent 64 bit distro Real Soon Now.
Then I will upgrade myself to Chromium as John suggested.
Did you report the bug?

Not yet - I need to ponder my use-case a bit, and think
about how it differs from their (minimal) likely testing.

My WAG is that this happened because we had browser windows
open when updates are scheduled, and their user-neglecting
code treats unlocked login/password files as "unencrypted".

However, the fact that they would even conceive of deleting
/any/ user-generated file without warning or permission
suggests that their design goals are sociopathic and
arrogant. I'll send them a bug report when I develop an
easy-to-reproduce use case, but I expect it to be rejected.
It won't be the first time they've done that to my reports.

I hope the Chromium development team is more humane. If
there is less code, there are fewer insecure interactions.
Code evaluated by two different groups (Google developers
and outsider repackagers) may be better tested. Many eyes
make all bugs shallow; two sets of eyes makes bugs ever so
slightly less deep.

-----

As an aside, my original reason for becoming involved with
"open-source" (long before Chris Peterson named it) was
that even a non-programmer like me could understand it and
find bugs. I found the Y2K error in BSD, and my suggested
improvement was coded by Real Programmer(tm). When most of
us become mere "code consumers", we eat whatever the "cooks
in the fast food code kitchen" churn out. Some is great,
some is absolutely awful, but the quantity of code is huge,
and the combinatorial number of possible interactions is
literally astronomical, more than the baryon count for the
universe. That makes secure, high-reliability software
impossible, even with "perfect" programmers and methods.

Web browsers are vulnerable to their innate flaws, but
also to the flaws and exploits in every scrap of active
web content on the internet. Perhaps we need a two-stage
process; our personal computers use plain-vanilla html
browsers and external proxies that process all the varied
crap out there into maximally simple html, with very few
local extensions. That simplifies code on our machines,
though admittedly it helps big brother snoop the external
proxies. I'd rather not have video codecs on the same
machine accessing the same memory as my password files.

----

I wonder how many of you read down this far? In the
twitter age, most can't read a page of plain English,
much less software code.

Keith

--
Keith Lofstrom ***@keithl.com

Russell Senior

2018-10-02 20:37:12 UTC

Permalink

In my brief investigation, it might result from the location of profiles
moving from one version to another. I can say that I, on firefox 62.0 from
Ubuntu, have not seen this behavior. Since distributions often tweak
builds, it's not beyond the realm of possibility that your distribution's
packagers are at fault here.

Post by Keith Lofstrom

I'm running an old 32 bit distro on the laptops, which
will get upgraded to a recent 64 bit distro Real Soon Now.
Then I will upgrade myself to Chromium as John suggested.
Did you report the bug?

Not yet - I need to ponder my use-case a bit, and think
about how it differs from their (minimal) likely testing.
My WAG is that this happened because we had browser windows
open when updates are scheduled, and their user-neglecting
code treats unlocked login/password files as "unencrypted".
However, the fact that they would even conceive of deleting
/any/ user-generated file without warning or permission
suggests that their design goals are sociopathic and
arrogant. I'll send them a bug report when I develop an
easy-to-reproduce use case, but I expect it to be rejected.
It won't be the first time they've done that to my reports.
I hope the Chromium development team is more humane. If
there is less code, there are fewer insecure interactions.
Code evaluated by two different groups (Google developers
and outsider repackagers) may be better tested. Many eyes
make all bugs shallow; two sets of eyes makes bugs ever so
slightly less deep.
-----
As an aside, my original reason for becoming involved with
"open-source" (long before Chris Peterson named it) was
that even a non-programmer like me could understand it and
find bugs. I found the Y2K error in BSD, and my suggested
improvement was coded by Real Programmer(tm). When most of
us become mere "code consumers", we eat whatever the "cooks
in the fast food code kitchen" churn out. Some is great,
some is absolutely awful, but the quantity of code is huge,
and the combinatorial number of possible interactions is
literally astronomical, more than the baryon count for the
universe. That makes secure, high-reliability software
impossible, even with "perfect" programmers and methods.
Web browsers are vulnerable to their innate flaws, but
also to the flaws and exploits in every scrap of active
web content on the internet. Perhaps we need a two-stage
process; our personal computers use plain-vanilla html
browsers and external proxies that process all the varied
crap out there into maximally simple html, with very few
local extensions. That simplifies code on our machines,
though admittedly it helps big brother snoop the external
proxies. I'd rather not have video codecs on the same
machine accessing the same memory as my password files.
----
I wonder how many of you read down this far? In the
twitter age, most can't read a page of plain English,
much less software code.
Keith
--

Tomas Kuchta

2018-10-03 04:03:40 UTC

Permalink

FWIWI, I have seen no Firefox issues whatsoever on both openSuse and 16/18
LTS Ubuntu branches.

Release notes would most likely mention settings location change and how to
proceed with the upgrade. I'd guess.

-T

Post by Russell Senior
In my brief investigation, it might result from the location of profiles
moving from one version to another. I can say that I, on firefox 62.0 from
Ubuntu, have not seen this behavior. Since distributions often tweak
builds, it's not beyond the realm of possibility that your distribution's
packagers are at fault here.

Post by Keith Lofstrom

I'm running an old 32 bit distro on the laptops, which
will get upgraded to a recent 64 bit distro Real Soon Now.
Then I will upgrade myself to Chromium as John suggested.
Did you report the bug?

Not yet - I need to ponder my use-case a bit, and think
about how it differs from their (minimal) likely testing.
My WAG is that this happened because we had browser windows
open when updates are scheduled, and their user-neglecting
code treats unlocked login/password files as "unencrypted".
However, the fact that they would even conceive of deleting
/any/ user-generated file without warning or permission
suggests that their design goals are sociopathic and
arrogant. I'll send them a bug report when I develop an
easy-to-reproduce use case, but I expect it to be rejected.
It won't be the first time they've done that to my reports.
I hope the Chromium development team is more humane. If
there is less code, there are fewer insecure interactions.
Code evaluated by two different groups (Google developers
and outsider repackagers) may be better tested. Many eyes
make all bugs shallow; two sets of eyes makes bugs ever so
slightly less deep.
-----
As an aside, my original reason for becoming involved with
"open-source" (long before Chris Peterson named it) was
that even a non-programmer like me could understand it and
find bugs. I found the Y2K error in BSD, and my suggested
improvement was coded by Real Programmer(tm). When most of
us become mere "code consumers", we eat whatever the "cooks
in the fast food code kitchen" churn out. Some is great,
some is absolutely awful, but the quantity of code is huge,
and the combinatorial number of possible interactions is
literally astronomical, more than the baryon count for the
universe. That makes secure, high-reliability software
impossible, even with "perfect" programmers and methods.
Web browsers are vulnerable to their innate flaws, but
also to the flaws and exploits in every scrap of active
web content on the internet. Perhaps we need a two-stage
process; our personal computers use plain-vanilla html
browsers and external proxies that process all the varied
crap out there into maximally simple html, with very few
local extensions. That simplifies code on our machines,
though admittedly it helps big brother snoop the external
proxies. I'd rather not have video codecs on the same
machine accessing the same memory as my password files.
----
I wonder how many of you read down this far? In the
twitter age, most can't read a page of plain English,
much less software code.
Keith
--

_______________________________________________
PLUG mailing list
http://lists.pdxlinux.org/mailman/listinfo/plug

Ben Koenig

2018-10-04 13:15:11 UTC

Permalink

Deleting user data without warning is bad. There are a number of decisions
in firefox that concern me as well, and if there really is a situation in
which it automagically overwrites user data, then that must be fixed.

The idea that it works "fine for me" but not everyone is not applicable
here. While a feature may be less popular, that does not excuse the
unexpected deletion of user data. It doesn't matter if a feature was
changed or updated. Deleting data on a user's computer WITHOUT WARNING is
unacceptable and that is all there is to it.

If you can reproduce the behavior then fixing it in the code is the only
acceptable answer.
Or maybe those of us on the use-case fringe deserve the discrimination
being dished out by the Twitter birds.

Post by Tomas Kuchta
FWIWI, I have seen no Firefox issues whatsoever on both openSuse and 16/18
LTS Ubuntu branches.
Release notes would most likely mention settings location change and how to
proceed with the upgrade. I'd guess.
-T

Post by Russell Senior
In my brief investigation, it might result from the location of profiles
moving from one version to another. I can say that I, on firefox 62.0

from

Post by Russell Senior
Ubuntu, have not seen this behavior. Since distributions often tweak
builds, it's not beyond the realm of possibility that your distribution's
packagers are at fault here.

Post by Keith Lofstrom

I'm running an old 32 bit distro on the laptops, which
will get upgraded to a recent 64 bit distro Real Soon Now.
Then I will upgrade myself to Chromium as John suggested.
Did you report the bug?

Not yet - I need to ponder my use-case a bit, and think
about how it differs from their (minimal) likely testing.
My WAG is that this happened because we had browser windows
open when updates are scheduled, and their user-neglecting
code treats unlocked login/password files as "unencrypted".
However, the fact that they would even conceive of deleting
/any/ user-generated file without warning or permission
suggests that their design goals are sociopathic and
arrogant. I'll send them a bug report when I develop an
easy-to-reproduce use case, but I expect it to be rejected.
It won't be the first time they've done that to my reports.
I hope the Chromium development team is more humane. If
there is less code, there are fewer insecure interactions.
Code evaluated by two different groups (Google developers
and outsider repackagers) may be better tested. Many eyes
make all bugs shallow; two sets of eyes makes bugs ever so
slightly less deep.
-----
As an aside, my original reason for becoming involved with
"open-source" (long before Chris Peterson named it) was
that even a non-programmer like me could understand it and
find bugs. I found the Y2K error in BSD, and my suggested
improvement was coded by Real Programmer(tm). When most of
us become mere "code consumers", we eat whatever the "cooks
in the fast food code kitchen" churn out. Some is great,
some is absolutely awful, but the quantity of code is huge,
and the combinatorial number of possible interactions is
literally astronomical, more than the baryon count for the
universe. That makes secure, high-reliability software
impossible, even with "perfect" programmers and methods.
Web browsers are vulnerable to their innate flaws, but
also to the flaws and exploits in every scrap of active
web content on the internet. Perhaps we need a two-stage
process; our personal computers use plain-vanilla html
browsers and external proxies that process all the varied
crap out there into maximally simple html, with very few
local extensions. That simplifies code on our machines,
though admittedly it helps big brother snoop the external
proxies. I'd rather not have video codecs on the same
machine accessing the same memory as my password files.
----
I wonder how many of you read down this far? In the
twitter age, most can't read a page of plain English,
much less software code.
Keith
--

_______________________________________________
PLUG mailing list
http://lists.pdxlinux.org/mailman/listinfo/plug

Russell Senior

2018-10-04 15:16:30 UTC

Permalink

This sounds suspiciously like it might be related:

https://www.scientificlinux.org/category/sl-errata/slsa-20182834-1/

Post by Ben Koenig
Deleting user data without warning is bad. There are a number of decisions
in firefox that concern me as well, and if there really is a situation in
which it automagically overwrites user data, then that must be fixed.
The idea that it works "fine for me" but not everyone is not applicable
here. While a feature may be less popular, that does not excuse the
unexpected deletion of user data. It doesn't matter if a feature was
changed or updated. Deleting data on a user's computer WITHOUT WARNING is
unacceptable and that is all there is to it.
If you can reproduce the behavior then fixing it in the code is the only
acceptable answer.
Or maybe those of us on the use-case fringe deserve the discrimination
being dished out by the Twitter birds.

Post by Tomas Kuchta
FWIWI, I have seen no Firefox issues whatsoever on both openSuse and

16/18

Post by Tomas Kuchta
LTS Ubuntu branches.
Release notes would most likely mention settings location change and how

Post by Tomas Kuchta
proceed with the upgrade. I'd guess.
-T

Post by Russell Senior
In my brief investigation, it might result from the location of

profiles

Post by Tomas Kuchta

Post by Russell Senior
moving from one version to another. I can say that I, on firefox 62.0

from

Post by Russell Senior
Ubuntu, have not seen this behavior. Since distributions often tweak
builds, it's not beyond the realm of possibility that your

distribution's

Post by Tomas Kuchta

Post by Russell Senior
packagers are at fault here.

Post by Keith Lofstrom

I'm running an old 32 bit distro on the laptops, which
will get upgraded to a recent 64 bit distro Real Soon Now.
Then I will upgrade myself to Chromium as John suggested.
Did you report the bug?

Not yet - I need to ponder my use-case a bit, and think
about how it differs from their (minimal) likely testing.
My WAG is that this happened because we had browser windows
open when updates are scheduled, and their user-neglecting
code treats unlocked login/password files as "unencrypted".
However, the fact that they would even conceive of deleting
/any/ user-generated file without warning or permission
suggests that their design goals are sociopathic and
arrogant. I'll send them a bug report when I develop an
easy-to-reproduce use case, but I expect it to be rejected.
It won't be the first time they've done that to my reports.
I hope the Chromium development team is more humane. If
there is less code, there are fewer insecure interactions.
Code evaluated by two different groups (Google developers
and outsider repackagers) may be better tested. Many eyes
make all bugs shallow; two sets of eyes makes bugs ever so
slightly less deep.
-----
As an aside, my original reason for becoming involved with
"open-source" (long before Chris Peterson named it) was
that even a non-programmer like me could understand it and
find bugs. I found the Y2K error in BSD, and my suggested
improvement was coded by Real Programmer(tm). When most of
us become mere "code consumers", we eat whatever the "cooks
in the fast food code kitchen" churn out. Some is great,
some is absolutely awful, but the quantity of code is huge,
and the combinatorial number of possible interactions is
literally astronomical, more than the baryon count for the
universe. That makes secure, high-reliability software
impossible, even with "perfect" programmers and methods.
Web browsers are vulnerable to their innate flaws, but
also to the flaws and exploits in every scrap of active
web content on the internet. Perhaps we need a two-stage
process; our personal computers use plain-vanilla html
browsers and external proxies that process all the varied
crap out there into maximally simple html, with very few
local extensions. That simplifies code on our machines,
though admittedly it helps big brother snoop the external
proxies. I'd rather not have video codecs on the same
machine accessing the same memory as my password files.
----
I wonder how many of you read down this far? In the
twitter age, most can't read a page of plain English,
much less software code.
Keith
--

_______________________________________________
PLUG mailing list
http://lists.pdxlinux.org/mailman/listinfo/plug