In commit 08998d6 of PR git-lfs#5779 we
updated our Git credential helper test program to reflect the new
support in Git v2.46.0 for authentication schemes other than those
using usernames and passwords, specifically by accepting input
lines with the "capability[]" key and replying with similar lines
as appropriate.

In particular, if the client sends one or more "capability[]" lines,
we check their values against the list of capabilities our helper
program supports, which at the moment is just the "authtype" and
"state" capabilities.  If any matches are found, we include those
in "capability[]" lines in our reply, excluding any capabilities
the client announced but which our program does not support.

At the moment, we do this by first overwriting the "capability[]"
entry in the map of key/value pairs we created from the client's input,
and then copying that entry into the "return" map of key/value pairs
we will send back to the client.  Finally, we make sure to output
the values from the "capability[]" entry in that map before sending
the values of all the remaining entries.  (Note that each entry
in these maps may have multiple values.  If a key is multi-valued,
we send each value on a separate line in the output.)

We can simplify our handling of these "capability[]" lines somewhat
by skipping the step where we overwrite the entry in the map of
input lines, and also by not making a copy of the values we intend
to return into the "result" map.  Instead, we can just return the
filtered set of capabilities we support from our discoverCapabilities()
function, and then output the values from that set first before
sending the values from our "return" map.

This does mean that we only pass the filtered set of capabilities
to the Serialize() method of our "credential" structure, instead of
the full set received from the client.  But this change has no
functional impact because that method only needs to check for
the capability types we support ("authtype" and "state"), so those
will always be in the filtered set of capabilities, assuming the
client sent them to us.

At present, our credential helper test program echoes a number of
identifying input lines back to the client, including the "host",
"protocol", and "path" lines (as well as certain "capability[]" lines
when those are appropriate).

However, common credential helper programs such as Git's own
git-credential-store and the git-credential-osxkeychain helper for
macOS generally avoid echoing such input lines back to the client,
with the exception of "capability[]" lines where the helper is
confirming which of the client's announced capabilities it supports.

This is roughly in line with the advice in Git's documentation,
which recommends against helpers overriding the values sent by clients,
other than for "username" and "password" fields.

  https://github.com/git/git/blob/4590f2e9412378c61eac95966709c78766d326ba/Documentation/gitcredentials.txt#L288-L290

Of course, just echoing the client's data back will cause no
functional difference in the client's behaviour, and is not a case
where the helper is overriding the data provided by the client with
different values.

Nevertheless, we can simplify our helper's logic and output, and
bring its operation into closer alignment with that of actual
credential helper programs, if we do not echo the "host", "protocol",
and "path" fields back to the client.  This also allows us to
exit early in the case where there are no fields to return other
than possibly some "capability[]" ones.

Our credential helper test program looks for a credential record file in
the directory specified by the CREDSDIR environment variable, using the
values of the "host" and, if provided, "path" fields from the input lines
sent by a client.  At the moment, the correct construction of the paths
and names of the files which the program then tries to open depends on
the path in the CREDSDIR environment variable ending with a slash
character.

While our test suite always supplies a path with a trailing slash in
the CREDSDIR variable, the requirement to do this adds a small amount of
friction when debugging or testing our helper program.  By refactoring
the credsForHostAndPath() function in the program, we can both remove
the necessity for a trailing slash on the CREDSDIR path and clarify
the logic by which the function constructs file names and paths,
so we do that now.

Due to the issue described in git-lfs#5658, the "clone ClientCert" test in our
t/t-clone.sh test script does not actually run to completion, because
it exits early due to an improper check of the TRAVIS variable (which
is, itself, 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 test will run fully, exposing a number of long-standing problems
with the test.  One of these occurs on Windows when the test checks the
use of a TLS/SSL client certificate with an encrypted client key file.
This check was added in commit 706beca
of PR git-lfs#3270 in 2018, but may never have been fully validated since then.

Our Windows CI jobs run in the Git Bash environment provided by the
Git for Windows project, which in turn is based on the MSYS2 environment.
In this context, when we set the "http.<url>.sslCert" Git configuration
value in our setup() shell function in t/testhelpers.sh, the command-line
argument with the path to the certificate file is converted by the MSYS2
environment into a Windows-style path with a leading volume identifier.

When Git later makes a request to our credential helper test program to
retrieve the passphrase for the encrypted key, it passes this path in the
input "path" field.  Our helper program then converts this path into a
filename by replacing slash characters with dashes, and looks for a
matching credential record file.  However, we have created this file
in the setup_creds() shell function using the Unix-style path in the
LFS_CLIENT_KEY_FILE_ENCRYPTED environment variable we populate in
our t/testenv.sh script.  As a result, our credential helper program
is unable to find the record file with the passphrase for the encrypted
key, and Git then attempts to prompt the user for it, which also fails
because our CI jobs run in a context without a terminal prompt, and
the "clone ClientCert" test fails as a consequence.

In theory we might work around this problem by setting the
MSYS2_ARG_CONV_EXCL environment variable with a "*" value before
calling "git config" to set the "http.<url>.sslCert" configuration
value, as this would prevent MSYS2 from rewriting command-line arguments
which look like Unix-style paths.  Unfortunately, this introduces
other failures into our test suite on Windows.

Instead, we work around the problem by performing a simple
Windows-to-Unix path translation in our credential helper test program.
As we note in a code comment, a more comprehensive solution might
invoke the "cygpath" utility to perform the path conversion.  But
as we only need to perform this translation step in a single test
in our Windows CI jobs, for the deprecated "git lfs clone" command,
for now we just look for paths which start with an uppercase volume
identifier such as "D:" and replace them with a lowercase version
which starts with a leading slash, like "/d".  This is sufficient to
resolve the problem in our current Windows CI jobs on GitHub Actions
runners.

Our lfstest-gitserver test utility program was updated in commit
daba49a of PR git-lfs#1893 to help test
Git LFS's support for the use of client TLS/SSL certificates, and as
part of this change, the program was adjusted to write out several
new files upon startup with the values of the client certificate,
key, and URL to be used when testing this Git LFS feature.

In practice, the names of these files are always supplied by our
test scripts in LFSTEST_CLIENT_* environment variables, as defined
in our t/testenv.sh script and then passed to our lfstest-count-tests
test utility program in the setup() shell function that is run at the
start of every test script.  The lfstest-count-tests program then
invokes the lfstest-gitserver program, when necessary, and so the
lfstest-gitserver program inherits the LFSTEST_CLIENT_* environment
variables and uses the filenames defined by them.

However, should the lfstest-gitserver program be started manually,
without all of these environment variables, it will use a set of
default filenames for the files it creates after starting.  Two
of these default filenames are identical, specifically the default
names of the files containing the URLs the tests should use to contact
the test server when validating regular TLS/SSL behaviour and TLS/SSL
behaviour with a client certificate.  As such, the URL for the former
would be unavailable, as the file containing it would be overwritten
by the file containing the latter's URL.

We correct this minor issue now by defining a unique default name for
the file which contains the URL the tests should use when validating
TLS/SSL behaviour with a client certificate.  Note again, though, that
this makes no difference in the context of our test suite as it always
supplies unique, non-default values for all these files' names in its
environment variables.

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.

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

As well, since the "clone ClientCert with homedir certs" test was added
in commit c54c9da, as part of PR git-lfs#5657,
we have skipped executing it on Windows.  We do this to avoid an error
when Git attempts to retrieve the encrypted key of the test's client
TLS certificate from our git-credential-lfstest test utility program.

We will address the first issue in subsequent commit in this PR, at
which point the tests will run fully, exposing a number of long-standing
problems with the "cloneSSL" and "clone ClientCert" tests.

One of these problems occurs on Windows, where by default, Git uses the
Secure Channel (SChannel) backend for TLS/SSL verification in libcurl.
However, Schannel's CertGetNameString() function rejects the TLS
certificate of our lfstest-gitserver program because we connect to the
server on the local IP address 127.0.0.1, and although the certificate
lists that address in an IPAddress field among its Subject Alternative
Name (SAN) attributes, the Schannel library only looks for hostname
matches with the DNSName fields and ignores any IPAddress fields.
As a result, Git returns a "failed to match connection hostname
(127.0.0.1) against server certificate names" error, as produced by
libcurl.  Since version 8.9.0 of libcurl the CertGetNameString() function
is called with the CERT_NAME_DNS_TYPE option, which is documented to have
this behaviour:

  https://github.com/curl/curl/blob/5040f7e94cd01decbe7ba8fdacbf489182d503dc/lib/vtls/schannel_verify.c#L577-L582
  https://github.com/curl/curl/blob/5040f7e94cd01decbe7ba8fdacbf489182d503dc/lib/vtls/schannel_verify.c#L373-L378
  https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certgetnamestringw#cert_name_dns_type

The TLS certificate presented by our lfstest-gitserver program 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

While it does include a DNSName field in its SAN list with the hostname
"example.com", attempting to use this in our tests would involve forcing
both Git and Git LFS to override the available system DNS resolution.
For Git LFS in particular, there does not appear to be, at the moment,
a straightforward way of overriding the DNS resolution of the Go
language's "net" package in a cross-platform and convenient manner.

Instead, with recent versions of Git and libcurl, we can bypass this
problem by setting the "http.sslBackend" Git configuration option
to "openssl", and thereby forcing the use of OpenSSL in place of
Schannel in libcurl.  This option has been available since commit
git/git@21084e8 in Git version 2.20.0,
and is supported so long as libcurl's version is 7.56.0 or above.
Since our CI jobs on Windows are executed on GitHub Actions, where the
pre-installed Git for Windows releases are kept current, we can make
use of this Git option in our tests when TLS certificate validation
is required.

Note that this option does not affect how Git LFS behaves, because it
uses the TLS validation provided by the Go "net/http" and "crypto/tls"
packages.  Also, because the intent of our tests is to confirm correct
behaviour of Git LFS and not Git, using OpenSSL instead of Schannel
to ensure Git accepts our test server's TLS certificate on Windows
does not compromise the integrity of our tests.  (Further, having our
tests actually run to completion will be a significant improvement over
the current state, where they trivially pass in all circumstances due
to the bug in our conditional check of the TRAVIS variable.)

As for the problem mentioned earlier regarding the reason we skip the
"clone ClientCert with homedir certs" test on Windows, this also stems
from the use of the Schannel backend.  Specifically, Git reports the
error "refusing to work with credential missing host field" when
libcurl uses the Schannel library, and so we have always skipped this
test on Windows.

When we enable the "clone ClientCert" test, by removing the check on
the TRAVIS variable, it too will report the same error.

We can again resolve this problem for both tests by switching to the
OpenSSL backend, as noted in a discussion on the Git mailing list:

  https://lore.kernel.org/git/TY0PR06MB54426B92E745B3035F0CC2DFD197A@TY0PR06MB5442.apcprd06.prod.outlook.com/

So for these tests we also set the "http.sslBackend" Git configuration
option to "openssl" when executing them on Windows.  Notably, this will
allow the "clone ClientCert with homedir certs" test to run successfully
on that platform for the first time since it was introduced.

In commit cdec9f2 of PR git-lfs#5699 we
updated two tests in our t/t-clone.sh test script to ensure they
add and commit the ".gitattributes" files created by "git lfs track"
before proceeding to generate commit data with Git LFS objects.
Per the commit description, this change was made so as to be explicit
about the order of expected Git operations, and to avoid relying
on the "git lfs clone" command to search for Git LFS pointer files
in the current Git working tree.

However, two other tests in the same test script have not run for
a long time, due to the bug described in git-lfs#5658, where an improper
check of the TRAVIS variable causes the tests to exit early and
always declare success.  Hence, the need to make corresponding
changes to ensure these tests also explicitly add and commit
their ".gitattributes" files was not clear at the time when
commit cdec9f2 was written.

We will enable these skipped tests in a subsequent commit in this PR,
at which time they will fail unless we also adjust them to call
"git add" and "git commit" on their ".gitattributes" files, so we
do that now.

We also take the opportunity to make matching changes to a third
pair of tests, the "clone ClientCert with homedir certs" and "clone
with flags" tests, although these do run fully and successfully now.
While they do not depend on the ".gitattributes" file being committed
to their respective test repositories, aligning their code with that
of the other tests in the same test script may help avoid problems
in the future.

In commit db4e3b2 of PR git-lfs#2811 we
updated the progress meter text of the Git LFS client from "Git LFS"
to the more explicit "Uploading LFS objects" or "Downloading LFS
objects".  A large number of tests were changed in the same commit
because they check the progress meter output in logs they capture
from Git LFS operations.

However, the "cloneSSL" test in our t/t-clone.sh test script was not
updated because it has not actually run to completion for a long time,
as described in git-lfs#5658, so it did not fail when the progress meter text
changed.  Due to a bug in the conditional used to check the TRAVIS
variable, the test instead always exits early and declares success.

We will address this problem in a subsequent commit in this PR,
at which point the test will fail unless we adjust it to check
for the same progress meter text as all our other tests, so we do
that now.

We also take the opportunity to add a similar check of the same
progress meter message to the "clone ClientCert" test.  This brings
our tests in the t/t-clone.sh script into slightly closer alignment
with each other, which should help ensure they stay consistent in
the future.  (Note that this test does not run to completion at the
moment either, for the same reason as the "cloneSSL" test.)

In commit caaa0f9 of PR git-lfs#2647 a
number of tests of the "git lfs clone" and "git lfs pull" commands
were enhanced so as to check that after those commands are invoked,
the "git status" command returns a "working tree clean" message.
To perform these checks, a call to our assert_clean_status()
shell function was added to the tests.

In the case of the "cloneSSL" test, an assert_clean_status() call
was added, but left commented out; it was then uncommented in commit
e0eede1 of the same PR.  Unfortunately,
the call is made when the current working directory has not yet been
changed to that of the newly cloned repository's working tree, and
so should fail as it stands now.

However, as described in git-lfs#5658, the "cloneSSL" test and the "clone
ClientCert" tests in our t/t-clone.sh test script do not actually
run to completion, 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).  Instead, the tests exit early and
always declare success.

We will address this problem in a subsequent commit in this PR, and when
we do so, the "cloneSSL" test will fail because the misplaced assertion.
Therefore we move the assertion into the block of checks performed
after a "pushd" shell command changes the current directory to that
of the new clone's working tree, which will allow the test to pass
when we resolve the bug with the TRAVIS variable check.

We also take the opportunity to add assert_clean_status() calls to a
number of other tests in the t/t-clone.sh test script, so the tests are
all performing similar sets of checks.  This will help us keep the
tests in that script more consistent with each other in the future.

In commit d2c1c0f of PR git-lfs#1067 the
"cloneSSL" test in what is now our t/t-clone.sh test script was changed
with the intent that the test should be skipped when it was run by the
Travis CI service.  The commit description from that time notes that
we could not determine why the test was failing on just that platform,
so the decision was made to simply ignore the test in the Travis CI
environment.

Subsequently, similar checks were added to three other tests.  First,
the "clone ClientCert" test was introduced in PR git-lfs#1893, and since
commit b471566 in that PR it has
included an initial check for a Travis CI environment with the intent
of skipping the test when it is run there.

Next, in commits 9da65c0 of PR git-lfs#2500
and e53e34e of PR git-lfs#2609 the "askpass:
push with core.askPass" and "askpass: push with SSH_ASKPASS" tests
in what is now our t/t-askpass.sh test script were amended to also
skip executing in the Travis CI context.

