Phil Ross wrote:
It would appear that there are (at least) two separate areas where
segmentation faults are being raised. Revision 17530 fixes segmentation
faults with string concatenation that was causing my Rails applications
to crash:
http://www.ruby-forum.com/topic/157250
I guess that the root cause must be revision 17222 in the ruby_1_8_6
branch that the smartleaf patch reverts.
Ah, thanks for the update.
So before we discard the 17222 patch too casually … can anyone explain
what Matz was trying to do there? He clearly went through a fair amount
of effort to try to copy those crefs, but why? And does anything else
depend on that change?
-igal
Igal K. wrote:
So before we discard the 17222 patch too casually … can anyone explain
what Matz was trying to do there? He clearly went through a fair amount
of effort to try to copy those crefs, but why? And does anything else
depend on that change?
Well, as noted earlier, really understanding this code requires
a fairly deep grounding in the internal data structures of MRI
1.8, which I haven’t got.
But, for what little it’s worth…
The code affected by the 17222 patch seems to mostly have to do
with the internal implementation details of “initialize_copy”
methods on Module and Class, and the cloning of an object’s
singleton class when the object itself is cloned. The newer,
post-17222 versions seem to copy more… or try to. More,
perhaps, if I’ve got the time to investigate the details of
MRI 1.8 representations of method tables…
Robert Thau
rst AT {ai,alum}.mit.edu
Any idea when the Windows one-click installer will be updated to Ruby
1.8.7? The question was asked earlier in the thread but no one
responded to it.
Robert Thau wrote:
Well, if we want the Japanese team to be more rigorous in applying test
suites in testing their stuff… we’ve got the test suites too.
People have reported that the current versions are broken on every
imaginable Ruby-related site and list for the last four days, so we as
users have done our part in pointing out the problem.
What can we do to lobby the Ruby maintainers to prevent a repeat of this
in the future? How do we get a “red telephone” or something so we can
contact them about critical errors? How do we convince them to respond
back to the community in a timely manner about stuff like this? And how
do we convince them to at least run the RubySpec, Rails and RSpec test
suites before shipping an official version to avoid such a problem in
the future?
really understanding this code requires
a fairly deep grounding in the internal data structures of MRI
Unfortunately, I don’t have the expertise to make sense of that code and
can only recognize that something is obviously wrong and try to contact
people that may be able to do something. If ruby-talk and ruby-core
aren’t the right places, where do we find someone with this expertise?
the silence is somewhat troublesome to me too.
I’ve contacted other lists and blogs I mentioned earlier, sent out a
broadcast to ruby-core, sent emails, submitted a RubyForge ticket, and
even tried the #ruby IRC channel. I don’t know what else I can do at
this point.
The maintainers published the code for the security patches on the 18th,
thus giving crackers almost a week head start in finding an exploit in
older versions. They then shipped broken releases on the 20th, making it
impossible for anyone to upgrade to an official version. And we haven’t
heard anything since. What’s going on?
How do we get a hold of the official maintainers?
-igal
Dominic S. wrote:
Maybe you should try posting a issue on the new redmine bug tracker
they have set up for ruby
http://redmine.ruby-lang.org/projects/show/ruby-18
I’ve added a ticket on RedMine and it sent out a broadcast to ruby-dev.
Thank you for the suggestion, Dominic.
-igal
Just wanted to say that we all appreciate those fixes you guys have been
able to hack together so quickly, and thanks for your efforts in getting
through to the Ruby maintainers. There are a lot of folks out here
looking to re-stabilize their apps.
Cheers,
-Jason
Maybe you should try posting a issue on the new redmine bug tracker
they have set up for ruby
http://redmine.ruby-lang.org/projects/show/ruby-18
How do we convince them to respond back to the community in a
timely manner about stuff like this?
Please don’t speak for everyone. I personally rather not want to be
grouped to people like Mr. Shaw that use every opportunity to lash out
at something they dislike.
Different use cases will remain different - for me these issues are
simply not important at all, for example. And I don’t want to give the
ruby devs the feeling that the “community” as such is an angry mob. I’d
rather see more effort to improve the docu of ruby, API docs as such are
boring and not that helpful, but there are also many examples of people
who went to great length to make their docu usable.
We are individuals with individual opinions, it is only polite to speak
primarily merely for yourself, not for, or in the name of, others.
I however want to say one thing - the original team (or dev) that
reported the security problem(s) should have either described exactly
what the problem was (including giving patches), or simply shut up. This
whole issue is blown out of proportion by being repeated over and over
again.
The way to “handle” security-related problems seems inherently unfair to
people who don’t have the time to dig for the patches or find the
problem. And some people did invest their time to find out which patches
were applied, which changes were done etc… etc…
I still dont care about the security-related problems, but to be honest
this would be the only way to handle security related problems in a fair
manner for everyone - by telling what exactly was the problem.
I am quite sure that professional crackers will collect all information
anyway, can glance at patches and changes, and they will have more
knowledge and resources to make any real use of this anyway, no matter
if a problem is kept secret or not. So I do not understand at all why
the original reporter did not reveal the info as well. There is no valid
use case that makes sense for keeping things secret, but loudly
proclaiming that there are problems at the same time.
Marc H. wrote:
for me these issues are simply not important at all […] I still dont care about the security-related problems
That’s nice. I have companies that depend on me to deliver applications
on a platform they can rely on, so I do care.
How do we convince them to respond back to the community in a
timely manner about stuff like this?
Please don’t speak for everyone. I personally rather not want to be
grouped to people like Mr. Shaw that use every opportunity to lash out
at something they dislike.
What’s this have to do with Zed? Six days ago we were told by the
maintainers that, “Multiple vulnerabilities in Ruby may lead to a denial
of service (DoS) condition or allow execution of arbitrary code.” They
still haven’t shipped a working fix or said a single word to us
regarding this topic. I’ve personally posted on every list and every bug
tracker they have, so they couldn’t have missed it, and still silence.
I’m disappointed.
In contrast, I was really impressed by how professionally Stanislav,
Hongli and Robert handled the situation and how quickly they delivered
working solutions.
I do not understand at all why the original reporter did not reveal the info as well.
Because that’s not the reporter’s responsibility. Drew Yao reported the
bug to the maintainers, and Dominique Brezinski claims that he reported
the same problems two years ago but was ignored. Taking action on
reports and dealing with public relations is the responsibility of the
official maintainers, not the reporter.
-igal
M. Edward (Ed) Borasky wrote:
http://www.retrospectives.com/pages/retroPrimeDirective.html
Thanks for the reminder.
To put my earlier comments in perspective. I really enjoy working with
Ruby, work hard to promote it, publish multiple open source projects
with it, and want it to succeed.
-igal
Has anyone ported this “fix patch” to 1.8.5-p231? I get patch errors
using this one.
Larry Rosenman wrote:
Has anyone ported this “fix patch” to 1.8.5-p231? I get patch errors
using this one.
I haven’t heard of any such effort.
Do you have a compelling reason to stay with 1.8.5? If you do, you may
be able to use the Smartleaf 1.8.6 patch for p230 as a guide. It
basically reverts one bad commit, so if you can just walk through the
commits in the 1.8.5 SVN branch till you find a conceptually similar
commit, you can try reverting it.
-igal
Igal K. wrote:
grouped to people like Mr. Shaw that use every opportunity to lash out
In contrast, I was really impressed by how professionally Stanislav,
-igal
http://www.retrospectives.com/pages/retroPrimeDirective.html
Igal K. wrote:
Larry Rosenman wrote:
Has anyone ported this “fix patch” to 1.8.5-p231? I get patch errors
using this one.
I haven’t heard of any such effort.
Do you have a compelling reason to stay with 1.8.5? If you do, you may
be able to use the Smartleaf 1.8.6 patch for p230 as a guide. It
basically reverts one bad commit, so if you can just walk through the
commits in the 1.8.5 SVN branch till you find a conceptually similar
commit, you can try reverting it.
-igal
We have one RoR app that is basically unmaintained. I’ll see if it’ll
work with 1.8.6 and this patch.
Thanks!
Larry Rosenman wrote:
We have one RoR app that is basically unmaintained. I’ll see if it’ll
work with 1.8.6 and this patch.
I’ve personally confirmed that both the Stanislav S. and Hongli L.'s
1.8.6p111 backport and the Smartleaf 1.8.6p230 revert patches both pass
the Rails 2.0 test suites, so you should be fine. Another alternative is
the Phusion Ruby Enterprise Edition, which uses the p111 backport.
The only thing I can remember being different between 1.8.5 and 1.8.6 is
that the breakpointer feature stopped working, so if you ever need that
feature, just use ruby-debug instead.
-igal
Larry Rosenman wrote:
Igal K. wrote:
Larry Rosenman wrote:
Has anyone ported this “fix patch” to 1.8.5-p231? I get patch errors
using this one.
I haven’t heard of any such effort.
Do you have a compelling reason to stay with 1.8.5? If you do, you may
be able to use the Smartleaf 1.8.6 patch for p230 as a guide. It
basically reverts one bad commit, so if you can just walk through the
commits in the 1.8.5 SVN branch till you find a conceptually similar
commit, you can try reverting it.
-igal
We have one RoR app that is basically unmaintained. I’ll see if it’ll
work with 1.8.6 and this patch.
Thanks!
1.8.6-p230 + http://dev.smartleaf.com/misc/p230_fixit_patch.txt
seems to not segfault or give me glibc corruption errors, and the app
works, so I am going to deploy it.
Thanks for the push, and especially the patch.
LER
Has anyone tried the latest 1.8.6. releases p231 through p236 to see if
they have the same problems with Rails as the p230 release does?
Good news: Urabe S. responded and fixed the segmentation faults in
his latest SVN release, see the ruby-core thread at
http://www.ruby-forum.com/topic/157392#695343
Bad news: The new version in SVN is failing dozens of tests that worked
fine in p111. This is bad because any apps that depend on that old
behavior will break. If you have time, please grab the files from
[http://redmine.ruby-lang.org/issues/show/199] and see if you can figure
out what’s going on.
Thanks!
-igal
PS: I’ve sent email to Brian F., the primary author of RubySpec to see
if he can lend a hand in making sense of the errors. Maybe in the
process we can also submit some code to RubySpec to improve its
coverage.
Could somebody please explain how to apply the Smartleaf Stanislav and
Hongli’s patches? I too am experiencing glibc segmentation problems and
would like to fix my local copy of rails 1.8.6.
Thanks!
Cheri
I’ve been watching http://redmine.ruby-lang.org/issues/show/199
but there hasn’t been a peep from the powers that be.
They seem to be maintaining “radio silence”.
Why might that be?
– Mike B.