Getting Past C
blog.ntpsec.org
Getting Past C
1–10 of 504 posts
Re: Getting Past C
#2How much concern would non-standard architecture support matter for ntp? Given how many architectures Linux supports, I would think that C would still be the best choice, until these other languages gain support for those missing architectures.
Or perhaps it's a good opportunity for a language which offers transpilation with ANSI C as the target?
Re: Getting Past C
#3How much concern would non-standard architecture support matter for ntp? Given how many architectures Linux supports, I would think that C would still be the best choice, until these other languages gain support for those missing architectures. Or perhaps it's a good opportunity for a language which offers transpilation with ANSI C as the target?
Rust has impressive support for different architectures. I ran `rustc --print target-list` and it returned 63.
Re: Getting Past C
#4Outside of the language war bubble it's really great to see a post like this. Practical concerns, reasonable advantages/disadvantages of each language, a real project dealing with real timelines. Thanks!
Re: Getting Past C
#5How much concern would non-standard architecture support matter for ntp? Given how many architectures Linux supports, I would think that C would still be the best choice, until these other languages gain support for those missing architectures. Or perhaps it's a good opportunity for a language which offers transpilation with ANSI C as the target?
Rust has impressive support for different architectures. I ran `rustc --print target-list` and it returned 63.
That includes one line per architecture / platform (i.e. OS) combination. I only count about 14 architectures, though my rustc is old (GCC has 23 major, 24 minor, and 30 legacy as a point of comparison).
Last I checked, some of the popular IOT architectures (atmega, etc) were not included without some 3rd party plugins.
Re: Getting Past C
#6How much concern would non-standard architecture support matter for ntp? Given how many architectures Linux supports, I would think that C would still be the best choice, until these other languages gain support for those missing architectures. Or perhaps it's a good opportunity for a language which offers transpilation with ANSI C as the target?
In addition to squiguy7's point, I'd add that A: it may not be clear if this is your only contact with ntpsec.org [1], but this is actually a fork of the classic ntp, so they may be more willing to abandon some older architectures to produce a more secure product going forward than the core NTP project would and B: the older versions will still be around even so.
Also, it has been suggested by some experiences that older architectures often end up getting supported past when they really should be stopped out of sheer inertia, though I'm not having luck digging up the articles that prompt me to say this. Are there that many systems out there running ntp that can't run Go and/or Rust, and if there are, are there enough to be worth bending the project around? If the people running those things care, perhaps they should fork the project and maintain it themselves. Which is less harsh than it may sound, because they can still pull from upstream, and they probably just need to tread water rather than stay up with the latest & greatest.
(I should emphasize that the operative question is are there enough to be worth bending the project around, rather than whether there are any. Because there certainly are non-zero numbers of systems running ntpd that can't run Rust or Go. But who's going to pay to maintain them? Especially if classic ntp is still available?)
Re: Getting Past C
#7> One of the medium-term possibilities we’re seriously considering for NTPsec is moving the entire codebase out of C into a language with no buffer overruns
For a small one time fee of 1000 USD I can copy paste you 50-100 lines of C that provides an implementation of an array without buffer oveflows. Cheaper than switching to rust or you know, learning C properly.
Re: Getting Past C
#8> One of the medium-term possibilities we’re seriously considering for NTPsec is moving the entire codebase out of C into a language with no buffer overruns For a small one time fee of 1000 USD I can copy paste you 50-100 lines of C that provides an implementation of an array without buffer oveflows. Cheaper than switching to rust or you know, learning C properly.
Can you pass this buffer to e.g. read() and it will still guarantee no buffer overflow even if the programmer mis-calculate the size argument to read() ?
Re: Getting Past C
#9How much concern would non-standard architecture support matter for ntp? Given how many architectures Linux supports, I would think that C would still be the best choice, until these other languages gain support for those missing architectures. Or perhaps it's a good opportunity for a language which offers transpilation with ANSI C as the target?
In addition to squiguy7's point, I'd add that A: it may not be clear if this is your only contact with ntpsec.org [1], but this is actually a fork of the classic ntp, so they may be more willing to abandon some older architectures to produce a more secure product going forward than the core NTP project would and B: the older versions will still be around even so. Also, it has been suggested by some experiences that o…
Well, it's not just older architectures which are not currently supported, it's architectures used in IOT devices, mainframes, and other non-commodity hardware. Specific to LLVM based languages, if it's not a priority to Apple (or the other big LLVM players), it infrequently gets done.
Specific to IOT devices, I would personally love to see secure everyting. NTP, TLS, SSH, etc.
Re: Getting Past C
#10Earlier quoted context omitted.
Rust has impressive support for different architectures. I ran `rustc --print target-list` and it returned 63.
That includes one line per architecture / platform (i.e. OS) combination. I only count about 14 architectures, though my rustc is old (GCC has 23 major, 24 minor, and 30 legacy as a point of comparison). Last I checked, some of the popular IOT architectures (atmega, etc) were not included without some 3rd party plugins.
ATmega is not really a popular architecture any more. It only stuck around because of Arduino, and even that is moving towards ARM.
Nobody is going to be running NTPsec on it in any case!