Automatic bug-repair system fixes 10 times as many errors as its predecessors

Those moments of updating the files: That little euphoria of finding the fix but needing to focus to get it done correctly and finally hitting enter for the last time...ahhh.

I'l take that instead.

They're not obsolete at all, they're just doing better things with their time.

http://security.ece.cmu.edu/aeg/

"Automatic Exploit Generation" which does basically this. (I haven't read enough of either paper to understand how similar the analyses are, but both seem to be based on symbolic execution.)

If you have a tool that can automatically find 0 day exploits, then you could try couple the 2 and have a piece of software telling you: "Tool 1: I think I found this 0 day exploit;Tool 2(the one in this paper): here is how I think you could fix it: ..."

* static (not necessarily explicit) typing

* no dynamic metaprogramming (static OK)

* no "eval"

* no first-class functions (second-class OK)

* no prototype-based OOP (class-based OK)

* no mutable variables (lexical shadowing OK)

* no mutable values, or very strict aliasing rules

* no unbounded recursion

* no dynamically defined structures

Of course you can perform useful static analysis with only some of these guidelines met. e.g. Erlang's Dialyzer does pretty well with dynamic typing, first-class functions, and unbounded recursion, because these features generally aren't abused in Erlang. (Though this took a hit recently due to the recent introduction of the `maps` feature, which was designed in such a way as to encourage violating that last guideline, despite proposals for a similar feature which would not have violated it.)

Surprisingly, C also meets all but two of these guidelines, and, although it is an egregious violator of those both, it is somewhat amenable to static analysis (see Coverity).

JavaScript, on the other hand, is notoriously difficult to statically analyze, since it not only permits code to violate all the above guidelines, but it's common for code to violate all of them.

As a person who works at a large organisation focused on correctness, there are some crazy intersections between what "error" means, what programs do, and how humans work. In general, if you can clearly define what "error" means, you can mostly solve it with a sufficiently good language. That is not so easy.

The "automatic"[1] hammers we seem to have are good type systems and "Design By Contract" (think Eiffel, but having a strong proof assistant is a much more powerful case). In this case, I'm discussing the problem from a security point of view:

Some examples in order of difficulty:

* Process errors outside software; OK, these are usually not the programmer's fault. For example, Amazon account hijacking via customer service. No way to point-fix; DBC or typing won't help you.

* Software interaction with humans; I've seen regexes to disallow shipping (e.g. for identity documents) to P.O boxes, which allow the input "POSTAL BOX" rather than a variant of "PO BOX", "P.O BOX", "POSTAL BOX", "LOCKED BAG" or so on. The problem is that the data will be eventually interpreted by a human, who will correct the error and ensure delivery. AFAICT not fixable with DBC or typing - you need a business process improvement here.

* Ambient or environmental changes. The call you used to make to a third-party library or binary was secure, but now it isn't. For example, your app used RC4 or $RANDOM_BINARY, and it used to be secure, but now it isn't because your environment changed out from under you. Now your code needs a countermeasure or a fix.

* Subtle business logic errors such as missing a permissions check on private profile or data views - probably only fixable with proof or DBC, type system is not the right hammer here although maybe with effort you can sort of do it. Probably encoding rapidly changing business rules into your types is not a good idea though.

* Obvious business logic errors, e.g. allowing -1 books to be ordered in an online store; fixable with a good type system or DBC. (e.g. type "Quantity" is a natural number rather than a machine type).

* XSS or SQLI - should be fixed by type system alone in a sufficiently advanced language.

It's mostly the relatively trivial stuff at the bottom of this stack of possible errors which is fixable by good programming languages, assuming of course that your DBC logic or way you structure your typing is correct.

As a total aside, what would be really interesting to me would be a powerful "business process definition language", which could map data flow between systems and humans - and actually describe the real-world information flows when a user contacts customer support to reset their password. If that could interact with contracts or proofs in individual applications, my world would be rocked.

[1] Not requiring humans to check when changes happen, although obviously human effort is required during system definition.

   While(1):
       Pass

running programs have state, that's the issue with the halting problem.

The main issues in many interesting ML projects are 'how do you feed the data to the model' and 'how do you determine its success/failure'.

For instance: you could try to train a Pacman AI by feeding the game state into some model and asking for an up/down left/right output. But a lower bound for all the game states would be 2^(number of dots possible on level), making it impractical/impossible to store such a model in memory much less train it.

The strategy would be to encode the game state into a manageable number of features. This is a lossy process and the hope is that your set of features is small enough to be trained on, yet meaningful enough that the model can learn from them.

In the paper, they parse the data (code) into a syntax tree, compares it with the patched version. This identifies the 'point' in the tree where the patch modification takes place. The 'point' the 'type of modification' and a 'collection of neighboring points' are the features that are fed into the model.

tl;dr, yep, probably linear svm or multinomial logistic