Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Secure Rust Guidelines

anssi-fr.github.io

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Secure Rust Guidelines

#21

Post by Grimburger »

estebank wrote: post #19
Grimburger wrote: post #14

Disappointed there's no mention of vendoring. Anyone with _proper_ security concerns should cargo vendor by default. Last I looked supply chain attackers don't respect semver and you are all one casual offhand cargo update away from catastrophe.

For applications (as opposed to libraries), Cargo.lock fulfills the same function as vendoring, but lets cargo audit continue working as expected.

To repeat:

> one casual offhand cargo update away from catastrophe

There is a scary amount of libraries who don't even bother specifying patch levels and will auto update everything upon request without question, even worse cargo doesn't make it explicit and as such version "1.0" is equivalent to "1.0.*" in the cargo manifest. Please refer to my previous comment about bad actors not respecting semver as much as many would love them to.

`cargo audit` can be compromised by bad actors. `cargo update` also. If you have a security first application then always vendor, this isn't rust specific.

Re: Secure Rust Guidelines

#22

Post by liftm »

Grimburger wrote: post #14

Disappointed there's no mention of vendoring. Anyone with _proper_ security concerns should cargo vendor by default. Last I looked supply chain attackers don't respect semver and you are all one casual offhand cargo update away from catastrophe.

Not only does the guide not mention it, it seems to actively disagree with you:

> The cargo-outdated tool must be used to check dependencies status. Then, each outdated dependency must be updated or the choice of the version must be justified.

Especially for open source projects, there are also some other arguments against vendoring, see e.g. https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packag...

If there's something that's missing mention, it is imho that the Cargo.lock files should be committed, and also included e.g. in docker builds. (I don't believe in offhanded "cargo update". And even if you did accidentally type it, nothing will be built/executed yet. There's ample opportunity to git restore Cargo.lock.)

Re: Secure Rust Guidelines

#23

Post by manicpolymath »

rpigab wrote: post #15
MrJohz wrote: post #12

Earlier quoted context omitted.

> seclippy According to a quick search, I propose "trombine" as the French version of clippy.

Don't you mean trombone? Or is there a hidden pun?

I detect a pun. _trombine_ is, according to Wiktionary anyway, a colloquial French word for _face_.

Re: Secure Rust Guidelines

#24

Post by mlindner »

tialaramex wrote: post #11
mlindner wrote: post #10

Earlier quoted context omitted.

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.

It's usually considered a leak if we can't release it. Arguably you can release the thing you leaked with Box::leak(). Just tell Box you want a new box that's just a thin wrapper for your mutable reference (this is unsafe), then drop the box. But generally the purpose of Box::leak() is to never release the thing inside the box. So, yes, you could argue semantically about whether this is "really" a leak but in practic…

My definition of leak would generally be what Valgrind would call a leak. Wouldn't Valgrind not call this a leak given that there would still be a reference remaining at program exit?

Re: Secure Rust Guidelines

#25

Post by MrJohz »

rpigab wrote: post #15
MrJohz wrote: post #12

Earlier quoted context omitted.

> seclippy According to a quick search, I propose "trombine" as the French version of clippy.

Don't you mean trombone? Or is there a hidden pun?

According to French Wikipedia, one of the names for Clippy in French is Trombine. Given the other user mentioned that it means "face", and given trombone is, I believe, a paper clip (my French education unfortunately did not get this far), I suspect it's used as a kind of cute pun thing.

Kind of like how "Clippy" is obviously derived from the word "paperclip", but has slightly cuter and more friendly connotations. (Except for those experienced with Clippy, who may have other connotations at this point...)

Re: Secure Rust Guidelines

#26

Post by kaba0 »

mlindner wrote: post #24
tialaramex wrote: post #11

Earlier quoted context omitted.

It's usually considered a leak if we can't release it. Arguably you can release the thing you leaked with Box::leak(). Just tell Box you want a new box that's just a thin wrapper for your mutable reference (this is unsafe), then drop the box. But generally the purpose of Box::leak() is to never release the thing inside the box. So, yes, you could argue semantically about whether this is "really" a leak but in practic…

My definition of leak would generally be what Valgrind would call a leak. Wouldn't Valgrind not call this a leak given that there would still be a reference remaining at program exit?

If my understanding is correct, the reference could get dropped at the end of the scope while the pointed at memory location will remain in memory - so Valgrind would leak it, but I haven’t tested it.

Re: Secure Rust Guidelines

#27

Post by kaba0 »

Grimburger wrote: post #14

Disappointed there's no mention of vendoring. Anyone with _proper_ security concerns should cargo vendor by default. Last I looked supply chain attackers don't respect semver and you are all one casual offhand cargo update away from catastrophe.

Is there any plan to move to domain-qualified names? They seem to have prevented most of these attack in case of the java ecosystem.

Re: Secure Rust Guidelines

#28

Post by ilammy »

Grimburger wrote: post #21
estebank wrote: post #19

Earlier quoted context omitted.

For applications (as opposed to libraries), Cargo.lock fulfills the same function as vendoring, but lets cargo audit continue working as expected.

To repeat: > one casual offhand cargo update away from catastrophe There is a scary amount of libraries who don't even bother specifying patch levels and will auto update everything upon request without question, even worse cargo doesn't make it explicit and as such version "1.0" is equivalent to "1.0.*" in the cargo manifest. Please refer to my previous comment about bad actors not respecting semver as much as many…

Oh, so you trust "cargo build"? Why?

Sure, "cargo update" will update the dependencies – that's what it's meant to do. The point of Cargo.lock is to ensure that all compilations use the same known set of versions, otherwise it's possible for developers to use one library and the users to use a different one. With Cargo.lock a new version of library won't be used without an explicit "cargo update".

Re: Secure Rust Guidelines

#29

Post by ilammy »

kaba0 wrote: post #27
Grimburger wrote: post #14

Disappointed there's no mention of vendoring. Anyone with _proper_ security concerns should cargo vendor by default. Last I looked supply chain attackers don't respect semver and you are all one casual offhand cargo update away from catastrophe.

Is there any plan to move to domain-qualified names? They seem to have prevented most of these attack in case of the java ecosystem.

Not on crates.io, they're pretty adamant about "no scoping" approach to naming.

Scoping does not really solve injecting malicious code into the dependency tree in some update. Scoping is more of a defense against typosquatting via new crates.

You can run your own crate registry if you're particularly concerned over what gets published on crates.io.

Post reply on HN