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;
}
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.
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.
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?
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.
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by