Am I missing something? Why not add the self-signed cert's CA to the
list of trusted CA's in the ~/.subversion/servers file? Then there'd
be no prompting in the first place.
On 9/23/05, Daniel L. Rall <dlr@finemaltcoding.com> wrote:
> Invocation of 'svn --non-interactive' which contacts a mod_dav_svn server
> over SSL should be possible. Currently, this doesn't seem to be possible
> for self-signed certificates.
>
>
> Use case:
>
> Code which has auth credentials available but does not run interactively
> should be able to contact a Subversion repository over SSL using ra_dav
> without having to jump through hoops (see "Existing work-arounds" below).
>
>
> Considerations:
>
> This is behavior inconsistent with other Subversion options and
> sub-commands, which all (?) provide a means to turn off interactivity
> without impacting their basic usage.
>
> svn's current behavior of identifying a server certificate as "issuer not
> trusted" is consistent with most web browsers for questionable server certs,
> which is to prompt for acceptance when a server cert with an unknown CA
> (e.g. self-signed). However, the fact that this behavior is absolute is
> not conducive to programmatic execution of svn or its APIs.
>
> I'm guessing that the experimental svnserve-ssl branch has similar issues,
> and would need to conform to any API modification.
> http://svn.collab.net/repos/svn/branches/svnserve-ssl/
>
>
> Existing work-arounds:
>
> Open a pipe to the svn binary and omit --non-interactive. This has the
> unfortunate site effect of requiring the caller to handle _all_ possible
> interactivity, not just the "accept certificate" prompt (for instance, an
> auth failure will also re-prompt for auth). Especially when the caller
> actually desires the --non-interactive behavior for the non-server cert
> case, this is less than ideal.
>
>
> Suggested interface:
>
> Add the equivalent of a 'svn --trust-server-cert' argument to the
> libsvn_client and libsvn_ra APIs, and exposed it via the command-line
> client.
>
>
> Existing implementation:
>
> libsvn_ra_dav indirectly invokes Neon's ne_openssl.c:check_certificate()
> (passing in some callbacks), which hands back an error saying that the
> server cannot be trusted:
>
> case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY:
> case X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN:
> case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT:
> /* TODO: and probably more result codes here... */
> failures |= NE_SSL_UNTRUSTED;
> ...
> if (failures == 0) {
> /* verified OK! */
> ret = NE_OK;
> } else {
> /* Set up the error string. */
> verify_err(sess, failures);
> ret = NE_ERROR;
> /* Allow manual override */
> if (sess->ssl_verify_fn &&
> sess->ssl_verify_fn(sess->ssl_verify_ud, failures, chain) == 0)
> ret = NE_OK;
> }
>
> Neon allows errors to be ignored via a ne_session callback:
>
> /* A callback which is used when server certificate verification is
> * needed. The reasons for verification failure are given in the
> * 'failures' parameter, which is a binary OR of one or more of the
> * above NE_SSL_* values. failures is guaranteed to be non-zero. The
> * callback must return zero to accept the certificate: a non-zero
> * return value will fail the SSL negotiation. */
> typedef int (*ne_ssl_verify_fn)(void *userdata, int failures,
> const ne_ssl_certificate *cert);
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 24 17:55:44 2005