Freeze more strings in generated gemspecs

[segiddins]

Specifically, this will have frozen string literals for:

• Gem platform tuple entries
• Gem::Version strings
• Gem::Specification#installed_by_version
• Dependency requirement strings

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

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

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

[martinemde]

Will this change the checksums of the gemspecs or is it outside of that process? I think we call to_ruby when storing the plain text gemspec for gem content storage?

[segiddins]

Will this change the checksums of the gemspecs or is it outside of that process

it's outside of that process, since the gemspec we upload to quick/ is the marshaled gemspec (and also those don't get regenerated, so changing what would be generated is kosher, and we've done that in the past)

[martinemde]

it's outside of that process, since the gemspec we upload to quick/ is the marshaled gemspec

Ok cool. Now I'm wondering which gemspec version should be uploaded with gem content.

[segiddins]

Ok cool. Now I'm wondering which gemspec version should be uploaded with gem content.

IMO it should be the yaml gemspec that's inside the .gem, but that's mostly since it's what'd be most helpful to me from a rubygems.org security perspective

[martinemde]

IMO it should be the yaml gemspec that's inside the .gem, but that's mostly since it's what'd be most helpful to me from a rubygems.org security perspective

That seems most reasonable to me. I can't imagine what else we'd want besides the most useful thing 😆