I'm dealing with a server which has a 'non-compliant certificate', using the most recent (in the last week) Subversion Edge. Client is svn 1.8.11.
This is all command-line based...:
svn ls https://server.whate%e2%80%8bver/svn/repository<https://server.whatever/svn/repository> --no-auth-cache --username username --password password
(with the obvious use of something real...)
Interactively, I get the prompt ".. (R)eject or accept (t)emporarily. Fine. (I also get the option to permanently accept, if I don't specify '--no-auth-cache'.)
If I add '--non-interactive', I get 'svn: E230001: ... issuer is not trusted'. Again, fine: bad cert, non interactive, gotta bail.
If I also add (append) '--trust-server-cert', based on the help for this, I expect things to work. However I still get the E230001 error.
The standard workarounds I see when Goggling seem to be:
1) (a hack) accept the cert permanently once interactively, then this should work. Means I have to do stuff on every server that might do this (and there are several). The fact that the actual behaviour is for the process to hang, rather than error out, makes chasing down all the boxes a real chore.
2) (a hack) have a stub script that does 'echo p | svn ....' (so that it's interactive and sets up the configuration). I don't like this, part of why I'm posting is problems with this workaround, buried in code written long ago by staff who are no longer with us (corporately).
3) (a hack) fiddle with the server so that it will also allow http, and where needed use the http://server.whatever instead of the <https://variant.> https://server.whatever variant.
All of these seem to be lacking something. So, this is (another) enhancement request to put to the maintainers of Subversion: please add a '--trust-server-cert​-really-i-mean-it' option so that the above workarounds aren't needed.
I am aware that 'fix the cert' is the recommended option, but this doesn't solve the problem of the moment.
To me the key is that there are already several clumsy workarounds in circulation, so a broader trust option isn't going to do anything that isn't already being done in the field, it'll just make it more straightforward --- and in the case of option 3, less intrusive. Moreover, the fact that the cert can be accepted interactively suggests that there's no good reason to not accept it in scripting mode (at least, with the "really-i-mean-it" flavour).
Option 3 seems to be the workaround answer, at least in my case, but the cure is worse than the disease in that it requires fiddling with the server and thus affects all users, not just the ones trying to get theirs scripts to work.
(Also note: this is stuff that's buried several layers deep, the direct command line is to replicate the issue).
This is also discussed at: http://svn.haxx.se/users/archive-2013-08/0494.shtml
Terry Madsen
Received on 2015-03-09 22:53:05 CET