The Geomys Standard of Care

One of the most impactful effects of professionalizing open source maintenance is that as professionals we can invest into upholding a set of standards that make our projects safer and more reliable. The same commitments and overhead that are often objected to when required of volunteers should be table stakes for professional maintainers.

I didn’t find a lot of prior art, so to compile the Geomys Standard of Care I started by surveying recent supply chain compromises to look for mitigable root causes. (By the way, you might have missed that email because it includes the name of a domain used for a phishing campaign, so it got flagged as phishing. Oops.) I also asked feedback from experts in various areas such as CI security, and from other Geomys maintainers.

The first draft is below, and we’ll maintain the latest version at geomys.org/standard-of-care. It covers general maintenance philosophy, ongoing stability and reliability, dependency management, account and CI security, vulnerability handling, licensing, and more.

In the future, we want to look into adopting more binary transparency tools, and into doing periodic reviews of browser extensions and of authorized Gerrit and GitHub OAuth apps and tokens (just GitHub has four places¹ to look in!). We also welcome feedback on things that would be valuable to add, for security or for reliability.

The draft Standard of Care

We aim to maintain our projects sustainably and predictably. We are only able to do this thanks to our retainer contracts with our clients, but these commitments are offered to the whole community, not just to paying clients.

Scope. We apply this standard to projects maintained or co-maintained by Geomys, including

• the crypto/... and golang.org/x/crypto/... packages in the Go standard library and the FIPS 140-3 Go Cryptographic Module (co-maintained with the rest of the Go team)
• Staticcheck
• Gotraceui
• filippo.io/edwards25519
• filippo.io/csrf
• filippo.io/keygen
• filippo.io/intermediates
• filippo.io/{bigmod,nistec,mlkem768,hpke} (externalized from the standard library)
• age and typage
• mkcert
• Sunlight and filippo.io/torchwood
• yubikey-agent
• bluemonday

For projects where we are not the sole maintainers, we prioritize working well with the rest of the team.

Geomys maintainers may also have personal projects that are not held to this standard (e.g. everything in mostly-harmless).

Code review. If the project accepts external contributions, we review all the code provided to us. This extends to any code generated with LLMs, as well.

Complexity. A major part of the role of a maintainer is saying no. We consciously limit complexity, and keep the goals and non-goals of a project in mind when considering features. (See for example the Go Cryptography Principles.)

Static analysis. We run staticcheck, by our very own @dominikh, in CI.

Stability. Once a Go package reaches v1, we maintain strict backwards compatibility within a major version, similarly to the standard library’s compatibility promise.

Ongoing maintenance. Not all projects are actively worked on at all times (e.g. some projects may be effectively finished, or we may work in batches). However, unless a project is explicitly archived or deprecated, we will address newly arising issues that make the project unsuitable for a previously working use case (e.g. compatibility with a new OS).

Dependency management. We don’t use automatic dependency version bump tools, like Dependabot. For our purposes, they only cause churn and increase the risk of supply chain attacks by adopting new module versions before the ecosystem has had time to detect attacks. (Dependabot specifically also has worrying impersonation risks, which would make for trivial social engineering attacks.)

Instead, we

1. run govulncheck on a schedule, to get high signal-to-noise ratio notifications of vulnerable dependencies that actually affect our projects; and

2. run isolated CI jobs with the latest versions of our dependencies (i.e. running go get -u before go test) to ensure we’re alerted early of breakages, so we can easily update to future security releases and so we’re aware of potential compatibility issues for our dependents.

Phishing-resistant authentication. Phishing is by far the greatest threat to our security and, transitively, to that of our users. We acknowledge there is no amount of human carefulness that can systematically withstand targeted attacks, so we use technically phishing-resistant authentication for all services that allow impacting our projects’ users.

Phishing-resistant authentication means passkeys or WebAuthn 2FA, with credentials stored in platform authenticators (e.g. iCloud Keychain), password managers (e.g. 1Password or Chrome), or hardware tokens (e.g. YubiKeys).

Critical accounts that allow escalating to user impact include:

• GitHub
• All Google accounts linked to a Gerrit account
• CI/CD
• Email
• Password manager
• Passkey sync (e.g. Apple iCloud)
• Slack
• Website host
• Domain registrar
• DNS host
• Package registry (if applicable, although Go’s decentralized package management largely removes this attack surface)

If a strict mode such as Google’s Advanced Protection Program or Apple’s Advanced Data Protection is available, we enable it. If a phishable fallback authentication or account recovery method is instead required, we configure one that is secret-based (e.g. TOTP or recovery codes) and either delete the secret or commit to never using it without asking a fellow Geomys maintainer to review the circumstances that necessitated it. TOTP can’t hurt us if we don’t use it.