In the case of the latter two tests, this check works as designed;
however, in the case of the two tests in t/t-clone.sh, the check is
written as a simple "if $TRAVIS" shell statement, rather than one
which uses a shell test command or builtin (i.e., "test" or "[" or
"[[").  As described in git-lfs#5658, the result is that when the TRAVIS
variable is undefined, these statements always succeed, and so their
conditional blocks run, meaning these tests are skipped on every
platform and system.

In previous commits in this PR we have addressed all the latent bugs
that have accumulated in these tests since this problem was first
introduced, and so we are now in a position to remove both the valid
and invalid checks for the TRAVIS environment variable from all four
of the tests.  This will ensure that our CI jobs always run the
entire set of tests from both of the t/t-askpass.sh and t/t-clone.sh
test scripts.

In PR git-lfs#1893 we introduced support for TLS client certificates, and
while that was largely successful, some of our CI test jobs ran on the
Travis CI platform, and those encountered problems when validating the
TLS certificate generated by our lfstest-gitserver test utility program.
Several attempts were made to resolve this issue, but ultimately in
commit 1cf7d6b the "http.<url>.sslVerify"
Git configuration value was set to "false" for our entire test suite,
just to allow the "clone ClientCert" test to pass in the Travis CI
environment.

However, we no longer use the Travis CI service, as we migrated our
CI jobs to GitHub Actions in PR git-lfs#3808.  Further, in a prior commit in
this PR we revised several tests in our t/t-clone.sh test script so
they do not run on the legacy CentOS 7 platform, where the libcurl
library used by Git depends on the libnss3 library.  The libnss3 library
does not accept the TLS certificate generated by our lfstest-gitserver
program, so these tests would otherwise fail on CentOS 7 if the
"http.<url>.sslVerify" option is set to "true".

