You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a tracking ticket for potential ideas for Rust security improvements to the core language and standard library to be submitted via the RFC process at https://github.com/rust-lang/rfcs
The idea here is list some potential RFC items and then coordinate who (if anybody) wants to work on them. Once we've figured that out we can go from there.
Feel free to edit the list below or request it be edited in the comments:
Add traits and auto impls to the language to express the idea that, given any valid instance of T, the bytes of that instance also constitute a valid instance of U. Particularly useful for zero-copy parsing/serialization, SIMD, and unlocking Atomic<T>.
An early draft that will need to be completely overhauled is here. Code which implements a subset of this concept is here.
This is used to address a use case for appending contents of a vector to itself. This is a common pattern in decompressors of all kinds (gzip, audio, images), but people doing it in practice tend to end up with implementations that are slow, unsafe, or both. See this pre-RFC for rather in-depth info.
I think it would be better to just submit each of these as a separate issue instead of having a meta-issue with many sub-issues. That is, it would be easier to deal with this kind of thing if there were a 1:1 correspondence between issues and proposals.
@briansmith this was just a quick ideas list for people who might want to work on the same RFCs to coordinate on collaboration. In the description I had suggested:
The idea here is list some potential RFC items and then coordinate who (if anybody) wants to work on them. Once we've figured that out we can go from there.
The next issues I feel we should open after this are the RFCs themselves (or Discourse pre-RFC threads).
Is there a way to selectively impose security lint on dependencies? This came up in the unicode RFC, but you guys would care much more about it for restrictions on unsafe.
How would this work with unsafe? It'd mean that code would stop compiling when a dependency not authorized to use unsafe started using it. To actually do this well, you'd need to patch the dependency for each unsafe usage, which makes cargo unhappy, but another solution might appear.
Activity
briansmith commentedon Oct 21, 2018
I think it would be better to just submit each of these as a separate issue instead of having a meta-issue with many sub-issues. That is, it would be easier to deal with this kind of thing if there were a 1:1 correspondence between issues and proposals.
tarcieri commentedon Oct 21, 2018
@briansmith this was just a quick ideas list for people who might want to work on the same RFCs to coordinate on collaboration. In the description I had suggested:
The next issues I feel we should open after this are the RFCs themselves (or Discourse pre-RFC threads).
burdges commentedon Oct 21, 2018
Is there a way to selectively impose security lint on dependencies? This came up in the unicode RFC, but you guys would care much more about it for restrictions on unsafe.
How would this work with unsafe? It'd mean that code would stop compiling when a dependency not authorized to use unsafe started using it. To actually do this well, you'd need to patch the dependency for each unsafe usage, which makes cargo unhappy, but another solution might appear.
Shnatsel commentedon Sep 3, 2019
For the record, this came out of safety-dance: rust-lang/rust#64069
I've also opened an RFC for another missing safe abstraction: rust-lang/rfcs#2714
I also need to turn this into an RFC for Cargo: https://github.com/Shnatsel/rust-audit
Shnatsel commentedon Sep 6, 2019
Another one came out of a discussion I started on clippy lints: rust-lang/rfcs#2756