Closed
Bug 369969
Opened 18 years ago
Closed 17 years ago
All passwords are not available to downlevel versions of 2.0/1.5 after upgrade
Categories
(Toolkit :: Password Manager, defect)
Toolkit
Password Manager
Tracking
()
VERIFIED
WONTFIX
People
(Reporter: zeniko, Unassigned)
References
Details
(Keywords: relnote)
Consequence from bug 360493: when using a Firefox 2.0.0.2/1.5.0.10 profile with an older Firefox version (e.g. due to roaming profiles), all stored passwords are lost.
This might be unavoidable - and reverting to older version probably never was officially supported in the first place - but introducing such a change on a stable branch might at least be worth a warning in the Release Notes.
Comment 1•18 years ago
|
||
If it's not avoidable, is there a way to detect the new format and then at least leave a backup of the old passwords file?
Severity: normal → critical
Keywords: dataloss
Comment 2•18 years ago
|
||
The data is not lost, it is still available in the new version.
Short of introducing code to keep data in the old format and the new in sync (which would get nightmarish when switching frequently) this was unavoidable without leaving sensitive data around in the profile.
We should relnote this, absolutely, but this isn't datalosos since the data is just in a new format that is not backwards-compatible.
Severity: critical → major
Keywords: dataloss
Summary: All passwords are lost when downgrading from Firefox 2.0.0.2/1.5.0.10(pre) → All passwords are not available to downlevel versions of 2.0/1.5 after upgrade
Comment 4•18 years ago
|
||
(In reply to comment #2)
> The data is not lost, it is still available in the new version.
>
> Short of introducing code to keep data in the old format and the new in sync
> (which would get nightmarish when switching frequently) this was unavoidable
> without leaving sensitive data around in the profile.
>
> We should relnote this, absolutely, but this isn't datalosos since the data is
> just in a new format that is not backwards-compatible.
>
Well the data is not forwards compatbale either. Upgrading form firefox 2.0.0.1 to 2.0.0.2 results in there bing no saved password in Firefox 3.0a3pre.
It is not that the files are not kept in sync. The upgrade creates a new file with a different name in the new format and then deletes the old file.
This IS dataloss unless or until the trunk is upgraded to have the new signons.txt data format.
Comment 5•18 years ago
|
||
(In reply to comment #4)
> This IS dataloss unless or until the trunk is upgraded to have the new
> signons.txt data format.
Data loss means that the data is lost. The fact that the data is there, but not read by Minefield, does not constitute data loss. Your problem will be fixed when the patch lands on the trunk (notice that bug 360493 isn't FIXED yet). The trunk comments in that bug refer to the first patch.
Comment 6•18 years ago
|
||
I had a file called signons.txt. It contained data that was being used by Minefield. The file was deleted by the Firefox release upgrade. The data that was contained in that file has been lost. It took me hours to get back to where I could use my default browser in a productive manner. Sounds like dataloss to me.
Comment 7•18 years ago
|
||
The data in the file was not lost. The data was moved to another file that Minefield doesn't know about.
(In reply to comment #7)
> The data in the file was not lost. The data was moved to another file that
> Minefield doesn't know about.
>
here is a scenario
1) user upgrades
2) new version doesn't fill in some passwords (bug 371525) or encounters some other bug
3) user reverts to the previous version
4) now all the passwords are gone
5) Gavin Sharp amd Mike Connor say, everything is fine
I wonder if this helps firefox/mozilla or not.
Mike Connor,
The old signons.txt should be backed up/not deleted, combined with the explanation in the release notes this would make going back relatively painless.
As a more general solution, there are serialization formats, like xml, where new fields in a record do not prevent older versions from reading the file.
Comment 10•18 years ago
|
||
I didn't say "everything is fine". I said "this bug doesn't meet the criteria for having the dataloss keyword".
Comment 11•18 years ago
|
||
(In reply to comment #9)
> (In reply to comment #7)
> > The data in the file was not lost. The data was moved to another file that
> > Minefield doesn't know about.
> >
>
> here is a scenario
>
> 1) user upgrades
> 2) new version doesn't fill in some passwords (bug 371525) or encounters some
> other bug
> 3) user reverts to the previous version
> 4) now all the passwords are gone
> 5) Gavin Sharp amd Mike Connor say, everything is fine
Ultimately, 2.0.0.1 has known and public exploits, so we don't officially support downlevel versions. Inconvenience is a lesser evil than insecurity.
> The old signons.txt should be backed up/not deleted, combined with the
> explanation in the release notes this would make going back relatively
> painless.
That was the plan, initially, but the problem becomes that without writing a ton of code to maintain both files in sync, you run the risk of storing data that users can't selectively clear. i.e. if I want to kill my banking site password from pwdmgr, that data is still in the old format and thus easily accessible if someone gets local access. Since most people don't read the release notes, and even fewer will ever go to a downlevel version, this was deemed to be the best plan.
We're going to face a similar issue with history and bookmarks in the Firefox 3 timeframe, fwiw.
> As a more general solution, there are serialization formats, like xml, where
> new fields in a record do not prevent older versions from reading the file
Using XML-based formats will be ok for reading, but for writing you will end up with serious issues where older versions won't know what to write for added information. XML is not a silver bullet. Sqlite, done right, can be much better, since you simply don't update fields you don't know about. Still requires great care though.
Comment 12•18 years ago
|
||
> That was the plan, initially, but the problem becomes that without writing a
> ton of code to maintain both files in sync, you run the risk of storing data
> that users can't selectively clear. i.e. if I want to kill my banking site
> password from pwdmgr, that data is still in the old format and thus easily
> accessible if someone gets local access.
if some one gets local access you are f'ed in so many ways that an old password file is the least of your problems. What if they install a rootkit keylogger, are you going to worry about this? This local access thing sounds like an excuse. Then why don't you provide a little utility that transforms the password file back to the old version.
> Since most people don't read the
> release notes, and even fewer will ever go to a downlevel version, this was
> deemed to be the best plan.
going back when encountering a regression bug is the most obvious and trivial solution, people do it all the time.
>
> We're going to face a similar issue with history and bookmarks in the Firefox > 3 timeframe, fwiw.
>
loss of profile compatibility accross major versions is acceptable, but here we not even dealing with minor versions, it's a 0.0.0.1 bugfix release
> > As a more general solution, there are serialization formats, like xml, where
> > new fields in a record do not prevent older versions from reading the file
>
> Using XML-based formats will be ok for reading, but for writing you will end
> up with serious issues where older versions won't know what to write for added
> information. XML is not a silver bullet.
I don't know about silver bullets, but it would solve this problem. And a database is overkill for this, will only introduce new bugs, new corruption issues, with no benefits, a plain text xml file is much better.
<record oldfield="val1" newfield="val2" />
old versions will not write the "newfield" but new version will at which point the old version will ignore it. So what's the problem?
Comment 13•18 years ago
|
||
(In reply to comment #7)
> The data in the file was not lost. The data was moved to another file that
> Minefield doesn't know about.
>
OK so this IS dataloss. It may be, that the data is still stored in a enrypted file. But if the new software is not able to read the old format so the user is not able to access the data, this IS datsloss. No more no less!
Comment 14•18 years ago
|
||
Regarding the data loss:
I've heard this quote attributed to Davy Crockett and Daniel Boone (both
famous American frontiersmen who went on long hunts and explorations in deep
wilderness) and I don't know who really said it . . . maybe they both did, when
someone asked whether they'd ever been lost:
“I’ve never been lost, but I have been a might bewildered for a week or
two”
I wouldn't worry about what to call it, because it's going to get fixed either
way.
Comment 15•17 years ago
|
||
I think mconnor and gavin have sufficiently explained things in previous comments: this isn't a dataloss bug by conventional definition, and it's impractical to retain backwards compatibility with previous versions. 2.0.0.2 has been out for some time now, and we've pushed the major update to 1.5 users, and this doesn't seem to have become a problem.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Comment 16•17 years ago
|
||
The tip of all branches currently works with the new format, downrev versions, despite some people being willing to use versions with public exploits, are not supported, nor should we expend effort on supporting them.
Status: RESOLVED → VERIFIED
Assignee | ||
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•