{“lastseen”:”2025-10-23T16:41:34″,”description”:”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.\\n\\nI didn\u2019t 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.\\n\\nThe first draft is below, and we\u2019ll 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.\\n\\nIn 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_ places1 to look in!). We also welcome feedback on things that would be valuable to add, for security or for reliability.\\n\\n## The draft Standard of Care\\n\\nWe 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.\\n\\n**Scope**. We apply this standard to projects maintained or co-maintained by Geomys, including\\n\\n * 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)\\n * Staticcheck\\n * Gotraceui\\n * filippo.io\/edwards25519\\n * filippo.io\/csrf\\n * filippo.io\/keygen\\n * filippo.io\/intermediates\\n * `filippo.io\/{bigmod,nistec,mlkem768,hpke}` (externalized from the standard library)\\n * age and typage\\n * mkcert\\n * Sunlight and filippo.io\/torchwood\\n * yubikey-agent\\n * bluemonday\\n\\n\\n\\nFor projects where we are not the sole maintainers, we prioritize working well with the rest of the team.\\n\\nGeomys maintainers may also have personal projects that are not held to this standard (e.g. everything in mostly-harmless). \\n\\n**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.\\n\\n**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.)\\n\\n**Static analysis**. We run staticcheck, by our very own @dominikh, in CI.\\n\\n**Stability**. Once a Go package reaches v1, we maintain strict backwards compatibility within a major version, similarly to the standard library\u2019s compatibility promise.\\n\\n**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).\\n\\n**Dependency management**. We don\u2019t 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.)\\n\\nInstead, we\\n\\n 1. run govulncheck on a schedule, to get high signal-to-noise ratio notifications of vulnerable dependencies that actually affect our projects; and\\n\\n 2. run isolated CI jobs with the latest versions of our dependencies (i.e. running `go get -u` before `go test`) to ensure we\u2019re alerted early of breakages, so we can easily update to future security releases and so we\u2019re aware of potential compatibility issues for our dependents. \\n\\n\\n\\n\\n**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\u2019 users.\\n\\nPhishing-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).\\n\\nCritical accounts that allow escalating to user impact include:\\n\\n * GitHub\\n * All Google accounts linked to a Gerrit account\\n * CI\/CD\\n * Email\\n * Password manager\\n * Passkey sync (e.g. Apple iCloud)\\n * Slack\\n * Website host\\n * Domain registrar\\n * DNS host\\n * Package registry (if applicable, although Go\u2019s decentralized package management largely removes this attack surface)\\n\\n\\n\\nIf a strict mode such as Google\u2019s Advanced Protection Program or Apple\u2019s 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\u2019t hurt us if we don\u2019t use it.\\n\\nWe never enable SMS as an authentication mechanism or as an account recovery mechanism, because SIM jacking is possible even without action on our part.\\n\\n**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.\\n\\nUnlike 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.\\n\\n**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`.\\n\\nWe 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.)\\n\\n**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.\\n\\nIf 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.\\n\\nUnder no circumstances will we release to public registration a domain, GitHub user\/org, or package name that was previously assigned to a Geomys project.\\n\\n**Availability monitoring**. We have automated uptime monitoring for critical user-facing endpoints, such as the Go import path meta pages.\\n\\nThis also provides monitoring for critical domain expiration, preventing accidental takeovers.\\n\\n**Transparency logging**. We subscribe to new version notifications via GopherWatch, to be alerted of unauthorized module versions published to the Go Checksum Database.\\n\\nWe 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.\\n\\n**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.\\n\\nWe 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.)\\n\\nOnce a vulnerability is made public, we ensure it is included in the Go vulnerability database with accurate credit and metadata, including a CVE number.\\n\\nIf the documented vulnerability reporting mechanism is unresponsive, an escalation path is available by emailing security at geomys.org.\\n\\n**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.\\n\\n**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._\\n\\n## The Picture\\n\\nI 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.\\n\\n\\n\\nThis 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!\\n\\nTeleport \u2014 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.\\n\\nAva Labs \u2014 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.\\n\\n* * *\\n\\n 1. https:\/\/github.com\/settings\/tokens and https:\/\/github.com\/settings\/personal-access-tokens and https:\/\/github.com\/settings\/apps\/authorizations and https:\/\/github.com\/settings\/applications \u21a9”,”published”:”2025-10-23T13:49:51″,”modified”:”2025-10-23T13:49:51″,”type”:”filippoio”,”title”:”The Geomys Standard of Care”,”source”:””,”references”:””,”id”:”FILIPPOIO:1B3C53923EE685A2EE6484DE7927D61A”,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/words.filippo.io\/standard-of-care\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2025-10-23T16:41:34″,”description”:”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…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,162,13,33,7,11,5],"class_list":["post-22922","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-filippoio","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n