TL; DR: If you want to use mutual authentication using a client certificate against a Subversion server there’s both a Windows-pitfall and an UnrealEngine-pitfall to be aware of, but there are workarounds for both of these.
Epic: There’s a bug in your distributed svn.exe binary, which is triggered when people want to secure access to a Subversion server using mutual authentication (i.e. use client certificates).
We have had an internal Subversion server used to source control UE projects, and this has worked fine apart from employees not being able to access their projects from outside the LAN. To remedy this I set up an a mutual authentication endpoint (i.e. the apache server requires a valid client certificate to authenticate, and the CN of the client certificate is mapped to the subversion user name). On Linux and mac this Just Worked™, but on Windows we encountered a few non-obvious peculiarities that I thought I’d share in case anyone else encounters them.
First problem – TLS handshake fails
The subversion client refused to speak to the server, and aborted very early (i.e. no application logs on the servers). A few quick searches on the two error codes pointed to a problem/solution which was not applicable in our case. The two errors apparently is commonly interpreted to mean that the TLS server does not offer any TLS versions that the TLS client accepts. I.e. the server does not offer any TLS revision high enough to meet the minimum requirement of the client. Clearly this is not necessarily the case; our server is TLSv1.3 capable, and at the time of this writing there is no higher revision.
After some hand-waving we discovered that the solution to this is the remove the client certificate from the Windows Certificate store. If the client certificate is present in the certificate store, then for some weird reason Windows hijacks the TLS connection attempt, and the whole thing explodes. Just store the .p12 in the svn server config to avoid Windows certificate management meddling in, and breaking, the handshake.
This is super annoying if the client certificate is used to access internal web resources, and the employee likes to use Edge (since it uses the Windows certificate store). We solved this by telling the affected users to use Firefox for internal resources.
Second problem – UE5 unable to connect to source control
Once the first problem was solved, we tried to connect a project to the subversion server, but it errors out with an error (in the server connection log) along the line of:
OPENSSL_Uplink(..): no OPENSSL_Applink
I’m still not quite sure what this means. I saw some post indicating that OpenSSL on Windows needs some special runtime initialization that is not needed on other platforms (sort of like the winsock init?). Allegedly a call to OPENSSL_Applink() is missing from the application code (I also saw comments about this no longer being necessary in later OpenSSL versions). Someone wrote that this “applink” issue comes into play when using PKCS#12, which is highly relevant for us.
… HOWEVER …
We’re using subversion for other things without these problems. The problem is hitting immediately, so it’s not some obscure corner-case, it explodes when trying to connect the source control system to a server.
I’ve never been clear on whether UE5’s Subversion plugin links to some subversion client library or calls the svn command, so I did some spelunking in the source code.
I only took a quick glance, but it kind of looks like UE5 tries to find a “system” svn.exe, and if it doesn’t find one it falls back to a pre-built distributedsvn.exe binary? Not sure I read that right, but I also found that it’s possible to point out a specific Subversion executable in Saved\Config\WindowsEditor\SourceControlSettings.ini.
I explicitly hard-coded:
[SubversionSourceControl.SubversionSourceControlSettings]
...
ExecutableLocation = "C:\Program Files\TortoiseSVN\bin\svn.exe"
… and restarted the editor.
Now connecting the project to the subversion server works like a charm! (I haven’t done any real work, so I may be celebrating too soon – but from my earlier experience with Unreal Engine and source control, the problem tends to be to get the initial connection working. Once that initial hurdle has been passed things tend to work.
Edit: A thought occurred. Perhaps it’s not a bug in the distributed svn.exe, but just a question of where it looks for its configuration files. I just blindly assumed it would be using the same locations as the binaries included in TortoiseSVN – but maybe that isn’t the case.