Tracking: Security, Trust models, Improving the status quo

[kinnison]

In order to properly improve rustup's security and trust model, we need to tackle a number of issues. When these are all dealt with, then we'll be in a better position to protect our users and thus we can consider enabling some kind of mirror or alternative-dist-server-by-default mechanisms.

• [ ] Simple signature verification with embedded static key available on all rustup targets (#2028)
• [ ] Design and implement a better trust model than the above (#2029)
• [ ] Signed Windows binaries (#1568)

[kinnison]

So at this time, cargo is out of scope for the work we're doing on the trust model for rustup. Again I ask that you hold off on pushing too hard until after we've opened discussion on the trust model work we're drafting. It'll be a little while, but in the short term I've told you what we have available and if that's insufficient for you then we're unlikely to be able to do anything to satisfy you before we have our proper trust model rolled out. Your point that people who need to use Tor in order to avoid scrutiny or interference from state actors is noted though, and will inform our design process, thank you.

[ms-ati]

@kinnison Hi from Dec 2022! Two years later, wondering if any updates on the trust model for rustup?

[tabbyrobin]

Any updates on this?

[djc]

I think the main work that is going on is https://github.com/rust-lang/rfcs/pull/3724.

It doesn't seem actually productive to ask questions in all of these issues. If there were updates, they'd likely have been commented on already.

Did you have a specific question or concern that you'd like answered?

[tabbyrobin]

It seems the updates I was looking for are indeed, currently, in rust-lang/rfcs#3724 that you linked. This wasn't initially clear, even after having skimmed the discussion on the RFC.

From a closer reading of the most recent RFC 3724 text, I realize that the work for cargo and rustup is tightly integrated, not just for the trust model, but also for the actual implementation(s).

I didn't realize this at first, because it's in a different repo. (From an outsider's perspective, rustup and cargo are very much distinct projects.) From the context of just this issue, one would get the impression that there was no movement since 2019. Digging through the history, it seems there were some other related RFCs etc in the intervening time, but which are now obsolete.

I don't mean to spam your issue tracker. Given how quiet the relevant issues have been over the past few years, I didn't think my comments were excessive.

Questions:

• Are there any other key places for updates on this besides rust-lang/rfcs#3724?
• Is there a timeframe for implementation? Even a rough estimate could be helpful -- it could assist others in deciding whether they might want to dedicate time towards the topic, plan workarounds, etc. Even if the answer is "we do not have enough momentum to give any timeframe estimate", it is helpful to state that clearly.
• Is there any progress on implementation details for rustup/cargo? From my reading of RFC 3724, it outlines a trust model and recommends that cargo and rustup implement it jointly. But it leaves implementation out of scope.
• (If implementation is not currently underway...) Are there technical and/or social reasons that the rustup/cargo implementation (at least a rough sketch) cannot be started immediately?

[djc]

I don't mean to spam your issue tracker. Given how quiet the relevant issues have been over the past few years, I didn't think my comments were excessive.

Replying to three different issues about substantially the same underlying topic at the same time (instead of waiting for an answer on one of the issues) does feel like "spam" from the receiving end, even if you didn't mean to.

I don't think there's any work ongoing within rustup, we're waiting for the outcome of the RFC. Any questions about the progress of the RFC (including implementation etc) are better directed to the RFC (authors).

• (If implementation is not currently underway...) Are there technical and/or social reasons that the rustup/cargo implementation (at least a rough sketch) cannot be started immediately?

I think there are two interacting reasons:

1. The RFC is, in my read, not very close to being accepted in its current state, making any implementation effort at risk of having to be substantially changed/thrown away.
2. All rustup maintainers are participating on a volunteer basis, so there's limited appetite for taking large/complex projects especially if there's a bunch of risk as in (1).