141–150 of 177 posts
Earlier quoted context omitted.
> 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.
So we need a new flag for gcc that writes zeros to any block of allocated memory before malloc returns, not a new language.
Have a little humility.
Earlier quoted context omitted.
I'm the person driving this. NTP is worth moving to a memory safe language but of course it's not the single most critical thing in our entire stack to make memory safe. I don't think anyone is claiming that. It's simply the first component that got to production status, a good place to start. NTP is a component worth moving to a memory safe language because it's a widely used critical service on a network boundary.…
Why are C and C++ all of a sudden unsafe? Did I miss something? What is safe now? JavaScript? PyTorch?
Earlier quoted context omitted.
> it's been running on many VMs without exploding memory for a while now Most of the security bugs we hear about don't cause random crashes on otherwise healthy machines, because that tends to get them noticed and fixed. It's the ones that require complicated steps to trigger that are really scary. When I look at NTP, I see a service that: - runs as root - talks to the network - doesn't usually authenticate its traff…
> runs as root ntpd can (and should) run as a user > talks to the network Makes outbound requests to the network. For it to be compromised, the network itself or a downstream server needs to be compromised. That's very different from something like hosting an http server. > doesn't usually authenticate its traffic Yes it does. ntp uses TLS to communicate with it's well known locations. > uses a bespoke binary packet…
> Yes it does. ntp uses TLS to communicate with it's well known locations.
My knee-jerk reaction is that TLS is not authentication. After skimming through the relevant spec [0], it is interesting how NTP uses TLS.
[NTS-KE] uses TLS to establish keys, to provide the client with an initial supply of cookies, and to negotiate some additional protocol options. After this, the TLS channel is closed with no per-client state remaining on the server side. [0]
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…
Earlier quoted context omitted.
JSON is a terrible configuration format since it doesn't support comments.
Ok. Do you want to now add anything relevant to the comment you’re replying to?
Earlier quoted context omitted.
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…
I also agree that there is too much churn in the Rust ecosystem and that we should try and slow things down in the coming years. ntpd-rs also does this: our MSRV is 1.70 right now (that was released over a year ago) and we test our code on CI against this version (as well as the current stable release). And we go a little further. Using the `direct-minimal-versions` (nightly only right now unfortunately) flag we down…
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/#:... .
I would consider that serious attempts have been made since 1961, however all of them failed in the presence of a free beer OS, with free beer unsafe compilers. The getting traction part is the relevance part.
1. They didn't have a big, well-known, company name with good enough reputation to attract contributors.
2. They didn't have brackets.
Success was because traction, traction was because appeal, and appeal was mostly because those two things. Nothing else was new AFAIK.
Earlier quoted context omitted.
Never heard of it. Shockingly little on wikipedia for example.
I hadn't heard of NTS until a Debian upgrade quietly installed ntpsec. It seems to now be the Debian default.
As far as I know, the Debian “default” is systemd-timesyncd. That is what you get out of the box. (Though, honestly, I automate most of my Linux installs, so I don’t interact with a stock install very often.) AFAIK, systemd-timesyncd does not support NTS at all.
Doing NTS on a pool would be quite complicated. The easy way is to share the same key across the pool. That is obviously not workable when pool servers are run by different people. The other way would be to have an another out-of-band protocol where the pool NTP servers share their key with the centralized pool NTS-KE servers. Nobody has built that, and it’s non-trivial.