GitLab

The traffic log could say a version was pulled, when, by which token and from
which address. None of that answers the question actually asked after a package
turns out to be malicious, which is where it is now. An address is a build agent
that has since been rebuilt, and a token is a name somebody typed once.

So an admin keeps two lists in Settings, applications and environments, and a
developer picks one of each when minting a token. Every request that token makes
is stamped with both, and so is every row on the pulled with a known advisory
list, which is the one somebody works through when an advisory lands.

The names are copied onto each row as it is written rather than joined in later.
That is the whole point of it: months afterwards the token may be revoked, moved
to another application, or gone, and none of that can be allowed to change what
the row says was true at the time. The token holds ids, so a rename follows every
token pointing at it without touching a single row of history.

Both are optional and nothing is backfilled. A token minted before the lists
existed carries neither and still works, and its rows read unassigned rather than
blank, because a blank reads as though nothing happened. Filtering the traffic
for unassigned is how the remaining ones get found.

Removing an entry is a retire. It stops being offered for new tokens and stays on
the ones already carrying it. Deleting outright is refused while any token still
points at it, revoked ones included: dropping the row underneath a token would
turn its label into unassigned, which is the same lie as a blank. The unique key
is case insensitive, so checkout-api and Checkout-API cannot both exist and split
every report between them.

Reading the two lists sits at viewer, not with settings. The token page needs it
to fill the dropdowns and the traffic page needs it to offer the filter, and it
gives nothing away, since anyone who can read the traffic is already reading
these same names off the rows. Changing them is settings:write like the rest.

The settings page is tabs now. It was long before this added to it, and the last
few sections were reachable only by scrolling past everything else. Every panel
stays in the page and only the visible one changes, so the one Save button at the
bottom still collects every field whichever tab is on screen. The applications
tab is the exception and says so, because those are rows rather than settings and
they save as they are edited.