Security

What the CLI holds

The only secret rickub handles is your personal access token (PAT).

It is stored in ~/.config/rickub/config.yaml (honouring XDG_CONFIG_HOME),
written atomically with mode 0600 in a 0700 directory. A save always
re-applies 0600, even over a file something else made world-readable.
A stored token is bound to the host it was minted for and is only ever sent
there. --host or RICKUB_HOST pointing elsewhere gets "no token stored
for that host", never your production credential.
A token given explicitly (--token, RICKUB_TOKEN) is sent to whatever host
is in effect; the CLI warns before sending it over plain http:// to a
non-loopback address.
auth status prints only the non-secret rickub_pat_ prefix. --token is
discouraged in the help text because arguments are visible to other
processes and end up in shell history; prefer auth login --with-token
(stdin) or the environment variable.

Network behaviour

Every request goes to <host>/api/v1/… with the token as a bearer header.
Redirects are followed only on the same host and never from https to http;
anything else is refused, so a redirect cannot carry the token away.
Response bodies are capped (128 MiB) so a hostile host cannot exhaust memory.
No TLS verification is ever disabled.

Shelling out

repo clone runs git with a URL assembled from a fixed scheme and host and
the owner/repo you typed; anything after -- is passed to git unchanged.
With --protocol https the token reaches git through its environment as a
header scoped to that one origin (http.<origin>/.extraHeader): never on
the command line, never written to .git/config, never sent to a redirect
target or another host's submodule.
browse and the device login hand a URL to the platform opener only after
checking it is http/https with a host, so no other scheme handler can be
reached.
Repo inference runs git remote get-url origin in the current directory.

Output

Text that comes from the server (titles, bodies, names) is stripped of terminal
control sequences before it is printed for a human, so a crafted issue title
cannot repaint your terminal. --json output and run logs are passed through
untouched.

Continuous checks

.github/workflows/security.yml runs on every push and pull request and weekly:
go vet, go mod verify + tidy check, govulncheck (stdlib and dependency
advisories reachable from this code), gosec (every accepted finding is
annotated in place with a reason), staticcheck, and a clean-tree release
build. go.mod pins the toolchain so builds do not silently use an older Go
with known CVEs.

Reporting

If you find a vulnerability, please report it privately to the maintainer
(see the commit authors) rather than in a public issue; open an issue at
https://rickub.com/rickub/cli/issues for anything that is not sensitive.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62


# Security

## What the CLI holds

The only secret `rickub` handles is your personal access token (PAT).

- It is stored in `~/.config/rickub/config.yaml` (honouring `XDG_CONFIG_HOME`),
  written atomically with mode `0600` in a `0700` directory. A save always
  re-applies `0600`, even over a file something else made world-readable.
- A stored token is bound to the host it was minted for and is only ever sent
  there. `--host` or `RICKUB_HOST` pointing elsewhere gets "no token stored
  for that host", never your production credential.
- A token given explicitly (`--token`, `RICKUB_TOKEN`) is sent to whatever host
  is in effect; the CLI warns before sending it over plain `http://` to a
  non-loopback address.
- `auth status` prints only the non-secret `rickub_pat_` prefix. `--token` is
  discouraged in the help text because arguments are visible to other
  processes and end up in shell history; prefer `auth login --with-token`
  (stdin) or the environment variable.

## Network behaviour

- Every request goes to `<host>/api/v1/…` with the token as a bearer header.
- Redirects are followed only on the same host and never from https to http;
  anything else is refused, so a redirect cannot carry the token away.
- Response bodies are capped (128 MiB) so a hostile host cannot exhaust memory.
- No TLS verification is ever disabled.

## Shelling out

- `repo clone` runs `git` with a URL assembled from a fixed scheme and host and
  the `owner/repo` you typed; anything after `--` is passed to git unchanged.
  With `--protocol https` the token reaches git through its environment as a
  header scoped to that one origin (`http.<origin>/.extraHeader`): never on
  the command line, never written to `.git/config`, never sent to a redirect
  target or another host's submodule.
- `browse` and the device login hand a URL to the platform opener only after
  checking it is `http`/`https` with a host, so no other scheme handler can be
  reached.
- Repo inference runs `git remote get-url origin` in the current directory.

## Output

Text that comes from the server (titles, bodies, names) is stripped of terminal
control sequences before it is printed for a human, so a crafted issue title
cannot repaint your terminal. `--json` output and `run logs` are passed through
untouched.

## Continuous checks

`.github/workflows/security.yml` runs on every push and pull request and weekly:
`go vet`, `go mod verify` + tidy check, `govulncheck` (stdlib and dependency
advisories reachable from this code), `gosec` (every accepted finding is
annotated in place with a reason), `staticcheck`, and a clean-tree release
build. `go.mod` pins the toolchain so builds do not silently use an older Go
with known CVEs.

## Reporting

If you find a vulnerability, please report it privately to the maintainer
(see the commit authors) rather than in a public issue; open an issue at
<https://rickub.com/rickub/cli/issues> for anything that is not sensitive.