- Feb 16, 2024
-
-
Ash McKenzie authored
-
Ash McKenzie authored
-
- Feb 15, 2024
-
-
Ash McKenzie authored
-
Ash McKenzie authored
-
- Feb 08, 2024
-
-
Ash McKenzie authored
-
Ash McKenzie authored
-
- Jan 29, 2024
-
-
Igor Drozdov authored
-
- Jan 18, 2024
-
-
Robert May authored
-
- Jan 02, 2024
-
-
Ash McKenzie authored
-
Ash McKenzie authored
-
- Nov 24, 2023
-
-
Ash McKenzie authored
-
- Oct 12, 2023
-
-
Harshit Prasad authored
-
- Sep 08, 2023
-
-
Stan Hu authored
This would previously fail since arm64 binaries need to be downloaded.
-
- Sep 07, 2023
-
-
Ash McKenzie authored
-
Ash McKenzie authored
-
- Sep 06, 2023
-
-
Ash McKenzie authored
-
- Aug 02, 2023
-
-
Ash McKenzie authored
-
- Jul 06, 2023
-
-
Ash McKenzie authored
-
- Jun 29, 2023
-
-
Ash McKenzie authored
-
Ash McKenzie authored
-
- Jun 16, 2023
-
-
Ash McKenzie authored
To quote 'go help test': The idiomatic way to disable test caching explicitly is to use -count=1
-
- Apr 13, 2023
-
-
DJ Mountney authored
- Otherwise this fails on some of the omnibus builder images
-
- Apr 07, 2023
-
-
Gabriel Mazetto authored
-
- Mar 07, 2023
-
-
Stan Hu authored
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.
-
- Feb 08, 2023
-
-
Ash McKenzie authored
-
Stan Hu authored
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
-
- Jan 27, 2023
-
-
Igor Drozdov authored
-
- Jun 23, 2022
-
-
Stan Hu authored
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
-
- May 05, 2022
-
-
Igor Drozdov authored
New version of LabKit provides FIPS checks that we can use instead of the custom code
-
- Apr 18, 2022
-
-
Stan Hu authored
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
-
- Feb 02, 2022
-
-
Ash McKenzie authored
-
- Sep 16, 2021
-
-
Kevin authored
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.
-
- Sep 07, 2021
-
-
feistel authored
-
- Jul 26, 2021
-
-
Stan Hu authored
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.
-
- Jul 01, 2021
-
-
Nick Thomas authored
Changelog: added
-
- May 17, 2021
-
-
Nick Thomas authored
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
-
- Apr 12, 2021
-
-
Nick Thomas authored
-
- Nov 05, 2020
-
-
Takuya Noguchi authored
Signed-off-by:
Takuya Noguchi <takninnovationresearch@gmail.com>
-
- Oct 16, 2020