Use the database as the location for SVN certificate acceptance storage.

Review Request #3420 — Created Oct. 15, 2012 and submitted


Review Board


Use the database as the location for SVN certificate acceptance storage.

Our cert model for Subversion worked such that when the user confirmed a
cert before adding a repository, we would tell Subversion to go ahead
and save that cert to the local ~/.subversion/auth. If the cert file
wasn't there, file fetches would fail. This made it quite annoying to
have a multi-server deployment, as that directory would have to be

Now, upon acceptance of the cert, we store the cert information in the
repository's extra_data field. We then look it up from there if pysvn
tells us it needs verification again on a cert.

We still save on the filesystem as well, which is more convenient, but
we're far more resilient now. We can work multi-server, and we can
easily nuke the auth directory, without affecting file fetches.

We also still generate the Subversion config files to configure rbssh
usage for Local Sites, but these are already resilient enough by
themselves, as they're just recreated as needed. So now, Subversion
should work perfectly fine without having to have a permanent
.subversion directory.
Started by turning off automatic trusting of default CAs, requiring
every single cert to be manually verified.

Configured an HTTPS repository without this patch. Verified the cert
file in the .subversion directory. Nuked that cert, and then tried
accessing a diff. Saw the cert verification failure errors.

Then applied this patch and re-saved the repository. Saw the cert file
and the cert info in the database. Accessed the files without problems.

Deleted the cert file, but kept the info in the database. Cleared the
cache. Re-accessed the file. It worked fine. Saw that SVN took the
in-database cert and re-saved it in the .subversion/auth directory.

Repeated another time just to be sure.
  1. What does the migration look like? Will users just have to re-accept the cert?
    1. For an existing, single server, none needed. Any existing .subversion directories will have auth certs that will take precedence.
      If planning multi-server, or wiping out a directory, repositories will need to be saved again, with the auth certs removed. So no automatic migration there. We'll need to solve this for ourselves, but I don't expect it to be terrible there, and I'll probably whip up some script. For the average admin, they'll be unaffected.
  1. Ship It!
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-1.6.x (9d74d3e)