We never enable SMS as an authentication mechanism or as an account recovery mechanism, because SIM jacking is possible even without action on our part.

Long-lived credentials. We avoid where possible long-lived persistent credentials, or make them non-extractable if possible. For example, we use git-credential-oauth instead of Gerrit cookies, and hardware-bound SSH keys with yubikey-agent or Secretive instead of personal access tokens for git pushes to GitHub.

Unlike phishing-resistant authentication, we found it impractical to roll out short-lived credentials universally. Notably, we have not found a way to use the GitHub CLI without extractable long-lived credentials.

CI security. We run zizmor on our GitHub Actions workflows, and we don’t use dangerous GitHub Actions triggers that run privileged workflows with attacker-controlled contexts, such as pull_request_target.

We run GitHub Actions workflows with read-only permissions and no secrets by default. Workflows that have write permissions or access to secrets disable all use of caches (including indirectly through actions like actions/setup-go), to mitigate cache poisoning attacks. (Note that, incredibly, read-only workflows can write arbitrary cache entries, which is why this must be mitigated at cache use time.)

Third-party access. For projects maintained solely by Geomys, we avoid providing user-impacting (i.e. push or release) access to external people, and publicly disclose any exceptions.

If abandoning a project, we prefer archiving it and letting a fork spawn to handing over control to external people. This way dependents can make their own assessment of whether to trust the new maintainers. Any exceptions will be widely communicated well in advance.

Under no circumstances will we release to public registration a domain, GitHub user/org, or package name that was previously assigned to a Geomys project.

Availability monitoring. We have automated uptime monitoring for critical user-facing endpoints, such as the Go import path meta pages.

This also provides monitoring for critical domain expiration, preventing accidental takeovers.

Transparency logging. We subscribe to new version notifications via GopherWatch, to be alerted of unauthorized module versions published to the Go Checksum Database.

We monitor Certificate Transparency logs for critical domains (e.g. the roots of our Go import paths) using tools such as Cert Spotter or Silent CT. We also set CAA records on those domains limiting issuance to the minimal set of CAs required for operation.

Vulnerability handling. We document the official vulnerability reporting mechanism of each project, we encourage coordinated vulnerability reporting, and we appreciate the work of security researchers.

We honor embargoes of up to 90 days, and we do not share vulnerability details with people not involved in fixing it until they are public. (Paying clients do not get access to private vulnerability details. This is to honor our responsibility to the various stakeholders of an open source project, and to acknowledge that often these details are not ours to share.)

Once a vulnerability is made public, we ensure it is included in the Go vulnerability database with accurate credit and metadata, including a CVE number.

If the documented vulnerability reporting mechanism is unresponsive, an escalation path is available by emailing security at geomys.org.

Licenses. We use permissive, well-known licenses: BSD-3-Clause, BSD-2-Clause, BSD-1-Clause, 0BSD, ISC, MIT, or (less preferably) Apache-2.0.

Disclaimer. This is not a legally binding agreement. Your use of the projects continues to be controlled by their respective licenses, and/or by your contract with Geomys, which does not include this document unless explicitly specified.

The Picture

I am getting a cat (if I successfully defeat my allergies through a combination of LiveClear, SLIT, antihistamines, and HEPA filters), so obviously you are going to get a lot of cat pictures going forward. For more, you can follow me on Bluesky at @filippo.abyssdomain.expert or on Mastodon at @filippo@abyssdomain.expert.

This is the work of Geomys, an organization of professional Go maintainers, which is funded by Smallstep, Ava Labs, Teleport, Tailscale, and Sentry. Through our retainer contracts they ensure the sustainability and reliability of our open source maintenance work and get a direct line to my expertise and that of the other Geomys maintainers. (Learn more in the Geomys announcement.) Here are a few words from some of them!

Teleport — For the past five years, attacks and compromises have been shifting from traditional malware and security breaches to identifying and compromising valid user accounts and credentials with social engineering, credential theft, or phishing. Teleport Identity is designed to eliminate weak access patterns through access monitoring, minimize attack surface with access requests, and purge unused permissions via mandatory access reviews.

Ava Labs — We at Ava Labs, maintainer of AvalancheGo (the most widely used client for interacting with the Avalanche Network), believe the sustainable maintenance and development of open source cryptographic protocols is critical to the broad adoption of blockchain technology. We are proud to support this necessary and impactful work through our ongoing sponsorship of Filippo and his team.