You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to the issue described in git-lfs#5658, the "cloneSSL" and "clone ClientCert"
tests in our t/t-clone.sh test script do not run to completion but exit
early, as a consequence of an improper check of the TRAVIS variable (which
is no longer used since we migrated our test suite to GitHub Actions in
PR git-lfs#3808).
We will address this issue in a subsequent commit in this PR, at which
point the tests will run fully, exposing a number of long-standing
problems. One of these occurs on the legacy CentOS 7 Linux system where
the libcurl library used by Git still depends on the libnss3 library,
which has several restrictions in the types of TLS certificates it
accepts. Specifically, in our current builds on CentOS 7, libcurl
version 7.29.0 is linked against version 3.90 of libnss3.
The libnss3 library rejects certificates which have both an Extended Key
Usage attribute for TLS Web Server Authentication and a Basic Constraint
setting of "CA:TRUE", meaning the certificate is intended to be used as
a Certificate Authority:
https://security.stackexchange.com/questions/176177/why-does-curl-nss-encryption-library-not-allow-a-ca-with-the-extended-key-usage
However, certificates with both these settings are accepted by most
modern TLS libraries, and the self-signed certificate used by our
lfstest-gitserver utility program has both attributes. Note that this
certificate is the one provided by the Go language's "net/http/httptest"
package, specifically the one from the "net/http/internal/testcert"
package:
https://github.com/golang/go/blob/7529d09a11496a77ccbffe245607fbd256200991/src/net/http/internal/testcert/testcert.go#L10-L33
Thus when we enable our "clone ClientCert" test, the second part of the
test, where it checks the use of an encrypted client key, will fail
on CentOS 7 because Git on that platform is dependent on the libnss3
library for TLS certificate validation.
Moreover, we would also like to reverse the change made in commit
1cf7d6b of PR git-lfs#1893, when the
"http.<url>.sslVerify" Git configuration option was set to "false"
in the setup() shell function of our t/testhelpers.sh library. This
was done, according to the commit description, to try to get the
"clone ClientCert" test working in the Travis CI environment. We no
longer use the Travis CI service, as noted above, but independent of
that, we want to be able to run all our tests with "http.<url>.sslVerify"
set to its default value of "true".
When we set the "http.<url>.sslVerify" Git configuration option to
"true", however, three tests in the t/t-clone.sh test script (the
"cloneSSL", "clone ClientCert", and "clone ClientCert with homedir
certs" tests) will fail on CentOS 7 because libnss3 rejects the TLS
certificate provided by the Go language test server, for the reasons
described above. In these tests, libnss3 will return a "Certificate
type not approved for application" SEC_ERROR_INADEQUATE_CERT_TYPE error.
We expect to drop support for CentOS 7 soon, given that it has
reached the end of official support in all but one distribution
(SUSE Linux Enterprise Server 12 SP5, for which general support
ends on October 31 of 2024). As well, CentOS 8 and more recent
related distributions have switched away from building libcurl
against libnss3; in fact, support for that TLS library has been
dropped by the curl project entirely as of v8.3.0, per commit
curl/curl@7c8bae0.
Therefore, rather than try to generate a different TLS certificate
for our lfstest-gitserver utility program, we simply skip the three
affected tests when we detect that they are running on a Linux platform
where the git-remote-https binary depends on libnss3. We can remove
these exceptions later once we drop support for CentOS 7.
0 commit comments