[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Oct 2014 17:45:26 -0400 (EDT)
From: "David A. Wheeler" <dwheeler@...eeler.com>
To: "oss-security" <oss-security@...ts.openwall.com>
Subject: Re: Thoughts on Shellshock and beyond
On Wed, 15 Oct 2014 02:10:41 +0800, Pavel Labushev <pavel.labushev@...box.no> wrote:
> By "Haskell" I mean any technology, its scientific basis and the
> other aspects altogether, that I think have the potential of
> significantly shifting the paradigm.
A rose by any other name will smell as sweet, but calling it a
"pig" inhibits communication. If you mean
"significantly better tools", just say that. Or create a new name and define it.
> I know that many would disagree and say that the devil is in the details.
I'm one of those who disagrees. The devil, as well as the rest of the universe,
*is* in the details. In particular, I think a lot of tools are hideously oversold,
leading to serious problems. All tools have limitations; knowing those limitations
is key to developing (more) secure software.
That said, tools that make it *easy* to write secure code (or at least
eliminate certain mistakes) often produce more secure code, simply because
developers are people who make mistakes.
> Imagine you're writing a shell and decide to introduce the high level
> distinguished concepts of code, data, data source, and derive the
> concepts of trusted|untrusted data|code [source].
That might help, though that's simply *one* approach
(among many) for stronger separation of code and data.
What we need are examples of such approaches, and experimental data
to show that they're really better.
> > I don't think Haskell is a magic bullet. I do think type-rich
> > languages (and languages with memory safety) have a lot to offer, but
> > writing secure software in them is still hard.
>
> And I'm convinced that "Haskell", in a broader sense and together with
> the other factors, is a part of a solution, capable of making a
> qualitative change.
I agree that better tools can be part of a solution, and in some cases
(especially together) could produce a qualitative change.
The most obvious example of an underused tool is memory-safe languages.
Shellshock would not have been countered by them,
but Heartbleed (and many others) *would* have been countered.
But many people are not willing to pay the runtime costs, and the
developer-retooling effort, to switch to a memory-safe language for
low-level components like operating systems, runtimes, crypto libraries,
image processing libraries, and the like. We *have* languages like Ada
which run at the same speed as C, and other languages are relatively close
(e.g., D, Go, Rust, Nimrod), but as yet there has
been no big switch. For a variety of reasons, it's hard to change.
--- David A. Wheeler
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
