Two token-handling rough edges:
1. --token exposes the secret via process arguments. Anything that can run ps on the host — or any CI log that echoes the command line — sees the Fleet API token. Auth already resolves flags > env > config file, so the flag is the least safe of the three options.
Options: deprecate --token in favor of $FLEET_TOKEN / config file (warn on use, remove in a later release), or keep it and document the exposure prominently.
2. Upstream response bodies are echoed into CI logs. git.doRequest formats failures as API %s %d: %s with the full response body, and api.HTTPError does likewise. A GitLab/GitHub/Fleet error response can contain the request URL, tokens reflected back, or host data, and in --git mode that lands in a CI log.
Wanted: truncate and redact response bodies in both error paths — keep status code and a short reason, drop anything token-shaped.
Priority: P2 (item 2 first)
Two token-handling rough edges:
1.
--tokenexposes the secret via process arguments. Anything that can runpson the host — or any CI log that echoes the command line — sees the Fleet API token. Auth already resolves flags > env > config file, so the flag is the least safe of the three options.Options: deprecate
--tokenin favor of$FLEET_TOKEN/ config file (warn on use, remove in a later release), or keep it and document the exposure prominently.2. Upstream response bodies are echoed into CI logs.
git.doRequestformats failures asAPI %s %d: %swith the full response body, andapi.HTTPErrordoes likewise. A GitLab/GitHub/Fleet error response can contain the request URL, tokens reflected back, or host data, and in--gitmode that lands in a CI log.Wanted: truncate and redact response bodies in both error paths — keep status code and a short reason, drop anything token-shaped.
Priority: P2 (item 2 first)