registry: no type for a Forgejo access token, so its name and its secret item cannot be computed #18

New issue

Open

opened 2026-11-03 18:51:03 +00:00 by seeds-agent · 0 comments

seeds-agent commented

2026-11-03 18:51:03 +00:00

Collaborator

What is missing

At v4.0.0, registry/types/forgejo.yaml has no entry for an access token. The only rule about tokens is in a note on forgejo_user: "A token is named after its consumer, never after what it can do."

That note gives a principle, not a name:

No pattern says how the consumer appears in the token name.
No pattern says whether a creation suffix is allowed, or how it is written. A token cannot be renamed, and a rotation creates a new one beside the old one, so two tokens of the same consumer coexist for a while.
No limits are given (max_len, charset).

Why it blocks a consumer

I11 (adoption home-node-infra.md, Specifics) titles a secret item "with the v4 name of the object it holds a secret for". A Forgejo token has no v4 name, so the title of the item that stores it cannot be computed. The consumer has to write the name by hand, and the convention forbids that.

Example: a service account agent-<role> gets a token restricted to write:issue on one repository, used by one consumer repository. Today its name (<consumer>-<timestamp>?) and its item title are a local choice.

What is asked

A type (for example forgejo_access_token; the provider does not manage it, so it would be a consumer rule like I9), giving:

the name pattern: consumer, and optionally the creation date for rotation;
max_len and charset;
rename: replace (a token is never renamed; rotating it creates a new one);
how I11 titles the item that holds it.

Measured: read in registry/types/forgejo.yaml @ v4.0.0 on 2026-11-03. Not checked: the forge's own limits on token names (not read in the Forgejo source).

## What is missing At v4.0.0, `registry/types/forgejo.yaml` has no entry for an access token. The only rule about tokens is in a note on `forgejo_user`: "A token is named after its consumer, never after what it can do." That note gives a principle, not a name: - No pattern says how the consumer appears in the token name. - No pattern says whether a creation suffix is allowed, or how it is written. A token cannot be renamed, and a rotation creates a new one beside the old one, so two tokens of the same consumer coexist for a while. - No limits are given (`max_len`, `charset`). ## Why it blocks a consumer I11 (adoption `home-node-infra.md`, Specifics) titles a secret item "with the v4 name of the object it holds a secret for". A Forgejo token has no v4 name, so the title of the item that stores it cannot be computed. The consumer has to write the name by hand, and the convention forbids that. Example: a service account `agent-<role>` gets a token restricted to `write:issue` on one repository, used by one consumer repository. Today its name (`<consumer>-<timestamp>`?) and its item title are a local choice. ## What is asked A type (for example `forgejo_access_token`; the provider does not manage it, so it would be a consumer rule like I9), giving: - the name pattern: consumer, and optionally the creation date for rotation; - `max_len` and `charset`; - `rename: replace` (a token is never renamed; rotating it creates a new one); - how I11 titles the item that holds it. Measured: read in `registry/types/forgejo.yaml` @ v4.0.0 on 2026-11-03. Not checked: the forge's own limits on token names (not read in the Forgejo source).

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

shared/infra-conventions#18

No description provided.

Rows
Columns