Skip to content

[pull] master from ruby:master - #1260

Merged
pull[bot] merged 4 commits into
turkdevops:masterfrom
ruby:master
Jul 30, 2026
Merged

[pull] master from ruby:master#1260
pull[bot] merged 4 commits into
turkdevops:masterfrom
ruby:master

Conversation

@pull

@pull pull Bot commented Jul 30, 2026

Copy link
Copy Markdown

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

hsbt and others added 4 commits July 30, 2026 05:42
… paths

Bundler::CompactIndexClient::Cache#info_path and #info_etag_path join
the gem name into the cache directory without validation. The name comes
from the remote index, either versions lines or transitive dependency
names in info files, so a crafted name like "../../../../pwn" escapes
the cache directory because the special-characters branch keeps the raw
name and only appends an MD5 suffix. Reject any name that is not a plain
basename before constructing the path, matching the fetch_spec guard
from ruby/rubygems@56ed326cb2, and apply the same guard to the independent
Gem::CompactIndexClient::Cache port.

ruby/rubygems@4b1c454526

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…er-Agent

The `options/` segment of Bundler's User-Agent is built from
`Bundler.settings.all`, which returns only setting names. Mirror
settings, however, embed a URI in the key itself
(`mirror.http://user:token@host/`), so the URI userinfo becomes part of
the name. That name is then sent to every gem source Bundler contacts,
including public or attacker-controlled sources, leaking the embedded
credentials cross-origin.

Strip the userinfo from any settings key that embeds a URI when building
the User-Agent, keeping the useful telemetry (which settings are in use
and the host) while dropping the secret. The redaction is limited to the
User-Agent; `Bundler.settings.all` still returns the real keys, which
`local_overrides` and `gem_mirrors` rely on.

ruby/rubygems@1468529cbe

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The documentation says that Process::Status.wait sets the thread-local
variable $? when there are child processes, but it never does.
rb_process_status_wait does not call rb_last_status_set, and $? is left
untouched:

    $?                        # => nil
    Process.spawn('cat /nop') # => 4996
    Process::Status.wait      # => #<Process::Status: pid 4996 exit 1>
    $?                        # => nil

The existing example showed this as well: the pid displayed for $?
(1155508) did not match the pid of the returned status (1155880),
contradicting the surrounding text.

Since $? is never set, the "does not set thread-local variable $?"
note in the no-child-process case is now redundant and has been folded
into the general description.
…ooldown

Declaring the same source URL twice with different cooldown values
silently drops one of them, because duplicate declarations are deduped
into a single source and cooldown applies per server, not per gem.
The reporter of #9723 used a second source block with cooldown: 0 as a
per-gem exemption and got no indication it had no effect. Keep the
dedup behavior but warn when a conflicting cooldown value is discarded.

ruby/rubygems#9723

ruby/rubygems@a2a44cf4e0

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@pull pull Bot locked and limited conversation to collaborators Jul 30, 2026
@pull pull Bot added the ⤵️ pull label Jul 30, 2026
@pull
pull Bot merged commit acc86e6 into turkdevops:master Jul 30, 2026
1 of 3 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants