rfcs

rfcs copied to clipboard

This RFC proposes a change to the project's security policy to expand the set of organizations who are notified with the full details of Rust security vulnerabilities ahead of public disclosure, and to pre-announce to the general public upcoming security releases.

Rendered

I think it would be appropriate to include crates that are maintained by the rust project but aren't rust itself, such as log, git2, hashbrown, etc. Many linux distros include those crates as well (e.g. Debian's rust-log package), so I think they'd need similar security treatment to rust itself.

To minimize confusion, I suggest adding timezone to the things that should be mentioned in the public pre-announcement.

Will the list of notified organizations be a shared publicly? From the public applications it's already possible to determine which organisations are on the list. Having this list public would ensure that everyone can gain a quick overview.

---

If a specific vulnerability warrants it, the Security Response WG can also decide to send advance notifications to other organizations who are not members of the list

Will it be disclosed afterwards, which additional organizations have been notified if any? :upside_down_face:

I think it would be appropriate to include crates that are maintained by the rust project but aren't rust itself, such as log, git2, hashbrown, etc. Many linux distros include those crates as well (e.g. Debian's rust-log package), so I think they'd need similar security treatment to rust itself.

Thanks for raising that. Distributions shipping packages of crates maintained by the project is something that slipped off my mind when drafting this. I'll see how to incorporate that in the next few days.

To minimize confusion, I suggest adding timezone to the things that should be mentioned in the public pre-announcement.

Good point. We've always included the timezone in our communications up to this point, but making it explicit won't hurt.

Will the list of notified organizations be a shared publicly? From the public applications it's already possible to determine which organisations are on the list. Having this list public would ensure that everyone can gain a quick overview.

There was a typo which made things confusing, but yes, the list of organizations will be shared publicly.

In the Prior Art section, you might want to list the Xen Project: https://xenproject.org/developers/security-policy/

As a longstanding member of the Xen Project Security Team I read through the RFC with interest. Most of the important things are covered and I agree with the thrust of the RFC.

It is IMO very important for a process like this to be fair, and seen to be fair (whatever that means to the people in the community). I think this RFC proposal achieves that fairness. I hope others will agree, and if not, raise their doubts via this process.

Thanks!

In the Prior Art section, you might want to list the Xen Project: https://xenproject.org/developers/security-policy/

As a longstanding member of the Xen Project Security Team I read through the RFC with interest. Most of the important things are covered and I agree with the thrust of the RFC.

Thanks for chiming in, and added Xen to the prior art section!

While the prior art is not meant to collect all similar policies and is focused mostly on other programming languages, there are a couple of interesting points in Xen's that would benefit the discussion in this RFC:

• Notifying other similar projects that could be affected is explicitly mentioned in the policy. This is something Rust has recently failed at (on the std::fs::remove_dir_all TOCTOU vulnerability), and mentioning this in our policy might be good.
• Xen takes a different approach than us on who's going to be notified, also notifying public clouds (not really applicable to Rust as it's hypervisor-specific) and large production users.
• Post-embargo transparency: this is also something @xFrednet highlighted. While it might not be in scope of this RFC, it's definitely something we should improve at (maybe also taking inspiration from LLVM's annual transparency report).

I'll have some thinking to do, but I expect to incorporate some text around transparency and notifying similar projects in the coming days (there is a discussion above on notifying large production users already).

Reading the text this initially indicated that only the toolchain stuff gets notified and I also see @programmerjake and @Mark-Simulacrum related comments -

I've been writing lately about the vendored OpenSSL that manages to stay out of the way and the caveat of static linking people should be looking after their binaries and take into account they should be re-building the whole binary whenever one of the components gets vulnerability -

Would different tiers of categories of notifications be introduced ? e.g. one for cargo (as whole incl. deps) and one for toolchain etc.

My questions around possible cases are -

Would this get notified and How would -

1. Vendored OpenSSL vulnerability get notified to distros who package it via cargo

2. tar vulnerability that affects cargo e.g. untar on .crate

3. git2 vulnerability that affects cargo via index

Also - since static linking makes the whole binaries vulnerable unlike .so system components that can be replaced

Let's say minimum requirement for tar used by cargo was x.x in Cargo manifest but tar was x.x vulnerable which gets fixed in x.y

Cargo gets bumped +1 and updates the tar requirement to x.y

Would we tell forward to move to cargo +1 since pre-bump dependency tar x.x was vulnerable making previously compiled cargo vulnerable with tar x.x where as cargo +1 includes tar x.y staticly linked ?

Normally in distros they just update distinct system components but static linking requires another level of thinking for the whole dependency chain.

hello, curious about the progress here: am I reading correctly that there no further points open? Can this RFC be merged? It has been a lot of work and effort, would be a bit sad to leave it here :slightly_smiling_face:

Update: I checked in with Pietro, and he said that he'll try to get back to this in a few months.