Comments (12)
as for rustup, I built this protoype so that we at least have some trust around the script which is being pulled down (and is where codedev got breached).
https://twitter.com/decodebytes/status/1404540227474046980
This works as follows.
- Someone makes a change to rust-init.sh
- They sign that change using sigstore (signing cert based on OIDC / entry into transparency log)
- A commit is then made which contains the sig, signing cert and the updated script: https://github.com/lukehinds/rustup/commit/cd091d867aec7038322bfe2bc41a2bdd9235bef0
- A release is made based on the above commit: https://github.com/lukehinds/rustup/releases/tag/v1.0
This is then what happens in the background.
curl -s -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/lukehinds/rustup/releases/latest | jq '.tag_name'
"v1.0"
curl -s -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/lukehinds/rustup/git/ref/tags/v1.0 |jq '.object'|grep sha
"sha": "cd091d867aec7038322bfe2bc41a2bdd9235bef0",
curl -s -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/lukehinds/rustup/commits/cd091d867aec7038322bfe2bc41a2bdd9235bef0 |
jq '.files'
The nice thing then is we have even more trust guarantees. The signing event is stored into github repo, which in turn has its own security controls (uses need 2FA) etc. We then have sigstore which adds even more layers, a maintainer uses an ODIC account to sign (no long term management of private keys). The signing event gets recorded into a public transparency log.
from community.
As a general thought: the crates.io team seems pretty overworked right now just keeping the lights on. It's probably not a good time to put anything more on their plate.
I think an interesting way to move forward here that will at least temporarily avoid integration headaches with cargo would be to prototype something like TUF + cargo as an external tool, possibly leveraging the work in something like rust-tuf
or rough
, or just doing sigstore verification in a manner similar to Go's sumdb.
Such a tool could take care of things like updating the crates.io index (e.g. checking the latest index is indexed in something like sigstore, then updating the local index using something like the crates-index
crate) as well as downloading dependencies which aren't already in the local crate cache and verifying they also have a hash indexed in something like sigstore.
You could imagine a tool that exposes the same UI as cargo, but handles doing verified index updates/crate downloads, then drives cargo
with the --offline
flag.
from community.
Something else I suggested on the call was that rustup
might be a better starting point, and actually plays nicely into a story for cargo
/crates.io.
One thing I've gotten out of discussions with some core devs is that they'd like to have a single trust root for rustup
, Rust releases/channels, and crates.io, and in that regard rustup
is a great place to start as it could also bootstrap the root keys for cargo
.
Here's a relevant issue: rust-lang/rustup#2028
I think this would be a pretty interesting application of sigstore: rustup self update
could check sigstore to ensure that new releases it's about to install are included.
from community.
I think an interesting way to move forward here that will at least temporarily avoid integration headaches with cargo would be to prototype something like TUF + cargo as an external tool, possibly leveraging the work in something like rust-tuf or rough, or just doing sigstore verification in a manner similar to Go's sumdb.
Regarding this, here's a WIP tool which roughly fits this bill: https://github.com/kutometa/carnet
from community.
Appears to be pointed at Cloudfront:
$ host sh.rustup.rs
sh.rustup.rs is an alias for dks7yomi95k2d.cloudfront.net.
Beyond that, I'm not sure.
from community.
I will add to the above as more information comes in and I have had some time to look at cargos infra and code. Please do chime in with any views or any other historically useful threads..
My own view on this matter is that the rust community are stuck in the quandary of wanting the best approach (which of course they should be driving for), but as a result perfect is becoming the enemy of good and they have spent around 5-6 years running infra with no cryptographic guarantees of its packages.
from community.
Sorry for the inaction @tarcieri , agree rustup is definately good a place to start here. Will take a look at carnet
from community.
@tarcieri et al, where does rustup currently store its artefacts (such as the shell script, windows binaries)?
from community.
rustup
is designed to be used by an individual user and does not support global installation (to my knowledge).
It uses this crate to determine the user's home directory, along with CARGO_HOME
and RUSTUP_HOME
:
from community.
ah sorry, should have been more specific: where is the shell script (that you pipe into sh) and the blobs that the shell script pulls down get hosted (something like ec2 bucket etc)?
from community.
FYI, discussion around Sigstore and TUF for crate signing seems to be picking up:
https://internals.rust-lang.org/t/pre-rfc-using-sigstore-for-signing-and-verifying-crates/18115/2
from community.
There's now an RFC open here for signing crates with Sigstore: rust-lang/rfcs#3403
from community.
Related Issues (20)
- Project transfer approval: rekor-search-ui HOT 5
- update calendar invite for the weekly call link HOT 2
- add pulumi automation for newly-created sigstore-conformance org HOT 1
- add automation to submit PRs to update upon cosign releases HOT 1
- Community Chair Election HOT 4
- Create documentation for Pulumi administration HOT 6
- GitHub sync failed for Pulumi HOT 2
- Adding collaborators to sigstore/docs
- New project root-signing-staging HOT 2
- REQUEST: New membership for jku
- pulumi run partially failed for new repository (root-signing-staging) HOT 2
- root-signing-staging maintainer permissions not working HOT 6
- setting GH actions variables in a project? HOT 1
- Microsoft in this space trying to standardize with IETF? HOT 1
- Pulumi up fails on main HOT 5
- Correctly use custom org role in root-signing-staging
- add coverage for gitlab.com/sigstore
- team membership should be public HOT 2
- sync-changes failing at HEAD HOT 3
- root-signing-staging branch protection changed HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from community.