plaintext password after import from Git repo
(1) By anonymous on 2023-09-18 20:00:34 [link] [source]
| Is this by design? When I do "git fast-export --all | fossil import --git new-repo.fossil" from https://fossil-scm.org/home/doc/trunk/www/inout.wiki, the automatically generated password is stored in the user table as plaintext. |
|---|
Shouldn't it be sha1 or is the documentation at https://fossil-scm.org/home/doc/trunk/www/password.wiki missing some detail about import and local repos?
(2) By Preben Guldberg (preben) on 2023-09-19 18:48:01 in reply to 1 [link] [source]
As far as I can tell, the same happens for fossil init, so it is more that
the random initial password is stored in clear text.
I don't know if this is deliberate, but as it is random it at least is not a password that a user might be using in multiple contexts (which the sha1 hash helps protect from prying eyes).
Still, it could be gleaned by someone with readonly access to the repository file itself, who might be able to then log in if the owner is serving via HTTP(S).
(3) By anonymous on 2023-09-19 19:51:18 in reply to 2 [link] [source]
Ah ok, that sounds reasonable. It seems I accidentally used "markdown" format, which broke the layout of my question. Should be "git fast-export --all | fossil import --git new-repo.fossil"
(4) By anonymous on 2023-09-19 19:52:53 in reply to 2 [source]
Is there some general advice to replace / hash them or protect the files?
(5) By Preben Guldberg (preben) on 2023-09-19 21:55:35 in reply to 4 [link] [source]
If you set a password (even the same one), it should be stored using sha1.
(6) By Preben Guldberg (preben) on 2023-09-19 22:12:20 in reply to 5 [link] [source]
That didn't address the question, though - just confirming that you can ensure the password is hashed. And probably what I'd do anyway if I was to serve out the repository via HTTP(S).
If you don't do that, and plan to serve via HTTP(S), I'd say setting file permissions to prevent other users from reading the file would be required. That way only the owner of the fie, presumably you, would be able to access the file to see the password. (OK, and root if that's your context, but that's got more ramifications anyway.)
If you want to let local users clone, they need read permissions. But in that scenario, the password is not a problem unless you are planning to serve the repository via HTTP(S) as well. At least I am not aware of other situations where the password would be useful.