This would previously fail since arm64 binaries need to be downloaded.

To quote 'go help test':

The idiomatic way to disable test caching explicitly is to use -count=1

- Otherwise this fails on some of the omnibus builder images

https://gitlab.com/gitlab-org/gitlab-shell/-/merge_requests/718 will
make Go 1.19 the default for gitlab-shell. Per
https://github.com/golang/go/issues/51940, the dev.boringcrypto branch
no longer exists, and to support FIPS we need to pass along
`GOEXPERIMENT=boringcrypto`.

To do this, we just see if this `GOEXPERIMENT` is available with `go
version` rather than do some more complicated version-specific
comparison.

Since https://gitlab.com/gitlab-org/gitlab-shell/-/merge_requests/682,
Kerberos headers and libraries are needed to build gitlab-sshd.  If
they are not available, `make build` successfully compiles
`bin/gitlab-shell` but fails to build `bin/gitlab-sshd`. However,
running `make build` again would do nothing and appear to be succeed
because `bin/gitlab-shell` existed. This led to Omnibus GitLab quietly
dropping the `gitlab-sshd` binary, as seen in
https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/6446#note_1265879416.

To ensure `make build` properly fails if `bin/gitlab-sshd` cannot
be built, we make the binary an explicit build target.

Changelog: changed

While testing
https://gitlab.com/gitlab-org/build/CNG/-/merge_requests/1062, we
found `make install` was not copying the right binaries, such as
`gitlab-shell-authorized-keys-check`.

This might have originally been written with a single binary in mind
(https://gitlab.com/gitlab-org/gitlab-shell/-/issues/207).

Changelog: fixed

New version of LabKit provides FIPS checks that we can use instead
of the custom code

This commit adds support of using a FIPS-validated SSL library with
compiled Go executables when `FIPS_MODE=1 make` is run. A Go compiler
that supports BoringSSL either directly (e.g. the `dev.boringcrypto`
branch) or with a dynamically linked OpenSSL
(e.g. https://github.com/golang-fips/go) is required.

This is similar to the changes to support FIPS in GitLab Runner and in
GitLab Pages:
https://gitlab.com/gitlab-org/gitlab-pages/-/merge_requests/716

Changelog: added

If git is not available or gitlab-shell is not built in a repository, it falls back the VERSION file. That command is not properly escaped and results in the message:

> awk: cmd. line:1: Unexpected token

When you remove the `2>/dev/null`. Escape the '$' characters to solve this.

gofmt doesn't return an exit code 1 if there are matching files:
https://github.com/golang/go/issues/24230

To fix this, use the same trick we use in Workhorse to parse output.
Also add a `make fmt` step to format all the code properly.

Changelog: added

Previously, opentracing (if configured) was initialized late in the
gitlab-shell process's lifespan, coming just before making a gRPC
call to Gitaly.

By moving the opentracing initialization to be at process startup, we
make it available for the whole process lifecycle, which is very useful
to gitlab-sshd, as it means we'll only call tracing.Initialize() once
on process startup, rather than once per SSH connection.

To get this working, we need to introduce a context to gitlab-sshd.
This carries the client/service name, but also carries an initial
correlation ID. The main outcome of this is that all calls to the
authorized_keys endpoint from a given gitlab-sshd process will now
share a correlation ID. I don't have a strong opinion about this either
way.

Changelog: fixed

Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>

This will help determine the version of the binary particularly on Cloud
Native GitLab, where VERSION may not be shipped with the binaries.

Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>

This would help catch race conditions such as
https://gitlab.com/gitlab-org/gitlab-shell/-/issues/450 before merge.

We had `gitlab-shell-authorized-keys-check` and
`gitlab-shell-authorized-principals-check` as symlinks to
`gitlab-shell` before.

We determine the `Command` and `CommandArgs` that we build based
on the `Name` of the `Executable`. We also use that to know which
fallback ruby executable should we fallback to. We use
`os.Executable()` to do that.

`os.Executable()` behaves differently depending on OS. It may
return the symlink or the target's name. That can result to a
buggy behavior.

The fix is to create binaries for each instead of using a symlink.
That way we don't need to rely on `os.Executable()` to get the name.
We pass the `Name` of the executable instead.