Mark Phippard wrote on Fri, Jan 21, 2022 at 20:29:21 -0500: > On Fri, Jan 21, 2022 at 7:22 PM Karl Fogel <kfo...@red-bean.com> wrote: > > > > On 21 Jan 2022, Mark Phippard wrote: > > >One aspect of the previous thread that came up is that someone > > >demonstrated a simple script to create a cached password (as a > > >workaround for current users). That is what led to the idea of > > >formalizing this using the svn auth command to create this file. > > > > > >I am the only one calling this a backdoor. I am saying that if I am > > >an admin that does not want plaintext passwords being cached and > > >you then create a simple way to do exactly that, then that is a > > >backdoor around the policy I wanted.
There's any number of other ways to auto-answer password prompts: - Build a custom client [It's easy, especially considering that many of our users happen to be programmers.] - Use the --password option [which would be visible in ps(1) output without needing local root, unlike the content of ~/.subversion/auth/] - Use wrapper tools that will run $SHELL in a pty and auto-answer password prompts [They exist] - Map some key or mouse button to one's password [and then forget to chmod one's ~/.xmodmaprc restrictively] - Run 1.14 [can be prevented server-side by checking the User-Agent string] - Set the password to adjacent home row keys, so it's easy to type [can be prevented by the admin] - Use kwallet/gnome-keyring with an empty or easy-to-guess master password And conversely, there might be encryption at or below the OS filesystem level, in which case plaintext password caching is pretty much comparable to the alternative caching options. > > >Maybe it is not the right term to use here. I'd say "circumvent". "Backdoor" specifically refers to bypassing authz. > > >I am just saying if we are going to make someone compile their own > > >binaries we might as well at least give them what they want. There'll always be ways to feed passwords to svn(1) automatically. The question is just how difficult it would be to do so. More below. > > >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? 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). > > That said, I do not have a strong opinion on this one. Neither do I :) Cheers, Daniel