As well, in another commit in this PR we altered the same tests in our
t/t-clone.sh test script to require that Git and libcurl use OpenSSL for
TLS verification on Windows, rather than the default Schannel backend.
This will prevent the tests from failing if TLS verification is enabled,
since Schannel rejects the TLS certificate that we use in our
lfstest-gitserver test utility, but OpenSSL accepts it.

With these changes, all our tests should now pass if we allow the
"http.<url>.sslVerify" Git configuration option to default to "true".
Therefore we now remove the command which set that option to "false"
for our whole test suite.

In prior commits in this PR we addressed a number of problems in our
test suite in order to fully enable all the tests in our t/t-clone.sh
test script, which previously did not run to completion, as described
in git-lfs#5658.

In one commit we updated our git-credential-lfstest test utility program
so it performs a simple Windows-to-Unix path translation on the path
provided by Git when it makes a credential helper request to the program.
In the case of the "clone ClientCert" test in our t/t-clone.sh test
script, this path is the one we set in the "http.<url>.sslCert" Git
configuration value, and in the Git Bash environment we use in our
Windows CI jobs, the MSYS2 environment has converted this path into a
Windows-style one.  However, in order to locate the appropriate
credential record file, our test credential helper requires a path that
matches the Unix-style one we used when setting up those record files.

We therefore adjusted the git-credential-lfstest program to simply look
for a leading uppercase Windows volume identifier like "D:" and convert
it into a lowercase version with a leading slash character like "/d".

In another commit we revised our lfstest-gitserver test utility program
so that after it generates the encrypted TLS certificate key that is
used in our "clone ClientCert" test, it converts the DEK-Info header
of the certificate key to use uppercase hexadecimal digits rather
than lowercase ones.  This resolves a problem in which the test fails
on our Debian build target platforms (Debian 10, 11, and 12) because
the GnuTLS library used by libcurl and therefore also by Git is older
than v3.8.0 and lacks support for lowercase hexadecimal strings in
its parsing of DEK-Info headers.

As suggested by larsxschneider in PR review, we can clarify the intent
of both of these sections of code where we convert bytes from lowercase
to uppercase, or vice versa, by using the standard Go library functions
to perform the conversions, so we do that now.