Hacker News new | past | comments | ask | show | jobs | submit login
If you're using Ruby trunk, regenerate your keys (ruby-lang.org)
134 points by peterhajas on Nov 5, 2011 | hide | past | favorite | 21 comments



A "counting bits" vs. "counting bytes" bug. Isn't crypto fun?


Software that doesn't work goes far beyond crypto algorithms.


That attitude is why we have so many crypto bugs. Crypto is (usually) software, and no software works 100% of the time.


I wouldn't call this a crypto bug. It's a non-crypto bug which just happens to be in the middle of some crypto code.


How common of a practice is it in the Ruby community to run the trunk version? Is it mainly just developers, or is it pretty widely used in production/development environments?


RVM, which is a standard tool to manage Ruby versions, does expose trunk:

  mil:~ poet$ rvm list known_strings | grep ^ruby
  ruby-head
  ruby-1.9.3-rc1
  ruby-1.9.3-preview1
  ruby-1.9.3-head
  ruby-1.9.2-p290
  ruby-1.9.2-p180
  ruby-1.9.2-head
  ruby-1.9.1-p431
  ruby-1.9.1-p378
  ruby-1.9.1-head
  ruby-1.8.7-p352
  ruby-1.8.7-head
  ruby-1.8.6-p420
  ruby-1.8.6-head
However, in my anecdotal experience most people run patch releases.


I've never heard of anyone running the trunk except those who are hacking the interpreter. There are fairly regular patch releases so there's no real drive to do so.


In production, I've never seen anyone running the trunk version. In development, fairly rare as well in my experience.


Very uncommon, even amongst the most progressive developers. Trunk is notoriously over the place (as it should be IMHO).


I'm just to lazy to compile trunk versions.


Yikes, this seems about as serious as the Debian OpenSSL bug a while back: key generation appears to work, but produces easily broken keys.


This is nowhere remotely nearly as bad as Debian's bug, which broke the underlying library underpinning most of the crypto on Linux, and broke the most universally sensitive component of that library.


Both cases cause key generation to produce weak, easily broken keys. I agree that far less software does key generation with Ruby than with OpenSSL, but that aside the severity of the bug seems quite similar.


While the effects caused by each bug might be on a similar level, I would argue that the fact that this particular bug was never released in a patch (I don't think I've ever seen anyone using Ruby trunk outside of those hacking the Ruby interpreter) makes it less severe.


The bug is pretty bad, but it's not as big of a deal because http://news.ycombinator.com/item?id=3201006


In other words, equally serious, but in software not nearly as widely used.


It'd be pretty bad if it were in any of the stable builds of ruby that people actually use in production. As it stands it's a month-old bug in a bleeding-edge repo, not a huge deal. Nice that someone caught it early!


This is bad, but it's not in the same league as the Debian ssh bug.


Luckily, the set of people affected is actually the intersection of people running Ruby trunk and people using Ruby's libraries to generate keys.


Could someone please explain to me what this code is doing in the Ruby tree in the first place?

My uses of OpenSSL in straight C don't involve performing this kind of bit twiddling, or really any bit twiddling, calculation, or manipulation at all. That's kind of the point of using OpenSSL.


Since the OpenSSL::PKey::RSA.generate method lets you generate RSA keys with a different exponent there is some manipulation needed between the ruby side and OpenSSL. From my understanding the code was part of a refactor to release the global interpreter lock, if possible, while generating RSA keys.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: