Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Tony Arcieri
    @tarcieri
    but also, I keep thinking how much nicer things would be if things weren't specified in terms of version ranges, but contained in yank metadata instead
    David
    @dvdplm

    yank metadata

    Like a special reason-for-yanking code of some sort, e.g. “security vulnerability”?

    Tony Arcieri
    @tarcieri
    yes
    David
    @dvdplm
    Trying to think of a situation where a crate is not yanked but still needs an entry in the cargo-audit DB… I guess some orgs could be very slow to update their code, e.g. for embedded deployments?
    Great post, food for thought indeed.
    Tony Arcieri
    @tarcieri
    thanks! your question comes up a lot and has remained an open question
    or to put it a different way: "is yanking for security vulnerabilities too onerous"
    David
    @dvdplm
    Playing the devils advocate here: what if a third party discovers the vulnerability and reports it to the owner but the owner is gone/unresponsive/unwilling to yank their crate? Today the report could still go into the vulnerabilities DB; if it’s tied to yanking it would not.
    Tony Arcieri
    @tarcieri
    that's true, and something I like about the way things work today
    vulnerability reporting isn't blocked on the crate owner
    it just seems we've had two advisories lately filed with bad version ranges and I'd like to do something about that
    Matt Taylor
    @64
    hello, i will be submitting an advisory for the spin crate soon
    my concern is that since lazy_static depends on spin (only when the no std feature is enabled), that many lazy_static users will see the vulnerability pop up when doing a cargo audit even though it doesn’t affect them at all
    i see there’s an ‘affected_functions’ entry, does cargo audit take this into account?
    Tony Arcieri
    @tarcieri
    @64 unfortunately it does not. the goal was to collect this information for call graph analysis but we've never actually integrated with anything that can do that RustSec/cargo-audit#21
    failing that, it'd be nice if we could have advisories which map to specific cargo features, but we don't have anything like that now
    however, let me check something
    yeah, I think you should be fine
    since it's an optional dependency, it doesn't wind up in Cargo.lock unless the relevant feature of the dependent crate is enabled
    so I think there won't be false positives for lazy_static users (I just checked some of my own projects that use lazy_static)
    Tony Arcieri
    @tarcieri
    looks like it will be rather disruptive for anything that uses ring though, as it's a hard dependency there
    Matt Taylor
    @64
    @tarcieri there will be false positives for those who have that feature of lazy_static enabled
    because lazy_static doesn’t use any of the vulnerable parts of spin
    Tony Arcieri
    @tarcieri
    aah, well there's no way to avoid that but the call graph analysis. you can note in the advisory that it can be ignored for lazy_static users
    Jeremy Fitzhardinge
    @jsgf
    Hi all - is there a package with a test advisory, like the EICAR test virus? I'd like to be able to have something to test that my advisory pipeline is working, without having to introduce a real vulnerability which might screw up real dependencies
    Jeremy Fitzhardinge
    @jsgf
    Konrad Borowski
    @KonradBorowski_gitlab
    if you specify a real package with exact version and a comment describing this is for RUSTSEC specifically, it should be clear enough i feel like
    if messing with dependencies is a concern, use a very old version of a 0.x library
    like so old that no new package would depend on it
    say safe-transmute 0.4.0 or something
    Tony Arcieri
    @tarcieri
    @jsgf what specifically are you looking to test? handling of new advisories in general? we've had quite a few recently due to the Safety Dance
    the latest RustSec crate supports informational advisories as well
    Jeremy Fitzhardinge
    @jsgf
    The problem I have right now is that none of the crates I'm managing have any advisories at all, so I don't necessarily know whether its working. It would be useful to have a canary to make sure things are working. Testing whether new advisories are working is a separate thing, but if we're OK with having test advisories at all, then publishing a test advisory - say - every month would help with that (you could alarm on not seeing an expected advisory indicating that something is wrong along the chain).
    @KonradBorowski_gitlab That's fine for a one-off test, but I'm looking at building out some infra for a large organization, and having special ad-hoc rules like "safe-transmute 0.4.0 isn't a real advisory" is hard to communicate effectively. It would be easier to say that "all advisories with the rustsec-test-advisory keyword and category are tests", because you could get a fair intuition about what it means just by looking
    and code/rules implementing that wouldn't look strange
    Tony Arcieri
    @tarcieri
    @jsgf I could potentially add one, with an associated test crate, that you could use to test. I don't think it makes sense to publish an unbounded number of them (in the same way there's only one EICAR string)
    if you want to test it periodically, you can add and remove the test dependency from your Cargo.toml
    Jeremy Fitzhardinge
    @jsgf
    Yeah, one is a good start
    Hanif Ariffin
    @hbina
    are there any crates that still publish a vulnerable version that have a non-vulnerable one? im trying to implement a cargo-audit fix but i dont have a test
    Tony Arcieri
    @tarcieri
    @hbina let me publish a test crate for this purpose
    svartalf
    @svartalf
    @tarcieri hey! Are there informational advisories I could see? I'm working on a some thing here and would love to see a live example of them :)
    Tony Arcieri
    @tarcieri
    we just published some of the first ones yesterday
    there's an example
    svartalf
    @svartalf
    Awesome, thanks!
    Tony Arcieri
    @tarcieri
    ooh awesome
    svartalf
    @svartalf
    :)
    I would love to hear your opinion about what data should be shown at the Check page at all