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

More Memory Safety for Let's Encrypt: Deploying ntpd-rs

letsencrypt.org

Post reply on HN
Print view View original

71–80 of 177 posts

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#71

Post by stouset »

VancouverMan wrote: post #62
stouset wrote: post #52

Earlier quoted context omitted.

Downvoting isn’t censorship. It’s disagreement. “What about this one C project that hasn’t been a mess of exploitable vulnerabilities” is thoroughly unconvincing in a world where networked C programs are an unending source of severe vulnerabilities.

When even a very small number of downvotes here can result in a comment's text being coloured in a way that makes it harder to read, or even nearly impossible to read in extreme cases, I think it's reasonable to equate downvoting with censorship. Censorship doesn't require content to be completely hidden or blocked; even just partially obscuring the content in some way is still censorship.

I disagree that this is equivalent to censorship, but it sure sounds like a really good incentive to make more convincing comments than “Then how do you explain this single counterexample? Checkmate, Rustaceans.”

Plenty of reasonable disagreement happens here without getting downvoted into obscurity. Substantive points are generally upvoted even when they’re controversial opinions. So I don’t feel too upset when borderline-trolling or bad-faith arguments get hidden by consensus.

Ironic counterexample: It looks like you may have gotten downvoted despite having a fundamentally reasonable perspective.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#73

Post by vlakreeh »

amiga386 wrote: post #23
orf wrote: post #15

Earlier quoted context omitted.

Would you rather it had a JSON dependency to parse a config file, or yet another poorly thought out, ad-hoc homegrown config file format?

Poorly thought out, ad-hoc homegrown config file format, please. Every time. 1. Code doesn't change at the whims of others. 2. The entire parser for an INI-style config can be in about 20 lines of C 3. Attacker doesn't also get to exploit code you've never read in the third party dependency (and its dependencies! The JSON dependency now wants to pull in the ICU library... I guess you're linking to that, too) 4. Compl…

1. I can pin my json parser dependency and literally never update it again

2. And how many times have we seen 20 lines of C backfire with some sort of memory safety issue.

3. First off, i'd go out on a limb and say the number of attacks from a well-established (or even a naive one) rust json parsing library is dwarfed by the number of attacks from adhoc config parsers written in C with some overlooked memory safety issue.

4. Usually being the key word, tons of adhoc config formats have weird shit in them. With json (or yaml/toml) you know what you're getting into and you immediately know what you're able and unable to do.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#74

Post by dequan »

johnklos wrote: post #72

[flagged]

I agree that it would be great if the ecosystem was a bit slower to use every new version and it does seem like things are beginning to tend in that direction as many foundational crates have begun declaring MSRVs of !LATEST.

However I don't think the pace of updates really changes anything in terms of tool chain security. If Rust decided to go to a 36 week release cycle, each release would just have 6x as much stuff in it. If you can't keep up reviewing N changes in a 6 week release cycle, moving to a 6*X release cycle will not help you review N*X changes.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#76

Post by [deleted] »

danudey wrote: post #9
akira2501 wrote: post #6

Why does your ntpd have a json dependency?

This is a good question to ask, especially in the age of everything pulling in every possible dependency just to get one library function or an `isNumeric()` convenience function. The answer is that there is observability functionality which provides its results as JSON output via a UNIX socket[0]. As far as I can see, there's no other JSON functionality anywhere else in the code, so this is just to allow for easily…

[deleted]

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#77

Post by koolba »

dheera wrote: post #61
ghshephard wrote: post #59

Earlier quoted context omitted.

One of the major drivers (if not the driver) for the creation of Rust the fact that C is not a memory-safe language. This has been known for decades, but it wasn't until 2010 that a serious attempt at writing a new system-language that was memory safe was attempted and got traction - Rust. https://kruschecompany.com/rust-language-concise-overview/#:... .

How is C not memory safe? If I access memory I didn't allocate the OS shuts the program down. Is that not memory safety? (Unless you're running it on bare metal ...)

> If I access memory I didn't allocate the OS shuts the program down.

The real problem is when you access memory that did allocate.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#78

Post by chaoskitty »

dequan wrote: post #74
johnklos wrote: post #72

[flagged]

I agree that it would be great if the ecosystem was a bit slower to use every new version and it does seem like things are beginning to tend in that direction as many foundational crates have begun declaring MSRVs of !LATEST. However I don't think the pace of updates really changes anything in terms of tool chain security. If Rust decided to go to a 36 week release cycle, each release would just have 6x as much stuff…

Serious question: why does it need to change so much and so often? I know nothing about rust development, so I'm curious about why it's worlds different from the development of other toolchains.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#79

Post by patmorgan23 »

dheera wrote: post #61
ghshephard wrote: post #59

Earlier quoted context omitted.

One of the major drivers (if not the driver) for the creation of Rust the fact that C is not a memory-safe language. This has been known for decades, but it wasn't until 2010 that a serious attempt at writing a new system-language that was memory safe was attempted and got traction - Rust. https://kruschecompany.com/rust-language-concise-overview/#:... .

How is C not memory safe? If I access memory I didn't allocate the OS shuts the program down. Is that not memory safety? (Unless you're running it on bare metal ...)

I think you have a missunderstanding on what memory safety is.

Memory safety means that your program is free of memory corruption bugs (such as buff overflow or under flow bugs) that could be used to retrieve data the user isn't supposed to have, or can be used to inject code/commands that then get run in the programs process. These don't get shut down by the OS because the program is interacting with its own memory.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#80

Post by patmorgan23 »

orf wrote: post #15
akira2501 wrote: post #6

Why does your ntpd have a json dependency?

Would you rather it had a JSON dependency to parse a config file, or yet another poorly thought out, ad-hoc homegrown config file format?

Why isn't there a decent parser in the standard library? More than 50% of programs will probably touch json at this point.
Post reply on HN