On Thu, Aug 26, 2021 at 10:11:44AM +0200, Branko Čibej wrote: > On 25.08.2021 21:01, Mark Phippard wrote: > > On Wed, Aug 25, 2021 at 3:16 AM Johan Corveleyn <jcor...@gmail.com> wrote: > > > > > > Is there a way to test whether one has rw access without actually doing > > > > a commit or a revprop edit? It's possible with hooks, of course, but is > > > > it also possible without hooks? > > > I'm not sure I understand: why would I need to know that the cached > > > credentials have read-write access? > > I think it was a good question. It is hard to predict if a build > > process just needs read access or read-write. If it needs the latter > > it could complicate the effectiveness of a solution that goes down > > this path. For example, imagine a scenario where the server allows > > anonymous read access .. it will not even be possible to check > > credentials unless you attempt a write operation. > > > > I was never super excited about this change to disallow plain text > > passwords but I figured fighting against a security issue is a losing > > battle. I personally prefer the suggestion of making it a compile > > option to disallow plain text passwords and have them enabled by > > default and just turned off in the default configuration. The > > alice/eve scenario while valid just does not concern me. > > > > Solving with svn auth is a nice idea but I do not see it working > > unless we have a way to authenticate for write access without writing > > something.
Thanks for bringing this up, Daniel and Mark. This is indeed an important point. > There isn't in general, since authz can complicate matters. And there isn't > currently, we don't have server-side support for that. I'm not even sure we > could add a server-side method for this check, since the check for write > access can be done entirely outside of Subversion. "svn authz write-check > $url" sounds plausible until you consider all the various possible > authn/authz checking combinations. The answer might be that 'svn authz add' should simply not contact the server to check credentials. Which means we cannot check upfront whether the user running 'svn auth add' knows valid credentials. I think this may still be better than the alternative where configuration files can be tweaked to trick Alice into unknowingly saving her password in plaintext while running regular SVN operations. Having 'svn auth' be the only command which would write a plaintext password does provide some protection in this scenario, regardless of whether credentials are checked against the server before they get cached. One consequence is that when Alice mistypes the --username option, or mistypes the username or password at the prompt, invalid credentials will be cached. Which should make any regular SVN operation fail and ask for credentials again. I don't think this would be a problem, apart from the possibility that invalid plaintext credentials would not be overwritten by SVN binaries compiled without support for writing plaintext passwords during regular operation. In the absence of non-plaintext auth caches SVN would then keep asking for a password until 'svn authz add --plaintext' is used again to store valid credentials. This problem also applies to any helper scripts that people might be running right now in order to add plaintext credentials to the auth cache. To mitigate this problem a bit, we could have 'svn auth add' ask for the password twice and repeat the prompt in a loop in case of a mismatch. And while we are considering read-only vs. read-write access: Plaintext passwords or not, in my contrived scenario Eve could always trick Alice into using a different user account by caching a set of valid credentials which Eve knows. Apart from not caching credentials at all I don't see a way to prevent this.
