[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Regression: Bad cert handling in subversion 1.6.11

From: Sören Bernstein <quasi_at_barkhof.uni-bremen.de>
Date: Sun, 4 Jul 2010 08:24:26 +0200

Am Sonntag 04 Juli 2010, 07:59:42 schrieb Daniel Shahaf:
> Sören Bernstein wrote on Sun, 4 Jul 2010 at 08:25 -0000:
> > Am Samstag 03 Juli 2010, 20:30:47 schrieben Sie:
> > > Firstly, thanks for the very clear bug report.
> > >
> > > Sören Bernstein wrote on Sat, 3 Jul 2010 at 09:04 -0000:
> > > > Hello all
> > > >
> > > > since I've upgraded to subversion 1.6.11 found that there is a bug
> > > > while accepting bad certs. This is also true for 1.6.12. I'm running
> > > > gentoo stable amd64 and gentoo stable x86.
> > > >
> > > > While checking out a trunk from svn with a bad server cert, svn warns
> > > > about it,but then it does not print the message with the options to
> > > > except or dicard. Instead it sits and waits for user input, AFTER
> > > > which it will show the input options.
> > > >
> > > > Subversion 1.6.9 does not have the error.
> > > >
> > > > Reproducible: Always
> > > >
> > > > Steps to Reproduce:
> > > > 1. Install subversion 1.6.11
> > > > 2. Checkout from a server with bad cert
> > > > 3. Wait for the warning message of subversion
> > > >
> > > > Actual Results:
> > > > Subversion will print the information about the bad certificate and
> > > > waits for user input. After Input it will show the input options for
> > > > the prior input.
> > > >
> > > > Expected Results:
> > > > Subversion should print the input options before waiting for input.
> > > >
> > > > A svn trunk with broken server cert could be found at:
> > > > https://svn.tabos.org/repos/ffgtk/trunk
> > >
> > > I cannot reproduce this using either svn 1.6.12 or svn 1.7.0-dev
> > > (>=r937607) on Windows, over neon, if I run
> > >
> > > svn co https://svn.tabos.org/repos/ffgtk/trunk
> > >
> > > then I get the following prompt:
> > > [[[
> > >
> > > Error validating server certificate for 'https://svn.tabos.org: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: *.krueger-it.net
> > > - Valid: from Sat, 07 Feb 2009 13:02:12 GMT until Mon, 07 Feb 2011
> > >
> > > 13:02:12 GMT
> > >
> > > - Issuer: http://www.cacert.org, Root CA
> > >
> > > - Fingerprint:
> > > a2:d3:f0:83:f9:8e:96:dd:d6:7f:9e:eb:1f:0c:6a:56:28:86:e9:21 (R)eject,
> > > accept (t)emporarily or accept (p)ermanently?
> > >
> > > ]]]
> > >
> > > Just to clarify, if you type 'R<newline>' blindly at the prompt, does
> > > svn read that and proceed to (R)eject the certificate? (it should
> > > print an error message)
> >
> > I'm running neon 0.29.3 which is the lastest stable version for gentoo
> > linux. Runnung svn co https://svn.tabos.org/repos/ffgtk/trunk leads to
> > this with system env set to german):
> >
> > [[[
> > Fehler bei der Validierung des Serverzertifikats für
> >
> > »https://svn.tabos.org:443«:
> > - Der Hostname des Zertifikats stimmt nicht überein.
> >
> > Zertifikats-Informationen:
> > - Hostname: *.krueger-it.net
> > - Gültig: von Sat, 07 Feb 2009 15:02:12 GMT bis Mon, 07 Feb 2011
> > 15:02:12 GMT - Aussteller: http://www.cacert.org, Root CA
> > - Fingerabdruck:
> > a2:d3:f0:83:f9:8e:96:dd:d6:7f:9e:eb:1f:0c:6a:56:28:86:e9:21
> >
> > ]]]
> >
> > with LANG="en-US.UFT-8" I get:
> >
> > [[[
> >
> > Error validating server certificate for 'https://svn.tabos.org:443':
> > - The certificate hostname does not match.
> >
> > Certificate information:
> > - Hostname: *.krueger-it.net
> > - Valid: from Sat, 07 Feb 2009 15:02:12 GMT until Mon, 07 Feb 2011
> > 15:02:12
> >
> > GMT
> >
> > - Issuer: http://www.cacert.org, Root CA
> > - Fingerprint:
> > a2:d3:f0:83:f9:8e:96:dd:d6:7f:9e:eb:1f:0c:6a:56:28:86:e9:21
> >
> > ]]]
> >
> > and subversion is waiting for user input. After the user input, which is
> > working as expected, I get the question with all the allowed option, but
> > it is a little to late for that:
> >
> > [[[
> > (R)eject, accept (t)emporarily or accept (p)ermanently?
> > ]]]
> >
> > In all other aspect the ceckout is working. So there is some mixup with
> > the question and the input reading.
>
> On the surface, the code seems okay: the "(R)eject" line is part of the
> same C-string as the rest of the prompt, and we do fflush() after
> printing the prompt.
>
> The following diff highlights the relevant parts in the code.
> [[[
> Index: subversion/libsvn_subr/prompt.c
> ===================================================================
> --- subversion/libsvn_subr/prompt.c (revision 958675)
> +++ subversion/libsvn_subr/prompt.c (working copy)
> @@ -105,6 +105,7 @@ prompt(const char **result,
> {
> svn_boolean_t saw_first_half_of_eol = FALSE;
> SVN_ERR(svn_cmdline_fputs(prompt_msg, stderr, pool));
> + SVN_ERR(svn_cmdline_fflush(stderr));
> fflush(stderr);
>
> while (1)
> @@ -302,11 +303,11 @@ svn_cmdline_auth_ssl_server_trust_prompt
> if (may_save)
> {
> svn_stringbuf_appendcstr
> - (buf, _("(R)eject, accept (t)emporarily or accept (p)ermanently?
> ")); + (buf, _("(R)eject, accept (t)emporarily or accept
> (p)ermanently? \n")); }
> else
> {
> - svn_stringbuf_appendcstr(buf, _("(R)eject or accept (t)emporarily?
> ")); + svn_stringbuf_appendcstr(buf, _("(R)eject or accept
> (t)emporarily? \n")); }
> SVN_ERR(prompt(&choice, buf->data, FALSE, pb, pool));
>
> ]]]
>
> > CU
> >
> > S. Bernstein
>
> (There's an svn_cmdline_fflush() because I didn't notice there is
> already fflush() there.)

I don't have the sources installed, so there's nothing I can do with the
diffset. But, there must be some differences between 1.6.9 and 1.6.11 because
1.6.9 is working correctly while 1.6.11 is not. Maybe you should run a diif
between those to versions.

-- 
Dipl. Inform.
Sören Bernstein
ZeS, Barkhof
Universität Bremen
Received on 2010-07-04 08:25:34 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.