Supply Chain Security Discussion un-RustConf23

gistfile1.txt

- Sandbox build for wasm
- Debian downloads dependencies and then builds without network
- Cargo vender exists for this reason
- Build scripts exist for many reasons
- Build scripts that link to something need read-only file system access and to write to a target 
- We need a capabilities for a build (network access, filesystem access)
- Figure out common patterns in build.rs and build libraries for build.rs that expresses capabilities
- Want developer experience with capabilities
- Person building the code is different from the author that knows what the crate needs
- cargo-vet was designed for for capabilities
- we need sandboxing before cargo-vet can be useful for this

- right now there is no enforcement that the crage you publish is what is in your github repo
- because you can force push into a git repo you can change the history of a git repo
- crates.io stores the hash you publish from
- we need better tooling to detect that

- crates.io rfc for security, source provience
- is it fair to put security practices on maintainers
- allot of people just don't know
- if we have helpful diagnostics it would be much more pallitable

- supply chain also means license tracking for companies
- does a crate accuratly represent their licenses?
- fossa works for this, it is huge pain, submit to legal when dependenies change
- bigger orgs care much more about this
- tooling for scanning repos
- foudation audit top x crates

- there is no unified vendor / build process
- intoto is a tool that can help you get there
- need to keep comercial users of rust in line with crates.io so we don't split the ecosystem
- enginex is re-writting everything from scratch because of a large distrust of the ecosystem

- lawyers tell you know because of reason and you go upstream and the authors often just don't know
- similar experience in upstream around unsafe, education goes a long way

- fear of build system at aws that someone will say "no more crates.io crates" because something bad happened and by re-inventing the wheel we will end up in a bad place
- part of the solution is better automated tooling
- we have the concept of idiomatic rust for .rs files, we should apply that idea for what happens in Cargo.toml and ci setup
- amazon and google are different, amazon allows crates.io and each team has complete freedom, google vendors and audits

- what is the best practice for small comapnies that has no auditing tooling
- cargo-vet and consume the output from a large company
- foundation is organizing some of this information, what the large companies care about is different 
- google is auditing only for unsafe, and other safety rules
- mozilla is doing safety auditing

- does cargo-vet have a default set of criteria? no

- worry about the noise of "this is unsecure" from npm
- cargo add should tell you
- vscode runs cargo check so anything you put in your Cargo.toml gets built right away

- feature unification makes auditing / sandboxing really hard
- features should be additive but we know there are many crates that don't just add with features
- it would be lovely if there was social pressure for non-additive features

- is crates.io doing any sort of security scan?
- crates.io, no... but Walter is doing it himself behind the scenes. Long term we want to make it more official?
- How offten do you find things?
- [Walter] Not often, there was one last week.
- Does this need to stay secret?
- [Walter] No, we plan on making this public
- Securtiy working group does receive reports about malware

- Say a major crate shipps unverifiable binaries?
- 2k .so files, 300 .exe files in crates.io

- can crates be required to be signed?
- no, crates.io does not have a feature for signing
- six door had lots of privacy concerns around it and that is why it died

- building code is inherently unsafe, it has to be sandboxed
- having rust analizer and downloading a crate is unsafe

- [aws] a big part of the problem is that developers see anything that is not writing code as a waste of their time. leaders even think that developers should not have to think about their builds or thier tools and that infrastructure work is someone else's problem
- cultural problem where some people do not believe this part of their job and other people saying this is a huge problem

- [cargo team] all of us are in favor of sandboxing and capabilities. there are refactorings going on to test out these features.