subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sören Bernstein <qu...@barkhof.uni-bremen.de>
Subject Re: Regression: Bad cert handling in subversion 1.6.11
Date Sun, 04 Jul 2010 06:24:26 GMT
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

Mime
View raw message