I used to use `go get` for grabbing even non-Go repos but had to stop because of similar problems. I finally wrote a small tool to replace it I call `grab` https://github.com/jmhodges/grab to take over my "fetch the code and organize it into a tidy directory system" need
It actually uses the nice VCS library guts that `go get` does!
Well, no, the DNS resolved to these endpoints, just like in an HTTP attack, and then this is as if the Host header wasn't checked by the HTTP provider. You and these few specific hosting providers didn't think they had to look at the SANs, but, in fact, the Baseline Requirements expected them to verify that the SANs in the certs are controlled by the same user.
There's a reasonable disagreement but I (and others[1]) liken this the "postmaster@" attacks. At some point, for every protocol the hosting provider handles, we always end up having them do a bit more work then they thought they had to do but them's the breaks when dealing with the modern internet.
My "Hosting providers haven't, previously, thought of TLS serving as an individual user service before (though the Baseline Requirements do) and are having to work out the kinks of that." covers what you're trying to get at here.
There are equivalent attacks on both the DNS and HTTP challenges as described in the Baseline Requirements and ACME, and those are expected to be mitigated (and are) by hosting providers. Let's Encrypt isn't bound by the Baseline Requirements to mitigate this for these hosting providers, but is doing so out of a esprit-de-corps while the web figures out how it wants to handle this.
Hosting providers haven't, previously, thought of TLS serving as an individual user service before (though the Baseline Requirements do) and are having to work out the kinks of that.
To be clear, the challenge types in question where removed from Let's Encrypt production config during the private beta period (when we had a strict whitelist of domains allowed to be issued for), had mitigations for them in while they were out, and we deleted the code for them entirely the other day (in
https://github.com/letsencrypt/boulder/pull/1247 )
FYI, using TLS compression makes you susceptible to the CRIME attack. I think I have a ticket with OpenSSL for them to turn that off by default, but I don't think they've done it, yet. Glad you got there accidentally!
Okay, really, I want you to apply for Systems. We're building horizontally scalable, distributed, big data systems that can take unprecedented growth. The company is only a 134 people right now, and your impact as a developer would be huge.
Twitter is hiring for systems, frontend, etc. We're pretty polyglot but the majority of integration with the web app is ruby, a good deal of the backend is Scala and the rest is whatever works best.
For those who were confused by the contradiction of this comment and the actual post, it looks like "less attention from men" was probably supposed to be "more attention from men".
For instance:
"So basically, guys are fighting each other 2-for-1 for the absolute best-rated females, while plenty of potentially charming, even cute, girls go unwritten."
(And it's doubly confusing because patio11 refers to it as an "old wive's tale".)
Clone that as your emacs.d, add a .el file named the same as your logged in user, and add your specific preferences there. (I like to have it include stuff in a jmhodges directory in emacs.d, of course.)
Yes, and those "k = m" lines are the problem! Those assume unsigned* types! And 64-bit integers! Those multiplications and other operations are all wrong!
You didn't port this to Java, you ported a broken algorithm to Java. Way to go, though.
It actually uses the nice VCS library guts that `go get` does!