Secure Rust Guidelines
anssi-fr.github.io
Secure Rust Guidelines
1–10 of 61 posts
Re: Secure Rust Guidelines
#2[deleted]
Re: Secure Rust Guidelines
#3This is published by the ANSSI[1], National Cybersecurity Agency of France. They do quite a good job at publishing security guide.
Re: Secure Rust Guidelines
#4The context that I was missing at first:
> The Agence nationale de la sécurité des systèmes d'information (ANSSI; English: National Cybersecurity Agency of France) is a French service created on 7 July 2009 with responsibility for computer security [1].
I didn't know about "cargo-outdated". I liked having "npm outdated" within the JavaScript ecosystem, so I'll give this a try.
1. https://en.wikipedia.org/wiki/Agence_nationale_de_la_s%C3%A9...
Re: Secure Rust Guidelines
#5I personally strongly disagree with:
Functions or instructions that can cause the code to panic at runtime must not be used.
First of all, they kind of dodge this later by saying "Array indexing must be properly tested" (else it can panic) -- everyone thinks they write code which is "properly tested".
Personally, I often write panicing code -- if the code gets in a state where I have no idea how to fix it, I panic. For some code it is important it does quit, but I'd much prefer more code paniced than tried to carry on and ended up creating other problems.
Also, in rust if we don't want to panic we need to never use array indexing and never use integer division, just to start.
Of course, it's fine to write code which plans to never panic, but I think it would be better to say "Have a formal 'panic plan'", where either one panics early, or tries to never panic.
Re: Secure Rust Guidelines
#6The context that I was missing at first: > The Agence nationale de la sécurité des systèmes d'information (ANSSI; English: National Cybersecurity Agency of France) is a French service created on 7 July 2009 with responsibility for computer security [1]. I didn't know about "cargo-outdated". I liked having "npm outdated" within the JavaScript ecosystem, so I'll give this a try. 1. https://en.wikipedia.org/wiki/Agence_…
`cargo-outdated` is mint. If you haven't already, consider installing `cargo-edit` too! It adds `cargo add`/`cargo rm` to add/remove crates, as well as `cargo upgrade` to bump semver versions.
Re: Secure Rust Guidelines
#7I personally strongly disagree with: Functions or instructions that can cause the code to panic at runtime must not be used. First of all, they kind of dodge this later by saying "Array indexing must be properly tested" (else it can panic) -- everyone thinks they write code which is "properly tested". Personally, I often write panicing code -- if the code gets in a state where I have no idea how to fix it, I panic. F…
> First of all, they kind of dodge this later by saying "Array indexing must be properly tested" (else it can panic) -- everyone thinks they write code which is "properly tested".
You're skipping half the recommendation though:
> Array indexing must be properly tested, or the get method should be used to return an Option.
emphasis mine
> Also, in rust if we don't want to panic we need to never use array indexing and never use integer division, just to start.
I mean, that's literally the block above the one you quote:
> Common patterns that can cause panics are:
> * using unwrap or expect,
> * using assert,
> * an unchecked access to an array,
> * integer overflow (in debug mode),
> * division by zero,
> * large allocations,
> * string formatting using format!.
>> Rule LANG-NOPANIC
>> Functions or instructions that can cause the code to panic at runtime must not be used.
The bit you quote is really a additional reminder that array indexing is not panic-safe.
Re: Secure Rust Guidelines
#8The context that I was missing at first: > The Agence nationale de la sécurité des systèmes d'information (ANSSI; English: National Cybersecurity Agency of France) is a French service created on 7 July 2009 with responsibility for computer security [1]. I didn't know about "cargo-outdated". I liked having "npm outdated" within the JavaScript ecosystem, so I'll give this a try. 1. https://en.wikipedia.org/wiki/Agence_…
`cargo-outdated` is mint. If you haven't already, consider installing `cargo-edit` too! It adds `cargo add`/`cargo rm` to add/remove crates, as well as `cargo upgrade` to bump semver versions. https://github.com/killercup/cargo-edit
There's also cargo-crev which is pretty neat.
Re: Secure Rust Guidelines
#9I personally strongly disagree with: Functions or instructions that can cause the code to panic at runtime must not be used. First of all, they kind of dodge this later by saying "Array indexing must be properly tested" (else it can panic) -- everyone thinks they write code which is "properly tested". Personally, I often write panicing code -- if the code gets in a state where I have no idea how to fix it, I panic. F…
> First of all, they kind of dodge this later by saying "Array indexing must be properly tested" (else it can panic) -- everyone thinks they write code which is "properly tested". You're skipping half the recommendation though: > Array indexing must be properly tested, or the get method should be used to return an Option . emphasis mine > Also, in rust if we don't want to panic we need to never use array indexing and…
What do you do when your algorithm works with array indexing and you are never supposed to handle than None within the Option?
Ie if you have indexed array out of bounds that’s a developer’s mistake and not a “condition to be handled up the stack”.
It’s ok to panic if you agree that it’s better to panic rather than end up in a state that will probably cause even more issues down the line
Re: Secure Rust Guidelines
#10I'm having problems fulfilling this requirement in my libs: "Crates providing libraries should never use functions or instructions that can fail and cause the code to panic."
The Rust standard library Vec, HashMap etc. can cause a panic in Rust, if the device (such as a mobile phone with a small memory) runs out of memory.
C and C++ standard libraries (malloc, std::vector, std::map..) can handle those situations by returning null or throwing an exception.
I wish Rust had some easy way to recover from out-of-memory situations when using the standard library. I have been considering writing my own out-of-memory safe Vec, HashMap etc, but it can't be the right way to do it..