PL Enthusiast

"Generating Software Tests" (https://www.fuzzingbook.org/) is pretty great (independent of your programming language) - arguably a must read for anyone interested in software testing.

John Regehr (the author of the blog post) has written more great posts:

- How to Fuzz an ADT Implementation - https://blog.regehr.org/archives/896

- Better Random Testing by Leaving Features Out - https://blog.regehr.org/archives/591

- Tricking a Whitebox Testcase Generator - https://blog.regehr.org/archives/672

- Fuzzers Need Taming - https://blog.regehr.org/archives/925

- Levels of Fuzzing - https://blog.regehr.org/archives/1039

- API Fuzzing vs. File Fuzzing: A Cautionary Tale - https://blog.regehr.org/archives/1269

- Reducers are Fuzzers - https://blog.regehr.org/archives/1284

In terms of software, DeepState (https://github.com/trailofbits/deepstate) may be a good place to start for C and C++. Relevant links:

- Fuzzing an API with DeepState: https://blog.trailofbits.com/2019/01/22/fuzzing-an-api-with-deepstate-part-1/, https://blog.trailofbits.com/2019/01/23/fuzzing-an-api-with-deepstate-part-2/

- NDSS 18 paper, "DeepState: Symbolic Unit Testing for C and C++": https://www.cefns.nau.edu/~adg326/bar18.pdf

In terms of choosing among fuzzing solutions,
https://blog.trailofbits.com/2018/10/05/how-to-spot-good-fuzzing-research/ is also worth a read -- as well as the article it refers to, http://www.pl-enthusiast.net/2018/08/23/evaluating-empirical-evaluations-for-fuzz-testing/. For a…

I'll leave other commenters with more parser-writing experience to critique this... but the general concept of "Write code in the simplest-to-reason-about direction, and the system magically inverts it into a much-harder-to-reason-about algorithm" is one of my favorite patterns in computer science.

For instance, there's probabilistic programming [1], where you write a procedural program that says "if we were to fix a bunch of properties/states of the natural world and provide them as input, here's the output/reading you'd hypothetically get," and then from that, a system creates a function that, given a large number of outputs/readings, provides a posterior probability distribution over those hidden properties/states of the world. It's still far from the level of performance you'd get from hand-rolled machine learning algorithms that take advantage of all sorts of insights you have into your data... but then again, in general programming, there was a time when compiler optimizations were so naive that you had to hand-roll assembly code for almost anything. I see probabilistic programming in a similar level of infancy, and I'm excited to see where it goes, especially with the backing of a large DARPA initiative [2] to do some really exciting fundamental research.

But there's so much more to the "invertible" paradigm. SQL itself is exactly along these lines - your WHERE clause is just a filter function that works on a single-record level, but it's interpreted as highly…

I'm sorry, but no: Generics are a technical issue and are not a political one. The Go team is not against generics per se, only against doing things that are not well understood and/or don't work well with Go.

There are deep technical issues that must be solved to fit the idea of generics into Go in a way that works well with the rest of the system, and we don't have solutions to those. I wrote on my blog about one issue years ago (http://research.swtch.com/generic), but there are others too. Even supposing you get past the problem on that page, the next thing you would run into is how to allow programmers to omit type annotations in a useful, easy-to-explain way. As an example, C++ lets you write make_pair(1, "foo") instead of make_pair<int, string>(1, "foo"), but the logic behind inferring the annotations takes pages and pages of specification, which doesn't make for a particularly understandable programming model, nor something the compiler can easily explain when things go wrong. And then there's a princess in another castle after that one I am sure.

We have spoken to a few true experts in Java generics and each of them has said roughly the same thing: be very careful, it's not as easy as it looks, and you're stuck with all the mistakes you make. As a demonstration, skim through most of http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html and see how long before you start to think "was this really the best way to do this?" (For example,…

I'm one of the authors of the paper. Two quick things I want to say:

I've written a blog post that is a short but rigorous description of the paper's results: http://www.pl-enthusiast.net/2018/08/23/evaluating-empirical-evaluations-for-fuzz-testing/

The paper does not make strong statements of the form, "fuzzers are/do X" or "all prior papers' claims are bogus." Rather, we say that the standard of evidence should be higher, and we demonstrate why failing to reach that standard could result in bogus claims. It's quite possible that a paper's idea really is an improvement. But it's also possible that additional evidence would cast doubt on that, or nuance it. For example, our experiments show that AFLFast probably does improve on AFL, though perhaps not as much as that paper made out (note we didn't do enough experiments ourselves to make that definitive statement).

Social engineering is responsible for in part or entirety many hacks. I'm not arguing that technical solutions will "fix everything". Technical stability is on aspect of secure systems.

The video is arguing: why should a doorbell have the ability to set your house on fire? (Metaphorically).

Heartbleed was an issue of exactly this

"The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software"

Architecturally, this should never have been possible.

http://www.pl-enthusiast.net/2014/07/01/how-did-heartbleed-remain-undiscovered-and-what-should-we-do-about-it/

http://heartbleed.com/

Obviously attackers are going to look for the weakest point, but your agument sounds like "social engineering should happen, so don't bother locking your doors at all".

I had the same thought. Harper has lots of interesting posts on his blog: http://existentialtype.wordpress.com/ (not to mention his research).

I was delightfully surprised running into this comment in a footnote :)

Here's the direct link to Harper's comment: http://www.pl-enthusiast.net/2014/08/05/type-safety/#comment-500

The way that Harper talks about types, such as, "It is not a matter of opinion whether an untyped language is unityped, it is a matter of fact." gives me a different perspective when I program in a language that is effectively unityped.