| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
While gitlab-shell currently has a major version of v14, the module path
it exposes is not using that major version like it is required by the Go
standard. This makes it impossible for dependents to import gitlab-shell
as a dependency without using a commit as version.
Fix this by changing the module path of gitlab-shell to instead be
`gitlab.com/gitlab-org/gitlab-shell/v14` and adjust all imports
accordingly.
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
|
| |
|
|
|
|
|
|
| |
When gitlab-sshd has been introduced we've started running our
own SSH server. In this case we're able to cache and reuse
Gitaly connections and Registry.
It helps to reduce memory usage.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until recently, Gitaly was silently swallowing any errors returned by
SSH `git upload-pack` processes. Clients would still receive stderr
output and a non-zero return code, but Gitlab-Shell would receive error
as nil and log success.
With 9deaf47f1ecb00f0f36d18ee4a0fb1576f5a0efe Gitaly will now return an
error when git fails, but this causes Gitlab-Shell to print out the
GRPC error code as a message to the client:
> fatal: couldn't find remote ref not-a-real-ref
> fatal: the remote end hung up unexpectedly
> remote:
> remote:
> ========================================================================
> remote:
> remote: rpc error: code = Internal desc = SSHUploadPack: exit status 128
> remote:
> remote:
> ========================================================================
> remote:
The `remote:` text gives no additional context for the user and adds
clutter.
This commit suppresses the additional message added by Gitlab-Shell on
failure when the error type is `Internal`, returning client output to
the format it was prior to the Gitaly change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the way sshd works, gitlab-shell could be called with a single
string in the form:
```
/path/to/gitlab-shell -c key-id
```
However, due to the tightening of the regular expressions in fcff692b
this string no longer matches, so logins would fail with:
```
Failed to get username: who='' is invalid
```
This can be reproduced by changing the user's shell to point to
gitlab-shell. For example:
```
usermod git -s /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell
```
While setting gitlab-shell as the user's shell isn't officially
supported, gitlab-shell still should be able to cope with the key being
specified as the last argument. We now split the argument list and use
the last value.
Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/530
|
| |
|
|
|
|
|
|
| |
Use reflection to log the command we are about to execute, both in
gitlab-shell and gitlab-sshd. Include the environment, which has all
the context we need to understand what the command is expected to do.
Changelog: added
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
parse logic will only run if the executable accept args.
healthcheck is the only one not accepting arguments.
|
| |
|
|
|
|
|
|
|
|
|
| |
- We start supporting the "color" format for logs.
- We now respond to SIGHUP by reopening the log file.
- We now respect the log format when no log filename is specified.
Output to syslog in the event of logging system setup is preserved in
OpenSSH mode.
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
|
| |
|
|
|
|
|
| |
Refactors introspection of execution environment to rely on
per-connection state (`gitlab-shell`) or per request (`gitlab-sshd`)
Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/496
|
| | |
|
| |
|
|
|
| |
This will help determine the version of the binary particularly on Cloud
Native GitLab, where VERSION may not be shipped with the binaries.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, gitlab-shell did not pass a context through the application.
Correlation IDs were generated down the call stack instead of passed
around from the start execution.
This has several potential downsides:
1. It's easier for programming mistakes to be made in future that lead
to multiple correlation IDs being generated for a single request.
2. Correlation IDs cannot be passed in from upstream requests
3. Other advantages of context passing, such as distributed tracing is
not possible.
This commit changes the behavior:
1. Extract the correlation ID from the environment at the start of
the application.
2. If no correlation ID exists, generate a random one.
3. Pass the correlation ID to the GitLabNet API requests.
This change also enables other clients of GitLabNet (e.g. Gitaly) to
pass along the correlation ID in the internal API requests
(https://gitlab.com/gitlab-org/gitaly/-/issues/2725).
Fixes https://gitlab.com/gitlab-org/gitlab-shell/-/issues/474
|
| |
|
|
|
|
|
| |
This restores the previous behavior of logging the success and failures
of internal HTTP requests.
Part of https://gitlab.com/gitlab-org/gitlab/issues/207916
|
| | |
|
| | |
|
| |
|
