The Geomys Standard of Care

This is the set of standards that Geomys maintainers strive to uphold in our professional activity as open source maintainers.

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. Retainer clients also get direct access to the expertise of the Geomys maintainers.

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 we will 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.