Since we're about to do a v3.0.0 release, let's bump the version to v3.
Make this change automatically with the following command to avoid any
missed items:
git grep -l github.com/git-lfs/git-lfs/v2 | \
xargs sed -i -e 's!github.com/git-lfs/git-lfs/v2!github.com/git-lfs/git-lfs/v3!g'
When our go.mod file was introduced in commit
114e85c2002091eb415040923d872f8e4a4bc636 in PR #3208, the module
path chosen did not include a trailing /v2 component. However,
the Go modules specification now advises that module paths must
have a "major version suffix" which matches the release version.
We therefore add a /v2 suffix to our module path and all its
instances in import paths.
See also https://golang.org/ref/mod#major-version-suffixes for
details regarding the Go module system's major version suffix rule.
The fix for CVE-2020-27955 was incomplete because we did not consider
places outside of the subprocess code that invoke binaries. As a
result, there are still some places where an attacker can execute
arbitrary code by placing a malicious binary in the repository.
To make sure we've covered all the bases, let's just use the subprocess
code for executing all programs, which means that they'll be secure. As
of this commit, all users of exec.Command are in test code or the
subprocess code itself.
This commit adds a new credential helper, NetrcCredentialHelper,
to retrieve credentials from a .netrc file. This replaces the
old .netrc authorization behaviour, which was done directly from
the `doWithAuth()` code.
Additionally, this commit moves all of the `.netrc` functionality
out of `lfsapi` and into `creds`. This was done both because
`creds` is now the logical place for the `.netrc` functionality,
and to prevent an import cycle between `creds` and `lfsapi`.
When using client certificates for TLS, it's possible to specify a
private key file with an encrypted private key. Previously, we silently
returned a nil Certificate object in this case which promptly resulted
in a panic in crypto/tls when attempting to push.
Instead, let's detect that the key is encrypted and prompt for a
passphrase. Git usually handles this with a prompt from OpenSSL, which
we aren't using, although it can be configured to use the credential
helper as well.
Since there isn't a portable way to turn off the echo in order to prompt
for a passphrase, even among Unix systems, let's use the credential
helper route for this purpose by prompting for credentials using a cert:
URL for the file holding the private key; this is the type of URL that
Git uses with the credential helper for this purpose.
In order to make things as intuitive as possible, tell the credential
code to always include the path for cert: URLs (so we don't just prompt
for "cert:///") and provide the user's current username in the username
field so they don't get a useless username prompt. Provide as much
helpful trace output as possible for debugging; note that credential
filling success and failure already have trace logging enabled
elsewhere.
Note that we create our own credential helper for the client object to
avoid having to pass it into the HTTP client context from the LFS API
context; this should be fine, since we're going to prompt and use this
value only within this context and for this purpose.
Finally, since we're in a context where we can't really return an error
up the chain, if for whatever reason an error occurs, ensure that we
don't pass nil to crypto/tls and instead skip passing a certificate
altogether. This will at least make the failure case obvious later on
and provide a better user experience than a panic.
In a future commit, we're going to be accessing credential handling from
multiple packages. To avoid an import loop, move credential handling
into its own package. Update all the callers of the credential handling
code to use a qualified name.
Where there is a local variable called "creds", which would conflict
with our package name, rename it "cred" instead.
