[langsec-discuss] LangSec Workshop at IEEE SPW 2014, Sun May 18, 2014
Meredith L. Patterson
clonearmy at gmail.com
Tue Nov 26 00:35:23 UTC 2013
On Mon, Nov 25, 2013 at 7:20 PM, <travis+ml-langsec at subspacefield.org>wrote:
> On Fri, Nov 22, 2013 at 09:21:20PM +0100, Peter Bex wrote:
> > These are useful rules, and provide a simple answer to the complex
> > problem for programmers who are swamped in work and don't have time
> > to think about this stuff. I think that's something the langsec
> > project should strive for as useful output.
> To the point, if you want traction, you have to get it baked into the
> languages/frameworks they use. You can write haskell all you want,
> but until you get it (at least) ESAPI, or (better) into java, C# and
> ruby, in frameworks that developers are using, it's not going to
> affect the commercial world, and thus consumers at large.
I know Hammer is practically the only thing I talk about these days, but
that's precisely why I'm so keen on making sure that the language bindings
we're providing are suitably idiomatic. I don't just want tools for the
techniques Peter describes in every language, I want them written in ways
that users of those languages find comfortable and easy to remember.
Python, Go, Ruby, and PHP will all be landing soon, with Perl and C#
shortly thereafter. Java was done quite some time ago, though it needs to
be updated to reflect an internal API change. I'd also like to have Lua,
and weirdly enough a few people have asked about Haskell.
If there are any other languages that people would like to see Hammer
bindings for, please file a feature request at
https://github.com/UpstandingHackers/hammer/issues. Similarly, as bindings
land, if you can think of nicer APIs than the ones we've come up with,
please file a bug request!
The hard part is going to be spending the time and effort to integrate
> with those framework/library/language teams and get your stuff in
> there and up-to-date.
This is also what I'm finding. For instance, at some point I want to have a
talk with one of the core PHP developers with whom I'm acquainted about
what we could do within Zend to harden boundaries of competence between the
core Zend Engine and the rest of the language. Ditto with Django and the
boundaries of competence it has (though that should be an easy conversation
to start, since I think Paul McMillan's on this list). That's a lot of
networking, but it will have even larger network effects as devs who work
with these frameworks/library/languages roll out versions with more
hardened input handling.
This is a marathon, not a sprint.
> Not saying it's right, just that that's how it is. For the best
> security, we need to minimize the cost of using the systems.
Yup. Incentivise adoption by making systems easy or even invisible to adopt.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the langsec-discuss