We've kept TLSv1 in the list of defaults for a long while. The reason for this was that old Java IDE's would not be able to function with GitLab. However, the time has moved on and so should we.
I propose we remove TLSv1 from the list of default protocols for GitLab 10.
@joshlambert I tried to find that too but it is nearly impossible. But to make it clear, we should just remove it from defaults and write documentation on how the issue manifests itself. Users will still be able to change the setting (unless they are GitLab.com users).
@marin maybe we could just quick grab Eclipse w/ EGit and Intellij (or whatever other tools were problematic) and validate?
I think it would be good to know ahead of time what trouble to expect here, and what guidance we can provide. For example, if you upgrade to X.Y.Z version it will work.
@mydigitalself, adding you for the GitLab.com perspective.
In a nutshell, we still by default allow TLSv1 which is a security concern. We tried to disable 2 years ago, but pushback from users of Java IDE's was strong as apparently they didn't support TLSv1.1 yet.
For security reasons we'd like to try to take the opportunity with 10.0 and turn off TLSv1. Obviously on-prem users have the benefit of being able to simply flip it back on again.
With IntelliJ I was able to checkout, modify, and push to a repo with TLSv1 disabled. (1.1 minimum)
With Eclipse I kept getting errors, but it seemed more project related than anything else. Eclipse was able to connect and retrieve the branches of my repo, so TLS did work.
Did I miss any other popular Java IDE's? I think these are the main two from my recollection.