3 ms·

Sure, the context of the thread is that ruby-core is reluctant to start changing OpenSSL defaults because Security is Hard, the ruby team is volunteers who migh

Sure, the context of the thread is that ruby-core is reluctant to start changing OpenSSL defaults because Security is Hard, the ruby team is volunteers who might not have expert-level crypto understanding, and and you risk doing more harm than good if you mess with crypto when you do not know what you're doing, so they'd rather leave OpenSSL's defaults alone, and let OpenSSL, written and reviewed by security focused people, fix any issues (I think this is a fair summary?). While these are valid concerns, you can't wholly pass the buck to OpenSSL and to people installing a new version of OpenSSL and re-linking ruby against that -- ruby project should should always ship the most secure ruby possible, all the time. Newer OpenSSL has already changed these defaults, smart people who know what they are doing have already agreed and documented that this is a good idea, and ruby is only hurting their users by dodging responsibility. edit: spelling.

dperfect 13y ago
Yes, I agree - the ruby project should always ship the most secure ruby possible, all the time. Would you rather have a ruby-core of honest, hardworking developers who prefer to "delegate the task to other people" who are experts in security - because they admit their own weaknesses, or a ruby-core of arrogant developers who overstep their area of expertise just to try and deliver your "most secure ruby possible" - but more than likely worsening security? It sounds to me like they're doing the most responsible thing they possibly can given the circumstances. If you or anyone else is in a position to do better, then by all means, step up and bless the ruby world with your supreme intellect. admitting weakness + asking for help != dodging responsibility
- kingkilr 13y ago
  Let us present a third possibility: Maybe they shouldn't have shipped a TLS client if they weren't prepared to take responsibility for how it was configured.
  - dperfect 13y ago
    True, and by that same logic maybe anyone using ruby's TLS client shouldn't ship anything if they aren't prepared to take responsibility for how it's configured (since the default configuration can be overridden at any point from OpenSSL on up).
    - kingkilr 13y ago
      Sure, any consumer of this API really should fix it themselves to have a secure configuration. But I submit that basically none of them are. An API where almost everyone who uses it wrong is not a good API. When the consequence of using it wrong is poor security, that's a dangerous API. Knowingly shipping dangerous APIs is irresponsible. OpenSSL is a god damned shitshow, no questions from me, it's bad, it's dangerous, it's irresponsible. But they shipped something based on OpenSSL, and now they're making a deliberate decision not to act to protect their users. That's not cool, and that's unacceptable to me. If I actually used Ruby, this would make me reconsider that.
      - donaldstufft 13y ago
        Importantly, every layer in the stack is responsible for it's own security. A consumer of this API should be making sure that it's optimally configured and configure it differently where it's not. Any project that isn't doing that should have security reports sent to it to tell it to do that and if they refuse they are guilty of the same sort of negligence as ruby core. However the fact that other people should also be claiming responsibility for their own security does not absolve ruby of it's own responsibilities.

dperfect 13y ago

Yes, I agree - the ruby project should always ship the most secure ruby possible, all the time. Would you rather have a ruby-core of honest, hardworking developers who prefer to "delegate the task to other people" who are experts in security - because they admit their own weaknesses, or a ruby-core of arrogant developers who overstep their area of expertise just to try and deliver your "most secure ruby possible" - but more than likely worsening security? It sounds to me like they're doing the most responsible thing they possibly can given the circumstances. If you or anyone else is in a position to do better, then by all means, step up and bless the ruby world with your supreme intellect. admitting weakness + asking for help != dodging responsibility

kingkilr 13y ago
Let us present a third possibility: Maybe they shouldn't have shipped a TLS client if they weren't prepared to take responsibility for how it was configured.
- dperfect 13y ago
  True, and by that same logic maybe anyone using ruby's TLS client shouldn't ship anything if they aren't prepared to take responsibility for how it's configured (since the default configuration can be overridden at any point from OpenSSL on up).
  - kingkilr 13y ago
    Sure, any consumer of this API really should fix it themselves to have a secure configuration. But I submit that basically none of them are. An API where almost everyone who uses it wrong is not a good API. When the consequence of using it wrong is poor security, that's a dangerous API. Knowingly shipping dangerous APIs is irresponsible. OpenSSL is a god damned shitshow, no questions from me, it's bad, it's dangerous, it's irresponsible. But they shipped something based on OpenSSL, and now they're making a deliberate decision not to act to protect their users. That's not cool, and that's unacceptable to me. If I actually used Ruby, this would make me reconsider that.
    - donaldstufft 13y ago
      Importantly, every layer in the stack is responsible for it's own security. A consumer of this API should be making sure that it's optimally configured and configure it differently where it's not. Any project that isn't doing that should have security reports sent to it to tell it to do that and if they refuse they are guilty of the same sort of negligence as ruby core. However the fact that other people should also be claiming responsibility for their own security does not absolve ruby of it's own responsibilities.