- removed comment
GetComponents needs to come with (a selected few) trusted certificates
Issue #1812
wontfix
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.
Keyword:
Comments (8)
-
reporter
-
- removed comment
This can be a bit dangerous in case this happens on a user's workstation and they later run svn directly on the command line (eg svn update) and then receive the svn error message. We should output some information that a certificate file was created along with instructions for users to use it.
Instead of an svn option you can set the SSL_CERT_FILE environment variable (in GetComponents before calling svn) and point it to the proper file (works on OSX's svn 1.7 and 1.8 from macports and on my linux workstation). Git supports a sslcainfo option in the http section of its config file so at least for git we can try and see if it allows the system certificates to be supplemented by the ones GetComponents provided on a per repository basis.
The alternative (which I'd prefer) would of course be to get a ssl certificate from a common/old enough root authority that is supported by all systems we care about.
-
reporter
- removed comment
Using the environment variable is an interesting idea, but it assumes we can set it for all the future sessions of the user. Otherwise we would be back to square one for a subsequent 'svn update'. Subversion also lets you specify this without environment variable in it's user (or system) wide config files, but I didn't really want GetComponents mess with that. I would rather have the user deal with accepting the certificate if she updates later by hand.
Getting a cert from an old enough root CA might be difficult/impossible. First, the old certs might be insecure (SHA-1), or you simply have to way to specify the chain yourself, or even change the certificate itself, like on a public hosting system.
-
- removed comment
The reason I suggested using the environment variable is that this also work with versions of subversion that do not support the servers:global:ssl-authority-files option such as the stock OSX subversion client where I ran into this. I don't know on top of my head if my linux workstation accepted the option. The current version from homebrew accepts the option.
The SSL environment option seems to be actually parsed by openssl and not subversion itself.
Do we still need to worry about pre-1.6 subversion anywhere (any cluster)?
-
reporter
- removed comment
Replying to [comment:4 rhaas]:
The SSL environment option seems to be actually parsed by openssl and not subversion itself.
That's right. As I said, this is not a svn problem. It's either openssl or gnutls complaining, depending on what library clients are using.
Do we still need to worry about pre-1.6 subversion anywhere (any cluster)?
I guess we have to.
-
- removed comment
This is connected to
#1801. There seems to be nothing to actually review in this ticket. -
This seems to no longer be happening and since all of our repos are now on bitbucket or github we can expect that their certificates are accepted by all systems we encounter.
Unless there are objections I will close this ticket with 'wontfix' sometime next week.
-
- edited description
- changed status to wontfix
- Log in to comment
- Assignee
- –
- Type
- Priority
- Status
- wontfix
- Component
- GetComponents
- Milestone
- –
- Version
- development version
- Votes
- 0
- Watchers
- 0
Before implementing this I would like to have feedback.