Your message dated Mon, 14 Mar 2016 00:36:51 +0000 with message-id <[email protected]> and subject line Re: Solution has caused the Debian Bug report #776277, regarding subversion: certificate validation fails inconsistently in non-interactive mode to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 776277: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776277 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: subversion Version: 1.8.10-1~bpo70+1 Severity: important Dear Maintainer, When automating svn checkout with self-signed certificate (WinSVN) there is inconsistency in accepting it. Let's try to list SVN repository contents in default interactive way: svn ls $URL --username $SVN_USERNAME --password $SVN_PASSORD --no-auth-cache Error validating server certificate for 'https://dev.MYDOMAIN.com:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! - The certificate hostname does not match. Certificate information: - Hostname: WIN-CE9BA5GIC1A - Valid: from Oct 4 06:30:11 2011 GMT until Oct 1 06:30:11 2021 GMT - Issuer: - Fingerprint: 10:CC:5D:3A:EB:26:F5:44:3B:7D:47:13:B5:57:FA:48:36:5B:32:61 (R)eject or accept (t)emporarily? t scripts/ Temporary accepting "bad" certificate worked, got repository content. Now if I try to automatically accept it using input redirection: svn ls $URL --username $SVN_USERNAME --password $SVN_PASSORD --no-auth-cache <<< t svn: E230001: Unable to connect to a repository at URL 'https://dev.MYDOMAIN.com/svn/linux/trunk' svn: E230001: Server SSL certificate verification failed: certificate issued for a different hostname, issuer is not trusted And also the same error using non-interactive flags: svn ls $URL --username $SVN_USERNAME --password $SVN_PASSORD --no-auth-cache --non-interactive --trust-server-cert svn: E230001: Unable to connect to a repository at URL 'https://dev.MYDOMAIN.com/svn/linux/trunk' svn: E230001: Server SSL certificate verification failed: certificate issued for a different hostname, issuer is not trusted In result, it seems that it's not possible to automate SVN commands when using "untrusted" self-signed certificates, even if one accepts the risks of using them (--trust-server-cert). -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages subversion depends on: ii libapr1 1.4.6-3+deb7u1 ii libaprutil1 1.4.1-3 ii libc6 2.13-38+deb7u6 ii libldap-2.4-2 2.4.31-1+nmu2 ii libsasl2-2 2.1.25.dfsg1-6+deb7u1 ii libsvn1 1.8.10-1~bpo70+1 subversion recommends no packages. Versions of packages subversion suggests: ii db5.1-util 5.1.29-5 ii patch 2.6.1-3 pn subversion-tools <none> -- no debconf information
--- End Message ---
--- Begin Message ---Version: 1.9.0~rc1-1 Vincas Dargis wrote on Wed, Jan 28, 2015 at 09:10:14 +0200: > I have recreated self-signed certificate with propper CN inside VisualSVN > (by default it was computer hostname), and now --non-interactive > --trust-server-cert is working as expected (accepts without prompting or > error). > > Self-signed is also untrusted as one with non matching hostname, but maybe > it's SVN policy to ignore "--trust-server-cert" for hostname missmatch > specificlally as for "more dangerous" case? In 1.8, if a certificate had other failures besides being issued by an unknown CA, then at the interactive prompt you wouldn't be given the "(p)ermanently" option, and you wouldn't be able to accept it non-interactively at all. In 1.9, you can accept these "more dangerous" cases: % svn help update ⋮ --trust-server-cert : deprecated; same as --trust-server-cert-failures=unknown-ca --trust-server-cert-failures ARG : with --non-interactive, accept SSL server certificates with failures; ARG is comma-separated list of 'unknown-ca' (Unknown Authority), 'cn-mismatch' (Hostname mismatch), 'expired' (Expired certificate), 'not-yet-valid' (Not yet valid certificate) and 'other' (all other not separately classified certificate errors). Accordingly, I'm marking this bug as fixed. Cheers, Daniel
--- End Message ---
