Fix a bug that Gem::YAMLSerializer.load ignores quotation

[kou]

Fix #9551

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

.gemspec is serialized to YAML (metadata.gz) in .gem. metadata.gz may use double quote for string value like:

requirements:
  - "system: arrow-glib>=25.0.0: amazon_linux: arrow-glib-devel"

Gem::YAMLSerializer.load ignores the quotation and parses it as a map:

{
  "requirements" => [
    {"\"system" => "arrow-glib>=25.0.0: amazon_linux: arrow-glib-devel\""},
  ]
}

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

Recognize quotation and parse quoted value as a string value.

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

Fixes Gem::YAMLSerializer.load incorrectly treating quoted scalars containing : as mappings (notably within requirements entries in .gemspec YAML), so metadata in .gem files is deserialized correctly.

Changes:

• Add handling in the YAMLSerializer parser intended to recognize single/double-quoted scalars and parse them as scalars instead of mappings.
• Add a regression test ensuring quoted requirements entries load as an array of strings.

Reviewed changes

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

File	Description
lib/rubygems/yaml_serializer.rb	Adjusts node-type detection to treat quoted lines as scalars to avoid : triggering mapping parsing.
test/rubygems/test_gem_safe_yaml.rb	Adds a test case for quoted requirements values deserializing to strings.

---

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

[hsbt]

Thanks, Should we cover "key": "value" and 'key': 'value' cases?

This change introduce key": "value when "key\": \"value" was presented.

[kou]

Oh, I didn't notice the case. We may need to restructure the current parse_node approach to support both cases.

[kou]

Should we cover "key": "value" and 'key': 'value' cases?

I checked the current implementation. We don't need to care about this case because:

• "key": "value" case doesn't happen in the top-level. All top-level keys (!ruby/object:Gem::Specification's keys) are known and they never use "key": "value" form.
• Non top-level mappings are parsed in parse_mapping not parse_node.

parse_mapping:

rubygems/lib/rubygems/yaml_serializer.rb

Lines 150 to 170 in 5c535b0

	def parse_mapping(indent, anchor)
	pairs = []
	while @lines.any?
	line = @lines[0]
	stripped = line.lstrip
	break unless line.size - stripped.size == indent &&
	stripped =~ MAPPING_KEY_RE && !stripped.start_with?("!ruby/object:")
	key = $1.strip
	@lines.shift
	val = strip_comment($2.to_s.strip)
	key = decode_binary_tag(key) if key.start_with?("!binary ")
	val_anchor, val = consume_value_anchor(val)
	value = parse_mapping_value(val, indent)
	value = register_anchor(val_anchor, value) if val_anchor
	pairs << [Scalar.new(value: key), value]
	end
	register_anchor(anchor, Mapping.new(pairs: pairs))
	end

parse_mapping doesn't use parse_node to parse a key. So the added conditions aren't used.

BTW, users can specify mapping only in metadata. I found some problems in metadata. See #9560 for details.

[kou]

I've added a comment for the note.

[Copilot]

Pull request overview

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