| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Currently, we perform a request to Gitlab Rails that proxies
the request to primary
However, it causes timeouts on big pushes and consumes large
amount of memory. We can perform an HTTP request directly
from Gitlab Shell instead and stream the response to the user
|
| |
|
|
|
|
|
|
|
|
|
| |
Gitaly started to require `Repository` information for certain
commands like upload-pack, upload-archive, and receive-pack.
However, gitlab-shell tests are sending `git_object_directory` and
`git_alternate_object_directories` that do not exist.
To fix the tests, we set those to an existing directory in the
created repository.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for specifying host certificates via the
`host_cert_files` option and advertises the signed key to the
client. This acts similarly to OpenSSH's `HostCertificate` parameter:
gitlab-sshd attempts to match a host key to its certificate, and then
substitutes the matching host key with a certificate signed by a
trusted certificate authority's key.
This is the first requirement to supporting SSH certificates. This
will enable the client to trust the server if both trust a common
certificate authority. The `TrustedUserCAKeys` option will need to be
supported later for the server to trust all user keys signed by this
certificate authority.
Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/495
|
| |
|
|
|
|
|
|
| |
Issue: https://gitlab.com/gitlab-org/gitlab-shell/-/issues/576
ProxyHeaderTimeout must be small to avoid DoS risk
Let's make the value configurable and 500ms by default
|
| |
|
|
|
| |
- If an integer is specified, we assume that these are seconds
- A duration of format "500ms", "10s", "1m", etc... accepted
|
| |
|
|
|
|
|
| |
Before this change, the GitLab internal API could use a boolean
response field to indicate whether gitlab-shell should make
sidechannel connections go Gitaly. We now ignore that response field
and always use sidechannel connections.
|
| |
|
|
|
|
|
| |
If the GitLab API returns an allowed response with use_sidechannel set
to true, gitlab-shell will establish a sidechannel connection and use
SSHUploadPackWithSidechannel instead of SSHUploadPack. This is an
efficiency improvement.
|
| |
|
|
|
|
| |
This field will act as a feature flag that controls whether
gitlab-shell uses the old SSHUploadPack RPC or the new
SSHUploadPackWithSidechannel.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Logrus buffers its output internally, which makes these tests fail
intermittently. They're also not a good example to follow generally.
We now have acceptance tests that exercise this functionality so I'm
pretty relaxed about losing the expectations. However, we can test
them by inspecting the server-received metadata too, so there's no loss
of coverage here.
The move from logrus to labkit for logging also makes these tests hard
to justify keeping.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
In this case we don't need to propagate cleanup
function. It simplifies the code.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now when a client such as gitlab-shell calls the
`/api/v4/internal/allowed` API, the response only tells the client what
user has been granted access, and it's impossible to tell which deploy
key/token was used in the authentication request.
This commit adds logs for the following when available:
1. `gl_key_type` (e.g. `deploy_key` or `key`)
2. `gl_key_id`
These fields make it possible for admins to identify the exact record
that was used to authenticate the user.
API changes in the `/internal/allowed` endpoint in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37289 are needed
to support this.
Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/203
|
| |
|
|
|
|
|
|
|
| |
logrus fires a Goroutine to write logs, so the tests could fail if they
checked the event queue before the logrus have fired. Since there isn't
an easy way to flush all outstanding hooks, we just retry every 100 ms
for up to a second for log to arrive in the queue.
Closes https://gitlab.com/gitlab-org/gitlab-shell/-/issues/450
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
We'll reuse this module for uploadpack in the future
|
| |
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
| |
Add support for Gitaly feature flags
See merge request gitlab-org/gitlab-shell!351
|
| | |
|
| |
|
