Relationships
#3019 extension push: credentials-sensitive-field has no word boundaries and flags secretName, TokenReference, credential_id (fourth fix to the rule)
Opened by skunk-ape · 10/5/2026· Shipped 10/5/2026
Problem
The credentials-sensitive-field review rule (src/domain/extensions/extension_review_rules.ts:143) has no word boundaries and treats the word sensitive anywhere on the line as the suppression marker. On the swamp-extensions corpus it flags:
secretName: z.string()(a Kubernetes Secret name, 6 occurrences)TokenReference(9),credential_id,s3AccessKeyId- digitalocean app-platform spec fields
token/password/api_key, 180 times in one extension
Authors either mark non-secrets sensitive (which vaults them) or learn to skip the rule. This is the fourth fix to the same rule: #1044 (numeric counts and type aliases), #601 (marker on a continuation line), #2952 (token-count fields).
Expected
- The rule matches whole identifiers (word boundaries).
- A stop-list for identifiers that name a reference to a secret rather than the secret:
*Name,*Id,*Reference,*Arn,nextToken. - The suppression marker is
.meta({ sensitive(the actual Zod metadata), not the wordsensitiveanywhere on the line, including insidedescribe(). - The corpus cases above become test vectors so the rule does not regress a fifth time.
Acceptance
push --dry-runon @swamp/kubernetes, the digitalocean extension and the extensions namingTokenReferenceemits no credentials-sensitive-field warning for those identifiers.apiKey: z.string()with no.meta({ sensitive: true })still warns.
Out of scope
Per-rule suppression in the manifest is a separate issue in the same lane and goes last.
Source: the extension push assessment (2026-10-02, swamp 20261002.194016) and the Extension Push UX Plan, which groups this with its lane and order.
Shipped
Click a lifecycle step above to view its details.
skunk-ape commented 10/5/2026, 7:46:10 PM
Correction to the body: the digitalocean app-platform spec fields (token, password, api_key, 180 occurrences) listed above as false positives are real secrets. #3030, filed from this issue's triage, marks them sensitive in the generator and finds that about 215 of the extension's 244 warnings remain legitimate after whole-identifier matching; #3044 adds connection.uri, slack.webhook_url and bgp.auth_key. The fix here must not silence them: acceptance is that they still warn on the digitalocean extension until #3030 lands. The genuine false positives stand: secretName, TokenReference, credential_id, s3AccessKeyId, nextToken, and the word sensitive inside describe() acting as a suppressor.
Sign in to post a ripple.