brew doctor 'brew unlink' openssl

[alobaid]

After the laptop script if I run brew doctor I always get this so should I unlink or just ignore this ??

Warning: Some keg-only formula are linked into the Cellar.
Linking a keg-only formula, such as gettext, into the cellar with
brew link <formula> will cause other formulae to detect them during
the ./configure step. This may cause problems when compiling those
other formulae.

Binaries provided by keg-only formulae may override system binaries
with other strange results.

You may wish to brew unlink these brews:
openssl

[bmkmanoj]

+1. I too observed the same warning (OS: El Capitan).

[alobaid]

OS El Capitan here as well sorry I forgot to say that :)

[wlads]

laptop.log install openssl and force link:

Apple has deprecated use of OpenSSL in favor of its own TLS and crypto libraries

Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add to your
build variables:

    LDFLAGS:  -L/usr/local/opt/openssl/lib
    CPPFLAGS: -I/usr/local/opt/openssl/include

Not sure about the best solution here:

1. Use Homebrew's OpenSSL and doctor complains about not being a keg-only formula

2. Define LDFLAGS and CPPFLAGS when installing gems that need Homebrew's OpenSSL if it is not linked

3. Have problems compiling some sources like e.g. after running brew unlink openssl couldn't install puma gem (mini_ssl.o) and link openssl just to compile and then unlink

What do you think are the (dis)advantages of using Homebrew's OpenSSL vs Apple's TLS and crypto libraries??

PS: OSX El Capitan

[croaky]

Thanks for the reports and the options.

I think I'm leaning toward option number 1 above.

While the Laptop script is Mac-only, I'm a little nervous about its new-ness and different-ness compared to our Linux colleagues and Linux deployment environments, particularly for Ruby programs. We also sometimes do some lightweight preparation of SSL certificates that I believe typically use OpenSSL.

eventmachine/eventmachine#602 is an example of the hoops individual Ruby gem installations might need to go through without the OpenSSL link forcing.

I haven't done a lot of research on this yet, though. @jferris @mike-burns any thoughts?

[mike-burns]

I use LibreSSL, which is a fork of OpenSSL. In general, I'd rather use something besides OpenSSL -- OpenSSL continues to have more security issues than other TLS implementations, has the lowest code quality standards, and has the least open process. I recommend LibreSSL, BoringSSL, or Apple's TLS library for those reasons. (However, I don't use OS X.)

[geoffharcourt]

For Homebrew packages or Ruby gems that require OpenSSL's headers, is it easy for us to set options to point to the alternative such that the user doesn't need to specify them at install-time?

Given OpenSSL's dangerous policy regarding re-releasing multiple releases under the same version number when a release has issues, I'm very happy to see us move to another tool. I'd prefer that we use something OSS and subject to public scrutiny if using LibreSSL or BoringSSL presents no significant inconvenience to the end-user.

[croaky]

rbenv still seems to recommend OpenSSL in order to have Ruby installs generally go well: https://github.com/rbenv/ruby-build/wiki#suggested-build-environment

[mike-burns]

And indeed, the secure forks of OpenSSL won't work: https://github.com/rbenv/ruby-build/wiki#openssl-sslv3_method-undeclared-error

(All of them remove v3.)

So long as we're using rbenv, we need to do (1) as listed above?

[croaky]

I believe c8dca77 will address the brew doctor OpenSSL warning.

Whether to use an OpenSSL alternative could be a separate conversation if we wanted to explore that.