Hacker News Reader

Comment by jeffbee | Hacker News Reader

Hilarious build-time dependencies. You need Perl and Go and a C++ toolchain to build a Rust library!

It looks like that's because it's backed by an established SSL library. So this is more of a safely-typed Rust wrapper around that (which means they aren't rolling their own crypto, which is typically considered a good thing)

> which means they aren't rolling their own crypto

I will point out that BoringSSL is also mainly developed by Google, so...kinda?

I still trust it, just a kinda interesting fact

I think the intended meaning of "your own crypto" is "greenfield crypto"

I’d still rather use a pure rust implementation

Roll your own crypto library and see how far you get - there's a reason we all just depend on OpenSSL. Using rust wont make it easier to write it all from scratch.

I actually do roll my own crypto library :D

Or they could've used a formally verified crypto library such as HACL*.

Can't misuse it if you can't even build it.

Note that these are the requirements of the BoringSSL dependency, not the project itself.

That might make BoringSSL a poor fit for use outside of golang.

I mean this is kinda like a rust library with a dependency on a Java JVM.

It's not a runtime dependency.

Theres a Rust library that uses a Python script to generate part of its Rust code, checks that generated Rust code into git and the crates.io package does not include the Python script, so you can't actually build the crate from source properly.

Technically, you can avoid depending on Perl and Go (which are used to generate some assembly code) but you still need C++ toolchain to build most of the BoringSSL.

It is still possible to [make Mundane] link against system's OpenSSL. However, that's a bit different set of worms to locate it, auto-generate working FFI bindings, etc.

Couldn't the assembly code be generated with constexpr?

I do admire it!

Reply on news.ycombinator.com