PL Enthusiast

Currently security related things are implemented not only as libraries, but as libraries written in memory/type unsafe languages like C. A more principled approach to security might be to bake the relevant security features in to the semantics of our languages. There is work being done on languages with type systems that enforce security guarantees. http://www.pl-enthusiast.net/?p=11 and the pl-enthusiast blog in general covers this topic.

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'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…

It's a single course. I think no one, not even the author, expect a single course to cover enough ground to ensure that students can write secure applications moving forward. For instance, the author has a "formal verification" category on their blog: http://www.pl-enthusiast.net/category/formal-verification/ But they do think (like Daniel Bernstein and Edsger Dijkstra), that the usual "pentest & patch" does not work. http://www.pl-enthusiast.net/2015/09/30/penetrate-and-patch-to-buildin…

This article seems to confuse the concept of precision somewhat. Per Michael Hicks’ post on the same topic [1], precision is generally approaching soundness whereas recall or sensitivity is approaching completeness. Admittedly, I’ve also seen the term precision used far more loosely, including to describe approximate completeness (e.g. sound and precise). [1] (also cited in linked article) http://www.pl-enthusiast.net/2017/10/23/what-is-soundness-in-static-an…

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-evaluatio… 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-undi… 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".

Another link of interest: http://www.pl-enthusiast.net/2017/05/24/jean-sammet-a-remembrance/

>Rust and Go are both touted as memory safe. While this statement is absolutely true Duh? >So both languages are memory safe in that they are not memory unsafe This is more accurate statement imo. Saying Go is memory safe [1] is like saying a lamb is safe among a heard of hungry lions. [1] http://www.pl-enthusiast.net/2014/07/21/memory-safety/

The terms are evidently murky: http://www.pl-enthusiast.net/2014/08/05/type-safety/#comment-500

Someone recently did something like this for a programming language research conference. http://www.pl-enthusiast.net/2014/10/21/is-popl-one-community/

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.

"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-… https://blog.trailofbits.com/2019/01/23/fuzzing-an-api-with-deepstate-… - 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-resea… is also worth a read -- as well as the article it refers to, http://www.pl-enthusiast.net/2018/08/23/evaluating-empirical-evaluatio… For a…

This has a touching backstory on HN: https://news.ycombinator.com/item?id=8050106 https://news.ycombinator.com/item?id=4038113 I didn't realize that he had switched fields and moved. That info is here: https://www.uab.edu/medicine/news/latest/item/1411-white-house-strateg… and http://www.pl-enthusiast.net/2016/03/24/interview-matt-might/, via https://news.ycombinator.com/item?id=11366150