Re: Are bad developer libraries the problem with M$ software?

On Sat, Nov 16, 2002 at 03:47:44PM -0500, Steven M. Christey wrote:

>

Sure. There've even been efforts to harden C such as Cyclone, and some aspect-oriented work that could even harden legacy apps with a default security specification. There are three issues:

1. Lots of stuff that commonly goes wrong isn't appropriate to address at the language level. For example, misuse of crypography is more something that should be addressed at the API level, but there will always be people who go straight for the more powerful yet more error-prone APIs.
2. While it's certainly always been the researcher's solution to the problem, building a new language isn't the realistic way to solve this problem. Developers are rightly skeptical of yet another language, especially one where security is the only benefit for using it. There are lots of costs usually associated with using a new language including training, loss of productivity, interoperability with legacy code, ... And after switching to a new language, you might have protection against particular classes of things, but there will still be plenty of things that can go wrong... but you might then have a false sense of security, due to your programming language (a lot of Java developers are that way).
3. Sometimes there's a huge gap between academic research and practical development. Look at static data flow for security. It's an OLD notion, but the first practical system was Andy Myers' Jif (used to be called JFlow). I think there was a 25 year gap between the first research papers and the first practical implementation. And, I don't know anyone using the implementation (it does require a bit more work that most developers are willing to exert).

John Received on Mon Nov 18 21:55:17 2002