--Cheers
--Ragav
I'm seeing segfaults now with 1.8.5.p231. Intermittent
--Cheers
--Ragav
On Fri, 2008-06-20 at 23:34 -0700, Shawn Balestracci wrote:
> # Shawn Balestracci on 21 Jun 06:10:
> I’m getting segfaults on 1.8.5-p231 as well.
>
> # Jay on 21 Jun 06:18:
> Segfaults on both 1.8.5-p231 and 1.8.6-p230. So I’m stuck between a
> serious security vulnerability and a patched version that brings my
> site down within two requests. Wonderful!
On the bright side, I've figured out (again) the needlessly awkward
steps needed to build these as debian/ubuntu packages so I can release
them when a working version is shipped.
-igal
Ruby Enterprise Edition is a fork of Ruby MRI created by Phusion, the
makers of Passenger aka mod_ruby. They have backported the security
fixes from ruby-1.8.6-p230, so they claim that EE is not affected by
these vulnerabilities. But EE is based on ruby-1.8.6-p111, so it
shouldn't break any applications. And they offer a deb package that
installs EE in parallel with MRI.
The main downsides of running EE are that you may have to reinstall
all of your gems; and the garbage collector is less efficient than the
one in included in MRI if you are not using Passenger to serve your
app.
http://koji.fedoraproject.org/koji/buildinfo?buildID=54190
Note that you have to install all the same version dependency RPMs along
with it.
b
Matz says the bug isn't exploitable enough to be able to cause arbitrary
code execution after all, but it's still worth upgrading if you have a
publicly exposed Ruby-based server.
Ruby Enterprise Edition is great, and worth experimenting with.
However, if you're running a reasonably modern OS, your distributor has
probably shipped a patched version. Unfortunately, because the Ruby
maintainers have thusfar refused to provide an official fix or review
the patches, the different variants being shipped have different issues.
For instance, Ruby 1.8.6p230 and later versions break Ruby API
compatibility and thus any patch based on these may fail to run your
existing apps, which is affecting Fedora's version. You're much better
off sticking to the p111 and p114 derived variants, like Ruby Enterprise
Edition and those shipped by FreeBSD, Gentoo, Ubuntu and Debian.
-igal
I've put together code which demonstrates this at: http://pastie.org/226715
-igal
See also:
* RedMine ticket: http://redmine.ruby-lang.org/issues/show/216
* ruby-core thread: http://www.ruby-forum.com/topic/158334
* ruby-talk thread: http://www.ruby-forum.com/topic/157034
-Jeremy
Current releases of FreeBSD, Ruby Enterprise, Ubuntu, Debian have
shipped patched versions based on p111 with between 6 to 11 total
unofficial patches. Older releases of Ubuntu and Debian ship a patched
version based on p36 with 15 unofficial patches. I believe that Gentoo
is shipping a patched version based on p114. These should all be okay.
However, Fedora was using p230 with the Smartleaf patch to fix segfauls,
but it looks like they'll have to rollback to an backport because of the
memory leak.
The different patch levels and mismatched numbers of total unofficial
patches are problematic because no one has a clear idea of which
combination is "right". The Ruby maintainers have thusfar refused to
review any of these patches and really want us to switch to their latest
versions, which have been plagued with segfaults, incompatible API
changes that no longer run typical Ruby code, memory leaks, etc.
As far as I can tell, the patched versions based on p111 and p114 are
most likely to have the best balance of being compatible, secure and
stable. However, it's worth keeping an eye on ruby-talk and ruby-core
to keep track of what's going on because the situation is rapidly evolving.
-igal
This years theme so far as I am aware
Really Ought to do something
P.S That was a joke - as I tell my kids it is quantity of humor not
quality !
Anyway if you are interested in helping out can you drop me a note. I
know there were some others interesting in maybe taking lead roles so I
hope I am not stepping on any toes by sending this out, but people have
been asking what we are going to do. So I thought I would at least see
what is happening.
At Rails I did ask the About Us folks if they would be willing to host
the event at their building, and they were open to the idea. If we want
to do that we should probably start getting coordinated with them.
Other suggestions for venue are of course welcome.
Can you respond back to the list if you are interested. If there gets
to be to much chatter we can take it off line or to some other mechanism.
if you want to reach me directly you can send to bleh...@comcast.net
--Bob
-igal
I'd be glad to assist. However, I missed the earlier ones and have a
rather limited understanding of what goes on and into these events. Can
you or someone else that's been to previous events give us a rundown of
the sorts of tasks that need to bed done? Having that list will be
helpful because we'll be able to more easily assign smaller,
clearly-identifiable tasks to interested individuals, because right now
it's a bit amorphous. :>
Also, sharing and tracking tasks and planning information on FOSCON may
be a good use of 37Signals Backpack [http://www.backpackit.com/].
> Can you respond back to the list if you are interested. If there gets
> to be to much chatter we can take it off line or to some other mechanism.
>
If traffic gets to heavy, the pdxruby-business may be a good list for
that sort of thing.
-igal
> I'd be glad to assist. However, I missed the earlier ones and have a
> rather limited understanding of what goes on and into these events.
> Can
> you or someone else that's been to previous events give us a
> rundown of
> the sorts of tasks that need to bed done? Having that list will be
> helpful because we'll be able to more easily assign smaller,
> clearly-identifiable tasks to interested individuals, because right
> now
> it's a bit amorphous. :>
I'm too busy to help organize things this year, but here's the basic
outline:
* Date: an evening during OSCON, preferably one without other highly
enticing events
* Venue: somewhere we can drink, eat, and set up a projector. Past
locations have been Free Geek and Holocene. Free Geek is probably not
big enough to handle current demand. Holocene was comfy but we lacked
blackout curtains needed to have a projector in the front room before
dusk last year.
* Format: Short (20 min.) talks on interesting things people are
doing with Ruby. Emphasis on recruiting from OSCON speakers
(practicing scheduled talk or giving alternate that was rejected),
and other interesting guests from out of town.
* Sponsors: to pay for pizza and perhaps a round of beer.
* Advertising and getting people to the venue: we've done walking
tours and taxi service from the convention center in the past. We
were listed in the O'Reilly user group program email last year--I
think Thomas contacted Marsee about that. We also spread the word on
mailing lists and pdx.rb-ers' blogs.
* Door prizes: various publishers have been happy to donate books in
the past.
Audrey
> Do you know if anyone has set up some kind of "continuous
> integration?"
I've used Hudson, which is a bit hefty. We've gotten a recommendation to
use CruiseControl.rb. Any others?
> What would be really nice would be some kind of setup
> that continuously downloaded the latest SVN Ruby 1.8.6, compiled it
> with debug options and "GCOV" tracing, ran the tests, posted the
> coverage results, test results and tracebacks for any crashes. I'm
> thinking about attempting this, but if somebody else has already done
> it, I'll go back to my profiling stuff (which is similar anyhow).
>
The script I'm preparing provides much of the wrapping, basically
dumping the results of all the different test suites into a reports
directory. Can you send me instructions on how to get the debug, gcov
tracing, coverage, and whatever else stuff? All I know how to do is
compile Ruby.
> It's times like this when I wish I knew Rails. :)
If you can tell us what shell commands to run, I'm sure we'll figure out
how to wrap them somehow. :)
-igal
I'm running ruby-1.8.6-p114, with the 'array', 'intern', 'sprintf',
and 'string' patches from the FreeBSD ports tree
(http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ruby18/files/) on
our production Rails app cluster, and haven't seen any stability
issues. The patches applied cleanly to my source tree, as well.
I suspect that the Debian/Ubuntu packages are based on a similar set
of patches, but for those running on other platforms (or using their
own Ruby build) this might be an easy way to get the basic security
updates.
-Lennon
P.S.: There are also a number of newer patches in the ports tree that
I haven't had a chance to evaluate. Has anyone else tried the patches
for 'bignum', 'parse', and 'regex'?
Anyway, I recommend we take these discussions to ruby-core where they'll
help the Ruby community at large. :)
> But I think the wider issue is that the BSD ports, Linux distros,
> etc., should be getting their source from a tree maintained by the
> Ruby community as automatically as humanly possible, rather than the
> Ruby community getting its source from BSD ports or Linux distros. :)
>
Absolutely. Random distro admins should not have to individually decide
which of dozens of unofficial patches to apply.
-igal
I wouldn't presume to have much to offer the Ruby core team with my
anecdotal experiences running an old release of Ruby and unofficial
FreeBSD patchset. If anything, I'd prefer to stay out of the way of
Matz + co. so they can stick to the important business of implementing
my favorite programming language.
> Absolutely. Random distro admins should not have to individually decide
> which of dozens of unofficial patches to apply.
Actually, it's entirely normal for distributions to maintain their own
patches for upstream software. There are a variety of reasons:
packagers don't always have or want upstream commit privs; patches can
be distro or OS-specific in a way that the upstream folks don't want;
security updates get backported to unsupported releases; etc., etc.
I actually tend to agree with Matz that the current Ruby release
process is fine. If you want rock-solid reliability for every update,
or never want to be surprised by API changes, then it's up to you to
do (or pay someone to do) a full QA round on new releases before
rolling them out into production. That may be your Linux distribution,
or Phusion, or someone else, but the point is, it isn't going to be
Matz and the ruby-core team any time soon.
Anyway, I'm happy enough to move on to other topics on this list.
--
Lennon Day-Reynolds <rco...@gmail.com>
http://rcoder.net/
Amen. This whole "zomg secruity!" episode has resulted in a lot of
people showing up on ruby-core and trying to get Matz et al to change
their procedures. We often forget that there is a strong, established
community of Japanese developers, and what we see on ruby-core is only a
small section of what's actually going on.
I, for one, would be much happier if everyone would chill out and let
the people who are actively working on the language continue to do so as
they see fit. Frankly, all the freaking out on ruby-core has left me
feeling embarassed to be a member of the US Ruby community.
Ben
Ben and Lennon, I respect you and your opinions, but absolutely can't agree.
Describing the community response as "zomg security", "freaking out" and
"embarrassing" is baffling to me. The maintainers told us that Ruby was
vulnerable to denial of service and arbitrary code execution attacks,
published all the code needed for writing an exploit, then vanished for
over a week without a word or working solution, and still haven't
provided an official fix or reviewed the unofficial patches. These sorts
of failures are enough to get people to switch to other implementations
or languages. I used and loved Perl for 10 years, but had to abandon
ship because of those kinds of mistakes, and I don't want to see that
happen to Ruby.
If you're currently running a patched version of Ruby, it's thanks to
the random new people that showed up and decided to get "in the way" to
create unofficial patches on ruby-talk and ruby-core. If the Ruby code
had been exploitable, their efforts would have been your only defense.
If these folks hadn't let the maintainers do as they "see fit", you'd
have also seen two dead-on-arrival official releases shipped recently
that suffered from memory leaks, bugs, and compatibility breakages.
I'm very glad that these people got in "the way" because they helped
resolve problems and made Ruby healthier. They began publishing fixes
within hours and collaborated to come up with the two patches that most
of us are using. They provided RubySpec, a volunteer effort to describe
the behavior of Ruby, which caught countless bugs and API errors that
would have otherwise made it impossible to run existing code. The
alternative implementation teams jumped in to lend a hand. Folks
transformed vague hearsay off blogs into reproducible tests that the
Ruby maintainers then used to fix bugs. They delivered automated build,
testing, and profiling systems to make it easy for the maintainers and
others to assert the quality their code. Matz, Shyouhei and the other
Ruby developers are better off because they have more tools, test
suites, and people to help them. They're working more closely with the
community to review code and changes before these are shipped. They've
expressed their intent to deliver compatible, quality Ruby releases. All
of this happened thanks to this community response.
> Frankly, all the freaking out on ruby-core has left me
> feeling embarassed to be a member of the US Ruby community.
Sorry to hear that. Frankly, all the recent contributions on ruby-talk
and ruby-core have left me feeling inspired by the English-speaking Ruby
community, and upbeat about Ruby and MRI's future.
-igal
The only mention of arbitrary code execution I saw was one of the Ruby
maintainers (can't remember if it was Matz or not) saying that they
believed it was *not* an issue. I still haven't seen it demonstrated.
Too often a vulnerability is discovered and people leap to the
conclusion that it is an execution vulnerability.
Do you watch ruby-dev? Was that list silent during the quiet period?
I don't read Japanese so I don't know the answer to that question. I
did scan the subject lines for a few days and it looked like there was
plenty of discussion.
We seem to forget that we're using a language that is actively being
developed by Japanese people, in Japanese, in Japan. We assume that
if we're not made aware of something by Matz himself that it is not
happening. In my experience, that has never been the case. There is a
cultural difference there, and we shouldn't expect Ruby's maintainers to
necessarily behave the way that we want.
> If you're currently running a patched version of Ruby, it's thanks to
> the random new people that showed up and decided to get "in the way" to
> create unofficial patches on ruby-talk and ruby-core. If the Ruby code
> had been exploitable, their efforts would have been your only defense.
> If these folks hadn't let the maintainers do as they "see fit", you'd
> have also seen two dead-on-arrival official releases shipped recently
> that suffered from memory leaks, bugs, and compatibility breakages.
Let me be clear: I don't have any problem with people reporting bugs and
submitting patches. You're absolutely right that it was solely due to
community effort that there are patches out there for these problems.
What bothers me is the attitude of entitlement displayed by a number
of people on the ruby-core list. Clamoring for new release management
policies, demanding that certain patches be applied or reverted,
requesting that releases be delayed... all of these things have happened
in the last two weeks on ruby-core, ruby-talk, IRC, blogs, twitter,
etc. These are examples of the presumptiveness that I think Lennon was
talking about, and that is what embarasses me.
Igal, it's important to me that you know that I'm not talking
specifically about you, because I know that it seems that way from the
context. It's everybody who has, for lack of a better phrase, been all
talk and no code in these threads. It's not that I don't understand or
am not sympathetic to the issues at hand. It's also not that I'm the
kind of guy who ignores issues and shouts "patches welcome!"
It's just that I perceive(d) a strong sense of indignation that the
needs of the community were not being met. This, of course, is up for
interpretation... it is my (perhaps vain) belief that Matz & Co. are
always diligently working to make Ruby the best it can be. They are all
much smarter than I am, and I trust that when issues like these come up,
they are being handled.
I'm aware that many other people do not share that attitude, but until
it's been proven to be wrong I'm going to continue believing :)
> I'm very glad that these people got in "the way" because they helped
> resolve problems and made Ruby healthier. They began publishing fixes
> within hours and collaborated to come up with the two patches that most
> of us are using. They provided RubySpec, a volunteer effort to describe
> the behavior of Ruby, which caught countless bugs and API errors that
> would have otherwise made it impossible to run existing code. The
> alternative implementation teams jumped in to lend a hand. Folks
> transformed vague hearsay off blogs into reproducible tests that the
> Ruby maintainers then used to fix bugs. They delivered automated build,
> testing, and profiling systems to make it easy for the maintainers and
> others to assert the quality their code.
I too am thankful for the people who stepped up and contributed. I
should point out, though, that all of the things you mentioned are
things that have either already existed for some time or have been asked
for in the (sometimes distant) past and just didn't happen until now.
Don't get me wrong, I'm glad they're here and whatever the impetus,
they're still valuable.
What I object to is people who complain and don't contribute... and
I don't mean just code contributions. As a convenient example, the
work that you (Igal) did on determining which patchsets were good and
which needed love, and tracking down the memory leaks were very helpful,
there's no doubt about it. In fact, for all I know you did a bunch more
after that, but I stopped paying attention because the threads were
making me angry.
> Matz, Shyouhei and the other Ruby developers are better off because
> they have more tools, test suites, and people to help them. They're
> working more closely with the community to review code and changes
> before these are shipped. They've expressed their intent to deliver
> compatible, quality Ruby releases.
Very true. I just don't think that this was ever *not* the case.
> Sorry to hear that. Frankly, all the recent contributions on ruby-talk
> and ruby-core have left me feeling inspired by the English-speaking Ruby
> community, and upbeat about Ruby and MRI's future.
I'm sorry if my original email seemed like an attack. It wasn't meant
to be directed at anyone in particular.
Ben
> Do you watch ruby-dev? Was that list silent during the quiet period?
I did, and there was silence for about a week. Admittedly, they began
discussing it a day after it occurred to me to post to ruby-dev. I don't
know if they simply didn't think this was a big deal until then, or
whether they didn't know about the problem because they weren't
monitoring the two official English-language Ruby bug trackers, nor the
mailing lists, news sources, etc.
> We assume that if we're not made aware of something by Matz himself that it is not happening.
I think that most people, including me, just wanted someone from the
official team tell us that they were aware of the problem and were
working on it. There was great relief when Shyouhei appeared.
> What bothers me is the attitude of entitlement displayed by a number
> of people on the ruby-core list. Clamoring for new release management
> policies, demanding that certain patches be applied or reverted,
> requesting that releases be delayed... all of these things have happened
> in the last two weeks on ruby-core, ruby-talk, IRC, blogs, twitter,
> etc. These are examples of the presumptiveness that I think Lennon was
> talking about, and that is what embarasses me.
>
> It's just that I perceive(d) a strong sense of indignation that the
> needs of the community were not being met. This, of course, is up for
> interpretation... it is my (perhaps vain) belief that Matz & Co. are
> always diligently working to make Ruby the best it can be. They are all
> much smarter than I am, and I trust that when issues like these come up,
> they are being handled.
>
I apologize for the misunderstanding. I didn't catch those distinctions
in your earlier message.
I'm grateful to Matz and his team, but many people are relying on them
to provide stable, backwards-compatible releases and timely responses to
critical problems. If they don't have the resources to provide this,
they should consider asking for donations, accepting volunteers, or
endorsing some 3rd party effort
Because the p230 release failed, many people got involved -- some were
more helpful than others. The folks suggesting process improvements
offered ideas that would make future releases smoother. The folks that
asked to delay releases had identified critical bugs that the
maintainers hadn't noticed or prioritized. I felt that most of these
comments were well-meaning requests and suggestions, maybe you
interpreted them as orders?
> What I object to is people who complain and don't contribute... and
> I don't mean just code contributions. As a convenient example, the
> work that you (Igal) did on determining which patchsets were good and
> which needed love, and tracking down the memory leaks were very helpful,
> there's no doubt about it. In fact, for all I know you did a bunch more
> after that, but I stopped paying attention because the threads were
> making me angry.
>
Thanks. However, you may have been frustrated because many of those that
got involved -- including me -- lacked the context, time and ability to
contribute enough, so you saw more half-baked opinions thrown around
than fully-featured solutions. Thankfully, despite these limitations and
scattered bits of knowledge, I was impressed by how people in those
lists were able to work together and created solutions greater than they
could have made on their own.
-igal