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:password@example.com/, 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 a443fab.
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:example-password@example.invalid/" > "$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:REDACTED@example.invalid/
What actually happened?
The full configured URI was printed:
https://example-user:example-password@example.invalid/
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.
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:
gem sources --add,--prepend, and--appendoutput;gem sources;gem env remotesources;gem envoutput.When a configured source contains
https://username:password@example.com/, 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
gemrcas 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.redactconsistently 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
masterat a443fab.Post steps to reproduce the problem
A network request is not needed to reproduce the listing behavior:
A successful
gem sources --addagainst an authenticated private source also echoes the complete source URI after saving it.Which command did you run?
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:
What actually happened?
The full configured URI was printed:
Run
gem envand paste the output belowThis behavior is not platform-specific and is directly visible in the current implementations of
Gem::Commands::SourcesCommandandGem::Commands::EnvironmentCommand. The reproduction above uses an isolatedGEMRCand contains no real credentials.