Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Chrome's problem when a password is mis-encrypted #20

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

mramendi
Copy link

Hello,

Chrome, at least on Linux, has a frequent problem. A password gets mis-encrypted, this happens. But instead of just losing that one password, Google Chrome fails to display passwords in its settings and fails to push them into the Google account when syncing. As a result, the passwords are still there, but as soon as one loses the repo for some reason (like a reinstall or even enabling a KDE/Gnome wallet) - poof, they are gone!

I was at a loss for a solution, but I found this utility which was nearly ready for it. "Nearly" beacuse it crashed with an exception upon encountering a mis-encrypted password.

My changes:

  • By default, the exception is now handled, outputting the exception text instead of the password. So one can now get a password dump and all the valid passwords are still there.
  • Added rewrite_passwords(), which creates a new copy of "Login Data" in the current directory - with the faulty lines excised. To avoid analysing the entire database, I instead do an SQL dump and execute, while deciphering passwords on the fly from the SQL dump; this is bad, but trying to re-create every table without a dump would be worse.
  • Updated the readme for my changes, for the modules that I had to install using pip to make the utility work, and for the need to stop Chrome before playing with its database

Note that, when using rewrite_passwords, the user still has to copy "Login Data" into the Chrome config directory manually. I did this to ensure that one knows what one is doing. The procedure was only tested once, and so a backup is essential if it fails. (If the routine finds an existing "Login Data" file in the current directory, it stops to avoid overwriting it).

For avoidance of doubt:

  • My contribution is under the same license as the original, GPL3, as expected
  • While the PR comes from my work github account, it is a personal contribution; Red Hat has an explicit policy allowing such contributions

I would appreciate a merge because I'd like to post links to this workaround on forums where people complain about this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant