Tony Arcieri

@Spaceghost the C++ implementation does not expose a C ABI, much less an "FFIable" one (i.e. it doesn't rely on the preprocessor) I am a huge fan of FFI and...

There's a Ruby GSoC project underway to build a C wrapper around capnproto's C++ implementation and then re-wrap that in FFI. We'll see how it goes.

@peakxu last year's project didn't go so well, but there's another GSoC effort this year

It went well, I think! It should now support RPC: https://github.com/nemoNoboru/capnp-ruby Perhaps it should be moved to https://github.com/capnproto cc @kentonv @nemoNoboru

@kentonv not to my knowledge. I'm not sure people are actually aware of it. All that said, I think it's the most complete implementation of capnp in Ruby to date.

I looked at adding HChaCha20 to this crate, and it's not exactly straightforward as it's not amenable to a SIMD-based implementation. I wound up implementing the entire construction from scratch:...

I'm a fan of @newpavlov's https://github.com/RustCrypto work modularizing cryptographic algorithms into individual crates. He also pre-emptively namesquatted on the "chacha20" and "poly1305" crates, which could live inside these projects respectively:...

Hi. I'd just like to reiterate that this is an extremely serious issue. This gem should not be used until this is fixed, but given there's a PR that's been...

No, failure to use a random IV (#4) is a separate, unrelated, but still very bad problem.

Note: Unless we hear otherwise, we are going to officially start tracking this crate as unmaintained in the RustSec Advisory Database: https://github.com/RustSec/advisory-db/pull/183