I've setup svnserve with SASL authentication and encryption for encrypting the traffic. Anonymous access should be allowed. My configuration file conf/svnserve.conf
(with comments stripped) looks like this:
[general]
anon-access = read
auth-access = write
realm = realm-of-repo
[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256
The related sasl configuration file:
pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: /path/to/sasldb
mech_list: DIGEST-MD5
When supplying an username and password, everything works as expected: I can checkout and make changes. However, anonymous access (no username or password) fails with the next error message:
svn: SASL(-1): generic failure: All-whitespace username.
How do I enable anonymous SVN read access using svnserve
and SASL ? I'm not looking for a solution with Apache.
The
use-sasl = true
forces authentification (tells SVN to prohibit anonymous access).You could either create a user with read-only privileges and use it for anonymous access or use http for read-only access and sasl for read-write.
I was looking for this information recently, and thought I'd share what I've found. It is possible to allow anonymous access when using SASL for authentication, but you should be aware that any anonymous access will not be encrypted or integrity protected.
You already have
anon-access = read
insvnserve.conf
, as required.Next, you will have to set
min-encryption = 0
, since the anonymous access mechanism supports neither encryption nor integrity protection. Skipping this step would make anonymous access unavailable when authentication mechanisms are negotiated.The last step is to set your SASL authentication mechanisms, in
svn.conf
(your SASL configuration file for Subversion). Change the line:mech_list: DIGEST-MD5
to
mech_list: DIGEST-MD5 ANONYMOUS
which will make the anonymous mechanism available. Restart
svnserve
, and you should be able to perform a check-out with no authentication prompt. If you are using per-directory access control, you may want to confirm that user$anonymous
has been granted the appropriate access.There are a few things to consider. As mentioned, all access done anonymously will be in clear-text, which you may not want if you are dealing with confidential code over a public network. Also, all users will perform read accesses (check-out, etc.) via anonymous access, so your logs may not be as useful for tracking. Furthermore, if you allow anonymous writes, all code will likely be committed anonymously, meaning you won't know which changes were committed by whom.
As mentioned in the comments, one option is to create an actual user called anonymous, with a simple password (it will fail without a password), and use per-directory access control to make sure only read access is granted, and only to the directories you choose. This allows you to keep encryption/integrity checking, while still offering access that is almost as convenient as true anonymous access.