delta/gitlab/gitlab-shell.git/internal/gitlabnet/accessverifier, branch 499-log-command-invocation

refactor: move away from ioutil (deprecated)

2021-08-19T15:54:20+00:00

Refactor testhelper.PrepareTestRootDir using t.Cleanup

2021-07-14T14:43:36+00:00

fix: upgrade of the gitaly dependency

2021-06-02T08:56:45+00:00

Gitaly project now properly respects module release flow
and includes a module suffix in the package name. It requires
to re-write all non-suffixed imports with suffixed of a specific
version of tha module. With proper module versioning we don't
need to use a 'replace' directive to point to specific commit
and can use semantic versioning for the gitaly dependency.

Part of: https://gitlab.com/gitlab-org/gitaly/-/issues/3177

Respect parent context for Gitaly calls

2021-05-05T16:07:23+00:00

Without these changes, Gitaly calls would not be linked to a parent
context. This means that they would have an unassociated correlationID,
and Gitaly RPC calls would not be cancel()ed by parent context
cancellation.

Changelog: fixed

Replace cleanup functions with t.Cleanup

2021-03-17T18:23:07+00:00

In this case we don't need to propagate cleanup
function. It simplifies the code.

chore: Refactor env introspection to rely on command initialization

2021-03-15T20:47:11+00:00

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

RFC: Simple built-in SSH server

2021-01-18T18:36:25+00:00

Make it possible to propagate correlation ID across processes

2020-09-21T04:40:40+00:00

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

Generate and log correlation IDs

2020-07-31T12:58:42+00:00

This will make it easier to tie an SSH access request to Rails API and
Gitaly requests.

Log SSH key details

2020-07-23T06:19:57+00:00

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