Pick any line to see why it is the way it is: the commit, the pull request and issue it came from, and what the agent was thinking.
| A secret a job uses only to call an API can be brokered, so its value never enters the job's sandbox. Under Settings, Secrets and variables, a secret's new Brokered choice (Only for these hosts) takes the hosts it is for, written as allowed domains are (registry.npmjs.org, *.example.com); the list shows a Brokered badge whose hint names them. A workflow job then gets a stand-in in its place, g1tsec_ and 48 random hex characters, made for that job and that secret, wherever the value would have gone: as the secret, under any key a called workflow passes it as, and inside a value built from it. As the job's requests pass the runner Worker, a stand-in on a request to one of the secret's hosts becomes the real value in any header (inside Authorization: Basic it is decoded, filled in and encoded again) and in the query string, never the path or the body; a filled-in request is not followed through redirects outside the sandbox, and an answer that echoes the value has it swapped back for the stand-in in its headers, and in its body when that is small, uncompressed text. A stand-in sent to any other host goes as it is and the job's log says once that NPM_TOKEN was sent to example.com, which it is not for, so g1t did not fill it in. | 1 | -- Brokered secrets. A secret row with hosts is brokered: a workflow job is |
| 2 | -- given a stand-in for it in place of its value, and the runner Worker puts | |
| 3 | -- the value on the job's requests to those hosts as they leave its sandbox. | |
| 4 | -- The hosts are a JSON array of domains (`api.example.com`, | |
| 5 | -- `*.example.com`); null for a secret that is not brokered. | |
| 6 | ALTER TABLE settings ADD COLUMN brokered_hosts TEXT; | |
| 7 | ||
| 8 | -- The stand-ins jobs were given: each a random token unique to one job and | |
| 9 | -- one secret, its value sealed and bound to the stand-in, the hosts it is | |
| 10 | -- filled in for, and when it stops working (the job's time limit and ten | |
| 11 | -- minutes, in milliseconds since the epoch). Only a running job's own are | |
| 12 | -- ever answered, with its token. | |
| 13 | CREATE TABLE brokered_secrets ( | |
| 14 | stand_in TEXT PRIMARY KEY, | |
| 15 | job_id TEXT NOT NULL, | |
| 16 | name TEXT NOT NULL, | |
| 17 | value TEXT NOT NULL, | |
| 18 | hosts TEXT NOT NULL, | |
| 19 | expires_at INTEGER NOT NULL | |
| 20 | ); | |
| 21 | CREATE INDEX brokered_secrets_by_job ON brokered_secrets (job_id); | |
| 22 | CREATE INDEX brokered_secrets_by_expiry ON brokered_secrets (expires_at); | |
| 23 | ||
| 24 | -- Whether a job was given any, so its log is masked for their values too | |
| 25 | -- without asking on every report. | |
| 26 | ALTER TABLE jobs ADD COLUMN brokered INTEGER NOT NULL DEFAULT 0; |
