Comments URL: https://news.ycombinator.com/item?id=47947850

Points: 1

# Comments: 0

Firstly, the most important reason the ntp.org domain name is so well known is because of the NTP pool, which is an entirely separate project (the Network Time Foundation calls it an associated project), which was allowed to use the `pool.ntp.org` domain name, but does not directly receive significant funding from the Network Time Foundation as far as I understand (I do not know the details of the domain name arrangement). That pool project was developed independently of the Network Time Foundation and is run by a different group of volunteers, mostly being developed and maintained by Ask Bjørn Hansen and hosting servers entirely consisting of (sometimes professional) volunteer operators. This is what many NTP implementations, specifically many Linux distributions, use as their standard source of time. But it does not appear to depend much on the Network Time Foundation for continued existence.

Secondly, despite all the claims made on the Network Time Foundation site, the IETF took over development and maintenance of the NTP protocol for something like two decades now already under the NTP working group. This was all done with the Network Time Foundation fully agreeing this was the way forward. But for some reason they still consider themselves exempted from any process that the IETF uses and consider themselves as the true developers of the protocol. They constantly frustrate the processes that the IETF uses, claiming that they should receive special treatment as being the 'reference implementation'. Meanwhile, the IETF NTP WG does not have a concept of the reference implementation at all, instead considering all NTP implementations equal.

Aside from this frustrating stance, the Network Time Foundation also didn't do much work on trying to forward the standard at all, instead relying on the status quo from the late 90s and early 2000s. Meanwhile the IETF NTP WG worked on standardizing a way to secure NTP traffic (with regular NTP traffic being relatively easy to man in the middle, with older implementations even being so predictable that faking responses didn't even need reading the requests). That much more secure standard, NTS, was fully standardized in September of 2020, but the Network Time Foundation continues to not implement this standard. All of this has resulted in almost every Linux distribution that I know of replacing their ntpd implementation with NTPsec (with ntpd not even being available as an alternative anymore for installation).

Meanwhile people also started working on NTPv5, in order to remove some of the unsafe and badly defined parts of the standard, and in general bring the spec back up to date. As part of this process, it was decided some time ago that in contrast to the previous NTP standards, the algorithms specifying what a client should do in order to synchronize the time should be removed from the standard (the algorithms specified in the previous standards were not being used by any implementation, not even the ntpd implementation by the Network Time Foundation itself). NTPv5 instead focuses on the wire format of NTP packets and the simple interactions between parties. Yet despite there having been a consensus call on this, and despite no current implementation following the exact algorithm as specified in NTPv4, the Network Time Foundation continues to frustrate the process by claiming that these algorithms are an essential part of the standard.

All of this frustration was also a large part of why the PTP protocol was eventually developed at the IEEE. That is to say: even though the operating mode of PTP is often quite different to that of NTP these days, the information that needs to be transferred is essentially the same, and the packets could have trivially been defined to be the same as long as NTP had built in a little bit of additional flexibility a little bit earlier. This would have also helped NTP in the end (with for example hardware timestamping only being implemented for PTP right now, even though it could have been just as useful in NTP), and with PTP now also aiming to introduce a simpler client-server model via CSPTP that looks a whole lot like what NTP was trying to achieve all this time with its most used operating mode.

It is my belief that the Network Time Foundation continues to push themselves in a corner of more and more irrelevance even though that did not need to be. The historical significance of David Mills' ntpd implementation is definitely there, and we should applaud the initial efforts and their focus on keeping the protocol open and widely available. And I do believe that the current people at the Network Time Foundation could still provide more than enough valuable input in the standardization process, but they cannot claim anymore to be the sole developers of the NTP protocol. Times have changed, there are now multiple implementations with an equally valid claim. Especially with GNSS (specifically GPS) being under attack more and more these days, we need alternative ways of synchronizing computer clocks to a standard time in a secure way. NTP and NTS are perfectly positioned to take on that task and we need to make sure that we keep the standard up to date for our evolving world.

Edit: if you want something else to donate to, I would consider donating to the IETF, NTPsec, or maybe donating some time to the NTP pool. I would also link to donations for Chrony (one of the other major NTP server implementations) but they do not appear to offer anything. Linking to my own project's donation page does not seem fair considering the contents of this post.

As for dependencies: zlib, zlib-ng and zlib-rs all obviously need some access to OS APIs for filesystem access if compiled with that functionality. At least for zlib-rs: if you provide an allocator and don't need any of the file IO you can compile it without any dependencies (not even standard library or libc, just a couple of core types are needed). zlib-rs does have some testing dependencies though, but I think that is fair. All in: all of them use almost exactly the same external dependencies (i.e.: nothing aside from libc-like functionality).

zlib-rs is a bit bigger by default (around 400KB), with some of the Rust machinery. But if you change some of that (i.e. panic=abort), use a nightly compiler (unfortunately still needed for the right flags) and add the right flags both libraries are virtually the same size, with zlib at about 119KB and zlib-rs at about 118KB.

