On 09.03.2015 22:29, Madsen, Terry wrote:
>
> 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 ver/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://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
>
Why do you (and apparently Stefan, too) think it's a good idea for the
client to trust a cert that has expired, or has an invalid signature or
does not even parse correctly? The whole point of having server
certificates is to increase the chances that the client is actually
talking to the correct server, not to some hacked intermediary.
Even the current --trust-server-cert is a dangerous option because
you'll never actually see the information encoded in the certificate.
The decision to trust a certificate should be explicit, not a side
effect of some automated process that simply turns off certificate
validation.
In this context, your option 1 is /not/ a hack and the only sane thing
to do (assuming you actually verify the cert info that the client
prints). Of course, if you don't care about security issues, then using
TLS is a waste of time in the first place.
-- Brane
Received on 2015-03-10 08:47:44 CET