boringssl
min-sized-rust
Our great sponsors
boringssl | min-sized-rust | |
---|---|---|
10 | 101 | |
1,719 | 7,431 | |
3.4% | - | |
6.5 | 6.2 | |
4 days ago | about 1 month ago | |
C | Rust | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
boringssl
-
New vulnerabilities (CVE-2022-3602 and CVE-2022-3786) in OpenSSL, how they affect IoT and RTOS Devices.
I have nothing constructive to add except that OpenSSL has a long history of producing vulnerabilities so much so that Google has created their own fork publicly available here: https://boringssl.googlesource.com/boringssl/ (used in chromium, chrome, and android).
-
OpenSSL added new C parser code [...] without doing any basic security testing
> Large web companies like Google implement their own encryption stack anyway.
Google uses BoringSSL[1], which is another OpenSSL fork. I believe AWS uses a mix of OpenSSL and Boring SSL (someone can correct me!).
So it's "their own encryption stack," but that stack is at least originally comprised of OpenSSL's code. They've probably done an admirable job of refactoring it, but API and ABI constraints still apply (it's very hard to change the massive body of existing code that assumes OpenSSL's APIs).
[1]: https://boringssl.googlesource.com/boringssl/
-
CVE-2022-3786 and CVE-2022-3602: X.509 Email Address Buffer Overflows
OpenSSL gets plenty of funding but we need to put more funding into TLS implementations that have a bigger focus on security and stability like boringssl, nss, go's tls, and rustls. It's 2022 and we have both languages better suited for this and tools to make existing languages safer and more robust, it's incredible to me that we aren't even more anxious over the current state of openssl.
-
BearSSL: A smaller SSL/TLS library
It was not built for chromium AFAIK
To quote: https://boringssl.googlesource.com/boringssl/
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
- OpenSSL Security Advisory for CVE-2022-0778
-
I think a major issue with the rust ecosystem is that it's full of unexpected design decisions
Use Google's fork of OpenSSL which exists because Google likes to do it's own weird things sometimes. This doesn't say anything about "OpenSSL is considered dangerous", it says "This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you."
- Information and learning resources for cryptography newcomers
-
OpenSSL Security Advisory (14 December 2021)
And this is why projects like https://boringssl.googlesource.com/boringssl/ exist
-
U.S. Telecoms Are Going to Start Physically Removing Huawei Gear
The immediate effect of Heartbleed was the OpenBSD folk [1] and Google [2] forking OpenSSL.
There's a talk from Bob Beck of OpenBSD on pruning OpenSSL, it's pretty hilarious [3].
In that case open source was at least able to react appropriately, even if it didn't act preemptively.
[1]: https://www.libressl.org
[2]: https://boringssl.googlesource.com/boringssl/
[3]: https://www.youtube.com/watch?v=GnBbhXBDmwU
-
Cloudflare: Warp for Linux and Proxy Mode
I doubt the reference to Musk's brand is intentional. It's more likely that it's a reference/homage to BoringSSL (https://github.com/google/boringssl) and "boring tech" in general that is purposefully designed to be minimalist, simple to use, and narrow in scope.
min-sized-rust
-
The Linux Kernel Prepares for Rust 1.77 Upgrade
This is a good guide on building small Rust binaries: https://github.com/johnthagen/min-sized-rust
This talks about going to extreme lengths on making the smallest Rust binary possible, 400 bytes when it was written, https://darkcoding.net/software/a-very-small-rust-binary-ind...
The thing is, you lose a lot of nice features when you do this, like panic unwinding, debug symbols, stdlib… for kernel and some embedded development it’s definitely important, but for most use cases, does it matter?
-
Rust wont save us, but its ideas will
Oh it was 137, haha. I will link you to this older comment of mine: https://news.ycombinator.com/item?id=29408906
See also https://github.com/johnthagen/min-sized-rust
-
Making Rust binaries smaller by default
Are you sure? If so then this is awesome news, but I'm a bit confused; the commit in that min-sized-rust repo adding `build-std` to the README was merged in August 2021: https://github.com/johnthagen/min-sized-rust/pull/30
Are you saying that at that point the feature still hadn't "landed in Rust nightly" until recently? If so then what's the difference between a feature just being available in Rust nightly, vs having "landed"?
-
Was Rust Worth It?
Rust binaries are by default nowhere close to 500MB. If they are not small enough for you, you can try https://github.com/johnthagen/min-sized-rust. By avoiding the formatting machinery and using `panic_immediate_abort` you can get about the size of C binaries.
-
Compiling Rust binaries for Windows 98 SE and more: a journey
A useful reference: https://github.com/johnthagen/min-sized-rust
- How to minimize Rust binary size
- Error on flashing embedded code to stm32f103
-
Tiny Binaries (2021)
That must be without stripping. Also there are ways to reduce binary size. See e.g. [min-sized-rust](https://github.com/johnthagen/min-sized-rust). I've gotten stripped binaries of small cli utils less than 400KiB without doing anything special, less than 150 KiB by customizing profile settings and compressing with upx, and less than 30 KiB by replacing the std with the libc as the link shows. Haven't tried with fltk though...
-
Shared libraries
This is not quite what you're asking, but it does also address the underlying concern: https://github.com/johnthagen/min-sized-rust
What are some alternatives?
OpenSSL - TLS/SSL and crypto library
smartstring - Compact inlined strings for Rust.
wolfssl - The wolfSSL library is a small, fast, portable implementation of TLS/SSL for embedded devices to the cloud. wolfSSL supports up to TLS 1.3!
Cargo - The Rust package manager
libsodium - A modern, portable, easy to use crypto library.
rustc_codegen_gcc - libgccjit AOT codegen for rustc
Tink - Tink is a multi-language, cross-platform, open source library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse.
c2rust - Migrate C code to Rust
webpki - WebPKI X.509 Certificate Validation in Rust
regex - An implementation of regular expressions for Rust. This implementation uses finite automata and guarantees linear time matching on all inputs.
istlsfastyet.com - Is TLS fast yet? Yes, yes it is.
embedded-graphics - A no_std graphics library for embedded applications