Download svnserve

It's also possible, of course, for the client to be externally authenticated via a tunnel agent, such as ssh. In that case, the server simply examines the user it's running as, and uses this name as the authenticated username. As you've already guessed, a repository's svnserve. When used in conjunction with other supplemental files described in this section, this configuration file offers an administrator a complete solution for governing user authentication and authorization policies.

Let's walk through these files now and learn how to use them. For now, the [general] section of svnserve. Begin by changing the values of those variables: choose a name for a file that will contain your usernames and passwords and choose an authentication realm:.

The realm is a name that you define. The password-db variable points to a separate file that contains a list of usernames and passwords, using the same familiar format. The value of password-db can be an absolute or relative path to the users file. On the other hand, it's possible you may want to have two or more repositories share the same users file; in that case, the file should probably live in a more public place. The repositories sharing the users file should also be configured to have the same realm, since the list of users essentially defines an authentication realm.

Wherever the file lives, be sure to set the file's read and write permissions appropriately. If you know which user s svnserve will run as, restrict read access to the users file as necessary. There are two more variables to set in the svnserve.

The variables anon-access and auth-access can be set to the value none , read , or write. The example settings are, in fact, the default values of the variables, should you forget to define them. If you want to be even more conservative, you can block anonymous access completely:.

To make use of this feature, you need to define a file containing more detailed rules, and then set the authz-db variable to point to it:. Note that the authz-db variable isn't mutually exclusive with the anon-access and auth-access variables; if all the variables are defined at once, all of the rules must be satisfied before access is allowed. However, if your server and your Subversion clients were built with the Cyrus Simple Authentication and Security Layer SASL library, you have a number of authentication and encryption options available to you.

It adds generic authentication and encryption capabilities to any network protocol, and as of Subversion 1. It may or may not be available to you: if you're building Subversion yourself, you'll need to have at least version 2.

The Subversion command-line client will report the availability of Cyrus SASL when you run svn --version ; if you're using some other Subversion client, you might need to check with the package maintainer as to whether SASL support was compiled in. Certain mechanisms may or may not be available to you; be sure to check which modules are provided.

Normally, when a subversion client connects to svnserve , the server sends a greeting that advertises a list of the capabilities it supports, and the client responds with a similar list of capabilities. If the server is configured to require authentication, it then sends a challenge that lists the authentication mechanisms available; the client responds by choosing one of the mechanisms, and then authentication is carried out in some number of round-trip messages.

If server and client were linked against SASL, a number of other authentication mechanisms may also be available. However, you'll need to explicitly configure SASL on the server side to advertise them. To activate specific SASL mechanisms on the server, you'll need to do two things.

First, create a [sasl] section in your repository's svnserve. Second, create a main SASL configuration file called svn. Note that this is not the svnserve. On a Windows server, you'll also have to edit the system registry using a tool such as regedit to tell SASL where to find things. Because SASL provides so many different kinds of authentication mechanisms, it would be foolish and far beyond the scope of this book to try to describe every possible server-side configuration.

It goes into great detail about every mechanism and how to configure the server appropriately for each. For example, if your svn. A system administrator can then use the saslpasswd2 program to add or modify usernames and passwords in the database:. Also, due to a shortcoming in SASL, the common realm must be a string with no space characters.

Finally, if you decide to go with the standard SASL password database, make sure the svnserve program has read access to the file and possibly write access as well, if you're using a mechanism such as OTP. This is just one simple way of configuring SASL. Consult the full SASL documentation for details. Remember that if you configure your server to only allow certain SASL authentication mechanisms, this forces all connecting clients to have SASL support as well. SASL is also able to perform data encryption if a particular mechanism supports it.

To enable or disable different levels of encryption, you can set two values in your repository's svnserve. The min-encryption and max-encryption variables control the level of encryption demanded by the server. To disable encryption completely, set both values to 0. To enable simple checksumming of data i.

If you wish to allow—but not require—encryption, set the minimum value to 0, and the maximum value to some bit length. To require encryption unconditionally, set both values to numbers greater than 1. In our previous example, we require clients to do at least bit encryption, but no more than bit encryption.

On the other hand, some administrators already have well-established SSH authentication frameworks in place. It's easy to use SSH in conjunction with svnserve. In this example, the Subversion client is invoking a local ssh process, connecting to host. If the client performs a commit, the authenticated username harryssh will be used as the author of the new revision.

The important thing to understand here is that the Subversion client is not connecting to a running svnserve daemon. This method of access doesn't require a daemon, nor does it notice one if present.

It relies wholly on the ability of ssh to spawn a temporary svnserve process, which then terminates when the network connection is closed. The Subversion client often makes multiple connections to the repository, though users don't normally notice this due to the password caching feature.

The solution is to use a separate SSH password-caching tool such as ssh-agent on a Unix-like system, or pageant on Windows. Note also that this list does not include distributions of larger collections of software of which Subversion is but one piece.

Several vendors offer such things, but we concern ourselves primarily with Subversion itself. As such, the listing here is limited to those packages which may be reasonably considered binary distributions of Apache Subversion alone. A condition to be listed is to keep current with security fixes by offering the latest supported patch release or by backporting security patches. The rule will be implemented with a fair amount of flexibility to allow time to release new packages, as well as any considerations regarding the release process.

Please discuss at the Subversion users mailing list. CollabNet supported and certified by CollabNet ; requires registration. Subversion is an open source version control system.

Founded in by CollabNet, Inc. Subversion has enjoyed and continues to enjoy widespread adoption in both the open source arena and the corporate world. Subversion is developed as a project of the Apache Software Foundation , and as such is part of a rich community of developers and users.

We're always in need of individuals with a wide range of skills, and we invite you to participate in the development of Apache Subversion. Here's how to get started. For helpful hints about how to get the most out of your visit to this site, see the About This Site section below.

Subversion exists to be universally recognized and adopted as an open-source, centralized version control system characterized by its reliability as a safe haven for valuable data; the simplicity of its model and usage; and its ability to support the needs of a wide variety of users and projects, from individuals to large-scale enterprise operations.

The Subversion project has decided to move the official IRC channels to libera. The recent releases of Apache Subversion 1. We encourage server operators to upgrade to the latest appropriate version as soon as reasonable. Please see the release announcements for more information about the releases.

To get the latest release from the nearest mirror, please visit our download page. We are pleased to announce the release of Apache Subversion 1. This is the most complete Subversion release to date, and we encourage users of Subversion to upgrade as soon as reasonable.

Please see the release announcement and the release notes for more information about this release.