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

> Over the next few years we plan to continue replacing C or C++ software with memory safe alternatives in the Let’s Encrypt infrastructure: OpenSSL and its derivatives with Rustls, our DNS software with Hickory, Nginx with River, and sudo with sudo-rs. Memory safety is just part of the overall security equation, but it’s an important part and we’re glad to be able to make these improvements.

It seems like a really challenging endeavor, but I appreciate their desire to maintain uptime and a public service like they do.

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

#4

Post by _flux » Mon, Jun 24, 2024, 8:45 PM UTC

skilled wrote: post #2

[flagged]

Is it completely unwarranted, though? It seems most of the issues listed here are indeed memory safety bugs that are more difficult to pull off in memory-safe languages such as Rust: https://www.cvedetails.com/vulnerability-list/vendor_id-2153...

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

#5

Post by pjmlp » Mon, Jun 24, 2024, 9:00 PM UTC

skilled wrote: post #2

[flagged]

Because since the Morris Worm in 1988, there are still plenty of networking facing services that keep being written in C and C++, and without the necessary sanitary precautions.

True, there are plenty of alternatives for many of those networking services, not necessarily Rust.

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

#6

Post by akira2501 » Mon, Jun 24, 2024, 9:05 PM UTC

Why does your ntpd have a json dependency?

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

#7

Post by NelsonMinar » Mon, Jun 24, 2024, 9:09 PM UTC

I like the idea of NTPD in Rust. Is there anything to read about how well ntpd-rs performs? Would love a new column for chrony's comparison: https://chrony-project.org/comparison.html

Particularly interested in the performance stats, how well the daemon keeps time in the face of various network problems. Chrony is very good at this. Some of the other NTP implementations (not on that chart) are so bad they shouldn't be used in production.

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

#8

Post by akaletF » Mon, Jun 24, 2024, 9:10 PM UTC

[flagged]

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

#9

Post by danudey » Mon, Jun 24, 2024, 9:11 PM UTC

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 querying (and parsing) the daemon's internal state.

(I'm not convinced that JSON is the way to go here, but that's the answer to the question)

[0] https://docs.ntpd-rs.pendulum-project.org/development/code-s...

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

#10

Post by danudey » Mon, Jun 24, 2024, 9:13 PM UTC

pjmlp wrote: post #5

skilled wrote: post #2

[flagged]

Because since the Morris Worm in 1988, there are still plenty of networking facing services that keep being written in C and C++, and without the necessary sanitary precautions. True, there are plenty of alternatives for many of those networking services, not necessarily Rust.

I hate writing code in golang, because I have to pepper every single function call with `if err != nil`, but then I think about how much C code I've seen that doesn't do that and I wonder how much of it should.