Push with auto-attestation

[hsbt]

What was the end-user or developer problem that led to this PR?

We should expand to use attestation of rubygems. The current toolchain only enabled attestation by https://github.com/rubygems/release-gem or --attestation option with local sigstore json file.

What is your fix for the problem, implemented in this PR?

Integrate rubygems-attestation-patch.rb to gem push command. After that, gem push command perfome:

• Enable attestation with sigstore-cli and that result.
• When --attestation option provided, gem push only uses that.
• When sigstore-cli failed, gem push perform without atttestation
• Disable auto-attestation with JRuby or not rubygems.org host

TODO: After merging this, we should avoid to load rubygems-attestation-patch.rb at rubygems/release-gem with RubyGems >= 4.1.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[Copilot]

Pull request overview

This PR adds automatic Sigstore attestation support to gem push (targeting rubygems.org), generating an attestation bundle via sigstore-cli when no --attestation is provided and falling back to a non-attested push if attestation fails.

Changes:

• Updated Gem::Commands::PushCommand to push with multipart attestations by default (rubygems.org-only), and retry without attestations on errors.
• Added attest! implementation using gem exec sigstore-cli:0.2.2 sign ... --bundle ....
• Refactored push command tests to validate multipart attestation requests via a shared helper and added tests for auto-attestation and fallback behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
lib/rubygems/commands/push_command.rb	Implements auto-attestation flow, multipart request building, and fallback-to-non-attested push logic.
test/rubygems/test_gem_commands_push_command.rb	Adds/updates tests for multipart attestation requests, auto-attestation behavior, and fallback behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The early return for RUBY_ENGINE == "jruby" || !attestation_supported_host? skips all attestation, including when the user explicitly passes --attestation. That changes existing behavior and also contradicts the PR description (“When --attestation option provided, gem push only uses that.”). Consider only disabling auto attestation here (i.e., still call send_push_request_with_attestation when options[:attestations].any?), and gate the attest! path separately for JRuby/unsupported hosts.

Suggested change

	def send_push_request(name, args)
	def send_push_request(name, args)
	if options[:attestations].any?
	begin
	return send_push_request_with_attestation(name, args)
	rescue StandardError => e
	alert_warning "Failed to push with attestation, retrying without attestation.\n#{e.full_message}"
	return send_push_request_without_attestation(name, args)
	end
	end

[Copilot]

alert_warning includes e.full_message, which typically contains a full backtrace and can be extremely verbose/noisy (and may leak local paths). Consider logging only e.message by default and printing the full backtrace only under Gem.configuration.really_verbose (or similar), while still retrying without attestation.

Suggested change

	alert_warning "Failed to push with attestation, retrying without attestation.\n#{e.full_message}"
	message = "Failed to push with attestation, retrying without attestation."
	if Gem.configuration.really_verbose
	message = "#{message}\n#{e.full_message}"
	else
	message = "#{message}\n#{e.message}"
	end
	alert_warning message

[Copilot]

attestation_supported_host? uses exact string equality against "https://rubygems.org". If the host is configured as https://rubygems.org/ (trailing slash) or otherwise equivalent, auto-attestation will be incorrectly disabled. Consider normalizing/parsing the URI (scheme + host) or comparing against Gem::DEFAULT_HOST after normalization.

[Copilot]

@hsbt I've opened a new pull request, #9326, to work on those changes. Once the pull request is ready, I'll request review from you.

[Copilot]

@hsbt I've opened a new pull request, #9327, to work on those changes. Once the pull request is ready, I'll request review from you.

[colby-swandale]

I'm not sure making Attestations the default path going forward would be a net positive in its current form. I don't have the stats in front of me, but I believe the vast majority of gem pushes to rubygems.org are still from local dev machines, so the vast majority of gem push will start showing “Failed to push with attestation, retrying without attestation” on every push, which could confuse users. And even when sigstore-cli is installed, it will still fail, since rubygems.org rejects anything not published via GitHub Actions (as of now).

[hsbt]

since rubygems.org rejects anything not published via GitHub Actions (as of now).

@colby-swandale Oh, I didn't know that.

This change eliminates the need for monkey patching. That's the fist my motivation.

The long term goal, I would like to consider a system that would enable attestation even when pushing from local, but I don't have any ideas yet.

[Edouard-chin]

This change would be great !

I have this use case on cibuildgem . I can't use the standard rubygems/release-gem action because it's calling rake release which can't work in my case (it's related to building fat binary gems). So I setup rubygems credential with the underlying rubygems/configure-rubygems-credentials github action and then push manually.

With this change, the gem pushed will be fully attested 🥳