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

RE: Re: client certificate request cancel: only once

From: Craig McQueen <Craig_McQueen_at_aapl.com.au>
Date: Tue, 29 Jul 2008 12:05:05 +1000

 

> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn_at_gmail.com]
> Sent: Monday, 28 July 2008 4:09 PM
> To: users_at_tortoisesvn.tigris.org
> Subject: Re: client certificate request cancel: only once
>
> cri10000 wrote:
>
> > Stefan: that's a seriously flawed assumption...
> >
> > I'm having the same problem. Here's the setup:
> > 1x Apache server
> > 2x vhosts
> > 7x repos (4 on vhost1, 3 on vhost2)
> >
> > It seems to be well documented that, in order for client
> certificates
> > to play nice with TortoiseSVN, Apache must use an 'SSLVerifyClient
> > optional' directive in the main server section (ie, outside of any
> > vhosts sections).
>
> Where is that documented?

http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/help-onepage.html#tsvn-serversetup-apache-sslcerts
 

> > This works, but here's the catch: by design, all repos on vhost1
> > should be accessed WITHOUT a client certificate. All repos on vhost2
> > require it... Better yet, the wish list is: SOME repos on vhost1 as
> > well as vhost2 require a certificate, the others are in the clear.
> > Through a browser, I can get this to work fine. But through
> > TortoiseSVN, it doesn't because of the user is constantly bugged by
> > this dialog asking for a certificate. (well... in reality
> it works by
> > pressing 'cancel' every time the dialog comes up, but no
> one in their
> > right mind would consider this a 'usable' or friendly system)
>
> if all repos on vhost1 don't require a client certificate, then don't
> make apache ask for one!
>

There are limitations on using SSL with virtual hosts. See for starters:
http://www.onlamp.com/pub/a/apache/2005/02/17/apacheckbk.html

It sounds as though the original poster is hitting against the limitations of what can be reasonably accomplished with SSL.

> > The flaw in you reasoning is: don't pass the file, don't
> get access...
> > wrong! It must go: don't pass the file, don't get access >>>to those
> > ressources that require it!<<< Doesn't mean the others are off limit
> > by implication. TortoiseSVN seems to think so...
> >
> > Here's the problem: from a server point of view (let's take Apache):
> > 'SSLVerifyClient require' means 'give me a file!', whereas
> > 'SSLVerifyClient optional' means 'got a file?'
>
> And 'SSLVerifyClient no' means 'I don't need a file'.
>
> > Now, from Tortoise's point of view, when told, 'gimme a file', it
> > shows the dialog asking the user for one, which is the correct
> > behaviour. But when asked 'got a file?', it keeps on thinking it's
> > mandatory again, and scrambles back to the user for one. That's a
> > significant problem. It should just say 'no'...
>
> There's no way for a client to know why the server asks for a
> file. If
> the server asks for it, the client has to ask the user for
> it. It's as
> simple as that. If the server later decides that it doesn't
> really need
> the file, the client doesn't know that.
>
> > To quote the first post in this thread: 'it would be nice if
> > tortoisesvn could remember that it has no certificate.' I think it
> > really should remember.
>
> If you really want such a feature, you'd have to ask on the
> Subversion
> mailing list for it: authentication is done by the Subversion
> library,
> not TSVN.
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
>
>
- The contents of this email, and any attachments, are strictly private and confidential.
- It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers.
- It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
- Please think before printing this email. Environmental Balance is Everyone's Job.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-07-29 04:05:23 CEST

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

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