Guess this is why metasploit has started segfaulting.
Drew Yao
· 1 year ago
"In fact, one of the test cases showed that the official release missed one of Drew’s patches."
To clarify, that(crash when concatenating a string to itself) was a regression introduced in the latest version. It's fixed by http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/bra... which is not yet in a released official version.
The version of Ruby shipped with Mac OS X is not affected because it never had that regression.
Eric Monti
· 1 year ago
@Drew
May want to double check that. The string concatenation segfault I pasted into my post (http://www.matasano.com/log/1070/updates-on-dre...) was created using the stock ruby interpreter on OS X Leopard.
Drew Yao
· 1 year ago
That test case would have triggered a different bug, an integer overflow, prior to Mac OS X 10.5.4.
In the patched official version of ruby, it would trigger a separate bug (dangling pointer after realloc). This bug never existed in the Apple-shipped version of Ruby.
Yeah
· 1 year ago
This is why meta meta meta meta self hacked on hacked object building helper do it all syntax fletching projects fail.
Stephane Grenier
· 1 year ago
This seems to be something that needs to be learned, relearned, and relearned again. People complain that they want a fast and agile system, and that's great. However as a system becomes more mainstream, some processes have to be built to verify that it still works for everyone.
When Ruby existed before Rails (RoR) it didn't matter that much. However now that you have more and more people jumping in, the speed of changes must slow down.
It's interesting to see the parallels between Ruby and Java. Early on Java was able to make bigger and quicker changes because it had a smaller community. Now, after over a decade, changes take more time, require more testing, and better adoption by the whole community.
Don't think this won't eventually happen to Ruby if it becomes mainstream. Eventually the speed of change will have to slow down to make sure nothing gets broken along the way. Breaks like this will become unacceptable.
Bleeding edge is great, but it has its costs. As long as the benefits outweigh the costs, it's all great!
Adam
· 1 year ago
Since 2 of your three are targeted at software creators, I'm surprised that you don't list "test the hell out of your releases" or "be transparent about your test process."
Why isn't Rubyonrails part of the Ruby test suite?
Max Caceres
· 1 year ago
@Stephane: agreed, although I don't think becoming more mainstream is a bad thing (not that you were implying that). The fact that there's a substantial level of attention highlights the fact that the Ruby team has done a great job so far.
@Adam: I don't know, and it is surprising in a number of ways. Testing seems to be ingrained within the Ruby ethos, most Ruby projects come with great test suites that can be run very easily.
To be clear though, I think Ruby releases do get tested before GA, the problem is that Rails is not part of these tests.
Stephane Grenier
· 1 year ago
Hi Max,
You're right, I'm not implying that going mainstream is a bad idea, it's a good thing! :) And they've done a good job so far.
All I'm saying is that getting to the next level means that you'll lose a lot of your flexibility and speed. The more adoption a language has, the more luggage it needs to support. And don't forget that if Ruby supports Rails, Rails supports other websites.
Something else I'd like to quickly note, I believe that a lot of the excitement about RoR also stems from the fact that most RoR implementations are new, and they don't have to support legacy monsters. Give it another 5 years and it will be in the same boat as all the other more "mature" languages.
And this is not a bad thing, it's just something we all need to be aware of. Getting to that stage is a very good thing, it means you have a great product/language that's benefiting many people!
Chris
· 1 year ago
Did I read that correctly? Ruby maintainers didn't have a release branch, so they patched the latest dev build and threw it out there, thinking there would be no problems?
Even without a branch, couldn't they have just rolled back to whatever revision corresponded to the release date, created a branch after the fact, and patched from there?
While Ruby is no Java in terms of maturity, it's still been around for long enough where there should be a more robust development/test process.
Carey
· 1 year ago
Chris, it’s really easy to create a branch or tag from an arbitrary Subversion revision, without needing to roll back the checked out copy at all. See the example at the end of: http://svnbook.red-bean.com/en/1.4/svn.ref.svn....
I have to admit that this has made me a bit lax about tagging releases on internal projects.
Max Caceres
· 1 year ago
@Chris: ruby has release branches. My understanding is that by the time the security fixes were applied there were other unreleased changes in them. In trying to respond quickly to the vulnerabilities the releases were cut with these other changes in them.
All Comments
To clarify, that(crash when concatenating a string to itself) was a regression introduced in the latest version. It's fixed by http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/bra...
which is not yet in a released official version.
The version of Ruby shipped with Mac OS X is not affected because it never had that regression.
May want to double check that. The string concatenation segfault I pasted into my post (http://www.matasano.com/log/1070/updates-on-dre...) was created using the stock ruby interpreter on OS X Leopard.
In the patched official version of ruby, it would trigger a separate bug (dangling pointer after realloc). This bug never existed in the Apple-shipped version of Ruby.
When Ruby existed before Rails (RoR) it didn't matter that much. However now that you have more and more people jumping in, the speed of changes must slow down.
It's interesting to see the parallels between Ruby and Java. Early on Java was able to make bigger and quicker changes because it had a smaller community. Now, after over a decade, changes take more time, require more testing, and better adoption by the whole community.
Don't think this won't eventually happen to Ruby if it becomes mainstream. Eventually the speed of change will have to slow down to make sure nothing gets broken along the way. Breaks like this will become unacceptable.
Bleeding edge is great, but it has its costs. As long as the benefits outweigh the costs, it's all great!
Why isn't Rubyonrails part of the Ruby test suite?
@Adam: I don't know, and it is surprising in a number of ways. Testing seems to be ingrained within the Ruby ethos, most Ruby projects come with great test suites that can be run very easily.
To be clear though, I think Ruby releases do get tested before GA, the problem is that Rails is not part of these tests.
You're right, I'm not implying that going mainstream is a bad idea, it's a good thing! :) And they've done a good job so far.
All I'm saying is that getting to the next level means that you'll lose a lot of your flexibility and speed. The more adoption a language has, the more luggage it needs to support. And don't forget that if Ruby supports Rails, Rails supports other websites.
Something else I'd like to quickly note, I believe that a lot of the excitement about RoR also stems from the fact that most RoR implementations are new, and they don't have to support legacy monsters. Give it another 5 years and it will be in the same boat as all the other more "mature" languages.
And this is not a bad thing, it's just something we all need to be aware of. Getting to that stage is a very good thing, it means you have a great product/language that's benefiting many people!
Even without a branch, couldn't they have just rolled back to whatever revision corresponded to the release date, created a branch after the fact, and patched from there?
While Ruby is no Java in terms of maturity, it's still been around for long enough where there should be a more robust development/test process.
I have to admit that this has made me a bit lax about tagging releases on internal projects.