openssl dependency doesn't work

[JosephShering]

Compiling openssl v0.7.4
Build failed, waiting for other jobs to finish...
failed to run custom build command for openssl v0.7.4
Process didn't exit successfully: /Users/reactor/Projects/r_gifts/target/debug/build/openssl-3ceab475d186eefe/build-script-build (exit code: 101)
--- stdout
TARGET = Some("x86_64-apple-darwin")
OPT_LEVEL = Some("0")
PROFILE = Some("debug")
TARGET = Some("x86_64-apple-darwin")
debug=true opt-level=0
HOST = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
HOST = Some("x86_64-apple-darwin")
CC_x86_64-apple-darwin = None
CC_x86_64_apple_darwin = None
HOST_CC = None
CC = None
HOST = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
HOST = Some("x86_64-apple-darwin")
CFLAGS_x86_64-apple-darwin = None
CFLAGS_x86_64_apple_darwin = None
HOST_CFLAGS = None
CFLAGS = None
running: "cc" "-O0" "-ffunction-sections" "-fdata-sections" "-g" "-m64" "-fPIC" "-o" "/Users/reactor/Projects/r_gifts/target/debug/build/openssl-3ceab475d186eefe/out/src/c_helpers.o" "-c" "src/c_helpers.c"
ExitStatus(Code(1))

command did not execute successfully, got: exit code: 1

--- stderr
src/c_helpers.c:1:10: fatal error: 'openssl/ssl.h' file not found

include <openssl/ssl.h>

     ^

1 error generated.
thread '

' panicked at 'explicit panic', /Users/reactor/.cargo/registry/src/github.com-0a35038f75765ae4/gcc-0.3.21/src/lib.rs:772

[mcasper]

I ran into this problem recently and turns out my openssl had gotten linked to an older version. What does openssl version -a return?

[seanmonstar]

Yikes, forgot about this over the weekend.

Seeng that you're on a Mac, I'd bet the problem is that your computer currently still has the archaic version of openssl that OSX ships with. Try updating openssl.

[lilyball]

The problem is OS X doesn't ship with openssl/ssl.h anymore. Period. Apple has deprecated the use of OpenSSL on their platforms in favor of alternative libraries. The library is still present, but it's still the same 0.9.7 and 0.9.8 that Apple has provided for ages.

[lilyball]

Incidentally, the README of sfackler/rust-openssl states

OSX releases starting at 10.11, "El Capitan", no longer include OpenSSL headers which will prevent the openssl crate from compiling.

[simlay]

If you're using homebrew, I found that http://stackoverflow.com/a/17231736 fixed this issue for me.

[lilyball]

Sure, but that's just a stopgap. We can't expect everyone to install a new version of OpenSSL into /usr/local.

Three possible solutions that come to mind:

1. Change openssl-sys to actually include a copy of the OpenSSL 0.9.8 headers, which it falls back to on Apple platforms if there are no headers provided by the system.
2. Change openssl-sys to actually download and statically build a copy of OpenSSL if the headers can't be found on the system. Incidentally, Apple's own documentation states that if you want to use OpenSSL you should statically link your own version into your app (though it encourages you to not use it at all).
3. The ideal solution, though possibly the most work, is to change Hyper to use Apple's own APIs on Apple platforms instead of OpenSSL. It appears there's already a security-framework crate (by @sfackler) that provides SecureTransport. For symmetric encryption you'd want to use Common Crypto (though I don't see a crate offhand for it, but I admittedly didn't search very hard). Note that you'll also have to update any dependencies that use openssl as well.

[sfackler]

I am uncomfortable with option 2, particularly because I do not want to be the person on the hook to rush out an updated release with the download link changed to a new version when the next Heartbleed is inevitably found.

Common Crypto is part of security.framework so functionality for it would fall under the security-framework crate. Bindings for e.g. SecKey are already there, but the relevant encryption methods haven't yet been exposed.

Hyper's encryption support is already generic through the Ssl trait, though the implementation for the secure transport crate doesn't exist yet, and I think the trait definition should probably be tweaked a bit to make it work in more use cases.

Once rust-lang/rfcs#1361 lands, it'll be possible to switch SSL backends based on the target in a sane way.

[lilyball]

