Fwd: Your blog post "Getting past C"

[Mark Atwood]

Interesting. He makes good points, and I have earned a living coding in
Ada, myself. But all that said, there are sufficient good reasons not to
port to Ada. Well, unless and until the DOD, the ARPA, or the
Physikalisch-Technische Bundesanstalt want to pay us enough to do it, at
which point it can be revisited.


---------- Forwarded message ---------
From: <Thomas.Scheller at ptb.de>
Date: Thu, Jan 5, 2017 at 1:05 AM
Subject: Your blog post "Getting past C"

Dear Mr. Raymond,

a German IT news website recently had a news item about your blog post
"Getting past C". I would like to comment on that. But before doind that I
would like to provide some background of my interest in NTP.

I am working at Physikalisch-Technische Bundesanstalt which is the national
metrology institute of Germany, much like the NIST for the USA. One of our
legal tasks is to provide the official time for the country, which of
course involves NTP. Recently the requirements for reliable time signal got
even tighter due to the increasing use of smart electricity meters. I am
tasked with working on the institute's information security management
system which involves the integrity and availability of our time service.

But I am not writing on behalf of my employer, I merely want to express my
personal opinion. My programming experience is rather limited, I only did a
few rather small projects for measurement systems, mostly using graphical
programming. My first language was Pascal, later I acquired minor C and
Perl experience.
I totally understand your motivation for writing that blog post. Most of
the CVEs result from absolutely unnecessary mistakes during programming. On
the other hand: Why should the programmer have to care about checking every
data that should be written into a variable? Why aren't these check
implemented automatically? Humans tend to forget things and to make
mistakes, and obviously the are not well-suited to take care of every
detail. The motivation is clear: Use a language that does not allow such
mistakes. In doing so, you can be the one who started it, and in ten years
we might have much safer and more reliable core services for the internet.

All is wel up to the point where you present your options: Go and Rust.
What, that it? Two very young languages that -for the outsider- seem to be
under heavy development? You forgot the most natural choice of all: Ada.
This language is well-established for high safety and high reliability
applications like the aerospace industry. It is standardised (last revision
was in 2012), the reference manual is available online and there are free
software tools and compilers. Ada even features concurrency, object
orientation, exception handling and an interface to C. Furthermore several
studdies suggest that the total lifetime cost is lower and projects are
finished fasterand with less bugs when using Ada .

Although I would like to see Ada being used for internet core services, I
am well aware that it might not be the best choice. But it would be a grave
mistake to not consider it when thinking about programming languages with
built-in safety. That is my request to you: Consider more languages than
just Go and Rust, and try to choose wisely, even when that means to rewrite
the whole NTP code. You can set an example for future choices. We urgently
need a much higher level of integrity, security and safety in the software
that drives our lives.

With best regards,
Thomas Scheller


procedure Signatur is
begin
-- Themenbeauftragter Informationssicherheit
-- Präsidialer Stab
-- Physikalisch-Technische Bundesanstalt
-- Bundesallee 100
-- 38116 Braunschweig
-- Telefon: +49 531 592 2007 <+49%20531%205922007>
-- Telefax: +49 531 592 69 2007 <+49%20531%20592692007>
-- E-Mail: thomas.scheller at ptb.de
-- Website: https://www.ptb.de/
null;
end Signatur;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170105/c2c2c89e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 10571 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170105/c2c2c89e/attachment.obj>