Often, the data that is in a repository is not something that you want everyone to get their hands on—or if it is something you want everyone to get their hands on, the odds are that you don’t want everyone to be able to directly modify the repository. For this reason, many repositories are accessible only through a secure HTTP link, which is encrypted using the Secure Socket Layer (SSL). If a repository that you are connecting to is set up thus, it may be necessary for you to configure Subversion to recognize the certificate that identifies the server and the keys for connecting to it.
The first thing that you may need to do is to tell Subversion which certificate authorities it should use to validate a server certificate. A certificate authority (CA) is a trusted source, which is capable of validating the authenticity of a certificate you receive. Without the certificate authority, you have no way to ensure that a certificate received from a server is valid and authentic. To tell Subversion which certificate authority it should use, you need to get a certificate identifying the CA and then point Subversion to the file containing it. You do so through thessl-authority-filesoption in yourserversfile, which is a list of authority files, separated by colons. If you set thessl-trust-default-caoption to
yes, Subversion will also look to a set of built-in default CAs.
Some servers will require you to have a client certificate to prove your own identity. In this case, you will want to tell Subversion where to find that file, too. Subversion looks for the client certificate in the location pointed to by thessl-client-cert-fileoption (if there is no such option listed, it will ask you for the certificate when you run the client). Additionally, you may need to tell Subversion which type of certificate you are providing it, using thessl-client-cert-typeoption, which takespemorpkcs12as valid values. If your client key isn’t stored in the same file as your client certificate, you may also need to tell Subversion where to find it, using thessl-client-key-fileoption. If your cer- tificate requires a passphrase, you may also want to place that in yourserversfile, using the optionssl-client-cert-passwordoption. Be careful though. As with the HTTP- proxy password, this will be stored in plain text, so you need to take steps to secure the
serversfile itself.
Security is always a good idea, and in general it’s a bad idea to turn off the built-in security safeguards that Subversion provides when authenticating a certificate—especially because Subversion can be directed to allow unknown certificates on a case-by-case ba-
“svnbook” — 2005/4/14 — 14:55 — page 104 — #125
i i
104 Chapter 7 Configuring the Client
sis, after prompting for your approval. That said, we’re all adults here, and sometimes, even with the best intentions of having a secure environment, the practical reality of things means that you need to cut some security to improve usability. To that end, Subversion provides you with a few options that you can use to relax your communications to an SSL- enabled server. If a server has a certificate that is self-signed (or otherwise signed with a certificate authority you can’t check), you can direct Subversion to ignore the unknown certificate authority by setting thessl-ignore-unknown-ca option toyes. Similarly, if you are accessing a machine that has an incorrectly dated certificate, you can set the
ssl-ignore-invalid-dateoption toyesin order to direct Subversion to accept the cer- tificate anyway. And finally, if the host that a server is reporting as its location doesn’t match the certificate for that server, you can direct Subversion to allow the mismatch using
ssl-ignore-host-mismatch(again, set toyes).
To help tie all of this together, here is a sampleserversfile, showing a setup that you might use for setting up some sane global SSL options, along with a group that overrides those settings for a couple of local area network servers that have certificates that are not kept properly up-to-date.
[groups]
UnkemptServers = moe.localnet curly.localnet [UnkemptServers] ssl-ignore-unknown-ca = yes ssl-ignore-invalid-date = yes [global] ssl-trust-default-ca = yes ssl-authority-files = /home/bill/.ssl/localCA.pem ssl-client-cert-file = /home/bill/.ssl/myCert.pem
ssl-client-cert-password = mI^paSs-42 # this is the password, # not an encrypted version
7.3
Summary
In this chapter, you’ve seen the configuration files that are available for configuring Subver- sion. Both of the configuration files,configandservers, were discussed, along with the options that you can set in each file. You saw how to configure authentication and proxies, as well as several other Subversion options, such as the default editor and diff command.
In the next chapter, you will see how to make interacting with Subversion easier by using a number of different external tools to integrate Subversion with the GUI and the development environment.