der Mouse is correct. I recall a product from the early 80s called "The Last One". There was an advertisement for the product on Prof Doug Comer's door when I was a grad student at Purdue... the claim was that this product made designing applications so simple that you'd never have to program again. I'm sure you're all familiar with this product, since it made your lives obsolete.
And it would have succeeded, if the Mafia hadn't hushed it up along with Jimmy Hoffa's death. One of the buzzwords du jour is "model driven architectures" (MDA); OMG has a working group on it (http://www.omg.org/mda/). It's just the latest iteration in what der Mouse called "very-high-level languages". It has the same promises as we've heard by countless iterations of abstractions.... faster development, fewer bugs, less need for programmers, etc. I'm skeptical. Getting back to the point at hand, though, I think this discussion is confusing two related topics: languages that help you build code that doesn't have security implementation bugs, and languages that help you build code that doesn't have security design flaws. [Gary McGraw pushes the difference between bugs & flaws, and I agree.] Example: Java helps you avoid a lot of the common *bugs* (by doing some things automatically like bounds checking, and providing libraries to do other things correctly like cryptography], but can't do much to help you avoid misdesigning the software. I think we're getting pretty good (relatively speaking) at building languages for bug-free code, but much less so for flaw-free code. To me, that's the *real* potential of the very-high-level languages... if things can be brought up to a point where the design becomes more obvious (since the implementation becomes somewhat automated), then there's a better chance of finding the security design problems. On the other hand, the problem with abstracting too much is that the security problems can get swept under the rug. To get REALLY back to the point, I'd like to comment on Fabien's comment that "In my opinion, it's the most important things for a languages, something to easily validate user input or to encrypt password are a must have." Fabien is right, but increasingly that's only half the problem. There also needs to be something in the libraries for the language to securely store data that can't be one-way hashed, as are (inbound) passwords. For example, if I need to store the password my application needs to authenticate to a database, or other critical data, it would be nice to have that built into the language libraries, instead of having to build it myself. It would certainly reduce the number of programmers who build such storage mechanisms themselves, and insecurely at that. My $0.02 or equivalent in local currency. --Jeremy > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of der Mouse > Sent: Friday, July 09, 2004 4:18 PM > To: [EMAIL PROTECTED] > Subject: Re: [SC-L] Programming languages used for security > > > > 2. Do we need programming languages at all? Why not write precise > > high-level specifications and have the system generate the program, > > thereby saving time and eliminating coding error? > > Then the "high-level specification" _is_ the programming language, > albeit a relatively unusual one, with the thing you call "the system" > being what is normally called the language's compiler. > > Such very-high-level languages are a perennial idea. As you > point out, > they aren't always appropriate, but when they are they can be helpful. > But they don't eliminate programming, any more than COBOL (which was > supposed to make it possible to write programs in plain English and > thereby eliminate programming as a skill) did. And they won't > eliminate coding error. They'll eliminate certain classes of coding > error, just as assembly does as compared to machine language, or as C > or Pascal does as compared to assembly language - but coding errors > will still occur, just as they do in assembly or C. They'll just be > errors at or above the level at which the code is written. > > Or, of course, they'll due to be bugs in the compiler. > > /~\ The ASCII der Mouse > \ / Ribbon Campaign > X Against HTML [EMAIL PROTECTED] > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > >
