Stream: wg-secure-code

Topic: security-related crates


Tony Arcieri (Oct 17 2018 at 23:40, on Zulip):

Well guess I'll try making my first Zulip topic here... a place to dump info about your security-related crates

Tony Arcieri (Oct 17 2018 at 23:40, on Zulip):

here's another one of mine: subtle-encoding: constant time hex and base64 encoders/decoders: https://github.com/iqlusioninc/crates/tree/master/subtle-encoding

Tony Arcieri (Oct 18 2018 at 15:59, on Zulip):

this looks pretty neat https://github.com/Shnatsel/libdiffuzz

Shnatsel (Oct 18 2018 at 19:30, on Zulip):

Hey! libdiffuzz author here. That thing is kind of a hack to get by without Memory Sanitizer, and will be mostly obsolete in Rust contexts once MSAN works well with Rust (but there are use cases for it elsewhere).
Also, it is a dynamic analysis tool that's only really useful when combined with a fuzzer (just like sanitizers), and does not check the program exhaustively. This is explicitly out of scope of this WG, which is more about verifying unsafe code statically or getting rid of unsafe code entirely.

Shnatsel (Oct 18 2018 at 19:31, on Zulip):

As for as security-related crates, https://crates.io/crates/untrusted looks neat. I have never used it, though, so can't say if it's actually good or bad.

Tony Arcieri (Oct 18 2018 at 23:48, on Zulip):

I like what untrusted accomplishes

Tony Arcieri (Oct 18 2018 at 23:48, on Zulip):

although I find it moderately annoying it's part of ring's public API

Tony Arcieri (Oct 18 2018 at 23:48, on Zulip):

rather than hidden behind the scenes

Tony Arcieri (Oct 18 2018 at 23:49, on Zulip):

I guess that gives the caller more control over allocation... still a bit obtrusive

Tony Arcieri (Nov 01 2018 at 23:42, on Zulip):

here's a crate some of you might find interesting: https://keychain-services.rs/docs/

Tony Arcieri (Nov 01 2018 at 23:46, on Zulip):

wrapper around the macOS Security Framework's Keychain Services

Tony Arcieri (Nov 01 2018 at 23:47, on Zulip):

gonna try to use this for GPG and git signing

briansmith (Nov 02 2018 at 20:22, on Zulip):

The idea being untrusted is that you are supposed to be able to use it end-to-end without using the as_slice_less_safe() function. That's why it's part of ring's API.

briansmith (Nov 02 2018 at 20:26, on Zulip):

In particular, any function that takes an untrusted::Input indicates that it is responsible for parsing and validating those untrusted inputs, so the caller doesn't have to (and in many cases, shouldn't try). This design design works well if one is using untrusted::Input for all parsing but it works less well if one is using it only because ring requires it. For example, it worked very well in my own TLS implementation because I used untrusted to parse TLS records and TLS handshake messages, so everything is already in untrusted::Input form when I hand it to ring.

Last update: Nov 11 2019 at 21:55UTC