BTW, @Jack Moffitt was telling me recently about a lint that he developed for a specific bug that was found in Libra. I'm not sure whether he's tried to upstream said lint somewhere, but I thought I would raise it here, as I thought some of the folks in this stream would be interested. Maybe @Jack Moffitt can provide more details though =)
Apologies if this is already well known
The pattern in question was something like
fn foo<'a>(x: impl AsRef<str> + 'a) -> &'a str
which looks like the
'a in the return type is "constrained" to the lifetime of the data in
x, but doesn't actually have that effect all of the time (e.g.,
x could be a
String, in which case any reference to the data in
x would be dangling upon return).
I did an audit of the first party unsafe code in libra/libra. I totally missed that the
'a in that signature could be unbound, which David Tolnay thankfully caught in this PR: https://github.com/libra/libra/pull/1949
After talking with @nikomatsakis I decided to try writing a lint to catch this case. The PR to rust-clippy can be found here: https://github.com/rust-lang/rust-clippy/pull/4908
Awesome! A capacbility it feels like we should have is:
a) The ability to select only clippy "security" lints
b) Something like crater for clippy security lints
Many correctness lints already fall into that category. Like pointer casts that violate size or alignment constraints.
I expect the deny-by-default lints already encode something similar - critically broken code that should be flat out prohibited
The required categorization may already exist, I haven't explored clippy's configuration deeply.
I like the idea of rustwide + Clippy deny-by-default lints, I have to admit.
https://github.com/rust-lang/rustwide makes it pretty easy.
yeah really liking Rustwide. It's what I'm using to try to drive reproducible builds