Hi Daniel, your patch to use the password callback in ne_ssl_load_pem is
now in CVS for the next neon release, along with the reference counting
fix - thanks again.
On Mon, Aug 05, 2002 at 01:31:49AM -0400, Daniel Berlin wrote:
> (Neon people, i'm not on the ml, but i figured you'd want to read
> this, since it contains a note about an openssl bug that should be worked
> around. But if you respond, please include me on the cc. The main neon
> version i'm using is 0.21.3, though i tested it with cvs over the time i
> composed the message)
>
> First, if i use the neon callbacks, rather than preload the
> certificate, we can't get good error handling, because we can't return
> errors from the provide_ccert callback (it's a void return).
Can you explain how you could do better error handling if the callback
could fail? Currently if the callback doesn't load a client cert, the
SSL negotiation will fail anyway (though strictly I suppose it could
proceed depending on the server configuration).
> Thus, rather than get something sensible when you mistype the password, by
> the time we get ahold of an error, it's a connection closed from the
> server. Which we take to be some other type of error, and eventually get
> a fun:
> [root_at_dberlin myrepo]# svn co https://localhost/repos
> Enter PEM pass phrase:
> Enter PEM pass phrase:
>
> svn_error: #21095 : <Bad URL passed to RA layer>
> No part of path '/repos' was found in repository
>
> Cute, no?
If that error message is being generated from an SSL negotiation failure
(which is all this is, right?), I think there's a bug somewhere else.
> we get two chances only because the provide functions exist for both neon
> sessions we open, and it only makes one attempt.
> If you get it right, it only asks once (I cache the password in the
> password providing function).
>
> Without the callbacks (IE preloading the certificates), i can give
> sensible error messages, but it would always asks twice (one for each
> session), so i had to cache the password in the ra_session structure
> to get around this.
> Which should i keep in the patch?
Unless you are doing anything fancy like determining which client cert
to use based on which server cert is given, the two methods are
equivalent, so I'd say go for the no-callbacks version since it's
simpler.
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 5 22:50:12 2002