On Wed, May 16, 2012 at 9:25 AM, Greg Stein <gstein_at_gmail.com> wrote:
> [avoiding responding, in favor of collecting feedback, but one item...]
> On Wed, May 16, 2012 at 9:15 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> Having not reviewed the issues myself, I can only submit the following
>> litmus test of ra_serf readiness: can it do everything that our current
>> user base expects ra_neon to do? I don't see any reason to make it more
> I think Mark tracks this. iirc, serf does not do "smart card" authn,
> or somesuch.
No, it wasn't me. I do recall some people posting items like this but
I do not remember who.
Interestingly, GMail is suggesting I add Ivan to this email and that
is also what I was thinking. I recall that VisualSVN advertises smart
card support so he might have some info.
On Windows, most of the SVN binaries are supporting Smart Cards via
OpenSSL. It can be built in a way that it works with the Windows
CryptoAPI which adds smart card support. This all happens in the SSL
negotiation outside of Subversion so it should work with Serf as well
as Neon. On Unix, I have no idea how people do it, except I do recall
Joe Orton or someone posting about using Neon with pakchois or some
other library that does this. AFAIK, this requires doing a custom
build of the stack for your specific smart card implementation.
FWIW, a downside of using OpenSSL to do this is that our servers file
is ignored so you cannot configure a specific cert in that file as you
could if OpenSSL is not compiled to use that API. We have a few
customers this is a problem with because they use Smart Cards for some
stuff on their LAN, but for SVN they are using client certs. They are
always prompted to insert their Smart Card and that is not what they
want. TortoiseSVN applies a custom patch to OpenSSL to allow this to
be turned on/off at runtime but that approach does not work for the
command line binaries.
Received on 2012-05-16 15:33:10 CEST