Den tis 28 mars 2023 kl 14:41 skrev Johan Corveleyn <jcor...@gmail.com>:
> On Mon, Jan 24, 2022 at 5:02 PM Mark Phippard <markp...@gmail.com> wrote: > > > > On Mon, Jan 24, 2022 at 10:44 AM Daniel Shahaf <d...@daniel.shahaf.name> > wrote: > > > > > > > >I return to my "two camps" argument. The people that do not want > > > > > >plaintext passwords to be cached ... do not want them being > > > > > >cached. > > > > > > > > > > I see what you mean. > > > > > > > > > > If svn is compiled to not cache passwords, but a legacy cached > > > > > password exists on disk for a given repository, should svn not > > > > > only not read it but actually warn the user that the cached > > > > > password exists? > > > > > > > > IMO, it is not necessary and if a compiler option disables the code > > > > then I would envision we do not even have any code running that is > > > > looking for those files to give the warning. > > > > > > Plaintext passwords are saved in the "password" element of the > > > serialized hash in ~/.subversion/auth/svn.simple/. > > > > > > Those are the same files that cache the username when the username is > > > cached without its password. > > > > > > We can't know whether a file contains a password or not until we have > > > opened, read, and parsed it. > > > > > > So, "not even have any code running that is looking for those files" > > > isn't an option (unless we're willing to throw away cached usernames > > > even if they were cached without a password) > > > > > > So, what should we do if we have parsed one of those files and the > > > resulting apr_hash_t contains a "password" key? > > > > > > Ignore it? Erase it (memset() it to zero)? Warn about it? Use it? > > > > Good points and excellent questions. If we would already be > > discovering this file then I suppose we could do something. I would be > > fine with just ignoring the cached password but some kind of other > > option would also be good. > > > > > > > And for that matter, should there be a configure option that disables > > > the --password command-line option? It, too, can be used insecurely > > > (see above about filesystem-level encryption). > > > > Also a good question. A configure option to disable this might be > > appreciated by some users. > > Is this issue on someone's radar? It seems the discussion died out > here, and I can't find anything further. Maybe worth taking another > look now that we're getting closer to 1.15? > > We seemed to get stuck "finding consensus on desired behaviour". > Various proposals were made, but none got over the "bar of > objections", and we ran out of steam. Which leaves us with the status > quo, however imperfect it is :-(. > > (This recently came up in my company, when we were looking at > upgrading the svn client on a unix build machine -- oops can't upgrade > past SVN 1.12 or so, because of the compiled-out plain-text pwd > caching support) > > For some background (warning long read): > > https://lists.apache.org/thread/b6g2hx2m3s117wcmno08opl874ons3q8 > https://lists.apache.org/thread/shzxh04l493qnj8pdt8vl0x4gkjrkvcy > One outcome was that I wrote a script (based on suggestions by danielsh) to store plaintext passwords. It is linked from the website: https://subversion.apache.org/faq.html#plaintext-passwords And the script can be found here: https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/store-plaintext-password.py Hopefully the script will help you at least some part of the way. Stefan Sperling has previously described how OpenBSD explicitly compile SVN /with/ support for caching plaintext passwords but disable it in the global runtime config. That sounds like a good option to me - reverting the previous change and changing the default config. I don't know (didn't check, no time) what the default config is right now and if it can be interpreted as "don't cache passwords" for old clients being updated. One downside is that it might be difficult for administrators to enforce a policy (ie, "don't allow users to store a password") but since SVN uses existing passwords, such policy is easily circumvented (create the auth cache file on another machine and copy it manually). Kind regards, Daniel