@sfackler CommonCrypto is provided in libSystem, under the import path <CommonCrypto/CommonCrypto.h>. Security.framework is built on top of CommonCrypto rather than including it. That said, it is perfectly reasonable to expose CommonCrypto as part of the security-framework crate.

Incidentally, while iOS provides basic encryption/decryption using SecKey as part of Security.framework (specifically the functions SecKeyEncrypt, SecKeyDecrypt, SecKeyRawSign, and SecKeyRawVerify), these functions don't appear to exist on OS X.

[sfackler]

Ah thanks

[BProg]

On Debian you should just install libssl-dev package and it will work, or just update libssl.

[mr4x]

Use:

sudo chown -R $(whoami) /usr/local
brew install openssl
brew link openssl --force

[xaviershay]

I hit this problem, found this issue, brew link openssl --force worked for me.

[pandeiro]

Thank you @BProg, that command worked for me on Xubuntu as well.

As the referenced rust-lang/rfcs#1361 has already landed and this issue persists at least for now, could I recommend adding these fixes (at least for OSX/Debian-based Linux) directly in a note in the README? It would help beginners like me, who may not know to search through the Issues list.

[kiliankoe]

Current homebrew (v0.9.9) is refusing to link openssl 😕

$ brew link --force openssl

Warning: Refusing to link: openssl
Linking keg-only openssl means you may end up linking against the insecure,
deprecated system OpenSSL while using the headers from Homebrew's openssl.
Instead, pass the full include/library paths to your compiler e.g.:
  -I/usr/local/opt/openssl/include -L/usr/local/opt/openssl/lib

I'm failing to compile hyper 0.9.10. Should this be using something different than openssl on macOS or is this still correct? I'd love to get this working somehow.

[seanmonstar]

You can try using the 'security-framework' feature instead of the 'ssl'
feature in your Cargo.toml.

On Tue, Aug 9, 2016, 7:19 AM Kilian Koeltzsch [email protected]
wrote:

Current homebrew (v0.9.9) is refusing to link openssl 😕

$ brew link --force openssl

Warning: Refusing to link: openssl
Linking keg-only openssl means you may end up linking against the insecure,
deprecated system OpenSSL while using the headers from Homebrew's openssl.
Instead, pass the full include/library paths to your compiler e.g.:
-I/usr/local/opt/openssl/include -L/usr/local/opt/openssl/lib

I'm failing to compile hyper 0.9.10. Should this be using something
different than openssl on macOS or is this still correct? I'd love to get
this working somehow.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#709 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AADJF10kFocOQEZgRuUvW0RqiTDquhESks5qeIrDgaJpZM4G7PrN
.

[kiliankoe]

Sorry to ask, but I'm rather new to using rust... I've added features = ["security-framework"] to my Cargo.toml, but am running into the same issue as before. How do I go about disabling the default ssl? Thanks 😊

[sfackler]

hyper = { version = "0.9", default-features = false, features = ["security-framework"] }

[lilyball]

Seems to me that hyper should use the target.*.dependencies feature to automatically select between openssl and security-framework.

[sfackler]

@kballard I'm close to publishing https://github.com/sfackler/rust-native-tls which should handle all of that and I believe we'll be able to make the default SSL backend for hyper.

[masche842]

A workaround to link against openssl (installed with homebrew) is to use a custom .cargo/config:

[target.x86_64-apple-darwin.openssl]
libdir = "/usr/local/opt/openssl/lib"
include = "/usr/local/opt/openssl/include"

Anyway, using security-framework seems the way to go.

[fungos]

Same thing for windows:

[target.i686-pc-windows-msvc.openssl]
libdir = "C:\\OpenSSL-Win32\\lib"
include = "C:\\OpenSSL-Win32\\include"

[target.x86_64-pc-windows-msvc.openssl]
libdir = "C:\\OpenSSL-Win64\\lib"
include = "C:\\OpenSSL-Win64\\include"

[brianirish]

I just ran into this issue for the first time today (new Hyper user), and @sfackler has provided the best answer. I changed it slightly to use the latest version of hyper from GitHub.

Cargo.toml:

[dependencies]
hyper = { git = "https://github.com/hyperium/hyper", default-features = false, features = ["security-framework"]}