This is more of a question than a feature request. Currently MesaLink is not available on crates.io, which makes it difficult to use within a Rust application. I know that native Rust code is better to use Rustls directly, but I'm in a bit of a unique situation.

I am interested in adding to the curl-sys crate on crates.io the ability to statically link to MesaLink as the TLS implementation; this would allow Rust applications to use a statically linked libcurl that in turn uses a statically linked MesaLink for its TLS implementation. This would be a pretty big win for Rust applications that make use of curl (including cargo itself) as it eliminates the OpenSSL dependency and gains the safety of MesaLink + Rustls.

Doing this as-is is a challenge for several reasons:

• curl-sys cannot be published to crates.io if it depends on crates that are not also on crates.io
• We need to be careful to ensure that libraries are not duplicated (like libstd) when linking to MesaLink. Having Cargo aware of the mesalink crate is the best way to avoid this.

I see only a few ways of making this possible:

• Publish mesalink to crates.io along with its forked dependencies (as mesalink-rustlsand so on).
• Absorb all of mesalink's forked dependencies inside the mesalink crate (under modules or something) and publish that.
• Pre-compile MesaLink without libstd for every platform, and ship that as a wrapper crate. (yuck)
• Create a mesalink-sys crate that builds MesaLink inside a build script. (Awkward running Cargo inside a build script inside Cargo...)
• Fork MesaLink and do one of the above.

I am interested to hear of better solutions, or if there is any interest in publishing to crates.io.

Hi, I'm a new learner of mesatee. I read something about intel sgx secret provisioning and mesalink from github and intel official guide, and that confuses me. Because I dont understand why u guys write another TLS library. For my perspective, intel already shows us a way to send secrets into enclave, which is secret provisioning, so we should not have to make another one. Looking forward to any relay. Thx.

Bump rustls to 0.20.0, as well as ring and webpki. I'm wondering that GitHub Dependabot might be very helpful in updating these dependencies. Sadly I failed to file a PR for this as I have mere experience in rust :-(

when I use make It show cd . && \ cargo rustc \ --release --no-default-features --features " client_apis server_apis error_strings aesgcm chachapoly tls13 x25519 ecdh ecdsa verifier" -- -C overflow-checks=yes -C link-args=-Wl,--gc-sections -C opt-level=z Updating git repositoryhttps://github.com/mesalock-linux/rustlserror: failed to load source for a dependency onrustls`

Caused by: Unable to update https://github.com/mesalock-linux/rustls?branch=mesalink#12dd7e88

