| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
- Otherwise this fails on some of the omnibus builder images
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix CGO_CFLAGS to use output from `brew --prefix`
Closes gitlab-development-kit#1790
See merge request https://gitlab.com/gitlab-org/gitlab-shell/-/merge_requests/724
Merged-by: Ash McKenzie <amckenzie@gitlab.com>
Approved-by: Ash McKenzie <amckenzie@gitlab.com>
Approved-by: Alejandro RodrÃguez <alejandro@gitlab.com>
Co-authored-by: Gabriel Mazetto <gabriel@gitlab.com>
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename the ruby scripts to have `-ruby` suffix and add a symlink
for both to `./gitlab-shell`. The executable name will be used to
determine how args will be parsed.
For now, we only parse the arguments for gitlab-shell commands. If
the executable is `gitlab-shell-authorized-keys-check` or
`gitlab-shell-authorized-principals-check`, it'll always fallback
to the ruby version.
Ruby specs test the ruby script, the fallback from go to ruby and
go implementation of both (still pending).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
`make update-redis` will clone the library and adjust the paths properly
|
