Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Tony Arcieri
    @tarcieri
    anything with interior mutability and bugs :trollface:
    Konrad Borowski
    @KonradBorowski_gitlab
    i would say it's a good practice to avoid mutable state
    Tony Arcieri
    @tarcieri
    that's great until you... want to do I/O, or have a secure channel, heh
    as it were I'm in the midst of refactoring some code so it doesn't have to be RefUnwindSafe
    Konrad Borowski
    @KonradBorowski_gitlab
    if necessary, you can AssertUnwindSafe, implementing UnwindSafe is safe, but you may violate your code invariants
    i think it's a great thing that Rust forces you to think about "will my application be in proper state when a panic occurs somewhere"
    Tony Arcieri
    @tarcieri
    I'm in the process of moving things around so I don't have to lug things across unwind boundaries
    Konrad Borowski
    @KonradBorowski_gitlab
    that's great :)
    Tony Arcieri
    @tarcieri
    and in the process deleting an impl RefUnwindSafe
    msehnout
    @msehnout
    Hi, I work on a project, where we are trying to aggregate CVEs for many different languages and ecosystems (like PyPi, NPM, Maven etc.). The current approach works by collecting data from various sources and processing them in various ways, but it has many pitfalls due to the lack of clear versioning scheme like semver or backporting fixes to some older versions etc. Anyway, do you have any plans for an automated way in which the RUSTSEC advisories could be submitted? e.g. some Github bot. and, on the other hand, some API/RSS feed for fetching data about the advisories?
    It would be nice, it there was a system that could be used across all languages, though I am not sure if that isn't too ambitious.
    Tony Arcieri
    @tarcieri
    @msehnout I've heard rumors GitHub is working on something like that, but no, for now the closest thing would be automating submissions by opening issues via GitHub's API
    msehnout
    @msehnout
    @tarcieri ok, thanks for your response
    Konrad Borowski
    @KonradBorowski_gitlab
    Okay, so I reported a security issue in yaml crate two months ago (2018-09-25), but I got no response from a maintainer
    i'm not sure how to continue from here
    Tony Arcieri
    @tarcieri
    @KonradBorowski_gitlab you can open a RUSTSEC issue... is there a public issue on the yaml crate?
    Konrad Borowski
    @KonradBorowski_gitlab
    i probably should create one, i only sent an e-mail
    didn't want to make it public
    Tony Arcieri
    @tarcieri
    maybe try following up and giving them 90 days?
    that's more or less the "standard" now... I think mostly from people cargo culting what Project Zero does
    Konrad Borowski
    @KonradBorowski_gitlab
    okay
    leo-lb
    @leo-lb
    hi there, considering that most people are importing dependencies without reading their code and that these can contain build script or procedural macros that can compromise one's computer, I was thinking we should maybe provide a sandboxed offline compilation process by default in Cargo (SELinux, Hyper-V APIs, jail). What is your opinion on such a thing?
    Tony Arcieri
    @tarcieri
    @leo-lb this might interest you rust-secure-code/wg#29
    leo-lb
    @leo-lb
    @tarcieri indeed it is, by that time, I had already found those as well as discussion on Zulip about it :) Thanks.
    @tarcieri Do we have an integrated solution in the mean time? Sanboxing without losing integration with IDEs etc.
    Tony Arcieri
    @tarcieri
    nope
    Andronik Ordian
    @ordian
    ID:     RUSTSEC-2019-0003
    Crate:     protobuf
    Version: 1.7.5
    Date:     2019-06-08
    URL:     https://github.com/stepancheg/rust-protobuf/issues/411
    Title:     Out of Memory in stream::read_raw_bytes_into()
    Solution: upgrade to: >= 1.7.5, >= 2.6.0
    Is it a bug in cargo audit?
    Konrad Borowski
    @KonradBorowski_gitlab
    ">= 1.7.5, >= 2.6.0"
    this seems wrong
    it's saying that a version needs to both >= 1.7.5 and >= 2.6.0
    Andronik Ordian
    @ordian
    Konrad Borowski
    @KonradBorowski_gitlab
    generally there is no space after ^ operator, just saying
    Andronik Ordian
    @ordian
    fixed
    Tony Arcieri
    @tarcieri
    :thumbsup:
    Tony Arcieri
    @tarcieri
    a note I left on RustSec/cargo-audit#76 - "Perhaps the rustsec crate should detect whether specified version ranges overlap and reject advisories that do."
    Andronik Ordian
    @ordian
    @tarcieri good idea, but ideally this should be implemented by the semver crate that is currently lacking this overlap API. Another way to ensure that is to force that only the latest patched version has >= prefix, and others have ^ (semver compatible). In this case there was another bug, namely, the requirement were listed as one string, not two. Not sure how to prevent it from happening in future other than implement a custom semver parser.
    Tony Arcieri
    @tarcieri
    well, there's plenty of custom validation logic on each advisory. however, there have also been instances in the past where VersionReq was a poor fit
    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