Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 08 Oct 2014 20:20:04 -0400 (EDT)
From: "David A. Wheeler" <>
To: "oss-security" <>
Subject: Re: Thoughts on Shellshock and beyond

On Wed, 8 Oct 2014 15:48:10 -0700, Tim <> wrote:
> To me, it's not about anticipating the next bug, it is about providing
> guidance to developers who care only so much about security so that we
> can avoid some bugs that we didn't anticipate.


> PS- I'm of two minds on this.  More recently I've decided that educating
>     developers isn't nearly as effective as providing developers APIs and
>     development environments that make it unlikely they will shoot
>     themselves in the foot.  It's not that developers can't be trained,
>     it is that they will probably only be developers for a handful of 
>     years and move on to other roles later, with a whole new batch of
>     green coders coming in to fill their positions.  Anyway...

I don't think there's an either/or here.  Yes, if you *can* change the
tools/libraries/development environments to prevent attacks, or reduce
their effectiveness, you *should*.

That said, a fool with a tool is still a fool.  There's no way to create
a development environment that can't be misused.  Thus, you'll always need
to educate and train developers for situations the system cannot prevent.
In the long term I think this will be easier, because novice developers will be able
to learn from the many experts around them.  Today, the number of
developers who understand security issues is a vanishingly small percentage
of the total, so the novice has no one to learn from.

--- 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.