[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-dev
Subject:    Re: [PROPOSAL] Allow plaintext passwords again.
From:       Mark Phippard <markphip () gmail ! com>
Date:       2022-01-24 16:01:55
Message-ID: CAHFaGCodLF9MsHGD7wMx_Ncz2+fG923rtAD_AfxfvxKC7K+BHA () mail ! gmail ! com
[Download RAW message or body]

On Mon, Jan 24, 2022 at 10:44 AM Daniel Shahaf <d.s@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.

Mark
[prev in list] [next in list] [prev in thread] [next in thread]