Project

General

Profile

Actions

Bug #1277

closed

Incorrect passing of file handle between runtime libraries in OpenSSL extension

Added by cfis (Charlie Savage) about 12 years ago. Updated almost 10 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Target version:
ruby -v:
ruby 1.9.2dev (2009-03-12) [i386-mswin32_90]
Backport:
[ruby-core:22859]

Description

=begin
The openssl extension uses the BIO_new_fp openssl api, which takes a stream. This causes segmentation faults on windows if openssl and the openssl ruby extension are using different runtime c libraries since you can't pass streams between libraries.

Better to use BIO_new_file.

Patch attached.
=end


Files

ossl_bio.patch (639 Bytes) ossl_bio.patch cfis (Charlie Savage), 03/13/2009 01:21 AM
Actions #1

Updated by nobu (Nobuyoshi Nakada) about 12 years ago

  • Status changed from Open to Rejected

=begin

=end

Actions #2

Updated by cfis (Charlie Savage) about 12 years ago

=begin
Hi Nobu,

I'm curious why you rejected this patch. Is there any real difference between Ruby opening the file or openssl opening the file?

The reason I think it is important is that it causes a segmentation fault if you mix runtime libraries on Windows. Say a Windows developer downloads Openssl binaries from here (this is the recommended link from the openssl home page):

http://www.slproweb.com/products/Win32OpenSSL.html

Those are built with VC2008 it seems. So if you have a MingW built version of Ruby then this call will result in a segmentation fault. Using the file api, as the patch does, fixes the problem.

Would you accept a patch if it does an #ifdef just for Windows?

Charlie
=end

Actions #3

Updated by nobu (Nobuyoshi Nakada) about 12 years ago

=begin
Hi,

At Fri, 13 Mar 2009 17:00:22 +0900,
Charlie Savage wrote in [ruby-core:22868]:

I'm curious why you rejected this patch. Is there any real
difference between Ruby opening the file or openssl opening
the file?

IO isn't always associated with a file, and the file may has
been renamed or unlinked.

The reason I think it is important is that it causes a
segmentation fault if you mix runtime libraries on Windows.
Say a Windows developer downloads Openssl binaries from here
(this is the recommended link from the openssl home page):

What about errno?

--
Nobu Nakada

=end

Actions #4

Updated by cfis (Charlie Savage) about 12 years ago

=begin

IO isn't always associated with a file, and the file may has
been renamed or unlinked.

Ah, that's a good point. Maybe ruby could convert the io stream to a string and pass that to openssl (at least on Windows)?

Note that I have built ruby with msvcr90d.ll, but all the extension libraries (iconv, openssl, etc.) are built with msvc90.dll. I've run into two issues - the memory issue (fixed) and this file issue.

What about errno?

Yes, I remember you mentioned this the other day. What is the issue? Do you have some example code I could look at by chance? I've never run into this problem with ruby (I have seen an issue once in the gdal code base).

Thanks for taking the time to go through all these issues.

=end

Actions #5

Updated by daz (Dave B) about 12 years ago

=begin
Charlie,

I was searching earlier for some explanation and came up with a post from July 2006.

Small world, the author is you :)

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/8267

On Windows, errno is implemented by macro (in errno.h) to a function:
#define errno (*_errno())

Different runtimes might have different opinions on where the real errno resides.

Searching the Ruby source tree finds quite a few ref's to errno ... /\s+errno\W/

=end

Actions #6

Updated by cfis (Charlie Savage) about 12 years ago

=begin
Well that's ironic :)

If only I had a better memory.

Charlie
=end

Actions

Also available in: Atom PDF