On Wed, Feb 20, 2013 at 10:22 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> On 19.02.2013 21:51, Bogardus, Robert K Jr CTR DODHRA DMDC (US) wrote:
>
>> Hi Stefan,
>> [I'm taking over this issue for DMDC as Delmar is being reassigned
>> shortly.]
>>
>> Thanks so much for the time you spent looking into this.
>>
>> Could you suggest how we should proceed? The serf issue you mentioned was
>> last updated in Oct 2011.
>>
>> If it would help, I can run test nightly builds if you have time to work
>> that approach. (I agree it's very hard to debug that way though -- unless
>> you could print some extensive diagnostics? -- perhaps triggered with some
>> flag setting if there's a concern about bothering other testers with the
>> output.)
>>
>
> Since as I mentioned before, this needs to be implemented in serf and the
> svn library, I can't do it directly in TSVN.
> But I'll try to implement this in serf myself, and then in the svn library
> and once that works in TSVN. Not sure when I have the time, maybe this
> weekend, but don't count on it that I get it working right away...
>
So, implementing this in serf and/or svn doesn't work either:
Since smartcard certificates and certificates in the cert store are usually
marked as "not exportable", there is no way to get them out of the
smartcard or the cert store. You can only use them with the windows crypto
API, but never ever get their key directly.
Which means to actually use those certificates, de/encrypting data has to
be done with the crypto API.
OpenSSL however does not provide callbacks for clients to do that. Only
'engines' (kind of plugins) can do that, and that's what the e_capi engine
in OpenSSL actually does.
So: clients can not use those certificates.
No way around that, no tweaks or hacks possible.
It seems the only way to get this really working is to use the e_capi
engine in OpenSSL and patch that engine to work better in our situation.
As I mentioned before, the way e_capi works right now is not really usable.
A short recap:
If a server requests a certificate, it first checks all available
certificates and selects those that match the request.
* if there's only one certificate that matches the request, that
certificate is used unconditionally. That's what you see if there's only
one certificate on your smartcard, and as you mentioned this works quite
well.
(since for some people even this doesn't work, TSVN has patched e_capi to
disable the engine completely with a registry entry)
* if there are more than one certificate available that match the request,
e_capi would show a dialog to select the certificate. But that selection is
not stored/saved/cached. That means for longer checkouts/updates/... you'll
get more than one dialog to choose the very same certificate. And the
repository browser which makes a separate connection for every listed
folder would be completely unusable - you'd get hundreds of those dialogs
before you could even see the first file/folder listing.
right now, TSVN has patched e_capi to never show the cert selection dialog,
but show its own instead. TSVN caches the selection so you won't get the
dialog more than once. Problem is: that only works if the certificate is
exportable - as you've seen with your smartcards that have more than one
matching cert.
It seems the only way to make this work better is to patch the e_capi
engine even more (a perfect solution might not be possible, at least I
haven't found one yet):
We have to patch e_capi to save the user choice of the certificate.
Here's how I've implemented this:
* the index of the certificate in the store is saved to the registry
* if another request from the same cert chains is requested, use the saved
index and return that certificate without showing the selection dialog
* export a function to remove the cached index for the last connection
This should work fine in most situations.
But: in some situations, this requires user interaction or won't work at
all.
* if the order of the certificates in the store/smartcard changes or the
user selected the wrong certificate, the connection will fail. And further
connections will fail as well. If the server returns an auth error code,
then TSVN will automatically clear the cached data from the registry, and
the next attempt will show the cert selection dialog again. However if the
server does return another error code indicating a connection failure
instead, TSVN will not recognize this and not clear the cached cert index.
So further connections will fail over and over again. The user must then
remove that cached data manually with the registry editor (for now) or in
the settings dialog (will do that later).
* if there are multiple repositories the user connects to that have the
same certificate requests, but the user must use different certificates for
those (e.g., if the user has two certificates, one as 'user' and one as
'admin') then e_capi will repeatedly fail and operations need to be
repeated a lot. And depending on the error code, the use would also have to
clear the auth data every time.
* worst case scenario: situation as in the previous point, but now with
those two repositories connected with svn:externals, and the user is using
the repository browser. Here, best thing would be to just disable e_capi
completely since you won't get the repo browser to show up properly.
If you've read all my nonsense above: I have a test version for you to try:
http://nightlybuilds.tortoisesvn.net/CAPITest/
Please note that this version is from TSVN trunk, using trunk of the svn
library. If you were using TSVN 1.7.x before, you have to upgrade your
working copies first (or use the repo browser only).
Do you have a repository where you don't have access to certain subfolders?
If yes, please use the repo browser and try to browse to those folders. It
would be interesting to see how the patched e_capi reacts in this situation.
If not, please test at least the following:
* run update on a working copy
* show the log
* show the repo browser
always check how many times you have to select the certificate.
And: please also test what happens if you select the wrong certificates of
the two you have on your smartcard (I'm guessing only one is valid or can
be used to access the repository).
If you need to clear the cached cert selection, use regedit.exe to delete
the registry key
HKCU\Software\TortoiseSVN\CAPIAuthz
(you could also change the value of the entry below that key to another
value and see what happens then).
I hope it's not too much work for you to test this, but I really need
someone with such a setup to test this before I commit my changes.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3049678
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-02-23 22:12:03 CET