4 ms·
Preventing compromise and ensuring determinism using checksums and SECCOMP is more reliable and easier to implement than reimplementing in rust an already de-fa
by saynsedit 10y ago
Preventing compromise and ensuring determinism using checksums and SECCOMP is more reliable and easier to implement than reimplementing in rust an already de-facto secure library used millions of times every day.
I'm sorry but the Rust rationale just isn't there. Porting to Rust is a strictly less efficient way of accomplishing the same exact goal.
Now, writing a new library in rust, that's a different story and actually is reasonable.
- daniel_rh 10y agoYour argument is certainly reasonable. One case where it might matter is if SECCOMP weren't available on all platforms that needed to decompress data. Also: a vulnerability could decide to only strike after a certain clock date. In that way it could sneak past certain checksum checks and still cause issues later.
- gribbly 10y agoA bit off topic, but I was excited about that lossless jpeg (re)compressor you guys had developed, is there a chance it will be open sourced ?
- saynsedit 10y agoOn the client side there is already a vast amount of C-code that is interpreting file data, the brotli portion is a minimal part of that security risk. Porting brotli to rust for the purposes of increased security is like optimizing the part of your program that takes the least time. Lots of effort for minimal gain.
- tveita 10y agoPeople were finding buffer overflows in zlib when it was more than twice as old as Brotli, and they're still finding bugs in libpng. I don't see any reason to think that Brotli is "de-facto secure" or even mature. If history is an indication it takes decades to shake the buffer overflows out of even a very popular C library.
- deleted 10y ago[deleted]
- saynsedit 10y agoDefacto secure doesn't mean "has no buffer overflows." It just means it's already a prevalent security risk outside of your system.