Release v13.8.0

See merge request gitlab-org/gitlab-shell!416

Update Gitaly module dependency

See merge request gitlab-org/gitlab-shell!414

This updates Gitaly's latest Protocol Buffer definitions, which were
last updated in Feburary 2020, with the latest version of Gitaly. This
is done to ensure the definitions are in sync with Workhorse
(https://gitlab.com/gitlab-org/gitlab-workhorse/-/merge_requests/619)
and Gitaly.

Because we started tagging Gitaly versions `v13.x.x` instead of
`v1.x.x`, `go get` refuses to update the Gitaly module using the latest
tag or SHA (https://gitlab.com/gitlab-org/gitaly/-/issues/3177).  Go
tries to enforce semantic compatibility by requiring the use of module
paths (e.g. `m/v13`), and Gitaly doesn't adhere to this scheme.

To workaround this issue, we use the replace directive
(https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive):

```
go mod edit -replace gitlab.com/gitlab-org/gitaly=gitlab.com/gitlab-org/gitaly@3f5e218def93024f3aafe590c22cd1b29f744105
```

config: Set a secret example

See merge request gitlab-org/gitlab-shell!415

The config.yml.example didn't include a field I was expecting to be
there, which lead me to believe the field didn't exist. This change adds
the `secret` YAML field, and describes how it interacts with the
secrets_file.

Make it possible to propagate correlation ID across processes

Closes #474

See merge request gitlab-org/gitlab-shell!413

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

hooks: Remove deprecated hooks dir

See merge request gitlab-org/gitlab-shell!411

Over a year ago, through e0824f17, the
hooks in this repository were updated to not be successful, basically
block each push from happening.

This change removes the hooks, and updates the documentation. There's no
customer impact, and these changes are just part of a general cleanup.

Fix SAST and Dependency Scanning

See merge request gitlab-org/gitlab-shell!410

Use docker image for Code Intelligence

See merge request gitlab-org/gitlab-shell!409

Release v13.7.0

See merge request gitlab-org/gitlab-shell!408

Fix gitlab-shell not handling relative URLs over UNIX sockets

See merge request gitlab-org/gitlab-shell!406

From
https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4498#note_397401883,
if you specify a relative path such as:

```
external_url 'http://gitlab.example.com/gitlab'
```

gitlab-shell doesn't have a way to pass the `/gitlab` to the host. For example, let's say we have:

```
gitlab_url: "http+unix://%2Fvar%2Fopt%2Fgitlab%2Fgitlab-workhorse%2Fsocket"
```

If we have `/gitlab` as the relative path, how do we specify what is the
UNIX socket path and what is the relative path? If we specify:

```
gitlab_url: "http+unix:///var/opt/gitlab/gitlab-workhorse.socket/gitlab
```

This is ambiguous. Is the socket in
`/var/opt/gitlab/gitlab-workhorse.socket/gitlab` or in
`/var/opt/gitlab/gitlab-workhorse.socket`?

To fix this, this merge request adds an optional
`gitlab_relative_url_root` config parameter:

```
gitlab_url: "http+unix://%2Fvar%2Fopt%2Fgitlab%2Fgitlab-workhorse%2Fsocket"
gitlab_relative_url_root: /gitlab
```

This is only used with UNIX domain sockets to disambiguate the socket
and base URL path. If `gitlab_url` uses `http://` or `https://`, then
`gitlab_relative_url_root` is ignored.

Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/476

Release v13.6.0

See merge request gitlab-org/gitlab-shell!407

Add support obtaining personal access tokens via SSH

See merge request gitlab-org/gitlab-shell!397

Implements the feature requested in gitlab-org/gitlab#19672

This requires the internal api counterpart in gitlab-org/gitlab!36302 to
be merged first.

It can be used as follows:
```
censored@censored-VirtualBox:~/git/gitlab$ ssh git@gitlab-2004 personal_access_token
remote:
remote: ========================================================================
remote:
remote: Usage: personal_access_token <name> <scope1[,scope2,...]> [ttl_days]
remote:
remote: ========================================================================
remote:

censored@censored-VirtualBox:~/git/gitlab$ ssh git@gitlab-2004 personal_access_token newtoken read_api,read_repository 30
Token:   aAY1G3YPeemECgUvxuXY
Scopes:  read_api,read_repository
Expires: 2020-08-07
```

Specify more recent go version in go.mod

See merge request gitlab-org/gitlab-shell!405

Release v13.5.0

See merge request gitlab-org/gitlab-shell!404

Generate and log correlation IDs

See merge request gitlab-org/gitlab-shell!400

Stan Hu authored 4 years ago and Igor Drozdov committed 4 years ago

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

Revert "Update executable.go"

See merge request gitlab-org/gitlab-shell!403

This reverts commit 869aeb90

Release v13.4.0

See merge request gitlab-org/gitlab-shell!402

Log SSH key details

See merge request gitlab-org/gitlab-shell!398

Stan Hu authored 4 years ago and Igor Drozdov committed 4 years ago

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

Log remote IP for executed commands

Closes #199

See merge request gitlab-org/gitlab-shell!399

Drop Go v1.12 support

See merge request gitlab-org/gitlab-shell!401

We officially use Go v1.13+ for everything
(https://docs.gitlab.com/ee/install/requirements.html#go-versions), and
dropping Go v1.12 allows us to use new methods such as
`http.NewRequestWithContext`.

Admins may want to know what client IP originated the request. This
commit adds a `remote_ip` field to the log that extracts the IP address
from the `SSH_CONNECTION` environment variable.

Closes https://gitlab.com/gitlab-org/gitlab-shell/-/issues/199

Merge branch '459-system-default-ssl_cert_dir-is-being-used-during-remote-gitaly-over-tls' into 'master'

Support ssl_cert_dir config setting

See merge request gitlab-org/gitlab-shell!393