Require production env to reach the production malware PDS

What does this MR do and why?

SyncConfiguration::Location.malware_pds_endpoint chose the malware PDS endpoint with a denylist:

Gitlab.staging? || Gitlab.dev_or_test_env? ? PDS_MALWARE_STAGING_ENDPOINT : PDS_MALWARE_ENDPOINT

Read the other way round, that says anything not explicitly enumerated resolves to the production PDS. Staging, development and test are named; everything else — a review app, or any custom RAILS_ENV — falls through and reaches production advisory data.

This MR inverts it into an allowlist. A deployment now has to positively be RAILS_ENV=production and not staging.gitlab.com:

def self.malware_pds_endpoint
  production_deployment? ? PDS_MALWARE_ENDPOINT : PDS_MALWARE_STAGING_ENDPOINT
end

def self.production_deployment?
  Rails.env.production? && !Gitlab.staging?
end

Everything unrecognised now falls back to staging, which is the safe direction to fail in.

Behaviour

Only one row changes. Every real deployment resolves exactly as before.

Deployment	Rails.env	Gitlab.staging?	Before	After
Self-managed production	production	false	production	production
Dedicated	production	false	production	production
GitLab.com production / canary	production	false	production	production
staging.gitlab.com	production	true	staging	staging
GDK	development	false	staging	staging
test	test	false	staging	staging
Unrecognised env, e.g. review	other	false	production	staging

Implementation notes

Why Rails.env.production? and not Gitlab.com?. Gitlab.com? would be wrong in both directions. It is true on staging, because gl_subdomain? matches %r{\Ahttps://[a-z0-9-]+\.gitlab\.com\z} and so any gitlab.com subdomain qualifies (lib/gitlab.rb:112). And it is false on self-managed, which would cut every self-managed instance off from production advisory data. Self-managed instances run RAILS_ENV=production and must keep reaching the production PDS, which is exactly what the Rails env check preserves.

Why the !Gitlab.staging? half is still needed. staging.gitlab.com also runs with RAILS_ENV=production, so the Rails env alone does not identify production. Both halves are load-bearing.

Not addressed here: Gitlab.staging? is exact URL equality against https://staging.gitlab.com (lib/gitlab.rb:76), so a staging-canary.gitlab.com deployment has staging? == false and takes the production branch. That is pre-existing behaviour and this MR does not widen it. Closing it would need a staging-host pattern rather than equality, which felt like a separate decision rather than something to slip into this change.

No change to the offline path. for_malware_advisories still short-circuits to :offline whenever vendor/package_metadata/malware_advisories exists, before the endpoint resolver is consulted at all.

Test coverage

Five contexts in ee/spec/models/package_metadata/sync_configuration_spec.rb, replacing three. The previous specs stubbed Gitlab.staging? and Gitlab.dev_or_test_env? directly; they now stub the Rails env with stub_rails_env, which is what the code actually reads.

Context	Asserts
production	production PDS
staging	staging PDS despite RAILS_ENV=production
development	staging PDS
test	staging PDS
unrecognised env	staging PDS, rather than reaching production

The last one is the regression test for the behaviour this MR changes.

Spec and RuboCop output

$ bundle exec rspec ee/spec/models/package_metadata/sync_configuration_spec.rb
43 examples, 0 failures

$ bundle exec rubocop ee/app/models/package_metadata/sync_configuration.rb \
    ee/spec/models/package_metadata/sync_configuration_spec.rb
2 files inspected, no offenses detected

Related

• Malware advisory sync epic: &20876
• PDS distribution endpoints were introduced in #602430 (closed)