Skip to content

Every sign-in needs its device key #45

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
camilb merged 1 commit into from
Nov 3, 2026
Merged

Every sign-in needs its device key #45

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 6 additions & 7 deletions docs/security.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,8 +45,9 @@ so saved credentials copied to another computer authenticate nothing there. A Ma
without a Secure Enclave, a computer without a TPM, or a Linux user outside the
group that owns `/dev/tpmrm0` (usually `tss`) gets a software key saved with the
credentials, and `edka login` says which key it made. Even then, a token that
leaks on its own, from a log or a proxy, authenticates nothing. A login from an
earlier CLI gets a key at its next refresh. `edka logout` deletes the key.
leaks on its own, from a log or a proxy, authenticates nothing. Edka issues no
token without a proof of a key, so a sign-in made before v0.10.0 needs
`edka login` again. `edka logout` deletes the key.

Access tokens expire after 15 minutes, and refresh tokens rotate. `edka logout`
revokes the refresh token, then deletes the saved credentials; `logout --local`
Expand All @@ -55,9 +56,8 @@ until it expires, but a user who is disabled or leaves the organization fails th
next request. A token is bound to one organization, and a request can't switch it to
another.

`EDKA_TOKEN` supports short-lived automation and is never saved. Keep access tokens
out of shell arguments, repository files and logs. Edka issues no long-lived
machine-to-machine CLI tokens. The CLI collects no telemetry and runs no shell
Edka issues no long-lived machine-to-machine CLI tokens, and no token works
without the key it is bound to. The CLI collects no telemetry and runs no shell
scripts.

A GitHub Actions job signs in with a trust instead of a stored secret. With
Expand All @@ -71,8 +71,7 @@ and saves nothing. Edka accepts each GitHub token once and checks its signature,
issuer, audience, expiry, repository ID, owner ID, ref, environment and workflow
against the trust. A trust's token reaches only the routes of `edka apps publish`
and `edka apps update`, for the one app the trust names, and never passes a
passkey check. `EDKA_TOKEN` and `EDKA_TRUST` together are refused, and so is
`edka login` while `EDKA_TRUST` is set.
passkey check. `edka login` is refused while `EDKA_TRUST` is set.

The CLI replaces its binary only when `edka upgrade` runs. The upgrade reads the
latest release of github.com/edkadigital/cli over HTTPS, without a token. It follows a
Expand Down
Loading