Author of the linked CL here: we added this mostly so that we could abuse the memory initialization tracking to test the constant-time-ness of crypto code (similar to what BoringSSL does, proposed by agl around fifteen years ago: https://www.imperialviolet.org/2010/04/01/ctgrind.html), which is an annoyingly hard property to test.
We're hoping that there are also a bunch of other interesting side-effects of enabling the usage of Valgrind for Go, in particular seeing how we can use it to track how the runtime handles memory (hopefully correctly!)
edit: also strong disclaimer that this support is still somewhat experimental. I am not 100% confident we are properly instrumenting everything, and it's likely there are still some errant warnings that don't fully make sense.
There is a fifth, incredibly common, (arguably) non-malicious possibility.
You don't control the entirety of your web stack, and your hosting provider, or DNS provider, or someone else, has decided to be 'helpful' (either blindly, or due to some misconfiguration somewhere along the line) and issue a certificate on your behalf, as they are able to intercept CA validation traffic at the DNS, TLS, or HTTP layer.
While Roberto Peon is one of the authors (and a core developer of the preceding SPDY protocol) saying that HTTP/2 is some Google invention is a bit of a punch in the face to the IETF and the two other authors who do not work at Google.
It allowed users to bypass Twitter blocks by tweeting at the bot while tagging users that block them, which seems pretty bad and was abused very quickly. Also it's a violation of the Twitter TOS.
> The two CVEs against Varnish were both utterly bogus "trophy-hunter" CVEs in my opinion. (But don't take my word for it, judge for yourself.)
ok
> CVE-2013-4484: Varnish before 3.0.5 allows remote attackers to cause a denial of service (child-process crash and temporary caching outage) via a GET request with trailing whitespace characters and no URI.
Guh, until CF/FB can provide some data that shows users with no upgrade path are genuinely going to be effected by this, and not connections MITM'd by some crappy AV or other random middlebox the LV proposal seems like a pretty silly idea...
Many hosting providers are choosing to integrate LE into their products directly so even if you don't get shell access you will still be able to get a cert. As far as I know both Plesk and cPanel are also working on official plugins for their software.
The backend and client are both very large, very different projects that share a small crossover (the ACME protocol) and were written by two different teams.
I can't speak exactly to why Python was chosen, but it should be noted this isn't intended to be the be-all-end-all in terms of clients. There are already a number of other independent clients that have been developed for various different purposes.