Support wildcards in Trusted Publisher gem ownership check

[jsvd]

Is your feature request related to a problem?

Elastic publishes tens/hundreds of gems, many with the same prefix, and it would not be practical to set up a trusted publisher per gem name. Allowing the use of a wildcard we could setup a couple of trusted publishers for "logstash-" or "elastic-" instead.

Describe the solution you'd like

The solution could be done either at the github_action publisher by modifying owns_gem?:

def owns_gem?(rubygem_pattern)
  rubygem_trusted_publishers.joins(:rubygem)
    .where("rubygems.name LIKE ?", rubygem_pattern)
    .exists?
end

Or more generally at the RubygemTrustedPublisher record with something like:

class OIDC::RubygemTrustedPublisher < ApplicationRecord
  belongs_to :rubygem
  belongs_to :trusted_publisher, polymorphic: true

  def self.owns_gem_with_pattern?(publisher, rubygem_pattern)
    where(trusted_publisher: publisher)
      .joins(:rubygem)
      .where("rubygems.name LIKE ?", rubygem_pattern)
      .exists?
  end
end

Both of these would have to either accept % as the wildcard character or do a tr('*', '%').

Describe alternatives you've considered

A) Use the API to add hundreds of publishers (added in #4690)

• It is extremely burdensome to maintain, as any new gems or deleted gems requires a new api call to add or remove a publisher.

B) Implement TOTP, connecting it, for example, to company's Vault

• Feasible, more moving pieces, more complex, and I'm not sure what the long term plan for TOTP support is.

C) Use non-mfa, push-scoped api keys

• Current solution while we figure out which MFA way to go

D) Try for rubygems.org to allow 1 publisher to push any gem from a maintainer

• Potentially too loose, meaning that a publisher would be able to publish any gem under the user account. The wildcards would maintain a measure of allow listing.

Additional context

Elastic has hundreds of gems, a total of 1.7 billion downloads, with many gems being over 10 Million downloads, including elasticsearch-api which is over 180M.

https://rubygems.org/profiles/elastic

[segiddins]

@woodruffw what has pypi done around this space?

[woodruffw]

@woodruffw what has pypi done around this space?

PyPI is currently limited in the same way: we require publishers to be configured on a point-by-point basis. We don't even expose a management API for publishers (yet).

One thing we've talked about (IIRC) on PyPI's side is connecting the Trusted Publishing and Organization features, i.e. so that organizations can mark entire GitHub/GitLab namespaces as trusted for their purposes. Something like that might be applicable here as well, although I'm not sure if RubyGems has the same account/organization split as PyPI does.

[jsvd]

I've beefed up the alternative design section with other options: non-mfa api keys, totp, and a broader "allow-all" alternative, given ruby gems don't have namespaces.

[segiddins]

My gut reaction is to recommend managing this through the REST API for now, since I'm very wary of introducing new footguns in such a sensitive area