Added some screenshots.
Review Request #1127 — Created Sept. 30, 2009 and submitted
Add repository path, SCMTool, SSH key and HTTPS certificate verification. This change introduces a number of new additions to the Repository creation/editing form and SCMTools that help ensure that the repository is configured correctly the first time. We do this by validating that the repository path is good, the SCMTool has all its dependencies installed, and that the SSH or HTTPS connection is valid and verified. Each SCMTool has lists of dependencies, both Python modules and binary executables, that are checked in the form during the validation step. If any dependencies are missing, we present the list to the user so that they must install the dependencies before saving the repository. Users should no longer be in a situation where they've configured a repository and then ended up confused later because p4 or something isn't found in the path. After SCMTool verification, we begin the repository verification. If the repository is behind an SSH connection, then we grab the host key (using the Paramiko Python module) and then see if it's known. If it's an unknown key, then we present the key to the user, much like ssh would. They can choose to indicate that they trust it (which will save in the ~/.ssh/known_hosts file), or they can go back and re-edit the repository information. If the key is a "bad" key (the key we get is different tan what is recorded in the known_hosts file) then we warn the user, indicate that it may be malicious, and show the recorded key and the new key returned. Like with the unknown key, we allow the user to indicate they trust the host, or they can go back and re-edit the info. If they trust the new key, we replace it in the known_hosts file. If the repository is on an HTTPS connection, and the certificate wasn't previously verified, then we present the certificate, along with any warnings (such as it not matching the host name or not being from a trusted certificate authority). The user is presented with the same choices as with the SSH key. Unlike the SSH support, the HTTPS support is not centralized around a common API and a known_hosts file. It is up to each SCMTool that supports certificates to handle grabbing the certificate information and to accept it. Right now, only SVN supports this. It's far more tricky with Git (and would require a dependency on curl and pyCurl), but hopefully less common as well. Once all the above is checked, we attempt to connect to the repository to verify that it is indeed a valid repository. If this fails, we present the error to the user.
Tested unknown SSH keys, bad SSH keys, and already known SSH keys. Tested HTTPS certificate verification with Subversion. Tested the following URL types on the following repository types: Bazaar: bzr://. bzr+ssh:// CVS: :pserver:, :ext: (for SSH) Git: http://, git://, ssh://, user@host:/path/, user@host:~path/, user@host/path/, /local/path SVN: http://, https://, svn://, svn+ssh:// The other types had minimal changes, so I didn't do extensive testing. Mercurial, Monotone, Clear Case and Perforce don't yet support verification. Tested both binary executable and Python module dependencies.
Condensed some lines in errors.py.
Revision 2 (+937 -152)