[Ok, I read the headline, now just show me the solution]
As many other mac users, and developers using subversion on macs somewhere in their pipeline, I ran into this recently introduced issue (apparently introduced by Apple) where server certificates can no longer be trusted permanently. The problem is quite easy to fix, and people with a broarder understanding of subversion and “what’s under the hood”, will no doubt just have fixed this problem and moved on… However, I am not one of those people, and have therefor not been able to use my home computer for work, since that’s the mac cheep of the family. As indicated in the solution section, there’s a chance that this problem is only related to secure connections, which will also kinda explain why the outcry for a solution has not been heard from the vast majority of mac based developers. Guess the subset of developers that do use secure connections but does not know what’s under the hood of subversion is pretty limited…
Many wrong ways around it
I really didn’t care about having to manually confirm that the certificate was trustworthy every time I made a subversion operation that connected to the server. So I could have added the –trust-server-cert and –non-interactive options to “just make it do what it was supposed to do”. However, our build scripts rely heavily on automated svn routines, which are all handled through precompiled java programs, and these routines would fail when a cert was not permanently trusted. And since I couldn’t get to the svn call within these programs, I could have tries some ugly hacks with aliases setting the svn call to always include these options, but then my system would be far too vulnerable if someone got access to it. AND it’d be ugly… and wrong. So any ways, while I was snooping around in those parts of the forrest my boss has a tendency to look in direction of “the more correct way of doing things” and sent me a link that pretty much just cleared the whole thing up.
The simple solution
As usual, once the actual problem is identified, there is a clean and simple solution. And as posted in this thread, the problem is that the authorization / authentication folder storing (in my case for the secure servers) svn.ssl.servers folder does not belong to the user experiencing the problem. Apparently this part of the subversion structure is new and initially created by the system, and therefor not owned by the user. For this reason the user has no permission to write to this folder or it’s content and therefor the flag to permanently trust some certificate is never stored.
So the simple solution is simply to change your read/write permissions (e.g. by changing the owner) of the folder recursively or simply delete it and let a new one (belonging to you) be created the next time you access the server. No matter which solution you choose; the next time you’re asked about the level of trust to show this particular server, your choice to permanently trust the certificate will be stored and the system will respect your authoritah.
svn.ssl.server is located in
~/.subversion/auth on *nix systems and in
C:\Users\"USERNAME"\AppData\Roaming\Subversion\auth on Windows.
On a *nix system you have the option to change the owner of the folder recursively by running
chown -R $USER ~/.subversion/auth to take ownership
chmod -R u+w ~/.subversion/auth to make it writable for you
On both *nix and Windows systems you can delete the folder altogether and have a new one created when it’s needed.
so for *nix:
rm -r ~/.subversion/auth/svn.ssl.server
and on Windows - You know what to do… But if you REALLY wanna use the terminal:
After step 1) the folder is now either non-existing or at least writable, so now you just need to set the “permanently trus it”-flag for the server in question, so go ahead and run
svn list <url to server>
and when prompted to trust it, type p for permanently. And violá. You’re all done!
As mentioned above; I’ve only had this problem with secure servers. It makes sense that this has been mindlessly put in place to further secure these connections, but I’m still leaning towards a classic brain fart. Any ways, I will assume this same procedure will solve the problem as well if any other connection type is causing a similar blockade, so feel free to try this for the other files in <SVNpath>/auth and put your experiences and any insight on a public Apple based solution or the reasons for this fluke if you know it in the comments below.