Skip to content

Svn

How-to

Onboarding

Windows

  1. admin creates an account:

      htdigest /srv/svn.torproject.org/svn-access/wc/private/svn-access-passwords.corp 'Tor Project Corporate SVN' $USERNAME

  2. download TortoiseSVN

  3. create directory outside the normal "User Documents" directory (say in C:\Tor) to avoid private data being sucked up in the Microsoft cloud

  4. start cloning the "corp" repository, https://svn.torproject.org/corp

  5. it will likely fail, run a cleanup routine (where?!)

  6. try again until it works

MacOS

???

Pager playbook

Failed update with 'Error running context: An error occured during authentication'

This occurs because the update goes on for too long and the digest authentication expires. The solution is to extended both the Apache2 Timeout parameter and add AuthDigestNonceLifetime 900 in the VirtualHost authentication config.

Design

Access control

Multiple people have access to the SVN server, in order:

Layer 0: "the feds"

While the virtual machine is (now) hosted on a server with full disk encryption, it's technically possible that a hostile party with physical access to the machine (or a 0-day) would gain access to the machine using illegitimate means.

This attack vector exists for all of our infrastructure, to various extents and is mitigated by trust in our upstream providers, our monitoring infrastructure, timely security updates, and full disk encryption.

Layer 1: TPA sysadmins

TPA system administrators have access to all machines managed by TPA.

Layer 2: filesystem permissions

TPA admins can restrict access to repositories in an emergency by making them unreadable. This was done on the svn-internal repository five months ago, in ticket #15949 by anarcat.

Layer 3: SVN admins

SVN service admins have access to the svn-access-policy repository which defines the other two access layers below. That repository is protected, like other repositories, by HTTPS authentication and SVN access controls.

Unfortunately, the svn-access-policy repository uses a shared HTTPS authentication database which means more users may have access to the repository and only SVN access control restrict which ones of those have actual access to the policy.

Layer 4: HTTPS authentication

The remaining SVN repositories can be protected by HTTPS-level authentication, defined by the Apache webserver configuration. For "corp-svn", that configuration file is private/svn-access-passwords.corp.

The SVN repositories currently accessible include:

  • /vidalia (public)
  • /svn-access-policy (see layer 3)
  • /corp (see above)
  • /internal (deactivated in layer 2)

Layer 5: SVN access control

The last layer of defense is the SVN "group" level access control, defined in the svn-access-policy.corp configuration file. In practice, however, I believe that only Layer 4 HTTPS access controls work for the corp repository.

Note that other repositories define other access controls, in particular the svn-access-policy repository has its own configuration file, as explained in layer 3.

Notes

The the above list, SVN configuration files are located in /srv/svn.torproject.org/svn-access/wc/, the "working copy" of the svn-access repository.

This document is a redacted version of a fuller audit provided internally in march 2020.

Discussion

SVN is scheduled for retirement, see TPA-RFC-11: SVN retirement and issue 17202.