Bug #6830
closed
test failure test_constants(OpenSSL::TestConfig) [/ruby/test/openssl/test_config.rb:27] on Mac + homebrew
Added by kosaki (Motohiro KOSAKI) over 12 years ago.
Updated about 12 years ago.
ruby -v:
ruby 2.0.0dev (2012-08-04 trunk 36617) [x86_64-darwin12.0.0]
[ruby-core:46974]
Description
When using homebrew openssl, following test failure was happen.
- Failure:
test_constants(OpenSSL::TestConfig) [/Users/kosaki/ruby/git/test/openssl/test_config.rb:27]:
Exception raised:
<#<Errno::ENOENT: No such file or directory - /usr/local/openssl-1.0.1c/openssl.cnf>>.
rough analysis.
homebrew installed openssl library to "/usr/local/Cellar/openssl/1.0.1c".
and following program output "/usr/local/openssl-1.0.1c".
int main()
{
printf("%s\n", X509_get_default_cert_area());
return 0;
}
I'm using following configure options.
configure
--disable-install-doc
--with-baseruby=/usr/bin/ruby
--prefix=${HOME}/local/ruby-${suffix}
--program-suffix=-${suffix}
--with-openssl-dir=/usr/local/Cellar/openssl/1.0.1c
So, I have several questions.
- Is X509_get_default_cert_area() a right way to obtain configuration file?
- If yes, is this homebrew bug?
- if yes, should we skip this test when using Mac OS X?
- Status changed from Assigned to Feedback
Click the update button, then click "(More)". You can continue editing the description.
- Description updated (diff)
- Status changed from Feedback to Assigned
=begin
Hello guys,
If I can chime in, something similar happens on Windows:
https://github.com/oneclick/rubyinstaller/pull/120#issuecomment-6641054
And we workaround the issue by setting (({OPENSSL_CONF})) environment variable.
Now, I believe the root issue is not OpenSSL extension but OpenSSL itself that is using hardcoded paths.
At least Ruby tests should check if the default configuration file exists prior attempting to load it, as suggested in the RubyInstaller comment.
This issue is very common on Windows, where packages/libraries can be relocated to different drives or paths altogether, turning hardcoded paths into a problem.
=end
Thanks for the detailed description! Luis has pointed out the issue on Windows to me already, and we agreed that this is probably a problem with OpenSSL itself. For quick relief, I will implement the check for the existence of the file about to be loaded and I'd also skip the test whenever it causes problems. Once done, I'll look into ways to avoid the issue with hardcoded paths altogether.
- Is X509_get_default_cert_area() a right way to obtain configuration file?
Hmm, I'll investigate if there are better ways or alternatives.
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
This issue was solved with changeset r36666.
Motohiro, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.
- test/openssl/test_config.rb (OpenSSL#test_constants): skip this
test if platform is Mac OS X or Windows. [Bug #6830]
On my Windows box, OpenSSL::Config::DEFAULT_CONFIG_FILE returns the right path.
So, this problem is not platform dependent but user's environment dependent.
Therefore, I can't agree r36666.
- Status changed from Closed to Feedback
- Assignee changed from MartinBosslet (Martin Bosslet) to usa (Usaku NAKAMURA)
On my Windows box, OpenSSL::Config::DEFAULT_CONFIG_FILE returns the right path.
Which path do your OpenSSL return? I'm ok that only Mac and MinGW skip this test.
usa (Usaku NAKAMURA) wrote:
On my Windows box, OpenSSL::Config::DEFAULT_CONFIG_FILE returns the right path.
So, this problem is not platform dependent but user's environment dependent.
Therefore, I can't agree r36666.
Test is incorrect, it should check if default file exist and skip if doesn't.
On windows if you change location openssl dlls it will cause an error, as explained in the github links I've included before.
So is not a problem of platform but a hardcoded path on openssl.
Usa, can you tell us if you moved OpenSSL dlls to different directories and verified OpenSSL::Config::DEFAULT_CONFIG_FILE?
- Status changed from Feedback to Assigned
- Assignee changed from usa (Usaku NAKAMURA) to kosaki (Motohiro KOSAKI)
(1) "is not a problem of platform but a hardcoded path on openssl."
Yes, I think so, too.
(2) "if you moved OpenSSL dlls to different directories and verified OpenSSL::Config::DEFAULT_CONFIG_FILE?"
Of course, it fails.
So, should not skip by platform, but should determine whether to skip or not
to skip by another method, such as checking the existance of the config file,
as luis said.
(1) "is not a problem of platform but a hardcoded path on openssl."
Yes, I think so, too.
(2) "if you moved OpenSSL dlls to different directories and verified OpenSSL::Config::DEFAULT_CONFIG_FILE?"
Of course, it fails.
So, should not skip by platform, but should determine whether to skip or not
to skip by another method, such as checking the existance of the config file,
as luis said.
This test confirm OpenSSL::Config::DEFAULT_CONFIG_FILE correctness. Therefore,
when we skip the test if OpenSSL::Config::DEFAULT_CONFIG_FILE is
incorrect, it doesn't
test any meaningful thing. I just suggest to remove the test instaed
if we can't use platform
check.
At least, the condition is not exact.
With MacPorts OpenSSL, the constant has a correct path.
- % Done changed from 100 to 50
On Fri, Aug 17, 2012 at 8:42 AM, nobu (Nobuyoshi Nakada)
nobu@ruby-lang.org wrote:
Issue #6830 has been updated by nobu (Nobuyoshi Nakada).
At least, the condition is not exact.
With MacPorts OpenSSL, the constant has a correct path.
Is there any way to detect MacPorts? I have no idea.
- Status changed from Assigned to Feedback
- Assignee changed from kosaki (Motohiro KOSAKI) to nobu (Nobuyoshi Nakada)
Now tests it if the file exists.
- Status changed from Feedback to Closed
- % Done changed from 50 to 100
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0