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

Extract coverage for Go code on CI pipeline

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

Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>

Use simplified setup for code intelligence

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

Use codequality CI template

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

In https://gitlab.com/gitlab-org/gitlab/-/issues/218797, it was
determined that gitlab-shell is using an outdated image that no
longer exists.

To ensure that we are using up to date codequality image, we
can use the built-in template instead.

Release v13.3.0

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