new rust-libtls crates

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

new rust-libtls crates

Reyk Floeter-2
Hi,

a bit off-topic, but a Rust-LibreSSL crossover:

It seems that many people have written Rust crates for libtls. And
most (or all) of them haven't been updated for years.

I talked to the owner of libtls and libtls-sys and he assigned
ownership of his libtls crates to me.  Yesterday I published a
complete and API-incompatible rewrite of the crates, under the ISC
license.  I'm trying to find a compromise between a close adaption of
the libtls API and a modern Rust way to implement such an API.

https://crates.io/crates/libtls

I'm working on additional code for async I/O with tokio and/or
async/await.  Async client/server already works but I'm tweaking the
code to a) clean it up and b) adjust it to the future with the new
"futures" API ;)

Why libtls?  Because it is a sane TLS API with secure defaults.  I
trust the decisions of the LibreSSL developers and libtls provides
some the best defaults.

The code works on OpenBSD and Linux.  Many distributions such as
Ubuntu don't seem to provide LibreSSL packages, so the very nice
libtls API is not available for them.  My crate tries to download,
build, and link LibreSSL statically if it is not found.

(I wonder if anyone has ever looked into packaging just libtls for
Ubuntu/Debian independently.  This would even help portability of our
OpenBSD daemons.)

Reyk

Reply | Threaded
Open this post in threaded view
|

Re: new rust-libtls crates

Consus-2
On 17:33 Sat 02 Nov, Reyk Floeter wrote:
> Why libtls?  Because it is a sane TLS API with secure defaults.  I
> trust the decisions of the LibreSSL developers and libtls provides
> some the best defaults.
>
> The code works on OpenBSD and Linux.  Many distributions such as
> Ubuntu don't seem to provide LibreSSL packages, so the very nice
> libtls API is not available for them.  My crate tries to download,
> build, and link LibreSSL statically if it is not found.

A bit of an offtopic, but most of the time people revert back to OpenSSL
due to lags in API compatibility between the two projects. Maybe it
would be better to provide libtls as a standalone library that can
coexist with OpenSSL.

E.g. install libssl.so and libcrypto.so as libressl.so and
librecrypto.so and make libtls.so depend on them instead of libssl.so
and libcrypto.so.