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

Aperta
  • Qualcosa non va?
#9,831 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
ruby
Ambito
cli, security

Direzione di ricerca

Inizia con Gem::Commands::SourcesCommand e Gem::Commands::EnvironmentCommand, quindi esegui la riproduzione isolata di GEMRC riportata nell’issue per esaminare ogni percorso di output della gestione delle sorgenti e dell’ambiente. Il lavoro è completato quando gli output elencati non espongono più le informazioni utente dell’URI e il comportamento è stato verificato in modo coerente con la gestione esistente di Gem::Uri.redact.

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

Descrizione

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.

Lingua principale
Ruby
Stelle
4k
Fork
2k
Merge medio
1g 5h
PR unite (30g)
36

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

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

Tutte le issue di ruby/rubygems

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.