syscomet
syscomet on Hacker News
Defense in depth. First, the common RPC identity and authorization system provided RPC identity to the GFS API calls, and there was a common user/group system. GFS had ACLs and so despite what was said up-thread most people could _not_ access the data in the Gmail GFS cells. The team membership vs runtime user setup also ensured that Gmail SREs using their own credentials could not directly access the GFS cells (but once you have root on the storage boxes, that somewhat disappears). Second, on top of that you have encryption, using an encryption key service which would spot anomalies in things asking for the decryption keys to decode the stored data.
There are `-alpine` variants of the golang docker images, so if you're expecting to deploy to scratch or to alpine, the _builder_ step should be using `golang:1.17-alpine` instead.
[nb: I work for the main company behind NATS]
Jetstream is GA with the 2.2.0 release. Folks who believe in waiting for "not .0" won't have to wait too much longer.
Brad knows me slightly better than that and there was a bit more factoring into his decision. As I'm one of the maintainers and security/release people for Exim, a major MTA, I'd hope that the SMTP server on my personal domain is not too badly configured. :-D
Those figures are both good and depressing to know, thanks.
I figured the PGP usability problems were severe enough that I did not call you out by name in the post. This aspect was merely a darkly amusing aside leading into the main point of how the Golang devs handled this so well.
You didn't know the content of the report, so the irony is only clear in retrospect: the whole point of the report was about vulnerability to MitM attack and email MX->MX delivery is highly susceptible to that without some kind of trust anchoring in place, whether DANE or MTA-STS, neither or which is in place for the golang.org domain.
So the fact that TLS is _advertised_ by the gmail servers, which handle golang.org mail, doesn't mean that the advertisement reaches the sending mail-server.
I've since configured my mail-servers to always require verified TLS for outbound mail to the golang.org domain, as a manual override.
It's a special case though. The golang.org/x/ packages are experimental but also candidates for promotion to the standard library. Eg, "context".
But this sort of issue is exactly the sort of real-world review and hardening which justifies having a namespace for stuff to go _before_ it becomes stdlib.
blog-post author here, others are addressing the other points, but I wanted to answer Q1:
CVEs are for tracking response to issues, so that people can clearly communicate about what they are reacting to. Everyone using the library needs to update their code (unless they were already setting the callback) and so having a CVE lets them describe exactly what they're reacting to.
blog-post author here: all of them written in Golang which use SSH.
Packer, Terraform, Vault, all of them.
Using a bastion host in your configurations doesn't help if you invoke the tooling on your laptop, since the connection to the bastion host is done with the SSH package, again with no host-key verification.
In the linked consul documentation, we see a `LockIndex` field in the lock state;
https://www.consul.io/docs/agent/http/kv.html confirms that "LockIndex is the number of times this key has successfully been acquired in a lock. If the lock is held, the Session key provides the session that owns the lock."
So you can do fencing with consul.