Of course, there are many other services that could be made memory safe, and maybe there is some sort of right or smart order in which we should make our core network infrastructure memory safe. But everyone has their own priorities here, and I feel like this could end up being an endless debate of whatabout-ism. There is no right place to start, other than to just start.

Aside from memory safety though, I feel like our implementation has a strong focus on security in general. We try and make choices that make our implementation more robust than what was out there previously. Aside from that, I think the NTP space has had an under supply of implementations, with there only being a few major open source implementations (like ntpd, ntpsec and chrony). Meanwhile, NTP is one of those pieces of technology at the core of many of the things we do on the modern internet. Knowing the current time is one of these things you just need in order to trust many of the things we take for granted (without knowledge of the current time, your TLS connection could never be trusted). I think NTP definitely deserves this attention and could use a bunch more attention.

One thing to note about amplification: amplification has always been something that NTP developers have been especially sensitive to. I would say though that protocols like QUIC and DNS have far greater amplification risks. Meanwhile, our server implementation forces that responses can never be bigger than the requests that initiated them, meaning that no amplification is possible at all. Even if we would have allowed bigger responses, I cannot imagine NTP responses being much bigger than two or three times their related request. Meanwhile I've seen numbers for DNS all the way up to 180 times the request payload.

As for your worries: I think being a little cautious keeps you alert and can prevent mistakes, but I also feel that we've gone out of our way to not do anything crazy and hopefully we will be a net positive in the end. I hope you do give us a try and let us know if you find anything suspicious. If you have any feedback we'd love to hear it!

Given the amount of testing we (and other parties) have done, and given the strong theoretical foundation of our algorithm I’m pretty confident we’d do well in many production environments. If you do find any performance issues though, we’d love to hear about them!

Some responses to your notes:

- The trouble is that we had to re-implement an existing CLI, and as you might expect with something that evolved over a period of some 30 years, there are quite a few weird behaviors in sudo. We initially had a mostly working implementation based on clap, but could not get some parts of the CLI to parse nicely, i.e. the code just looked hacky, and had to do all kinds of post-processing to complete the parsing of the CLI, resulting in lots of additional code. Maybe we should have looked at something like lexopt, but we just went ahead and did it ourselves initially just to see how it would go, we kind of liked the result and never looked at any alternative implementations. I do believe we looked at clap alternatives for a little while to see if something would make our parsing a little easier, but lexopt didn't surface at that time for whatever reason. We're not perfect either. I do think our parsing is pretty decent though.

- We did think about contributing back, but in the end we wanted a little more control over where the password (or more precisely 'hidden input') was stored in memory, and needed some specific parts for handling TTYs (given our setuid context) resulting in us quickly deconstructing rpassword until almost nothing of it was left. I think it's a little hard to contribute those things back, but as a side project I'd love to contribute some of the changes we made back to rpassword, there just wasn't the time to do it at that time as it would be quite a bit of work.

- Glob is a hard one, as the Rust crate is not entirely compatible with how the original sudo works. But the logic has to be there one way or another and if we have to decide between libc (i.e. probably C code) and Rust, we'd prefer to go with Rust of course. That already resulted in an issue being opened for incompatibilities of course, but it's a hard one: I'd prefer to keep the Rust code, so I hope that someone who manages glob at least agrees that it should be as compatible as possible. But I can't and don't have the expectation that their team has the same priorities, and thus we are back at one of the reasons why a dependency might not always be worth it. There's always choices to be made. For now though, we'll keep the Rust crate dependency, as it works well enough!

- Thiserror is great for prototyping, but loses its value quickly once you know what kind of errors you have, it just takes a few lines of extra code. But, thinking about teams etc: given that it is not that big, and is created and maintained by dtolnay, whose code you probably already use in multiple ways in nearly any other project, it's not the worst either. For sudo-rs though, I still think it was the better choice to remove it.

- All the sudo-* packages were mostly removed because we didn't want to expose any public API for all that internal stuff. Our initial goal is to get sudo the CLI application working, not to provide all the building blocks while the API is still in flux. We initially put it all in separate crates because of compilation time worries, but in the end those worries were unfounded. It's one of those things where Rust is still somewhat limited: we can't specify these sort of semi-private dependencies in the crates ecosystem right now, if we would have been able to specify 'nobody but us can use these as a dependency' they would have probably stayed as separate crates.

BTW: I'd like to thank you for continuing to work on Clap! There might have been a time I would have been a little worried about all the breaking changes and churn happening, but since that has stabilized I couldn't be happier! I don't think there's anyone on the sudo-rs team that had anything against clap, and I did not want to single out clap in our post specifically, so I hope you don't consider it an attack against clap. At least personally I use clap in basically every other project with a CLI.

For me personally, creating this Rust version allowed me to work on something that I would normally not be able to work on, given how I would not rate my confidence in writing relatively safe C code very high. If nothing else, at least we already found a few bugs in the original sudo because of this work. Despite the 43 years of bugfixing, such a piece of software is unlikely to ever be free of bugs, even if just for the changing surroundings.

Other than that, having some alternatives can never hurt, as long as we keep cooperating and trying to learn from each others work (and from each others mistakes).