4 ms·

Yes, and all of those have had major security issues caused by their lack of foresight. "We're pretending security is not an issue." has been the feedback ever

Yes, and all of those have had major security issues caused by their lack of foresight. "We're pretending security is not an issue." has been the feedback every time this is raised with the Cargo team. To be honest, it's turned me off Rust a little bit. The attitude of "Rust is memory-safe, so we don't need any other form of security." is not a good one.

muldvarp 3y ago
> "We're pretending security is not an issue." has been the feedback every time this is raised with the Cargo team. Do you have a specific link where I can read this response, because this is not at all the responses I have read.
- jiggawatts 3y ago
  Just some random Cargo security-related issues I noticed: - No strong link between the repo and the published code. - Many crates were spammed that were just a wrapper around a popular C/C++ library. There's no indication of this, so... "surprise!"... your compiled app is now more unsafe C/C++ code than Rust. - Extensive name squatting, to the point that virtual no library uses the obvious name, because someone else got to it first. The aformentioned C/C++ libraries were easy to spit out, so they often grabbed the name before a Rust rewrite could be completed and published. So you now go to Cargo to find a Rust library for 'X' and you instead have to use 'X-rs' because... ha-ha, it's actually a C/C++ package manager with some Rust crates in there also. - Transitive dependencies aren't shown in the web page. - No enforcement or indication of safe/unsafe libs, nostd, etc... - No requirement for MFA, which was a successful attack vector on multiple package managers in the past. DISCLAIMER: Some of the above may have been resolved since I last looked. Other package managers also do these things (but that's not a good thing). In my opinion, any package manager that just lets any random person upload "whatever" is outright dangerous and useless to the larger ecosystem of developers in a hurry who don't have the time to vet every single transitive dependency every month. Package managers need to grow up and start requiring a direct reference to a specific Git commit -- that they store themselves -- and compile from scratch with an instrumented compiler that spits out metadata such as "connects to the Internet, did you know?" or "is actually 99% C++ code, by the way".
  - bjourne 3y ago
    Sure, but all the drawbacks you enumerate are also advantages for gaining critical mass. A free-for-all package repository is attractive to early adopters because they can become the ones to plug the obvious holes in the standard library. Having N developers each trying to make THE datetime/logging/webframework/parsing library for Rust is good for gaining traction. You end up with a lot of bad packages with good names though.
  - rat87 3y ago
    > Extensive name squatting, to the point that virtual no library uses the obvious name, because someone else got to it first. Maybe the obvious names should have been pre banned. But I don't see the issue with non-obvious names either way you're going to have to get community recommendation/popularity to determine if brandonq/xml is better or worse then parsers/xml
    - jiggawatts 3y ago
      In ASP.NET land, I regularly work on projects where there is an informal rule that only Microsoft-published packages can be used, unless there's good reason. You don't want to be using Ivan Vladimir's OAUTH package to sign in to Microsoft Entra ID. That probably has an FSB backdoor ready to activate. Why use that, when there's an equivalent Microsoft package? When any random Chinese, Russian, or Israeli national can publish "microsoftauth", you just know that some idiot will use it. That idiot may be me. Or a coworker. Or a transitive dependency. Or a transitive dependency introduced after a critical update to the immediate dependency. Or an external EXE tool deployed as a part of a third-party ISV binary product. Or... Make the only path lead to the pit of success, because the alternative is to let people wander around and fall into the pit of failure.
      - Fluorescence 3y ago
        fwiw but when I saw a 3rd party library pretty much exactly like "microsoftauth" on nuget, I reported it and it was swiftly removed. I think we need to encourage a culture that package managers are our shared garden and we must all help in the weeding.
pcwalton 3y ago
> "We're pretending security is not an issue." has been the feedback every time this is raised with the Cargo team. Literally nobody has said this. > The attitude of "Rust is memory-safe, so we don't need any other form of security." is not a good one. Fortunately it's an attitude that nobody in the Rust project has!
- Freedom2 3y ago
  > Literally nobody has said this. I know of a few people, personally, who have said this.
  - FridgeSeal 3y ago
    Ok, but like, were any of them people of note, actively working on the project? Because it seems like the people who are working on the project aren’t saying that.
    - jiggawatts 3y ago
      The people that are working on the project haven't implemented namespaces, or any other security feature really, so what they say is immaterial. What they do is the only thing that matters.
      - carols10cents 3y ago
        How do namespaces measurably increase security?
        richbell 3y ago
        They reduce the risk of supply chain attacks like typo squatting or Dependency confusion.
        littlestymaar 3y ago
        Funnily enough, they in fact increase it.

