12 ms·

They are justifying the rewrite by saying that it is memory safe. I don’t think its a bad goal but if they don’t do the work to maintain and package these for

by bogota 4y ago

They are justifying the rewrite by saying that it is memory safe. I don’t think its a bad goal but if they don’t do the work to maintain and package these for distros it wont make it very far. However im always surprised by how many people are fanatics of rust and they do contribute a lot to packaging at least for Gentoo which is my daily driver. I could see a lot of these taking off if it does show a reduction in attack surface and it works seamlessly as a replacement for existing solutions hopefully not forcing a new config on everyone.

akira2501 4y ago
Doesn't Rust just panic and abort on runtime memory errors? So, we maybe get memory security, but we seemingly do nothing for DoS. Isn't that a large attack vector for NTP, given it's primary utility in other protocols?
- steveklabnik 4y ago
  Rust the language doesn’t know anything about heap allocation, so in a strict sense, no. The standard library provides a number of APIs that abort on allocation failures, yes. There are currently nightly-only APIs for some of them to return Result instead, and they’ll hit stable eventually. You could also not use them if you don’t want that behavior.
- black_puppydog 4y ago
  No, rust avoids most memory errors by proving at compile time that they don't exist. That's why it forces you to write code with lifetime annotations and such, so that thst proof becomes feasible. I say "most" because it also allows you to get out the footguns, meaning you can sidestep this proof mechanism. But you do that by declaring a block/function as "unsafe", so if you do find a memory bug, you know exactly where to start your search.
- Veliladon 4y ago
  > Doesn't Rust just panic and abort on runtime memory errors? Technically yes if you directly access an index that's OOB but stuff like Vecs and Arrays have the get and get_mut methods which allows you to try to retrieve an element (or slice). If the element is in bounds you get a Some<T> with a reference to the element (or slice) and if it fails it'll return an Error type which can be handled rather than panicking out. It's not even slower to use the .get method rather than direct indexes because attempts to access indexes directly are implemented as .get.unwrap()
- staticassertion 4y ago
  That's right, DoS in Rust is still a thing you can have. But it's no worse than in memory unsafe languages, since memory unsafety can also lead to DoS (and in a much worse way - there are methods for managing panics, managing segfaults is much harder).

by bogota 4y ago

akira2501 4y ago

Doesn't Rust just panic and abort on runtime memory errors? So, we maybe get memory security, but we seemingly do nothing for DoS. Isn't that a large attack vector for NTP, given it's primary utility in other protocols?

steveklabnik 4y ago
Rust the language doesn’t know anything about heap allocation, so in a strict sense, no. The standard library provides a number of APIs that abort on allocation failures, yes. There are currently nightly-only APIs for some of them to return Result instead, and they’ll hit stable eventually. You could also not use them if you don’t want that behavior.
black_puppydog 4y ago
No, rust avoids most memory errors by proving at compile time that they don't exist. That's why it forces you to write code with lifetime annotations and such, so that thst proof becomes feasible. I say "most" because it also allows you to get out the footguns, meaning you can sidestep this proof mechanism. But you do that by declaring a block/function as "unsafe", so if you do find a memory bug, you know exactly where to start your search.
Veliladon 4y ago
> Doesn't Rust just panic and abort on runtime memory errors? Technically yes if you directly access an index that's OOB but stuff like Vecs and Arrays have the get and get_mut methods which allows you to try to retrieve an element (or slice). If the element is in bounds you get a Some<T> with a reference to the element (or slice) and if it fails it'll return an Error type which can be handled rather than panicking out. It's not even slower to use the .get method rather than direct indexes because attempts to access indexes directly are implemented as .get.unwrap()
staticassertion 4y ago
That's right, DoS in Rust is still a thing you can have. But it's no worse than in memory unsafe languages, since memory unsafety can also lead to DoS (and in a much worse way - there are methods for managing panics, managing segfaults is much harder).