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

Cerrado
  • ¿Algo no está bien?
#1,026 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Ya se ha fusionado un pull request relacionado.

  • #1027 de @CloneOfAlex — fusionado

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
Python
Estrellas
178
Forks
73
Merge medio
17 h 56 min
PR fusionados (30 d)
95

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de bmad-code-org/bmad-loop

Todos los issues de bmad-code-org/bmad-loop

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.