4 ms·

I don't think the RubyGems people were incompetent. The software serves its core purpose quite well (as a library delivery mechanism) and is quite reliable. B

I don't think the RubyGems people were incompetent. The software serves its core purpose quite well (as a library delivery mechanism) and is quite reliable. But clearly they weren't thinking about security in decision, and what would happen if the repos were compromised. Let's be honest here - no software is 100% secure. As developers and consumers, the idea that we all review all of the tools in our toolchain for security soundness is absurd. It's like saying that everyone using C made poor decisions because of security flaws in popular libraries (even security ones, like openssl) and therefore all of the C community has no engineering competence. The fact is, China already has their eyes on GitHub and it's not beyond the planning capability to place backdoors in popular software to suit their future ends. No matter who the attacker may be, you have to be prepared for the situation where your computers and data are compromised, period.

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 ago
    This 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 ago
      I'm simply contesting the "no means of code verification whatsoever" statement.
      - pifflesnort 14y ago
        My point is simply that without signatures, there is no means of verification. Having the code isn't enough.

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 ago
  This 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 ago
    I'm simply contesting the "no means of code verification whatsoever" statement.
    - pifflesnort 14y ago
      My point is simply that without signatures, there is no means of verification. Having the code isn't enough.