Caused by: revspec '12dd7e883e3c5a8ca782ff90e2046ae760e39161' not found; class=Reference (4); code=NotFound (-3)`

Is network error?

-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Cargo Home: /home/chaz/.cargo
-- Rust Compiler Version: rustc 1.33.0
CMake Error at CMakeLists.txt:26 (message):
  Rust is too old, please install at least 1.31 to support the Rust 2018
  edition

The host is running linux 3.10.0-957.5.1.el7.x86_64.

From the build instructions:

MesaLink currently supports Linux, Android and macOS. We will introduce support for other platforms in future releases.

When is Windows support expected?

Note that rust-native-tls supports the following:

Specifically, this crate uses SChannel on Windows (via the schannel crate), Secure Transport on OSX (via the security-framework crate), and OpenSSL (via the openssl crate) on all other platforms.

Hello,

i tried mesalink on freebsd. the only thing that needs to change is to include netinet/in.h in server.c.

This does not break compile on linux, through I dont know about Mac. If wanted I'll create a pull request.

System:CentOS6.9 x86_64 The error message is as follows：

aclocal: --install should copy macros in the directory indicated by the
aclocal: first -I option, but no -I was supplied.

How should I solve it? I did not find a solution on the network Thank you.

Since mesalink aims to be compatible to OpenSSL, I'd like to ask if it is already possible to use it as a drop-in replacement for the former mentioned library? So would it be possible to link e.g. a nginx web server against mesalink instead of OpenSSL?

The rust toolchain has changed the file extension for static libs on MinGW cross builds. This CL fixes cmake/CmakeCargo.cmake and replaces mesalink.lib with libmesalink.a

PS: first commit from Ryzen 3600 + WSL2 PS2: AMD YES

Under Gentoo's build tooling, network IO can be inhibited/restricted, because its generally viewed dimly that any build-time process can "phone home".

Its also in general bad practice to rely on the availability of network IO, because it makes assertions about your expectations about the build environment ( eg: it could be running on a firewalled / airgapped host ).

The recommendation is to first ascertain if network IO in the general sense can be expected to work, before executing tests that inherently require it to give valid output.

test libssl::ssl::tests::dummy_openssl_compatible_apis_always_return_success ... ok
test libssl::ssl::tests::get_ssl_fd ... FAILED
test libssl::ssl::tests::get_and_set_ssl_ctx ... ok
test libssl::ssl::tests::invalid_private_key ... ok
test libssl::ssl::tests::legacy_tls_versions_not_supported ... ok
test libssl::ssl::tests::load_verify_locations ... ok
test libssl::ssl::tests::mesalink_ssl_ctx_session_cache_mode_and_size ... ok
test libssl::ssl::tests::mesalink_ssl_set_good_host_name ... ok
test libssl::ssl::tests::mesalink_ssl_set_invalid_host_name ... ok
test libssl::ssl::tests::mesalink_ssl_set_null_host_name ... ok
test libssl::ssl::tests::private_key_not_found ... ok
test libssl::ssl::tests::ssl_ctx_is_not_null ... ok
test libssl::ssl::tests::invalid_certificate ... ok
test libssl::ssl::tests::ssl_ctx_is_thread_safe ... ok
test libssl::ssl::tests::ssl_ctx_load_certificate_and_private_key_asn1 ... ok
test libssl::ssl::tests::ssl_io_on_bad_file_descriptor ... ok
test libssl::ssl::tests::ssl_is_not_null ... ok
test libssl::ssl::tests::ssl_is_thread_safe ... ok
test libssl::ssl::tests::ssl_load_certificate_and_private_key_asn1 ... ok
test libssl::ssl::tests::supported_tls_versions ... ok
test libssl::ssl::tests::test_io_before_full_handshake ... ok
test libssl::ssl::tests::test_null_pointers_as_arguments ... ok
test libssl::ssl::tests::verify_certificate_and_key ... ok
test libssl::ssl::tests::verify_key_and_certificate_1 ... ok
test libssl::ssl::tests::verify_key_and_certificate_2 ... ok
test libssl::x509::tests::x509_null_pointer ... ok
test libssl::ssl::tests::ssl_on_nonblocking_socket ... FAILED
test libssl::ssl::tests::early_data_to_mesalink_io ... FAILED
test libssl::ssl::tests::cross_version_tests ... ok

failures:
---- libssl::ssl::tests::get_ssl_fd stdout ----
thread 'libssl::ssl::tests::get_ssl_fd' panicked at 'Connect error: Os { code: 101, kind: Other, message: "Network is unreachable" }', src/libcore/result.rs:1084:5
stack backtrace:
   0:     0x55813a931de1 - std::sys_common::backtrace::print::hba9498aea52b0a4c
   1:     0x55813a936a12 - std::panicking::default_hook::{{closure}}::h28904950cd69f5ae
   2:     0x55813a93675c - std::panicking::default_hook::h37de51f3afebd886
   3:     0x55813a9370fd - std::panicking::rust_panic_with_hook::hc888d5b8ee53f3c2
   4:     0x55813a936c92 - std::panicking::continue_panic_fmt::h4994c8523413f426
   5:     0x55813a936b76 - rust_begin_unwind
   6:     0x55813a947f7d - core::panicking::panic_fmt::h0f33ccf7fc2a1201
   7:     0x55813a94b627 - core::result::unwrap_failed::h5f2f3948a0c719bd
   8:     0x55813a82d4eb - core::result::Result<T,E>::expect::h6e0dc25503701241
                               at /var/tmp/portage/dev-lang/rust-1.38.0/work/rustc-1.38.0-src/src/libcore/result.rs:879
   9:     0x55813a82d4eb - mesalink::libssl::ssl::tests::get_ssl_fd::h0c0f21d37a37c246
                               at src/libssl/ssl.rs:3381
  10:     0x55813a853c2f - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h8e266f4baa94b6a7
  11:     0x55813a93794a - __rust_maybe_catch_panic
  12:     0x55813a85f26d - std::sys_common::backtrace::__rust_begin_short_backtrace::h7eec479e3b313f58
  13:     0x55813a8605b5 - std::panicking::try::do_call::h9921ee074f4070c3
  14:     0x55813a93794a - __rust_maybe_catch_panic
  15:     0x55813a865cd2 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hf525dbe56a508edf
  16:     0x55813a93451f - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h4c1084bf7672115a
  17:     0x55813a9377a0 - std::sys::unix::thread::Thread::new::thread_start::h9505cc4fd13f1815
  18:     0x7f36abd683a7 - start_thread
                               at /var/tmp/portage/sys-libs/glibc-2.29-r5/work/glibc-2.29/nptl/pthread_create.c:486
  19:     0x7f36abc7d0ff - __clone
  20:                0x0 - <unknown>

---- libssl::ssl::tests::early_data_to_mesalink_io stdout ----
thread 'libssl::ssl::tests::early_data_to_mesalink_io' panicked at 'Failed to connect: Custom { kind: Other, error: "failed to lookup address information: Temporary failure in name resolution" }', src/libcore/result.rs:1084:5
stack backtrace:
   0:     0x55813a931de1 - std::sys_common::backtrace::print::hba9498aea52b0a4c
   1:     0x55813a936a12 - std::panicking::default_hook::{{closure}}::h28904950cd69f5ae
   2:     0x55813a93675c - std::panicking::default_hook::h37de51f3afebd886
   3:     0x55813a9370fd - std::panicking::rust_panic_with_hook::hc888d5b8ee53f3c2
   4:     0x55813a936c92 - std::panicking::continue_panic_fmt::h4994c8523413f426
   5:     0x55813a936b76 - rust_begin_unwind
   6:     0x55813a947f7d - core::panicking::panic_fmt::h0f33ccf7fc2a1201
   7:     0x55813a94b627 - core::result::unwrap_failed::h5f2f3948a0c719bd
   8:     0x55813a82eead - core::result::Result<T,E>::expect::h6e0dc25503701241
                               at /var/tmp/portage/dev-lang/rust-1.38.0/work/rustc-1.38.0-src/src/libcore/result.rs:879
   9:     0x55813a82eead - mesalink::libssl::ssl::tests::early_data_to_mesalink_io::h348b7703c02fa9aa
                               at src/libssl/ssl.rs:3550
  10:     0x55813a853c2f - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h8e266f4baa94b6a7
  11:     0x55813a93794a - __rust_maybe_catch_panic
  12:     0x55813a85f26d - std::sys_common::backtrace::__rust_begin_short_backtrace::h7eec479e3b313f58
  13:     0x55813a8605b5 - std::panicking::try::do_call::h9921ee074f4070c3
  14:     0x55813a93794a - __rust_maybe_catch_panic
  15:     0x55813a865cd2 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hf525dbe56a508edf
  16:     0x55813a93451f - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h4c1084bf7672115a
  17:     0x55813a9377a0 - std::sys::unix::thread::Thread::new::thread_start::h9505cc4fd13f1815
  18:     0x7f36abd683a7 - start_thread
                               at /var/tmp/portage/sys-libs/glibc-2.29-r5/work/glibc-2.29/nptl/pthread_create.c:486
  19:     0x7f36abc7d0ff - __clone
  20:                0x0 - <unknown>

---- libssl::ssl::tests::ssl_on_nonblocking_socket stdout ----
thread 'libssl::ssl::tests::ssl_on_nonblocking_socket' panicked at 'Conenction failed: Custom { kind: Other, error: "failed to lookup address information: Temporary failure in name resolution" }', src/libcore/result.rs:1084:5
stack backtrace:
   0:     0x55813a931de1 - std::sys_common::backtrace::print::hba9498aea52b0a4c
   1:     0x55813a936a12 - std::panicking::default_hook::{{closure}}::h28904950cd69f5ae
   2:     0x55813a93675c - std::panicking::default_hook::h37de51f3afebd886
   3:     0x55813a9370fd - std::panicking::rust_panic_with_hook::hc888d5b8ee53f3c2
   4:     0x55813a936c92 - std::panicking::continue_panic_fmt::h4994c8523413f426
   5:     0x55813a936b76 - rust_begin_unwind
   6:     0x55813a947f7d - core::panicking::panic_fmt::h0f33ccf7fc2a1201
   7:     0x55813a94b627 - core::result::unwrap_failed::h5f2f3948a0c719bd
   8:     0x55813a82ba26 - core::result::Result<T,E>::expect::h6e0dc25503701241
                               at /var/tmp/portage/dev-lang/rust-1.38.0/work/rustc-1.38.0-src/src/libcore/result.rs:879
   9:     0x55813a82ba26 - mesalink::libssl::ssl::tests::ssl_on_nonblocking_socket::h1483b5459a0c207e
                               at src/libssl/ssl.rs:3037
  10:     0x55813a853c2f - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h8e266f4baa94b6a7
  11:     0x55813a93794a - __rust_maybe_catch_panic
  12:     0x55813a85f26d - std::sys_common::backtrace::__rust_begin_short_backtrace::h7eec479e3b313f58
  13:     0x55813a8605b5 - std::panicking::try::do_call::h9921ee074f4070c3
  14:     0x55813a93794a - __rust_maybe_catch_panic
  15:     0x55813a865cd2 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hf525dbe56a508edf
  16:     0x55813a93451f - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h4c1084bf7672115a
  17:     0x55813a9377a0 - std::sys::unix::thread::Thread::new::thread_start::h9505cc4fd13f1815
  18:     0x7f36abd683a7 - start_thread
                               at /var/tmp/portage/sys-libs/glibc-2.29-r5/work/glibc-2.29/nptl/pthread_create.c:486
  19:     0x7f36abc7d0ff - __clone
  20:                0x0 - <unknown>


failures:
    libssl::ssl::tests::early_data_to_mesalink_io
    libssl::ssl::tests::get_ssl_fd
    libssl::ssl::tests::ssl_on_nonblocking_socket

test result: FAILED. 61 passed; 3 failed; 0 ignored; 0 measured; 0 filtered out

Hi, I'm trying to compile nginx using mesalink as the replacement for OpenSSL.

I've compiled mesalink using the following:

mkdir out
./autogen.sh --prefix=$(pwd)/out
make && make install

Then compile nginx (sources available at github.com/nginx/nginx) with the following options:

./auto/configure --with-http_ssl_module \
    --with-cc-opt="-I/path/to/mesalock-linux/mesalink/out/include/mesalink -I/path/to/mesalock-linux/mesalink/out/include" \
    --with-ld-opt="-L/path/to/mesalock-linux/mesalink/out/lib"

I get the following error:

./auto/configure: error: SSL modules require the OpenSSL library.
You can either do not enable the modules, or install the OpenSSL library
into the system, or build the OpenSSL library statically from the source
with nginx by using --with-openssl=<path> option.

If you read through objs/autoconf.err you get:

checking for OpenSSL library in /usr/local/

objs/autotest.c:7:5: error: implicit declaration of function 'SSL_CTX_set_options' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
    SSL_CTX_set_options(NULL, 0);
    ^
1 error generated.
----------

#include <sys/types.h>
#include <unistd.h>
#include <openssl/ssl.h>

int main(void) {
    SSL_CTX_set_options(NULL, 0);
    return 0;
}

----------
cc -pipe -I/path/to/mesalock-linux/mesalink/out/include/mesalink -I/path/to/mesalock-linux/mesalink/out/include -D__APPLE_USE_RFC_3542 -I /usr/local/include -o objs/autotest objs/autotest.c -L/path/to/mesalock-linux/mesalink/out/lib -L/usr/local/lib -lssl -lcrypto

I searched for SSL_CTX_set_options in mesalink source code and issues, but I couldn't find anything. Any idea how to get past this? Do I need to define a shim .h file or something?

Updates #12.

Mesalink doesn't provide an equivalent interface to SSL_CTX_use_certificate_file. Furthermore, the function mesalink_SSL_CTX_use_certificate_chain_file takes these arguments:

• MESALINK_CTX *
• const char *
• int

Whereas the analogous OpenSSL function SSL_CTX_use_certificate_chain_file only takes two arguments:

• SSL_CTX *ctx
• const char *file

See the OpenSSL docs: https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_use_certificate_chain_file.html

Are ALPN and SNI still supported? I noticed that they were removed from the "Feature Highlights" list, and HTTP/2 over TLS doesn't work when using mesalink with isahc + curl-rust.

I am opening this issue here, since has no option to open issues in the mesalock-linux/rustls repository.

Looking at the first commit on the rustls fork that adds feature flags (currently fed32702b8d7afaec1271ef8494188d4f8ae688b), I can see there are some areas that can be simplified, and the feature selection can be performed with less code and more clearly.

As an example, in impl SupportedGroups for NamedGroups, there can be a single supported method, and each item in the vector can be conditioned directly on the related feature, which would make it much easier to see exactly what NamedGroups are included for which feature.

I would like to open a PR with these simplifications, and I would like to ask how do you think this should be handled: would you apply commits on top of the mesalink branch of the rustls fork, or would you apply it directly op top of fed32702b8d7afaec1271ef8494188d4f8ae688b and rebase on top of that ?