WANTED: ISPs with DDoS defense solutions

Vadim Antonov avg at kotovnik.com
Thu Jul 31 22:44:19 UTC 2003


On Thu, 31 Jul 2003, Petri Helenius wrote:

> > What we need is a new programming paradigm, capable of actually producing
> > secure (and, yes, reliable) software.  C and its progeny (and "program
> > now, test never" lifestyle) must go.  I'm afraid it'll take laws which
> > would actually make software makers to pay for bugs and security
> > vulnerabilities in shipped code to make such paradigm shift a reality.
> >
> Blaming the tools for the mistakes programmers make is like saying "guns kill people"
> when the truth is that people kill people with guns.

Yep, it is people who choose tools and methods which produce code which is
guaranteed to be unreliable and insecure - simply because those tools
allow one to be lazy and cobble things together fast without much design
or planning.
 
> We╢ve code running, where the core parts are C and has a track record better
> than the "utopian" five nines so many people mistakenly look for.

A real programmer can write FORTRAN program in any language.  The problem
is that the even the best programmers make mistakes.  Many of those
mistakes (particularly, security-related - such as not checking for buffer
overflows) can be virtually eliminated by the right tools.

As for "code running" - in the course of my current project I had to write
code interacting with ciscos - and immediately found a handful of bugs
(some of them serious) in the supposedly stable and working code which has
hundreds of thousands of users. I'm afraid you're confusing code running
stably in a particular environment with good-quality code. (Excuse me for
being rude - but my notion of reliable code comes from my early
programming experience in an organization which produced systems
controlling high-energy industrial processes - where an average computer
crash causes immediate deaths of those unlucky to be around the controlled
object, and prison terms for the manufacturer's management).

> However, since improvements are always welcome, please recommend tools which
> would allow us to progress "above and beyond" C and it╢s deficencies.

May I suggest Algol-68, for example? Or any other language which actually
supports boundary checks in arrays and strings not added as an
afterthought?  Or using CPUs and OSes which won't let to execute code from
stack and data segments? Or doing event-driven programming instead of
practically undebuggable multithreading?

There's no market[*] for higher-quality software - therefore, there's no
pressure to improve tools and methods. If anything, the trend is to use
more and more languages lacking strong typing and lots of implicit
conversions, specifically designed for "rapid prototyping" aka quick and
dirty hackery - all of which was known to be dangerous for decades.

--vadim

[*] "No market" means that quality is not a differentiator because it is
impossible to evaluate quality prior to purchase, and after purchase
manufacturers are shielded from any responsibility for actually delivering
on promises by the license language.




More information about the NANOG mailing list