muldvarp 3y ago

> "We're pretending security is not an issue." has been the feedback every time this is raised with the Cargo team. Do you have a specific link where I can read this response, because this is not at all the responses I have read.

jiggawatts 3y ago
Just some random Cargo security-related issues I noticed: - No strong link between the repo and the published code. - Many crates were spammed that were just a wrapper around a popular C/C++ library. There's no indication of this, so... "surprise!"... your compiled app is now more unsafe C/C++ code than Rust. - Extensive name squatting, to the point that virtual no library uses the obvious name, because someone else got to it first. The aformentioned C/C++ libraries were easy to spit out, so they often grabbed the name before a Rust rewrite could be completed and published. So you now go to Cargo to find a Rust library for 'X' and you instead have to use 'X-rs' because... ha-ha, it's actually a C/C++ package manager with some Rust crates in there also. - Transitive dependencies aren't shown in the web page. - No enforcement or indication of safe/unsafe libs, nostd, etc... - No requirement for MFA, which was a successful attack vector on multiple package managers in the past. DISCLAIMER: Some of the above may have been resolved since I last looked. Other package managers also do these things (but that's not a good thing). In my opinion, any package manager that just lets any random person upload "whatever" is outright dangerous and useless to the larger ecosystem of developers in a hurry who don't have the time to vet every single transitive dependency every month. Package managers need to grow up and start requiring a direct reference to a specific Git commit -- that they store themselves -- and compile from scratch with an instrumented compiler that spits out metadata such as "connects to the Internet, did you know?" or "is actually 99% C++ code, by the way".
- bjourne 3y ago
  Sure, but all the drawbacks you enumerate are also advantages for gaining critical mass. A free-for-all package repository is attractive to early adopters because they can become the ones to plug the obvious holes in the standard library. Having N developers each trying to make THE datetime/logging/webframework/parsing library for Rust is good for gaining traction. You end up with a lot of bad packages with good names though.
- rat87 3y ago
  > Extensive name squatting, to the point that virtual no library uses the obvious name, because someone else got to it first. Maybe the obvious names should have been pre banned. But I don't see the issue with non-obvious names either way you're going to have to get community recommendation/popularity to determine if brandonq/xml is better or worse then parsers/xml
  - jiggawatts 3y ago
    In ASP.NET land, I regularly work on projects where there is an informal rule that only Microsoft-published packages can be used, unless there's good reason. You don't want to be using Ivan Vladimir's OAUTH package to sign in to Microsoft Entra ID. That probably has an FSB backdoor ready to activate. Why use that, when there's an equivalent Microsoft package? When any random Chinese, Russian, or Israeli national can publish "microsoftauth", you just know that some idiot will use it. That idiot may be me. Or a coworker. Or a transitive dependency. Or a transitive dependency introduced after a critical update to the immediate dependency. Or an external EXE tool deployed as a part of a third-party ISV binary product. Or... Make the only path lead to the pit of success, because the alternative is to let people wander around and fall into the pit of failure.
    - Fluorescence 3y ago
      fwiw but when I saw a 3rd party library pretty much exactly like "microsoftauth" on nuget, I reported it and it was swiftly removed. I think we need to encourage a culture that package managers are our shared garden and we must all help in the weeding.

pcwalton 3y ago

> "We're pretending security is not an issue." has been the feedback every time this is raised with the Cargo team. Literally nobody has said this. > The attitude of "Rust is memory-safe, so we don't need any other form of security." is not a good one. Fortunately it's an attitude that nobody in the Rust project has!

Freedom2 3y ago
> Literally nobody has said this. I know of a few people, personally, who have said this.
- FridgeSeal 3y ago
  Ok, but like, were any of them people of note, actively working on the project? Because it seems like the people who are working on the project aren’t saying that.
  - jiggawatts 3y ago
    The people that are working on the project haven't implemented namespaces, or any other security feature really, so what they say is immaterial. What they do is the only thing that matters.
    - carols10cents 3y ago
      How do namespaces measurably increase security?
      - richbell 3y ago
        They reduce the risk of supply chain attacks like typo squatting or Dependency confusion.
        littlestymaar 3y ago
        Funnily enough, they in fact increase it.