Closed ellert closed 3 years ago
Just to be sure: If we merge #146 and/or #149 before this one, do you need to rebase this one? If yes, I'd prefer to merge this one here first.
Just to be sure: If we merge #146 and/or #149 before this one, do you need to rebase this one? If yes, I'd prefer to merge this one here first.
There are no conflicts with #146. There is one common file with #149, but the changes are far apart, so either being merged before the other should not cause conflicts. No need for rebase.
Hi guys, this is great news: congratulations & thanks very much!
However, we will need to be careful with releasing the new code, as it has not been tested against production services, particularly those that have their own GSI stack, like dCache and XRootD.
I think we need to keep the maximum TLS version at 1.2 by default, so that things will keep working as before, and then we can ask for v1.3 to be tried by various teams, e.g. the FTS devs.
What do you think?
It obviously needs to be tested against other implementations. Note that TLS 1.3 requires openssl 1.1. The default version of openssl in RHEL/CentOS 7 is openssl 1.0, so any installation running on that will be limited to TLS 1.2 anyway. Whether we should set the default higher version to 1.2 can be decided later based on what testing we manage to do before the next release. This just means changing a line in gsi.conf - no changes needed to the code.
Excellent, thanks!
Make GCT compatible with TLS v1.3.
With this change I was able to rebuild all other GCT packages without changes aigainst the updated globus-gssapi-gsi that enables TLS v1.3. That is all the unit tests that are run during the package build succeeded with TLS v1.3.
Fixes #43 (added for linkage) on issues page