Should gem sources and gem env redact credentials embedded in source URLs?

Abierto
  • ¿Algo no está bien?
#9,831 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
ruby
Área
cli, security

Línea de trabajo

Comienza con Gem::Commands::SourcesCommand y Gem::Commands::EnvironmentCommand; después, ejecuta la reproducción aislada de GEMRC del issue para inspeccionar cada ruta de salida de la gestión de fuentes y del entorno. Se considera terminado cuando las salidas indicadas ya no exponen información de usuario de la URI y el comportamiento se ha comprobado de forma coherente con el tratamiento existente de Gem::Uri.redact.

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

Descripción

Describe the problem as clearly as you can

This issue is a question about the expected output of RubyGems source inspection commands.

RubyGems supports HTTP Basic authentication through URI userinfo. Issue #2456 documents credentials in a source URL as the existing way to authenticate downloads. PR #4868 later added credential redaction to download logs, errors, and debug output.

However, the current source management paths still print the original URI:

  • successful gem sources --add, --prepend, and --append output;
  • gem sources;
  • gem env remotesources;
  • the configuration and remote-sources sections of the full gem env output.

When a configured source contains https://username:[email protected]/, these commands display the complete userinfo. This can copy a long-lived credential into terminal output, CI logs, support reports, or other diagnostics.

The credential is already stored in gemrc as part of the configured source, so redacting command output would not change the on-disk storage model. This question is specifically about avoiding additional disclosure through output.

I could not find an existing issue or Discussion addressing this exact behavior. Discussion #6136 concerns Bundler credential storage rather than RubyGems source display. The command reference describes private sources but does not document how source userinfo is displayed.

Is displaying the exact source URI intentional for these inspection commands? If it is, would a documentation warning be appropriate? If it is not, would maintainers accept using Gem::Uri.redact consistently for source-management and environment output, as the network paths already do?

Did you try upgrading RubyGems?

Yes. I verified the relevant paths in RubyGems 4.0.19 and current master at a443fab01e388cbd97707a1bdddc1a112832a9e3.

Post steps to reproduce the problem

A network request is not needed to reproduce the listing behavior:

tmp=$(mktemp)
printf "%s\n" ":sources:" "- https://example-user:[email protected]/" > "$tmp"
GEMRC="$tmp" gem sources
GEMRC="$tmp" gem env remotesources

A successful gem sources --add against an authenticated private source also echoes the complete source URI after saving it.

Which command did you run?
gem sources
gem env remotesources
gem env
What were you expecting to happen?

Either URI userinfo would be redacted consistently with RubyGems network logs and errors, or the documentation would explicitly state that source inspection commands display embedded credentials.

If embedding credentials in source URLs is considered a legacy or compatibility-only authentication mechanism, I would also expect the documentation to say so explicitly, explain the disclosure risks, and point users to the recommended alternative. If it remains the supported mechanism for authenticated gem downloads, redacting credentials from diagnostic output seems especially important.

For example:

https://example-user:[email protected]/
What actually happened?

The full configured URI was printed:

https://example-user:[email protected]/
Run gem env and paste the output below

This behavior is not platform-specific and is directly visible in the current implementations of Gem::Commands::SourcesCommand and Gem::Commands::EnvironmentCommand. The reproduction above uses an isolated GEMRC and contains no real credentials.

Lenguaje dominante
Ruby
Estrellas
4k
Forks
2k
Merge medio
1 d 17 h
PR fusionados (30 d)
50

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

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 ruby/rubygems

Todos los issues de ruby/rubygems

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.