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

11–20 of 177 posts

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

#11

Post by tialaramex »

skilled wrote: post #2

[flagged]

Correctness matters, in their particular game that's especially true although I'm doubtful of common insistence that it's better for this or that software to be fast than correct.

Rust is really good for correctness. Take "Hello, World", the obvious toy program. Someone tried giving it various error states instead of (as would be usual) a normal happy terminal environment. In C or C++ the canonical "Hello, World" program terminates successfully despite any amount of errors, it just doesn't care about correctness.

The default Rust Hello World, the one you get out of the box when you make a new project, or you'd show people on a "My First Rust Program" course, will complain about the errors when they happen. Because doing so is correct.

It's the New Jersey style. The priority for these languages was simplicity of implementation. It's more important that you can cobble together a C compiler easily than that the results are useful or worthwhile. This contributed to C's survival, but we pay the price until we give it up.

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

#12

Post by akaletF »

tialaramex wrote: post #11
skilled wrote: post #2

[flagged]

Correctness matters, in their particular game that's especially true although I'm doubtful of common insistence that it's better for this or that software to be fast than correct. Rust is really good for correctness. Take "Hello, World", the obvious toy program. Someone tried giving it various error states instead of (as would be usual) a normal happy terminal environment. In C or C++ the canonical "Hello, World" pro…

If println panics if the write fails that is kind of cheating, isn't it. Yes, toy C programs do not check the return value of printf. So what.

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

#13

Post by itishappy »

skilled wrote: post #2

[flagged]

> I struggle to understand why they would say that as the opening statement in such a matter-of-fact manner.

TFA's second sentence explains the facts of the matter along with the flavor of Kool-Aid they stock:

> The CA software itself is written in memory safe Golang, but from our server operating systems to our network equipment, lack of memory safety routinely leads to vulnerabilities that need patching.

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

#14

Post by dralley »

akaletF wrote: post #12
tialaramex wrote: post #11

Earlier quoted context omitted.

Correctness matters, in their particular game that's especially true although I'm doubtful of common insistence that it's better for this or that software to be fast than correct. Rust is really good for correctness. Take "Hello, World", the obvious toy program. Someone tried giving it various error states instead of (as would be usual) a normal happy terminal environment. In C or C++ the canonical "Hello, World" pro…

If println panics if the write fails that is kind of cheating, isn't it. Yes, toy C programs do not check the return value of printf . So what.

I would venture to say that most C programs don't check the return value of printf, including ones that ought not to be "toys"

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

#16

Post by itishappy »

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?

It uses TOML for configuration.

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

#17

Post by toast0 »

akaletF wrote: post #12
tialaramex wrote: post #11

Earlier quoted context omitted.

Correctness matters, in their particular game that's especially true although I'm doubtful of common insistence that it's better for this or that software to be fast than correct. Rust is really good for correctness. Take "Hello, World", the obvious toy program. Someone tried giving it various error states instead of (as would be usual) a normal happy terminal environment. In C or C++ the canonical "Hello, World" pro…

If println panics if the write fails that is kind of cheating, isn't it. Yes, toy C programs do not check the return value of printf . So what.

Setting up your environment so that you have to check for errors or the errors propagate doesn't seem to be cheating when the complaint is that other environments often omit checking for errors even when it matters.

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

#18

Post by akaletF »

dralley wrote: post #14
akaletF wrote: post #12

Earlier quoted context omitted.

If println panics if the write fails that is kind of cheating, isn't it. Yes, toy C programs do not check the return value of printf . So what.

I would venture to say that most C programs don't check the return value of printf, including ones that ought not to be "toys"

I don't know. Most serious programs will use write() and then check the return value. In locations where it does not matter (say a test suite that is guaranteed to signal an error but an fprintf() error message could fail in theory) not checking is fine I think.

You will not see the message if you get a panic either ...

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

#19

Post by motrm »

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…

If the pieces of state are all well known at build time - and trusted in terms of their content - it may be feasible to print out JSON 'manually' as it were, instead of needing to use a JSON library,

  print "{"
  print "\"some_state\": \"";
  print GlobalState.Something.to_text();
  print "\", ";
  print "\"count_of_frobs\": ";
  print GlobalState.FrobsCounter;
  print "}";
Whether it's worth doing this just to rid yourself of a dependency... who knows.

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

#20

Post by ComputerGuru »

Unlike say, coreutils, ntp is something very far from being a solved problem and the memory safety of the solution is unfortunately going to play second fiddle to its efficacy.

For example, we only use chrony because it’s so much better than whatever came with your system (especially on virtual machines). ntpd-rs would have to come at least within spitting distance of chrony’s time keeping abilities to even be up for consideration.

(And I say this as a massive rust aficionado using it for both work and pleasure.)

Post reply on HN