[BUG] diagnose/probe-adapter leak guard misses Stripe, Slack app-level, SendGrid and PyPI keys, and non-http URL credentials

Aperta
  • Qualcosa non va?
#1,026 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@CloneOfAlex ci sta già lavorando.

Dal 2/11/2026.

  • #1027 di @CloneOfAlex — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
Mezza giornata
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
python
Ambito
security

Direzione di ricerca

The guard lives in src/bmad_loop/sanitize.py: start with _SECRET_PREFIX_RE, _URL_CRED_RE, looks_like_secret, _scrub_str and assert_no_leak. Run the reproduction snippet from the issue to see the four key shapes and two connection strings pass through. Done means those values are redacted, assert_no_leak reports secret and url-credentials, and near-miss slugs stay clean. PR #1027 is already open against this, so check it before starting.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
Description

The egress guard in src/bmad_loop/sanitize.py that bmad-loop diagnose and probe-adapter rely on has two gaps.

1. Identifier-shaped credentials with no known prefix pass verbatim. looks_like_secret catches a value by a provider prefix (_SECRET_PREFIX_RE), a JWT, or a contiguous alnum run of >= 32 chars with high entropy. Several common credential formats split at ., - or _ into runs shorter than 32, and have no prefix in the list, so looks_like_identifier passes them and scrub_json / assert_no_leak let them through:

  • Stripe secret / restricted keys sk_live_ / sk_test_ / rk_live_ (legacy keys carry a 24-char tail; sk- is listed but not the underscore form)
  • Slack app-level tokens xapp-<n>-... (every segment short)
  • SendGrid SG.<22>.<43> (the 43 often split by -/_)
  • PyPI upload tokens pypi-AgE...

2. _URL_CRED_RE only matches https?://. Connection strings carry user:password@ userinfo the same way — postgres://, redis://, mongodb+srv://, amqp://, ssh:// — and pass assert_no_leak clean.

Severity is low in practice: today's scrub_text inputs are CLI --version/--help blobs and run-state JSON, where most strings with : or / are already redacted as non-identifiers. But assert_no_leak is documented as the fail-closed backstop that catches "URL-embedded creds" and credential-shaped tokens whatever the routing, so these are holes in that guarantee.

Steps to reproduce

From a checkout of main (49eb8a3f):

from bmad_loop import sanitize as s

for v in [
    "sk_live_CANARYxxxxxxxxxxxxxxxx",
    "xapp-1-A0CANARY01-0000000000-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "SG.CANARYxxxxxxxxxxxxxxx.CANARYxxxx-xxxxxxxxxxxxxxx_xxxxxxxxxxxxxxxx",
    "pypi-AgEIcHlwaS5vcmcCANARY",
]:
    print(s.looks_like_identifier(v), s.looks_like_secret(v), s._scrub_str(v))
# True False <the value, verbatim>  -- for every row

print(s.assert_no_leak("dsn postgres://app:hunter2@localhost:5432/db"))  # []
print(s.assert_no_leak("broker amqp://guest:guest@rabbit/vhost"))        # []

(Values are low-entropy canaries in each vendor's format, not real keys.)

Expected behavior

Each value above is redacted by scrub_json / _scrub_str (<redacted:secret>), assert_no_leak reports secret for the keys and url-credentials for the connection strings, and diagnose refuses to emit (fail-closed), as it already does for ghp_, sk-, AKIA, xoxb- and https://user:pass@ URLs.

I have a fix ready (PR to follow): anchored vendor-format arms in _SECRET_PREFIX_RE ([sr]k_(?:live|test)_, xapp-\d+-, SG\.[A-Za-z0-9_-]{16,}\., pypi-AgE) and _URL_CRED_RE widened to any RFC 3986 scheme, [A-Za-z][A-Za-z0-9+.-]*://[^/\s]*:[^/@\s]+@. Near-miss slugs (sk_util, pypi-mirror, SG.1, xapp-name) and userinfo without a password (ssh://git@host:22/..., https://host:8443/...) stay clean.

Actual behavior

looks_like_secret returns False for all four key shapes, _scrub_str returns them verbatim, and assert_no_leak returns [] for both connection strings.

Screenshots

No response

Which area is this for?

Not sure / Other

bmad-loop Version

0.13.2 (main @ 49eb8a3f)

Which coding CLI are you using?

Other

Operating System

Linux

Relevant log output
Diagnostic dump (bmad-loop diagnose)

No response

Confirm
  • I've searched for existing issues
  • If I attached a diagnose dump, I reviewed it and confirmed it contains no PII, secrets, or project-specific information
  • I'm using the latest version
Lingua principale
Python
Stelle
174
Fork
72
Merge medio
19h 25m
PR unite (30g)
84

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di bmad-code-org/bmad-loop

Tutte le issue di bmad-code-org/bmad-loop

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.