You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Essentially #21, but using a more naive approach by relying on the compiler optimizing out uncalled functions, which seems to work pretty well in practice. However this requires the functions field to be pretty strict for it to be useful and avoid false negatives/positives.
The definition for the functions field is:
# The path syntax is `cratename::path::to::function`, without any
# parameters or additional information, ...
But I found some (invalid?) "functions" info that doesn't match the above description:
RUSTSEC-2019-0037 lists a trait implementation instead of the function
RUSTSEC-2021-0073 also lists a trait impl, and this time with a generic type as well
RUSTSEC-2020-0070 lists multiple structs instead of functions
I understand specifying the exact trait impl is accurate than just the function without any parameters, it would be very useful if these can be moved to separate fields so that functions only has functions in it, to reduce the amount of false negatives in tooling consuming this data.
Just for reference here are some of the functions symbols that LLVM emits after being demanged, which is what most call analysis tools will be taking in and have to change to match against the RUSTSEC affected info:
<prost_types::Timestamp as core::convert::From<std::time::SystemTime>>::from // RUSTSEC-2021-0073
smallvec::SmallVec<A>::insert_many // RUSTSEC-2021-0003
<libflate::gzip::MultiDecoder<R> as std::io::Read>::read // RUSTSEC-2019-0010
libflate::huffman::EncoderBuilder::new
The text was updated successfully, but these errors were encountered:
I am trying to use RUSTSEC advisory's
affected
functions
info to determine whether code using a "vulnerable" dependency is actually affected or not for the https://github.com/google/osv-scanner tool. (google/osv-scanner#452)Essentially #21, but using a more naive approach by relying on the compiler optimizing out uncalled functions, which seems to work pretty well in practice. However this requires the functions field to be pretty strict for it to be useful and avoid false negatives/positives.
The definition for the functions field is:
But I found some (invalid?) "functions" info that doesn't match the above description:
functions
field as well (Addaffected
fieldmacros
#664)I understand specifying the exact trait impl is accurate than just the function without any parameters, it would be very useful if these can be moved to separate fields so that functions only has functions in it, to reduce the amount of false negatives in tooling consuming this data.
Just for reference here are some of the functions symbols that LLVM emits after being demanged, which is what most call analysis tools will be taking in and have to change to match against the RUSTSEC
affected
info:The text was updated successfully, but these errors were encountered: