[ET Trac] [Einstein Toolkit] #1812: GetComponents needs to come with (a selected few) trusted certificates

[Einstein Toolkit]

#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.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1812>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit