3 ms·
> I don't think the RubyGems people were incompetent. They sat on a publicly disclosed vulnerability in the YAML parser for a week. The YAML parser itself was
by pifflesnort 14y ago
> I don't think the RubyGems people were incompetent.
They sat on a publicly disclosed vulnerability in the YAML parser for a week. The YAML parser itself was ridiculously designed to (essentially) eval() YAML.
Those were the two active decisions of incompetence.
On top of this, they built a massively central system that is widely trusted with no means of code verification whatsoever. There is no telling what people could have injected into that repository at any point in its history.
- ceejayoz 14y ago> On top of this, they built a massively central system that is widely trusted with no means of code verification whatsoever. https://github.com/rubygems/rubygems/blob/master/History.txt https://github.com/rubygems/rubygems/blob/master/History.txt 0.8.11 / 2005-07-13: Added Paul Duncan's gem signing patch. They've had a mechanism for code signing for 8 years. Yes, they could require signing of all gems on the site, but the ability has been there for a long time.
- pifflesnort 14y agoThis doesn't do any good if it's not required/used, which it's not. As a counter-example, the maven central repository requires signatures, and caching Maven repositories validate those signatures.
- ceejayoz 14y agoI'm simply contesting the "no means of code verification whatsoever" statement.
- pifflesnort 14y agoMy point is simply that without signatures, there is no means of verification. Having the code isn't enough.