Re: cert caching touch-ups

Tobias Ringström wrote:

> Branko Čibej wrote:
>
>> Let's not forget that Subversion is more than the command-line client. I
>> can easily imagine that a GUI will run a lot longer. I'd hesitate to
>> tweak a library function's behaviour only to better support the command
>> line client.
>>
>>
> I'm not sure exactly what you object to. Do you object to the whole
> SSL server certificate permanent trusting mechanism, or only the fact
> that the user can trust a certificate that has an invalid date or
> hostname? Adding the possibility to trust certs with invalid date and
> hostname is only a few lines of code, and it's something that can
> benefit all kinds of clients. Another advantage is that if a cert is
> permanently trusted in one client, it will be trusted in another
> client as well, which makes sense, IMHO.
>
> Or did I miss the point completely?

I guess. :-)

I was objecting to modifying the caching mechanism so that the
_temporary_ acceptance a cert would hold across invocations of the
command-line client. I believe we should not tweak our libraries to
specifically serve the command line client more than necessary, because
it makes life complicated.

For example, right now there's quite a bit of code in libsvn_subr (and I
think even some instances in libsvn_client) that's useful only for
command-line programs and nothing else. This code slowly accumulated
there becasue libsvn_subr was the only place that seemed suitable. Now
it's becoming more and more obvious that this code will have to move to
its own library. In the same way, some sort of svnagent daemon that
specializes in temporary caching of authentication tokens (both client
and server) would be much better than magic in svn_auth.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org