Robert Thau wrote:
(of many that went into p230 as released) that was causing the
series of svn revisions that turned 1.8.6-p111 into 1.8.6-p230 (or
we can cut it in half again, and proceed to the one patch that
history,
introduced
to p238 to eliminate the problem. It does not give the Japanese
script which also blew up — see separate thread here:
introduce more than one leak, and a minimal script would replicate
HTH,
rst@{ai,alum}.mit.edu
“I love it when a plan comes together”. 
Jessee Hallett was talking
about the theory of patches in our monthly PDX Ruby meeting Tuesday.
This too can be automated in Ruby.
BTW, you might want to read the article about binary search in
“Beautiful Code”. It turns out to be non-trivial (or, the author found a
way to make it non-trivial – I haven’t quite decided.)
On Jul 3, 11:45 am, Rob F. [email protected] wrote:
is good.
quotes), when someone uploaded a file from under their 'C:\Documents and
Settings' path.
I switched to Ruby-1.8.6-p111 with the security patches posted above,
and the problem went away.
So I’ve seen a bunch of different ideas about what folks should
use…but is there a definitive set of sources to use at this point.
Given the short anecdote above and from reading past posts… it seems
like I should give 1.8.6-p111 with the patch above a try.
Any reasons not to?
Mike B.
Hi,
My thanks to all for such great work. I’m trying to figure out from the
msgs which is the right patch for ruby_1.8.6.p111
It seems that it would be
Posted by Hongli L. on 23.06.2008 15:40
I’ve made an updated patch set:
http://blog.phusion.nl/assets/r8ee-security-patch-20080623-2.txt
But when I run it using patch against ruby-1.8.6-p111, I get the
following:
$ patch < ../ruby_1.8.6.p111.ee-security-patch-20080623-2.txt
patching file array.c
patching file bignum.c
patching file eval.c
patching file intern.h
patching file io.c
can't find file to patch at input line 207
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/lib/webrick/httpservlet/filehandler.rb b/lib/webrick/httpservlet/filehandler.rb
|index 410cc6f..c8278b7 100644
|--- a/lib/webrick/httpservlet/filehandler.rb
|+++ b/lib/webrick/httpservlet/filehandler.rb
--------------------------
File to patch: EOF [I entered cntrl-d at this point]
Skip this patch? [y] y
Skipping patch.
4 out of 4 hunks ignored
patching file sprintf.c
patching file string.c
$
Advice would be much appreciated.
Thanks and regards,
Larry in New York City
Larry K. wrote:
My thanks to all for such great work. I’m trying to figure out from the
msgs which is the right patch for ruby_1.8.6.p111
It seems that it would be
Posted by Hongli L. on 23.06.2008 15:40
I’ve made an updated patch set:
http://blog.phusion.nl/assets/r8ee-security-patch-20080623-2.txt
I do believe that’s the right patch.
But when I run it using patch against ruby-1.8.6-p111, I get the
following:
[code]
$ patch < …/ruby_1.8.6.p111.ee-security-patch-20080623-2.txt
… but wrong command line. Since the patch has filename paths starting
with a/ and b/, you need to give -p1 to make patch strip off that part.
(And you need to be in the top of the source directory, but you probably
already are.)
Rob F. wrote:
… but wrong command line. Since the patch has filename paths starting
with a/ and b/, you need to give -p1 to make patch strip off that part.
Yup, that was it.
Thank you for your expertise and time.
Regards,
Larry
Larry K. wrote:
Rob F. wrote:
… but wrong command line. Since the patch has filename paths starting
with a/ and b/, you need to give -p1 to make patch strip off that part.
Yup, that was it.
Larry: If you’re running a modern version of FreeBSD, Ubuntu, Debian,
Fedora, Gentoo and some others, you may want to consider using their
updated packages because these contain the patches and will be easier to
install/update.
Rob: Thanks.
-igal
http://dev.smartleaf.com/misc/p230_fixit_patch.txt
This reverts changeset 17222 from the ruby_1_8_6 branch of the
main svn repository, which doesn’t look security-related, at
least at first blush (though it may be a failed backport from
another line of development).
I ran this against the Rails 2.0 and RSpec 1.1.4 test
suites, no seg faults, no glibc errs, and the same set of tests
succeeded/passed between this patched version and the stock p111. It ran
fine against automateit 0.80607 and the various Rails apps I tried. This
is good.
I was running Ruby-1.8.6-p230 with this patch for about a week on our
multi-rails-app server, but then came across a problem in an old Rails
app (originally Rails 1.1.6, which we upgraded to 1.2.6 in a failed
attempt at fixing this).
The problem was in file uploads from an Internet Explorer client. The
file object’s original_filename method was returning just 'Documents,
and the full_original_filename method was returning just ‘"C:\Documents’
(including the initial double-quotes, but not including the single
quotes), when someone uploaded a file from under their 'C:\Documents and
Settings' path.
I switched to Ruby-1.8.6-p111 with the security patches posted above,
and the problem went away.
Mike B. wrote:
If I want to use a 1.8.6 which solves the security issues but does not
have any segfault etc. breakage, what is the current advice?.
Is it p111 plus some patch?
Or might the dust settle soon on an official release?
Thanks much.
– Mike B.
Uhmmm, should I have asked this on core?
– Mike B.
If I want to use a 1.8.6 which solves the security issues but does not
have any segfault etc. breakage, what is the current advice?.
Is it p111 plus some patch?
Or might the dust settle soon on an official release?
Thanks much.
– Mike B.