#1812: GetComponents needs to come with (a selected few) trusted certificates ---------------------------+------------------------------------------------ Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ Most encrypted connections use some form of certificates. We use both ssl for subversion and git. The problem with certificates is that the certificate of the root CA has to be trusted by a client to be able to form a trusted connection. Otherwise users get warnings, and either cannot connect at all, or have to manually approve. We don't want both happening with GetComponents.
Root CA certificates have to be changed from time to time. They have a limited life time. In addition, there is a big movement away from SHA-1 certificates right now, as this has been found weak. The problem with that is that an updated root CA might not have it made to all (or at least most) clients at the time a user might have to trust it. Usually, root CAs are created, but not actually used for some time for that reason. Security problems like SHA-1 interfere with that. All this is nothing we can change.
So, in the light of root CAs possibly faster changing than clients update (and especially supercomputers update slowly in particular), we have to have a mechanism to make GetComponents still work 'out of the box' with these - no matter what the protocol is that actually uses it.
Right now, we only seem to have problems with svn, but in the future we might have the same problem with git (bitbuckets root CA is still using SHA-1).
For Subversion I propose the following. We ship 'too new' certificates with GetComponents (in-source, to still have one file). We then write this to a temporary file during checkout, and use the following option to svn to get it to accept it: {{{ --config-option servers:global:ssl-authority-files=<FILE> }}}
This mechanism was tested manually on one of the problematic machines (stampede), with one of the problematic certs (InCommon).
This only works for svn version 1.6 and newer. Most installations should have that. In case we encounter an older one we could disable trusted cert checking for problematic cases using --trust-server-cert.