[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 11 Oct 2014 16:21:33 +0800
From: Pavel Labushev <pavel.labushev@...box.no>
To: oss-security@...ts.openwall.com
Subject: Re: Thoughts on Shellshock and beyond
On Fri, 10 Oct 2014 10:39:54 +0200
Florian Weimer <fweimer@...hat.com> wrote:
> > Just as easily? Might be, but that's a totally unjustified conclusion.
>
> You need to put labels on shell variables. The SELinux folks did not do
No, I don't.
> it, but maybe they considered it. It seems unlikely that a shell
> rewrite came up with this concept on its own. None of the Bourne-like
> shells we have implement anything like that, after all.
We ain't living in a parallel universe where "Haskell" is a mainstream
technology. So we don't have e.g. an "army" of people unconstrained
enough intellectually and practically so they could start thinking
about the useful complex properties they actually can prove, what
formal models are more suitable for building the software in that
context, etc. Instead of trying to "write it in C in Haskell", which
looks like what you have in mind.
> Not using a parser generator, but a manually written recursive descent
> parser might have helped because you could have called the function
> corresponding to the function definition production directly. (However,
> there would still have been parser exposure to the network.)
What's the conclusion?
> The Haskell standard library does not even distinguish between a read
> error and an end-of-stream condition. You can't build reliable software
> on top of that.
Sounds like a weak excuse for not using it. Like it's impossible to
write a decent library or fix the existing one. Besides, the absence
of a decent standard library doesn't prevent anyone from using "Haskell"
as a meta-language right now, and that's how most people use it for
systems programming and similar stuff.
> Some of the incomplete state reset issues might have been more obvious
> with Haskell (but you can easily thread a state variable incorrectly, in
> effect discarding intended updates). But in any language, not using
> global variables for parser state (and building the state from scratch
> each time before calling the parser) would avoid those in a fairly
> reliable way.
More obvious as in manual labour style reasoning? Again, what's the
conclusion?
Content of type "application/pgp-signature" skipped
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.
