Pin nokogiri >= 1.19.3 (GHSA-c4rq-3m3g-8wgx)

[mokagio]

Note

Closed in favor of #498

Summary

Adds gem 'nokogiri', '>= 1.19.3' to Gemfile to pull in the fix for GHSA-c4rq-3m3g-8wgx — high-severity ReDoS in Nokogiri's CSS selector tokenizer (vulnerable < 1.19.3).

This repo is on fastlane-plugin-wpmreleasetoolkit ~> 13.8, which predates the toolkit's own nokogiri >= 1.19.3 floor (added in 14.4.1). The explicit pin closes the gap without requiring a release-toolkit major bump.

Generated as part of the nokogiri 1.19.3 Orchard campaign.

Testing

bundle install. Gemfile.lock resolves nokogiri to 1.19.3.

---

Posted by Claude Code (Opus 4.7) on behalf of @mokagio with approval.

[Copilot]

Pull request overview

This PR mitigates GHSA-c4rq-3m3g-8wgx by ensuring the project resolves Nokogiri to a non-vulnerable version (>= 1.19.3), without requiring an upgrade of fastlane-plugin-wpmreleasetoolkit.

Changes:

• Add an explicit nokogiri (>= 1.19.3) dependency to the Gemfile.
• Update Gemfile.lock to resolve nokogiri from 1.19.1 to 1.19.3 (including checksum and dependency list entry).

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated 1 comment.

File	Description
Gemfile	Adds explicit Nokogiri minimum version requirement and rationale comment.
Gemfile.lock	Updates resolved Nokogiri version and records it under dependencies/checksums.

---

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

[mokagio]

Holding this in draft. The CI failures here look like an infrastructure/cache-logic issue specific to this repo, not a problem with the lockfile bump:

• xcode-build-xcframework fails with tar: vendor/bundle: Cannot stat: No such file or directory while the cache-store step runs (No existing cache entry for gutenbergkit-...-storing in cache). The cache key changes because Gemfile.lock changed, so it's a cache miss; the storage step then fails because vendor/bundle isn't where the cache-store expects it. This would hit any Gemfile.lock-touching change, not just this one.
• The android-test-android-e2e and android-publish-android-library failures are likely cascade failures from the same root.
• The GHA validate failure should be inspected separately by someone with repo familiarity.

trunk's recent CI is healthy (#2236 passed), so this is specific to my PR's interaction with the cache logic. Recipe is identical to the rest of the campaign: gem 'nokogiri', '>= 1.19.3' in Gemfile, then bundle install. Gemfile.lock resolves nokogiri from 1.19.1 to 1.19.3 cleanly.

Once the CI cache logic is fixed (or someone with repo knowledge confirms the safe path), this PR can be re-monitored and merged.

---

Posted by Claude Code (Opus 4.7) on behalf of @mokagio with approval.

[mokagio]

Closing in favor of #498