ENOSUCHBLOG

ENOSUCHBLOGProgramming, philosophy, pedaling.README, nothttps://blog.yossarian.net/2026/07/16/README-not<body morss_own_score="2.7288135593220337" morss_score="44.07180872840416"> <h1>ENOSUCHBLOG</h1> <h2>Programming, philosophy, pedaling.</h2> <hr> <h1> <a href="https://blog.yossarian.net/2026/07/16/README-not">README, not</a> </h1> Jul 16, 2026 Tags: <a href="https://blog.yossarian.net/tags#ai">ai</a>, <a href="https://blog.yossarian.net/tags#oss">oss</a> <hr> <img src="https://blog.yossarian.net/assets/borat-not.png"> (Thanks to <a href="https://github.com/facutuesca">Facundo Tuesca</a> for the name inspiration). If you’re like me, you spend a lot of your working day (and a good chunk of your personal time) reading code online. Increasingly, that means accidentally reading a lot of “slop”<a href="https://blog.yossarian.net/2026/07/16/README-not#fn:slop">1</a>. Personally, slop isn’t annoying per se<a href="https://blog.yossarian.net/2026/07/16/README-not#fn:codegen">2</a>: it’s okay for personal software<a href="https://blog.yossarian.net/2026/07/16/README-not#fn:personal">3</a>, for example, to be slop. What makes slop annoying is the feeling of being bait-and-switched: much like the written word, I want to be informed<a href="https://blog.yossarian.net/2026/07/16/README-not#fn:informed">4</a> before I spend my human attention on machine outputs. I’m a big believer in giving people a way to express honest intentions. For example, I do sometimes want to drop some slop on the Internet (to save for myself later, or for others to reuse without reading), but I don’t want to mislead people about the intent or effort behind it. So: what if we gave people a way to express their honest intentions with slop? We use <code>README</code> files to tell users where to start when reading a project; I think we should have a <code>READMENOT</code><a href="https://blog.yossarian.net/2026/07/16/README-not#fn:naming">5</a> file that users (or their agents) can add to their projects when they’re slopping it up. The presence of that file would serve as an unambigous warning that the code within the project is unsuitable for unwitting human comprehension<a href="https://blog.yossarian.net/2026/07/16/README-not#fn:comprehension">6</a>. A <code>READMENOT</code> could contain anything, but it seems to me like a good default would be a short human-friendly explanation of why the project shouldn’t be read. For example: <pre><code><table><tbody><tr><td><pre>1 2 3 4 5 </pre></td><td><pre>Warning! You're reading a project that isn't intended for direct human consumption. You may wish to use an LLM or another tool to interact automatically with this project. </pre></td></tr></tbody></table></code></pre> <hr> <ol> <li> What is or isn’t “slop” in the context of programming is currently a matter of energetic (and sometimes emotionally charged) debate. I personally draw the line with either of two sufficient qualities: to me, a codebase is slop if it either (1) is developed primarily without human supervision, or (2) reflects a fundamental lack of operator understanding. These are qualities sometimes occur at the same time, but either suffices. It’s also worth noting that LLMs are getting better; 2026’s slop is not 2025’s slop. That makes it hard to grant “slop” as a static qualifier; this post reflects reality in July 2026. <a href="https://blog.yossarian.net/2026/07/16/README-not#fnref:slop">↩</a> </li> <li> I personally think about slop like generated code: it’s not annoying for generated code to exist, but it is annoying to find yourself reading it because it lacks the appropriate <code>@generated</code> (or whatever) marker. <a href="https://blog.yossarian.net/2026/07/16/README-not#fnref:codegen">↩</a> </li> <li> Meaning software that solves a personal problem, is bespoke, is single-use or “disposable,” &c. <a href="https://blog.yossarian.net/2026/07/16/README-not#fnref:personal">↩</a> </li> <li> I often choose to read machine-generated things. Being able to make an informed decision to do so is what matters to me. <a href="https://blog.yossarian.net/2026/07/16/README-not#fnref:informed">↩</a> </li> <li> I don’t really care what this file is named, or that it’s a file at all: any kind of consistent marker would suffice. But calling it <code>READMENOT</code> is funny, so that’s what we’re going with for this post. <a href="https://blog.yossarian.net/2026/07/16/README-not#fnref:naming">↩</a> </li> <li> There are lots of good reasons to still read slop as a human, not least of which is performing security research. The idea behind <code>READMENOT</code> not to tell you to never read a codebase, only to inform you about you what might expect to see if you do decide to read it. <a href="https://blog.yossarian.net/2026/07/16/README-not#fnref:comprehension">↩</a> </li> </ol> <hr> Discussions: <a href="https://infosec.exchange/@yossarian/116929949470585620">Mastodon</a> <a href="https://bsky.app/profile/yossarian.net/post/3mqreksj7lw25">Bluesky</a> <a href="https://www.reddit.com/r/enosuchblog/comments/1uy3apv/readme_not/">Reddit</a> <hr> <a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing">Previously</a> </body> Thu, 16 Jul 2026 00:00:00 UTCYou shouldn’t trust Trusted Publishinghttps://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing…because Trusted Publishing isn’t for you (or me) to trust! It’s for the machines.<body morss_own_score="2.7492202121023084" morss_score="104.28858278016169"> <h1>ENOSUCHBLOG</h1> <h2>Programming, philosophy, pedaling.</h2> <hr> <h1> <a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing">You shouldn't trust Trusted Publishing</a> </h1> Jul 7, 2026 Tags: <a href="https://blog.yossarian.net/tags#oss">oss</a>, <a href="https://blog.yossarian.net/tags#python">python</a>, <a href="https://blog.yossarian.net/tags#security">security</a> <hr> …because <a href="https://docs.pypi.org/trusted-publishers/">Trusted Publishing</a> isn’t for you (or me) to trust! It’s for the machines. Trusted Publishing is an authentication scheme that involves machine-to-machine trust. If you find yourself arguing against (or for!) Trusted Publishing on the basis that you (a human) can’t (or can) trust it then you’re making a category error, one that PyPI is careful to help you not make. I wrote about this indirectly <a href="https://blog.yossarian.net/2024/11/18/Security-means-securing-people-where-they-are">about two years ago</a>, but I left this observation implicit rather than laying it out explicitly. This is an attempt to correct that mistake. <h2>Quick recap<a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#quick-recap">#</a></h2> “Trusted Publishing” is a term of art that <a href="https://pypi.org">PyPI</a> uses to describe a form of authentication on top of OpenID Connect (<a href="https://openid.net/developers/how-connect-works/">OIDC</a>) federation. PyPI released it in 2023<a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:dev">1</a>, and it’s since been adopted widely by other packaging ecosystems (including <a href="https://docs.npmjs.com/trusted-publishers">npm</a>, <a href="https://guides.rubygems.org/trusted-publishing/">RubyGems</a>, <a href="https://crates.io/docs/trusted-publishing">crates.io</a>, and <a href="https://learn.microsoft.com/en-us/nuget/nuget-org/trusted-publishing">NuGet</a>). The basic observation behind Trusted Publishing is twofold: <ol> <li>Long-lived credentials (like index API tokens) are difficult to secure, and are often over-scoped because users find it frustrating to determine the “right” minimal scope and expiry. Consequently, the impact of a compromised or leaked credential can be much broader than the specific system it was stolen from.</li> <li>Many users provision credentials solely for the purpose of putting them in a CI/CD platform, which they then publish from. However, CI/CD platforms often also have identity mechanisms that allow a user to demonstrate control of a specific machine identity<a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:machine-identity">2</a> via OIDC.</li> </ol> Trusted Publishing combines these into an authentication scheme: the user performs a one-time registration of their “Trusted Publisher” (their CI/CD machine identity) with their package index. Then, whenever the CI/CD presents an identity token, the package index verifies it and issues a corresponding, minimally scoped, short-lived publishing credential. This can be hard to visualize; <a href="https://sethmlarson.dev">Seth Larson</a>’s diagram is instructive: <img src="https://blog.yossarian.net/assets/trusted-publishers-flow.png"> (Source: <a href="https://repos.openssf.org/trusted-publishers-for-all-package-repositories.html">OpenSSF</a>) Broadly speaking, this approach to short-lived, self-scoping credentials has been a huge success: we’ve found that users<a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:pypi">3</a> prefer not to manually manage credentials when they don’t have to, and that large Open Source projects and companies alike both like the property of their publishing being tied to their source identity rather than any individual project maintainer. Of course, Trusted Publishing is not perfect: it has a complicated data model<a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:datamodel">4</a>, requires bespoke treatment for each OIDC provider that an index chooses to support<a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:support">5</a>, and (of course) can still be compromised (since, at the end of the day, it’s still an authentication scheme and there needs to be a credential somewhere in the flow)<a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:compromised">6</a>. Despite these qualifications, I think Trusted Publishing has been a net win for packaging ecosystems that adopt it. As mentioned in <a href="https://blog.yossarian.net/2024/11/18/Security-means-securing-people-where-they-are">the earlier post</a>, security is a matter of identifying and protecting the areas where your users congregate their trust (their “watering holes”), and Trusted Publishing accomplishes that by reducing the number of long-lived, over-scoped credentials that users are exposed to. <h2>What of trust?<a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#what-of-trust">#</a></h2> Thus far, everything I’ve written makes Trusted Publishing sound pretty good, if not a silver bullet. So, why the emphasis on not trusting it? This is an important subtlety: Trusted Publishing is just an authentication method. The only thing Trusted Publishing does is establish a trust relationship between an external machine identity (like a CI/CD workflow) and a package identity on an index for the purpose of authenticating an upload; it does not tell a user that a package is safe to use, high quality, or anything else. You can prove this to yourself easily: PyPI is a public index (by design), which means that anybody can upload to it, and anybody can use a Trusted Publisher to upload<a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:can">7</a>. Because anybody can use one, they can be used to upload anything, including malware or vulnerable code. They are exactly like API tokens (PyPI’s other upload authentication method) in this regard. PyPI is very careful<a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:careful">8</a> to not mislead users into believing that they can or should trust a package based on its Trusted Publishing status. If you go to a project’s page on PyPI, you’ll notice that there is no “magic green checkmark” signaling a project’s Trusted Publishing status. Using <a href="https://pypi.org/project/zizmor/">zizmor</a> as an example: <img src="https://blog.yossarian.net/assets/zizmor-pypi.png"> Observe that the only “green checkmark” for user-controlled state on this page is for links that PyPI can prove came from the same source as the package itself. These links, too, are intentionally not described as “trusted”; as the <a href="https://docs.pypi.org/project_metadata/#verified-details">PyPI docs explain</a>: <blockquote> A URL being verified only attests that the URL is under control of the PyPI package owner at the time of verification, and does not imply any additional safety about that URL or any other relationship to the project in question. </blockquote> If you do want to see the Trusted Publishing status of a particular file on PyPI you’ll need to dig for it. You’ll find it ignominiously rendered as a simple “Yes/No” deep in the <a href="https://pypi.org/project/zizmor/#zizmor-1.26.1.tar.gz">file details</a>: <img src="https://blog.yossarian.net/assets/zizmor-pypi-details.png"> I say “ignominiously” because you can see how little effort has been placed into rendering the “file metadata” section, because it’s not important trust information. We don’t even bother to properly render the blob of JSON that comes from the uploading client’s user agent! Here, too, you can see that no normative statement of trust is applied to the Trusted Publishing status: there’s a boolean state, and nothing whatsoever to imply that a user can or should trust a project more or less because of that state. <h2>Summary<a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#summary">#</a></h2> Trusted Publishing is a mechanism for establishing trust between an external machine identity (like a CI/CD workflow) and one or more projects on a package index/registry. The “trust” in “Trusted Publishing” refers to that trust relationship, and not to anything else. It is not, and cannot be, a signal for package trust or quality. You cannot use it to determine whether a package is safe or “good,” and PyPI consciously stymies attempts to misuse it for that purpose by not rendering it as a “green checkmark” or anything else of the sort. Or as another framing: Trusted Publishing is just a form of authentication. It doesn’t tell you anything other than that an upload was authenticated, which all uploads to PyPI are. <a href="https://www.goodreads.com/quotes/361132-the-law-in-its-majestic-equality-forbids-rich-and-poor">With apologies to Anatole France</a>: <blockquote> Trusted Publishing, in its majestic equality, permits seasoned maintainer and script kiddy alike to publish malware, to release slop for HN karma, and to obtain security advisories for embarassing flaws. </blockquote> <h2>Afterword<a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#afterword">#</a></h2> This post is about Trusted Publishing, not <a href="https://docs.pypi.org/attestations/">attestations</a>. Attestations are a technically distinct topic on PyPI that (currently) also use OIDC machine identities, but are similarly not a signal of trust. To analogize: an attestation is effectively a signature on top of a machine identity, but anybody can upload to PyPI and therefore anybody can sign with any machine identity they control. The presence of an attestation is not guaranteed by the presence of a Trusted Publisher, and similarly does not imply any particular end-user trust until you separately establish trust in that identity. This, too, is <a href="https://docs.pypi.org/attestations/security-model/#trustworthiness">explicitly documented</a>. <hr> <ol> <li> To my recollection, we spent a good part of 2022 designing and implementing it. <a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fnref:dev">↩</a> </li> <li> The concept of a machine identity can be difficult to develop an intuition for, in no small part because what “counts” as a sufficient identity varies wildly by OIDC IdP. In the context of GitHub Actions (and Trusted Publishing specifically), the “machine identity” is effectively a tuple of cryptographically verifiable claims about the GitHub Actions workflow that issued the OIDC identity token. For example, the identity <code>(github, hello-world, publish.yml, pypi.org)</code> might correspond to a GitHub Actions workflow names <code>publish.yml</code>, running underneath the <code>github/hello-world</code> repository, running with an environment named <code>pypi.org</code>. <a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fnref:machine-identity">↩</a> </li> <li> At least on PyPI. I don’t have direct evidence from other ecosystems. <a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fnref:pypi">↩</a> </li> <li> PyPI has “pending publishers” as a way to solve the chicken-and-egg problem with nonexistent projects, but it’s not great: it complicates the data model significantly, and users find it more confusing than “regular” Trusted Publishing. <a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fnref:datamodel">↩</a> </li> <li> This is primarily a consequence of OIDC’s own (in my opinion, excessive) flexibility: outside of a common subset of claims, OIDC IdPs are free to put anything in their claim set. The consequence of this is that machine identities are not fungible across OIDC IdPs, and indices typically need to handle each IdP’s unique “shape” on a case-by-case basis. This is one of the reasons (but not the only reason) why PyPI adds new Trusted Publishing providers so slowly. <a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fnref:support">↩</a> </li> <li> One of the themes of 2026 so far is attackers realizing that they can exfiltrate a Trusted Publishing credential (or its “seed” credential, the OIDC ID token), typically as a pivot after compromising a CI/CD workflow. This is similar to what would happen if the workflow had a long-lived credential provisioned against it, except that the Trusted Publishing credential doesn’t have the same scoping and longevity risks. Still, it’s not ideal, and PyPI has taken steps to mitigate the (external) problem of CI/CD compromise by e.g. refusing token exchanges when the machine identity corresponds to a easily exploited trigger like <code>pull_request_target</code>. <a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fnref:compromised">↩</a> </li> <li> Anybody can use a Trusted Publisher on PyPI, but they do not have to and will never have to. It is simply infeasible as an engineering matter (in addition to being technically and socially undesirable) to force users into Trusted Publishing. It will always be optional, and cannot be any other way. <a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fnref:can">↩</a> </li> <li> I believe most package indices are similarly careful, although I have less direct experience with them. <a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fnref:careful">↩</a> </li> </ol> <hr> Discussions: <a href="https://www.reddit.com/r/enosuchblog/comments/1upucn0/you_shouldnt_trust_trusted_publishing/">Reddit</a> <a href="https://infosec.exchange/@yossarian/116878809694342665">Mastodon</a> <a href="https://bsky.app/profile/yossarian.net/post/3mq2nt4tt2m24">Bluesky</a> <hr> <a href="https://blog.yossarian.net/2026/04/29/Registering-my-dissatisfaction-with-GitHub">Previously</a> <a href="https://blog.yossarian.net/2026/07/16/README-not">Newer</a> </body> Tue, 07 Jul 2026 00:00:00 UTCRegistering my dissatisfaction with GitHubhttps://blog.yossarian.net/2026/04/29/Registering-my-dissatisfaction-with-GitHubMini-post.<body morss_own_score="2.518518518518518" morss_score="36.01165915699997"> <h1>ENOSUCHBLOG</h1> <h2>Programming, philosophy, pedaling.</h2> <hr> <h1> <a href="https://blog.yossarian.net/2026/04/29/Registering-my-dissatisfaction-with-GitHub">Registering my dissatisfaction with GitHub</a> </h1> Apr 29, 2026 Tags: <a href="https://blog.yossarian.net/tags#oss">oss</a> <hr> Mini-post. I read <a href="https://mitchellh.com/writing/ghostty-leaving-github">Mitchell Hashimoto’s blog post</a> yesterday and it resonated with me; this part in particular: <blockquote> Since then, I’ve opened GitHub every single day. Every day, multiple times per day, for over 18 years. Over half my life. A handful of exceptions in there (I’d love to see the data), but I can’t imagine more than a week per year. </blockquote> I can’t claim quite the same seniority (I <a href="https://github.com/woodruffw">joined</a> in 2012; my user ID is <code>3059210</code>), but I think I can fairly say that GitHub is both my favorite and the single most important service I’ve interacted with, both as a hobbyist maintainer and as a professional software engineer. I wouldn’t have the friends, connections, career, &c. that I have today if it wasn’t for GitHub. Despite that, using GitHub has become a thoroughly dissatisfying experience over the last 18 months. I don’t know exactly why that is<a href="https://blog.yossarian.net/2026/04/29/Registering-my-dissatisfaction-with-GitHub#fn:theories">1</a>, but that is the brute reality. I now frequently interact with GitHub with a defensive, rather than optimistic posture: I assume that things will be slow, buggy, or just plain broken, and my disappointment with the state of affairs has been ground down from surprise (and a desire to help by reporting bugs) to resignation and apathy. I hope that GitHub can turn things around, and that I get to use it for years to come. But as of now, I’m dissatisfied with it and, for the first time in over a decade, I am seriously considering alternatives. <hr> <ol> <li> Theories abound, and are too well-trodden to be worth repeating in detail. In brief: a loss of pride-in-craft (stemming from Microsoft’s acquisition), deprioritization of feature development in the core product, an ill-advised React frontend rewrite, talent loss (voluntary and involuntary), a surge of AI-driven traffic, &c, &c. I have no idea which (if any) of these are to blame. <a href="https://blog.yossarian.net/2026/04/29/Registering-my-dissatisfaction-with-GitHub#fnref:theories">↩</a> </li> </ol> <hr> <a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage">Previously</a> <a href="https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing">Newer</a> </body> Wed, 29 Apr 2026 00:00:00 UTCBrocards for vulnerability triagehttps://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triageI spend some of my hobby time doing vulnerability triage on open source projects. As part of that, I see (and filter through) a lot of nonsense1. Spam, “beg bounty” submissions, and increasingly zero-effort LLM submissions. ↩<body morss_own_score="2.667452830188679" morss_score="100.56608058906077"> <h1>ENOSUCHBLOG</h1> <h2>Programming, philosophy, pedaling.</h2> <hr> <h1> <a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage">Brocards for vulnerability triage</a> </h1> Apr 11, 2026 Tags: <a href="https://blog.yossarian.net/tags#oss">oss</a>, <a href="https://blog.yossarian.net/tags#security">security</a> <hr> I spend some of my hobby time doing vulnerability triage on open source projects. As part of that, I see (and filter through) a lot of nonsense<a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage#fn:nonsense">1</a>. Nonsense is not unique to vulnerability triage: lawyers deal with it too. To cope with it in the legal world, they use <a href="https://en.wikipedia.org/wiki/Brocard_(law)">brocards</a> — concise aphorisms that capture the essence of a legal principle. Any given brocard is not universally true<a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage#fn:law">2</a>, but provides a standard by which a claim can quickly be evaluated for legitimacy. Vulnerability triage has its own brocards, but I couldn’t find a comprehensive list of them anywhere. This is my attempt to compile such a list. <h2>No vulnerability report without a threat model<a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage#no-vuln-without-threat-model">#</a></h2> <a href="https://alexgaynor.net">Alex Gaynor</a> explains this one well in <a href="https://alexgaynor.net/2025/oct/20/motion-to-dismiss/">Motion to Dismiss for Failure to State a Vulnerability</a>: a vulnerability report can be safely dismissed if it lacks a threat model, or if the threat model presented is incoherent. Examples include: <ul> <li> A report for a Python API that raises an exception in some undocumented or surprising cases<a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage#fn:exceptions">3</a>, but doesn’t explain how an attacker could exploit that behavior to cause harm. </li> <li> A report for a hang or stall in a local developer tool. Hangs are undesirable behavior, but the opportunity for harm from one is negligible in a developer tooling context: the developer can always just kill the process. </li> </ul> <h2>No exploit from the heavens<a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage#no-exploit-from-heavens">#</a></h2> Closely related are vulnerability reports that describe a severe end state, but only under attacker capability assumptions that are more powerful than the vulnerability itself. In effect, in order to mount an attack that exploits the vulnerability, the attacker would already need to have an equal or more powerful capability than the vulnerability itself provides. Examples include: <ul> <li> A report for content manipulation on a web service, where the manipulation can only occur if the attacker is an active <a href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack">meddler in the middle</a>. No vulnerability exists here, because an active MiTM could send entirely arbitrary content, and would not have to limit themselves to manipulating pre-existing content. </li> <li> A report for code execution via memory corruption in CPython, where the memory corruption occurs by directly manipulating CPython’s object internals at runtime (via ctypes, for example). No vulnerability exists here, because the attacker is already running arbitrary code to perform the corruption. </li> </ul> <a href="https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283">Raymond Chen has 2006 post that covers the same concept</a>. Thanks to <a href="https://ldpreload.com">Geoffrey Thomas</a> for sharing that with me! <h2>No vulnerability outside of usage<a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage#no-vuln-outside-usage">#</a></h2> A vulnerability report can be safely dismissed if it describes a behavior that could occur, but does not in fact occur in actual usage of the software. Examples include: <ul> <li> A report for a vulnerability in a private API within a library, where the only (private) usage of that API is not vulnerable. For example, a C codebase might have a function that takes a <code>char *</code> and exhibits a buffer overflow with strings longer than 100 bytes, but a codebase where all calls to that function are statically assertable to not exceed that size is not vulnerable. </li> <li> Similarly, a report for a vulnerability in an API (public or private), where the vulnerability can only occur by violating an invariant that the programmer is responsible for maintaining. For example, an API might have a precondition that an input string is valid UTF-8, and an input that violates this precondition may cause an uncontrolled program abort. However, a fuzzer that discovers this behavior has not found a vulnerability, because in a real program the programmer is responsible for ensuring that the “building blocks” of the API are composed together. It’s worth noting some nuance here: because the programmer is responsible for maintaining the invariant, there is a potentially legitimate vulnerability when usage of the API violates the invariant. By analogy: <code>free(3)</code> is not considered vulnerable to a double free, but a program that calls <code>free(3)</code> on an already freed pointer is considered vulnerable to a double free. </li> <li> A re-report of a upstream’s vulnerability, where the upstream’s’s vulnerable behavior is not reachable in the downstream. For example, CPython is shipped with a build of OpenSSL, and OpenSSL <a href="https://www.openssl.org/news/vulnerabilities.html">regularly has security advisories</a>. However, CPython’s exposure to OpenSSL is mostly limited to SSL/TLS and a subset of the X.509 APIs, and therefore vulnerabilities outside of these surfaces do not constitute a reasonable re-report to CPython. </li> </ul> <h2>No vulnerability from standard behavior<a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage#no-vuln-from-standard-behavior">#</a></h2> Perhaps my most controversial (and personal) brocard: a vulnerability report can be safely dismissed if the behavior described is a direct consequence of the software’s correct adherence to a standard or specification. In these instances the vulnerability (if one exists) is present within the standard itself, and not the implementation. Examples include: <ul> <li> Behavior stemming from “robustness” requirements in standards. Many RFCs and similar standards inadvisably follow the (poorly named) <a href="https://en.wikipedia.org/wiki/Robustness_principle">robustness principle</a>, and allow interactions that are not well-defined (often by allowing the implementer to make a judgement call about the intended semantics of the interaction). For example, <a href="https://datatracker.ietf.org/doc/html/rfc7230">RFC 7230</a> has this under “Message Parsing Robustness” (ss. 3.5): <blockquote> In the interest of robustness, a server that is expecting to receive and parse a request-line SHOULD ignore at least one empty line (CRLF) received prior to the request-line. Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR. </blockquote> </li> <li> Behavior stemming from cryptographic requirements that are insecure in isolation but secure by construction. The “classic” example of this is (typically automated) reports of MD5 usage, where that usage is solely in constructions where MD5 is not actually broken (i.e. HMAC-MD5). There’s a strong argument to be made that a better hash function should be used where permitted, but the presence of MD5 in an HMAC construction is not itself a vulnerability. </li> </ul> The nuance with this is that an implementation that chooses to be more strict than the standard requires should be considered vulnerable if the intended strictness is violated. <h2>No vulnerability from documented behavior<a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage#no-vuln-from-documented-behavior">#</a></h2> (Many thanks to <a href="https://github.com/hugovk">Hugo van Kemenade</a> for this one!) Similar to the above: a vulnerability report can be safely dismissed if the behavior is documented to occur, particularly when the documentation explicitly describes the security implications of the behavior or specific contexts in which the software is unsafe to use. Examples include: <ul> <li> Python’s <a href="https://docs.python.org/3/library/http.server.html"><code>http.server</code></a> is explicitly documented as not suitable for production use, as it only implements <a href="https://docs.python.org/3/library/http.server.html#http-server-security">basic security checks</a>. </li> <li> Python’s <a href="https://docs.python.org/3/library/pickle.html"><code>pickle</code></a> is explicitly documented as not secure, full stop. </li> </ul> Like with the previous brocard, the nuance here is that a downstream usage that violates the documented guidelines for use may be considered vulnerable. In other words: a report against <code>pickle</code> itself (for e.g. enabling code execution) may be safely dismissed, but a report against a downstream usage of <code>pickle</code> that ignores the documented warnings may be considered valid. <h2>No cure worse than the disease<a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage#no-cure-worse-than-disease">#</a></h2> The maintainer should reject (or contest) vulnerability reports whose consequences are worse than the consequences of the vulnerability itself. The classic example of this is <a href="https://blog.yossarian.net/2022/12/28/ReDoS-vulnerabilities-and-misaligned-incentives">ReDoS</a> “vulnerabilities,” particularly in contexts where the impact of the “denial of service” is negligible<a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage#fn:negligible">4</a>. These reports typically involve nontrivial amounts of maintainer time and effort to triage, followed by nontrivial amounts of downstream time and effort to remediate, effectively resulting in a denial of service on the community itself. <a href="https://github.com/advisories/GHSA-5239-wwwm-4pmq">CVE-2026-4539</a> is a recent case of this: an anonymous reporter filed a CVE against <a href="https://github.com/pygments/pygments">pygments</a> with <a href="https://vuldb.com/">VulDB</a>, seemingly bypassing any maintainer or community review. This report was not accompanied by a fixed version (because it’s junk, and ignores <a href="https://pygments.org/docs/security/">pygments’ own security policy</a>), but lit up tens of thousands of downstream dependencies with a “medium” severity vulnerability, <a href="https://github.com/pygments/pygments/issues/3058">causing significant disruption</a>. The status quo in 2026 is that the CVE ecosystem unreasonably places the onus on maintainers to contest this kind of spam when adversarial reporters bypass them entirely. <h2>The report is neither necessary nor sufficient<a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage#report-neither-necessary-nor-sufficient">#</a></h2> The presence of a vulnerability report (and a CVE or other identifier for that report) is neither necessary nor sufficient for a vulnerability to exist. This cuts both ways: many (perhaps the majority of) vulnerabilities are never “formally” reported, and many formal reports do not actually describe meaningful vulnerabilities (per above). Consequently, no unvalidated assumption should ever be made about the relationship between the presence of a report and the presence of a vulnerability. This is another unfortunate status quo, one that stems from (seemingly intentional) <a href="https://blog.yossarian.net/2024/03/20/More-thoughts-on-vulnerabilities-and-misaligned-incentives">strategic ambiguity</a> in the vulnerability reporting ecosystem: partners like MITRE benefit simultaneously from being perceived as a high-quality source of vulnerability information, while also being able to disclaim any responsibility for communicating anything other than a stable identifier for a claim of vulnerability. <hr> <ol> <li> Spam, “beg bounty” submissions, and increasingly zero-effort LLM submissions. <a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage#fnref:nonsense">↩</a> </li> <li> Brocards are also not themselves law. <a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage#fnref:law">↩</a> </li> <li> Vulnerability reports for libraries/components that raise exceptions in managed libraries are very common, and often belie a fundamental misunderstanding of the language’s execution contract. In Python, for example, the presumed execution contract is that an exception can occur at any point, and that a system should always be prepared to handle an exception. This doesn’t mean that every single block of code needs a <code>try..except</code>, but that all exceptions do get handled eventually, and therefore vulnerabilities only emerge when an exception is mishandled. <a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage#fnref:exceptions">↩</a> </li> <li> Two common reasons for the negligibility of ReDoS: (1) the only impact is to local workflows where the “denial” is trivially cancellable (such as a developer tool running in a terminal), and (2) the vulnerable behavior is only exhibited on arbitrary inputs that would otherwise pose a denial of service “risk”. <a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage#fnref:negligible">↩</a> </li> </ol> <hr> Discussions: <a href="https://www.reddit.com/r/enosuchblog/comments/1sir2mf/brocards_for_vulnerability_triage/">Reddit</a> <a href="https://infosec.exchange/@yossarian/116387519824893265">Mastodon</a> <a href="https://bsky.app/profile/yossarian.net/post/3mjai6eav4527">Bluesky</a> <hr> <a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb">Previously</a> <a href="https://blog.yossarian.net/2026/04/29/Registering-my-dissatisfaction-with-GitHub">Newer</a> </body> Sat, 11 Apr 2026 00:00:00 UTCSome flexibility with Go’s sumdbhttps://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdbI noticed this a year or two ago, but forgot to write it up back then.<body morss_own_score="2.794912559618442" morss_score="131.56319682498543"> <h1>ENOSUCHBLOG</h1> <h2>Programming, philosophy, pedaling.</h2> <hr> <h1> <a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb">Some flexibility with Go's sumdb</a> </h1> Dec 29, 2025 Tags: <a href="https://blog.yossarian.net/tags#cryptography">cryptography</a>, <a href="https://blog.yossarian.net/tags#go">go</a>, <a href="https://blog.yossarian.net/tags#security">security</a> <hr> I noticed this a year or two ago, but forgot to write it up back then. I don’t think it’s particularly serious or important, but it’s an interesting demonstration of how flexibility in identity can make monitoring in transparency schemes nontrivial, as well as conflict with user intuitions around which identities are equivalent. TL;DR: Go’s sumdb log entries are unique per module version, but there are typically multiple valid case forms for the module path that point to the same module version contents. These forms are not confusable at import time, but they complicate the monitoring story and could form the basis of a typosquatting-like attack. Because the “typo” is just a case variation, it looks less suspicious than a normal typo. <h2>Background<a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#background">#</a></h2> Go’s packaging design includes the <a href="https://proxy.golang.org">Go module proxy</a>, which is effectively a caching proxy for Go modules. This serves (at least) two main purposes: <ol> <li> It makes Go packaging more reliable and resilient: <code>src.example.com/some/module@v1.2.3</code> will continue to work even if <code>src.example.com</code> goes down, so long as someone has previously resolved that module and version through the proxy. This also has the knock-on effect of making Go’s module resolution fast. </li> <li> It provides a degree of integrity against unreliable, malicious, or compromised<a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fn:tag">1</a> upstreams: the proxy’s copy of the module is can’t be mutated post facto by the origin, meaning that downstreams that haven’t previously locked their resolution still receive a version that’s consistent. </li> </ol> This second property is really useful, but still requires a degree of trust: if the proxy itself were compromised, it could serve malicious modules to not-yet-locked downstreams. This would be easy for an attacker to do in a precise manner (i.e. target specific victims) as well as difficult to detect, since independent downstrams have no easy way of gossiping amongst themselves about the proxy’s claimed responses. <h2>Transparency<a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#transparency">#</a></h2> In most ecosystems, the situation above (where the index is de jure immutable, but not easily verifiably so) is the norm. However, Go went a step further and introduced the Go <a href="https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md">checksum database</a>, or “sumdb.” Go’s sumdb is a transparency log: an immutable, append-only datastructure that yields cryptographic proofs of inclusion for data entered into it. Russ Cox has a nice <a href="https://research.swtch.com/tlog">explainer on Merkle Trees and transparency log design</a>; it’s also the same basic technology behind <a href="https://certificate.transparency.dev/">Certificate Transparency</a> and <a href="https://www.sigstore.dev">Sigstore</a>, albeit with different properties in each case<a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fn:claimantmodel">2</a>. With this database, Go’s module proxy becomes verifiably monitorable and auditable: the proxy is responsible for obtaining a log entry prior to serving a new module version, and clients can efficiently verify that the entry: <ul> <li>Exists in the log (i.e., the entry is not serving content that it hasn’t committed to).</li> <li>Matches the claimed module content (i.e., the entry is not a valid but unrelated log entry).</li> </ul> In effect, this forces our would-be attacker into the open: they’re still able to upload whatever malicious code they please<a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fn:design">3</a>, but they must commit to doing so in a globally visible manner. <h2>Monitoring<a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#monitoring">#</a></h2> Transparency itself is a useful technique for the game-theoretic reason mentioned above: many attackers want to operate surreptitously and without public evidence, and transparency logs prevent that. However, the mere presence of a transparency log does not foreclose on all possible risks: the log itself needs to be monitored (and audited<a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fn:auditors">4</a>). For example, maintainers want to know if an unexpected release occurs (indicating compromise) or if a release’s contents vary unexpectedly (indicating host/proxy tampering). Similarly, downstreams may wish to monitor their dependencies for unexpected activity. The transparency log operator controls submission to the log, and Go’s sumdb is no exception. This allows the operator to decide what goes into the log: <ul> <li> Every module version exists exactly once in the log. In other words: <code>src.example.com/foo/bar@v1.2.3</code> should have at most exactly one log entry. Uniqueness<a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fn:uniqueness">5</a> is not a native property of Merkle tree-based logs; it’s checked by log auditors. </li> <li> Only the Go proxy itself can submit entries to the log. External users can induce log entry creation by requesting module versions from the proxy, but the proxy is responsible for constructing and submitting the entry in accordance with the log’s policies. </li> </ul> <h2>Flexibility<a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#flexibility">#</a></h2> So, where does that leave us? Recall that a module version is a pair of (module path, version). <a href="https://pkg.go.dev/golang.org/x/mod/module">Per <code>x/mod/module</code></a>, the module path is the substring of a filesystem path in the context of the download cache. However, in the context of the proxy protocol, it’s a URL<a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fn:https">6</a>. In both of these contexts, Go correctly observes that case-sensitivity can’t be assumed: <code>src.example.com/Foo/Bar</code> and <code>src.example.com/foo/bar</code> must be treated as distinct module paths, even if a given filesystem or HTTP server treats them as equivalent. To keep them distinct, Go uses a very small escaping scheme in potentially-insensitive contexts: every uppercase letter is replaced with its lowercase equivalent, prefixed by an exclamation mark (<code>!</code>). This is unambiguous because Go <a href="https://go.dev/ref/mod#go-mod-file-ident">otherwise forbids</a> <code>!</code> in module paths. Using the example above, the module path <code>src.example.com/Foo/Bar</code> becomes <code>src.example.com/!foo/!bar</code> in the proxy protocol and, by extension, in the sumdb. The consequence of this is that there are often multiple valid URL forms that point to the same module version contents. That, in turn, means that there are multiple valid log entries that correspond to the same module version contents…almost. For example, here’s <code>github.com/google/uuid@v1.6.0</code> and <code>github.com/Google/uuid@v1.6.0</code> pulled from the <code>/lookup</code> API: <pre><code><table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 </pre></td><td><pre>% curl https://sum.golang.org/lookup/github.com/google/uuid@v1.6.0 22152757 github.com/google/uuid v1.6.0 h1:NIvaJDMOsjHA8n1jAhLSgzrAzy1Hgr+hNrb57e+94F0= github.com/google/uuid v1.6.0/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo= go.sum database tree 48546416 cEcdZrD3Oio0/tZ9JP2gKMdqeMWAvwiLDx0G2r3MJGI= — sum.golang.org Az3grl3WPuhg73ePSVE8gQId3sd0uJ7PAxsDvyUW8JsPKKTz5JQ96wQNIgsXJGB/wLrtzXoxtXKfrgWJlDsbu7R7YgA= </pre></td></tr></tbody></table></code></pre> and: <pre><code><table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 </pre></td><td><pre>% curl 'https://sum.golang.org/lookup/github.com/!google/uuid@v1.6.0' 22198707 github.com/Google/uuid v1.6.0 h1:2avh7oGmXo3QQBdhUzCNHa3t06F22DZJzaton5Cp5pc= github.com/Google/uuid v1.6.0/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo= go.sum database tree 48547430 nz45epGyfKdGJiU29VkyCZWYt8AvqzpTogcry0Ck9m0= — sum.golang.org Az3grr5LY/709J21wXS58h4kPuL0EUaVLrFdpHpRQiwfY9T7lh3gg71GDs3J40Kg6GDhj3XFEPt4u+6n4npgGNTemAg= </pre></td></tr></tbody></table></code></pre> Observe that the two have different log entry numbers (<code>22152757</code> vs <code>22198707</code>), despite pointing to the same logical module contents. However, they also have different content hashes (the first <code>h1:...</code>), but not different <code>go.mod</code> hashes. This is because the content hash includes the module path as part of its input, while the <code>go.mod</code> hash is the hash of the <code>go.mod</code> file itself, as it appears in the logical module contents. Moreover, we can induce a third log entry by requesting the module version from the proxy using yet another URL form, such as <code>https://proxy.golang.org/github.com/GOOgle/uuid/@v1.</code>: <pre><code><table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 </pre></td><td><pre>% curl 'https://sum.golang.org/lookup/github.com/!g!o!ogle/uuid@v1.6.0' 48547565 github.com/GOOgle/uuid v1.6.0 h1:pwtfSDjGACNyzYVFI0EQMg8KweQ5T+2NrQKJVXoKyj0= github.com/GOOgle/uuid v1.6.0/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo= go.sum database tree 48547566 4x18IY7uNfTK8JVpFSg93+aVFGUoS9slyyVfEn5PRWY= — sum.golang.org Az3grgmqwzBbDjb7ojZhmPLDCyCCAreUMfcQ1b7slVrxhFAS8JpZ8wJvGqZ1FW5a8t/FxUXbnQYD2s/+V7RQICZHHgU= </pre></td></tr></tbody></table></code></pre> This last one took a few seconds to respond<a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fn:sync">7</a>, unlike the other two. As the new log entry number close to the signed tree head indicates, it was created on demand (since I was the first to request it). <h2>Implications<a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#implications">#</a></h2> To tie things together: <ol> <li>Go sumdb log entries are unique per module version;</li> <li>Go module paths (within the module version) are case-sensitive;</li> <li>Module paths are URLs and the path component of URLs is case-indeterminate<a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fn:host">8</a>, meaning that multiple case forms may point to the same module version contents;</li> <li>(1)-(3) mean that the Go proxy can be induced into creating multiple distinct log entries that point to the same module version contents, albeit with different content hashes.</li> </ol> This has a few interesting consequences: <ol> <li> In practice, monitoring a module via the sumdb is not as trivial as monitoring a single representation: the monitor needs to be aware of all valid case forms, which in turn depends on the host. GitHub for example has case-insensitive paths, but other hosts may not. The simplest thing to do is probably to match on any case-folded variant of the module path being monitored, but that may yield false positives if the host is case-sensitive. The main (public) Go module monitor that I’m aware of is <a href="https://www.gopherwatch.org">GopherWatch</a>, which <a href="https://github.com/mjl-/gopherwatch/blob/26fe1de964d2b0ce14cbf0c507ca6757b38f8da6/data.go#L126-L129">intentionally only does case-sensitive comparisons</a>. This is probably a reasonable default for the average user (who is likely monitoring modules on GitHub or GitLab), but it does mean that a malicious case-sensitive host can evade detection. </li> <li> <code>src.example.com/Foo/bar</code> and <code>src.example.com/foo/bar</code> really are distinct modules from Go’s perspective, even though humans have been trained to treat them as the same (thanks to common web URL practices). An attacker could in principle take advantage of this to do something similar to <a href="https://en.wikipedia.org/wiki/Typosquatting">typosquatting</a>, where an innocent-looking rename of <code>src.example.com/acmecorp/widget</code> to <code>src.example.com/AcmeCorp/widget</code> results in completely different module contents. Or in other words: ask yourself if this diff would attract your scrutiny in an otherwise unobjectionable change: <pre><code><table><tbody><tr><td><pre>1 2 </pre></td><td><pre> - import "src.example.com/acmecorp/widget" + import "src.example.com/AcmeCorp/widget" </pre></td></tr></tbody></table></code></pre> What makes this (potentially) more pernicious than “normal” typosquatting is that it looks unobjectionable in a way that normal typosquatting (like <code>src.example.com/acmec0rp/widget</code>) wouldn’t. As evidenced by the log lookups earlier, it’s already common enough for people to use different case forms (e.g. <code>google/uuid</code> and <code>Google/uuid</code> both already having lower entries). In practice, what holds this back is that the attacker would either need to control the host (to ensure that different cases route differently) or find an existing host that does that. GitHub and GitLab both appear to guarantee case-insensitivity, but there may be others that don’t. </li> <li> For a module path containing <code>N</code> non-domain characters in <code>[a-zA-Z]</code>, there are 2N possible case variants. This doesn’t pose a problem for matching within the monitor (we can just compare case-insensitively), but it does pose fatigue and resource risks: <ul> <li> Using <code>src.example.com/acmecorp/widget</code> as an example, there are 214 = 16,384 possible case variants. An attacker who wants to obscure their activity against that module could spam the proxy with requests for those variants, causing alert fatigue (or dropped alerts due to volume) for the monitor. </li> <li> Similarly, the attacker can force the creation of 214 distinct log entries for the same module version, bloating the log and wasting the proxy and log’s compute and network resources. Anybody can already do this by submitting junk modules to the proxy, but this is partcularly bad because it makes amplification relatively easy: the attacker doesn’t have to create any additional modules, and can even use pre-existing innocent module versions. </li> </ul> </li> </ol> Of these, I think (2) is probably the most interesting: (1) is something that monitors can fix by comparing module paths case-insensitively, and (3) is just a griefing vector. The first half of (3) is also probably mitigable by deduplicating on the <code>go.sum</code>’s content hash, since the attacker can’t vary that just by varying the module path’s case. <h2>Concluding thoughts<a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#concluding-thoughts">#</a></h2> Does this matter from a security perspective? I think no, at least not much. The typosquatting-style attack is interesting, but assumes things about the module host that aren’t typically true. Specifically, it assumes a case-sensitive module host where the attacker can in fact register/emplace modules with different case forms. That’s probably uncommon in practice, and any host that’s observed to do this intentionally would probably be worth excluding from the Go module proxy altogether. At the most, it’s a quirk and a reminder of how subtle “identity” can be in a transparency scheme with additional uniqueness properties. Packaging ecosystems that aim to adopt transparency logs in a manner similar to Go’s sumdb will almost certainly run into similar issues. It’s also a great demonstration of how good and thoughtful Go’s packaging design is: the system as a whole lacks ambiguity except where introduced by external interactions (host filesystems, URL paths), and those ambiguities are carefully constrained down to managable levels. <hr> p.s. Thanks to <a href="https://filippo.io">Filippo Valsorda</a> for sanity-checking some of my conclusions here, since I am by no means a Go expert. <hr> <ol> <li> This happens for both innocent and malicious reasons, usually because Git tags are mutable and can be overwritten with a force-push. <a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fnref:tag">↩</a> </li> <li> The semantics of including some data in a transparency log are governed by a <a href="https://transparency.dev/pdfs/claimant-model-tutorial.pdf">claimant model</a>, as well as how clients are expected to interact with that log. For example, interactions with CT logs are generally expected to be “total” in the sense that a leaf certificate that chains up to a public CA should always be logged, and the absence of an entry is a notable signal. In contrast, a packaging ecosystem that adopts Sigstore generally can’t (and shouldn’t) compel every single package to be signed and logged, so the absence of an entry is not necessarily notable absent other context. <a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fnref:claimantmodel">↩</a> </li> <li> This being how open source packaging works by design. <a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fnref:design">↩</a> </li> <li> The difference between a monitor and an auditor is subtle: a monitor observes the log for specific behaviors (e.g. new entries matching some set of claims), while an auditor verifies the integrity/correctness of the log itself (e.g. ensuring the log is actually consistent and append-only). <a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fnref:auditors">↩</a> </li> <li> While writing this, I tried to find an resource that actually documents this property as guaranteed, but I couldn’t! However, it’s implied by the sumdb’s lookup API, which can only return a single entry per module version. It’s also mentioned indirectly in <a href="https://raphting.dev/posts/gosumdb-live-again/">this blog post on raphting.dev</a> and in Martin Hutchinson’s <a href="https://github.com/mhutchinson/sumdb-audit"><code>sumdb-audit</code></a> tool. The uniqueness check is also visible in the <a href="https://cs.opensource.google/go/x/mod/+/refs/tags/v0.31.0:sumdb/test.go;l=96-101">TestServer in x/mod/sumdb</a>. After discussion with Filippo, I understand why this isn’t ever described as “guaranteed”: uniqueness is a property that’s enforced by auditors, the log cannot itself guarantee it. <a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fnref:uniqueness">↩</a> </li> <li> The <code>https://</code> is implied. <a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fnref:https">↩</a> </li> <li> Unlike Certificate Transpareny, Go’s sumdb inclusion is synchronous: the proxy blocks until the log entry is actually fully included, instead of yielding a promise to include it later. I suspect the proxy is additionally fully fetching the module itself for hashing, which adds more synchronous delay. <a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fnref:sync">↩</a> </li> <li> In the sense that the path component of a URL is case sensitive, but that it’s up to the handling HTTP server/host to determine how it handles case sensitivity. <a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb#fnref:host">↩</a> </li> </ol> <hr> Discussions: <a href="https://www.reddit.com/r/enosuchblog/comments/1pypbhh/some_flexibility_with_gos_sumdb/">Reddit</a> <a href="https://infosec.exchange/@yossarian/115803589597737254">Mastodon</a> <a href="https://bsky.app/profile/yossarian.net/post/3mb55zn6bqj2u">Bluesky</a> <hr> <a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux">Previously</a> <a href="https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage">Newer</a> </body> Mon, 29 Dec 2025 00:00:00 UTC