Secure Rust Guidelines
anssi-fr.github.io
Secure Rust Guidelines
1–10 of 29 posts
Re: Secure Rust Guidelines
#2Took me a while to realise this is a project by the French National Cybersecurity Agency (ANSSI), not just some random github repos from someone with Important Opinions on how to use a programming language.
All of this advice makes a lot of sense but a lot of recommendations cannot easily be checked for or enforced. It would be nice to be able to quickly put Clippy into "ANSSI mode" to check and enforce all of these requirements.
Re: Secure Rust Guidelines
#3Took me a while to realise this is a project by the French National Cybersecurity Agency (ANSSI), not just some random github repos from someone with Important Opinions on how to use a programming language. All of this advice makes a lot of sense but a lot of recommendations cannot easily be checked for or enforced. It would be nice to be able to quickly put Clippy into "ANSSI mode" to check and enforce all of these…
On the other hand, if it could be easily checked, the document would be: "Enable ANSSI clippy mode" and not multiple pages.
Re: Secure Rust Guidelines
#4Took me a while to realise this is a project by the French National Cybersecurity Agency (ANSSI), not just some random github repos from someone with Important Opinions on how to use a programming language. All of this advice makes a lot of sense but a lot of recommendations cannot easily be checked for or enforced. It would be nice to be able to quickly put Clippy into "ANSSI mode" to check and enforce all of these…
On the other hand, if it could be easily checked, the document would be: "Enable ANSSI clippy mode" and not multiple pages.
Explaining why something is bad is still necessary if you rely on automated code review. Clippy does this, with specific codes for specific (potential) problems that the linter catches. You can learn a lot about patterns in Rust by just reading through the bad patterns and read their suggested alternatives.
Re: Secure Rust Guidelines
#5Earlier quoted context omitted.
On the other hand, if it could be easily checked, the document would be: "Enable ANSSI clippy mode" and not multiple pages.
Explaining why something is bad is still necessary if you rely on automated code review. Clippy does this, with specific codes for specific (potential) problems that the linter catches. You can learn a lot about patterns in Rust by just reading through the bad patterns and read their suggested alternatives.
I fully agree, but then it would be integrated with Clippy or in a wiki with a page per code (like shellcheck).
The document in this post is helpful because it does the first step of explaining the rationals, that can then eventually be automated (and then/copy pasted in the explanations).
Re: Secure Rust Guidelines
#6> In a secure Rust development, the code must not leak memory or resource in particular via Box::leak.
Uh, so is Box::leak forbidden in general? Because creating a &'static in some initialization code that lives for the rest of the program is a rather common use case… https://docs.rs/log/0.4.17/src/log/lib.rs.html#1408
Or is it only forbidden if it's actually a leak?
Re: Secure Rust Guidelines
#7> In a secure Rust development, the code must not leak memory or resource in particular via Box::leak. Uh, so is Box::leak forbidden in general? Because creating a &'static in some initialization code that lives for the rest of the program is a rather common use case… https://docs.rs/log/0.4.17/src/log/lib.rs.html#1408 Or is it only forbidden if it's actually a leak?
> creating a &'static in some initialization code that lives for the rest of the program is a rather common use case
Isn't that the use-case for lazy_static? Or SyncOnceCell once it's in stable Rust. Though I'm not sure how it's implemented under the hood.
Re: Secure Rust Guidelines
#8> In a secure Rust development, the code must not leak memory or resource in particular via Box::leak. Uh, so is Box::leak forbidden in general? Because creating a &'static in some initialization code that lives for the rest of the program is a rather common use case… https://docs.rs/log/0.4.17/src/log/lib.rs.html#1408 Or is it only forbidden if it's actually a leak?
I mean, it is actually a leak, that's exactly why you're doing it.
This document says you should not because, by their definition, that's not "secure Rust development".
Re: Secure Rust Guidelines
#9Earlier quoted context omitted.
Explaining why something is bad is still necessary if you rely on automated code review. Clippy does this, with specific codes for specific (potential) problems that the linter catches. You can learn a lot about patterns in Rust by just reading through the bad patterns and read their suggested alternatives.
I fully agree, but then it would be integrated with Clippy or in a wiki with a page per code (like shellcheck). The document in this post is helpful because it does the first step of explaining the rationals, that can then eventually be automated (and then/copy pasted in the explanations).
I agree with you all. Bake it into clippy or make a different clippy aka seclippy. Also, I appreciate the docs so I understand why with examples. Also make a attribute that blocks some of these things
Re: Secure Rust Guidelines
#10> In a secure Rust development, the code must not leak memory or resource in particular via Box::leak. Uh, so is Box::leak forbidden in general? Because creating a &'static in some initialization code that lives for the rest of the program is a rather common use case… https://docs.rs/log/0.4.17/src/log/lib.rs.html#1408 Or is it only forbidden if it's actually a leak?
How is it a leak if it still has a reference? I only would classify something as a leak if it has no remaining valid references to some piece of data.