An update on gomote

[Carlos Amedee]

TLDR; Efforts to increase the security of the build environment lead to a redesign of the gomote service. Gomote access requests are no longer frozen. All existing gomote users must re-request access if they still require it. The gomote client must be updated to the latest version after the new access is granted,.

Gomote is a service used by Go contributors to gain access to architectures and operating systems that are supported by Go. A small trusted set of contributors have traditionally had access to the gomote service. We've changed how portions of the gomote service infrastructure is implemented to increase the security of the build environment. Users will be impacted in the following ways:

• The gomote client will no longer use a Go team issued token for authentication. Instead, a Google account will now be used to authenticate to the service.

• GitHub will no longer be used to store public keys for SSH access.

• Users can start requesting access if it is essential to their contributor work.

• All existing gomote users must re-request access in order to continue having access.

• The updated version of the gomote client is required for gomote use.

• A small set of builders will be restricted from gomote access.

Instructions on how to request access can be found at https://go.dev/wiki/Gomote#access

Please be on the lookout for any bugs and feel free to file an issue (or fix an issue) if you discover any issues.

You can download the new client by running:

go install golang.org/x/build/cmd/gomote@latest

This work is leading to a more secure infrastructure for all Gophers!

[Filippo Valsorda]

Thank you Carlos and the whole team!

This is an important and complicated behind-the-scenes security and contributor experience improvement.

The device linking and SSH certificates architecture look like excellent UX and security choices.

[gro...@gmail.com]

A passphrase-optional ed25519 ssh key stored locally on developer workstations is good for interoperability, but I would prefer to require the "-sk" variant for an openbsd-ppc64 builder I'm planning to contribute. (The -sk variant protects the ssh private key using FIDO.)

My rationale is that I'm willing to accept the risk of my builder being used harmfully if we have good assurance of accountability to an individual. It is not reasonable to expect all developers to run extremely well locked down workstations, but they have to go out of their way to screw up FIDO and lose a long-term credential. Admittedly, a very skilled attacker might piggyback on an existing developer ssh connection, but that at least provides more potential for attribution of the bad actor.

The openbsd-ppc64 Go port is sufficiently exotic that I'm confident any Go contributor is quite capable of forking gomote and changing the hardwired ed25519 string as needed. Obviously the builder itself can enforce the ssh key type it accepts. I raise the point here just to ask if anyone sees a flaw in my rationale.

[Heschi Kreinick]

The primary goal of this project was to get a handle on who has access to the builders, and get us out of the business of identity management by using Google accounts. Preventing builders from being abused is a good goal, but their job by nature is to run arbitrary code, including code that hasn't been fully reviewed yet. As such, getting gomote access is not the only way to attack a builder, and probably not the easiest way. If that makes you uncomfortable, that's totally fair, but it's not something we're likely to fix any time soon.

As for the technical details:

The SSH key is not trusted at all, it's just used as an identifier. Our servers sign the key with a 5-minute expiration, and that signature is what's used to control gomote access. The important credential is the user's Google account, currently stored as a non-expiring bearer token. So requiring a security key on the SSH cert won't really improve anything. We might be able to get closer to what you're after by requiring reauthentication periodically. Unfortunately it looks like that's not supported for non-browser flows right now.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/20cc55b1-957e-40e1-ae24-b16141196504n%40googlegroups.com.

[gro...@gmail.com]

Thank you, that answers my question well and I withdraw the suggestion.

If someone checks in cryptomining and a TryBot executes, I imagine stern questions would get asked of the Contributor. If similarly there are adequate gomote logs with attribution to the bearer token, that works for me.