ENOSUCHBLOG

ENOSUCHBLOGProgramming, philosophy, pedaling.Registering my dissatisfaction with GitHubhttps://blog.yossarian.net/2026/04/29/Registering-my-dissatisfaction-with-GitHubMini-post.<body morss_own_score="2.5356037151702786" morss_score="36.02874435365173"> <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> </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 UTCDependency cooldowns, reduxhttps://blog.yossarian.net/2025/12/13/cooldowns-reduxThree weeks ago I wrote about how we should all be using dependency cooldowns.<body morss_own_score="2.592233009708738" morss_score="76.07895404228734"> <h1>ENOSUCHBLOG</h1> <h2>Programming, philosophy, pedaling.</h2> <hr> <h1> <a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux">Dependency cooldowns, redux</a> </h1> Dec 13, 2025 Tags: <a href="https://blog.yossarian.net/tags#oss">oss</a>, <a href="https://blog.yossarian.net/tags#security">security</a> <hr> Three weeks ago I wrote about how <a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns">we should all be using dependency cooldowns</a>. This got a lot of attention, which is great! So I figured I owe you, dear reader, an update with (1) some answers to common questions I’ve received, and (2) some updated on movements in large open source ecosystems since the post’s publication. <h2>Common questions and answers<a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#common-questions-and-answers">#</a></h2> Question: Aren’t cooldowns a self-defeating policy? In other words: if everyone uses cooldowns wouldn’t we be in the exact same situation, just shifted back by the cooldown period? Answer: I think there are two parts to this: <ol> <li> The observation in the original post is that there are parties other than downstreams in the open source ecosystem, namely secuity partners (vendors) and index maintainers themselves. These parties have strong incentives to proactively monitor, report, and remove malicious packages from the ecosystem. Most importantly, these incentives are timely, even when user installations are not. </li> <li> Even with a universal exhortation to use cooldowns, I think universal adoption is clearly not realistic: there are always going to be people who live at the edge. If those people want to be the proverbial canaries in the coal mine, that’s their prerogative! Or in other words, we certainly all should be using cooldowns, but clearly that’s never going to happen. </li> </ol> <hr> Question: What about security updates? Wouldn’t cooldowns delay important security patches? Answer: I guess so, but you shouldn’t do that! Cooldowns are a policy, and all policies have escape hatches. The original post itself notes an important escape hatch that already exists in how cooldowns are implemented in tools like Dependabot: cooldowns don’t apply to security updates. In other words: ecosystems that are considering implementing cooldowns directly in their packaging tools should make sure that users can encode exceptions<a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#fn:exceptions">1</a> as necessary. <hr> Question: Doesn’t this incentivize attackers to abuse the vulnerability disclosure process? In other words, what stops an attacker from reporting their own malicious release as a vulnerability fix in order to bypass cooldowns? Answer: Nothing, in principle: this certainly does make vulnerability disclosures themselves an attractive mechanism for bypassing cooldowns. However, in practice, I think an attacker’s ability to do this is limited by (at least) three factors: <ol> <li> Creating a public vulnerability disclosure on a project (e.g. via <a href="https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories">GitHub Security Advisories</a>) generally requires a higher degree of privilege/comprehensive takeover than simply publishing a malicious version. Specifically: most of the malicious publishing activity we’ve seen thus far involves a compromised long-lived publishing credential (e.g. an npm or PyPI API token), rather than full account takeover. We might seek that kind of full ATO in the future, but it’s a significantly higher bar (particularly in the presence of in-session MFA challenges on GitHub). </li> <li> The name of the game continues to be maximizing the window of opportunity, which is often shorter than a single day. At this timescale, hours are significant. But fortunately<a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#fn:fortunate">2</a> for us, propagating a public vulnerability disclosure takes a nontrivial amount of time: CVEs take a nontrivial amount of time to assign<a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#fn:ghsa">3</a>, and ecosystem-level propagation of vulnerability information (e.g. into RUSTSEC or PYSEC) typically happens on the timeframe of hours (via scheduled batch jobs). Consequently, abusing the vulnerability disclosure process to bypass cooldowns requires the attacker to shorten their window of opportunity, which isn’t in their interest. That doesn’t mean they won’t do it (especially as the update loop between advisories and ecosystem vulnerability databases gets shorter), but it does stand to reason that it disincentivizes this kind of abuse to some degree. </li> <li> Stealth. Creating a public vulnerability disclosure is essentially a giant flashing neon sign to security-interested parties to look extremely closely at a given release. More specifically, it’s a signal to those parties that they should diff the new release against the old (putatively vulnerable) one, to look for the vulnerable code. This is the exact opposite of what the attacker wants: they’re trying to sneak malicious code into the new release, and are trying to avoid drawing attention to it. </li> </ol> <hr> Question: What about opportunistic abuse of the vulnerability disclosure process? For example, if <code>1.2.3</code> is vulnerable and <code>1.2.4</code> is a legitimate security update, what stops the attacker from publishing <code>1.2.5</code> with malicious code immediately after <code>1.2.4</code>? Answer: This is a great example of why cooldown policies (and their bypasses) struggle to be universal without human oversight. Specifically, it demonstrates why bypasses should probably be minimal by default: if both <code>1.2.4</code> and <code>1.2.5</code> claim to address a vulnerability and both require bypassing the cooldown, then selecting the lower version is probably the more correct choice in an automatic dependency updating context. <hr> <h2>Ecosystem updates<a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#ecosystem-updates">#</a></h2> This is a somewhat free-form section for ecosystem changes I’ve noticed since the original post. If there are others I’ve missed, please let me know! <h3>Python<a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#python">#</a></h3> <ul> <li> <a href="https://docs.astral.sh/uv/">uv</a> has added support for dependency cooldowns via relative <code>--exclude-newer</code> values. Recently released versions of uv already include this feature. For example, a user can do <code>--exclude-newer=P7D</code> to exclude any dependency updates published within the last seven days. Documentation: <a href="https://docs.astral.sh/uv/concepts/resolution/#dependency-cooldowns">uv - dependency cooldowns</a>. References: <a href="https://github.com/astral-sh/uv/pull/16814">astral-sh/uv#16814</a> </li> <li> <a href="https://pip.pypa.io/en/stable/">pip</a> is adding an absolute point-in-time feature via <code>--uploaded-prior-to</code>. This is currently slated to be released with pip 26, i.e. early next year. In addition to the “absolute” cooldown feature above, pip is also considering adding a relative cooldown feature similar to uv’s. This is being tracked in <a href="https://github.com/pypa/pip/issues/13674">pypa/pip#13674</a>. References: <a href="https://github.com/pypa/pip/pull/13625">pypa/pip#13625</a>, <a href="https://github.com/pypa/pip/issues/13674">pypa/pip#13674</a> </li> </ul> <h3>Rust<a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#rust">#</a></h3> <ul> <li>cargo is discussing a design for cooldowns in <a href="https://github.com/rust-lang/cargo/issues/15973">rust-lang/cargo#15973</a>. This discussion predates my blog post, but appears to have been reinvigorated by it.</li> </ul> <h3>Ruby<a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#ruby">#</a></h3> <ul> <li>There’s been some discussion in the Bundler community Slack about adding cooldowns directly to the <a href="https://gem.coop">gem.coop</a> index, e.g. providing index “views” like <code>/view/cooldown/7d/</code> for index-level cooldowns. I think this is a very cool approach!</li> </ul> <h3>.NET<a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#net">#</a></h3> <ul> <li>The NuGet community is discussing a cooldown design in <a href="https://github.com/NuGet/Home/issues/14657">NuGet/Home#14657</a>.</li> </ul> <h3>JavaScript<a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#javascript">#</a></h3> <ul> <li> pnpm has had cooldowns since <a href="https://pnpm.io/blog/releases/10.16">September with v10.16</a>, with <a href="https://pnpm.io/settings#minimumreleaseage"><code>minimumReleaseAge</code></a>! They even have a cooldown exclusion feature. </li> <li> yarn added cooldown support one month after pnpm, via <a href="https://yarnpkg.com/configuration/yarnrc#npmMinimalAgeGate"><code>npmMinimalAgeGate</code></a> </li> <li> npm does not have cooldown support yet. There appear to be several discussions about it, some of which date back years. <a href="https://github.com/npm/rfcs/issues/646">npm/rfcs#646</a> and <a href="https://github.com/npm/cli/issues/8570">npm/cli#8570</a> appear to have most of the context. <a href="https://github.com/npm/cli/pull/8802">npm/cli#8802</a> is also open adding an implementation of the above RFC. </li> </ul> <h3>Go<a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#go">#</a></h3> <ul> <li>Go is discussing the feasibility/applicability of cooldowns in <a href="https://github.com/golang/go/issues/76485">golang/go#76485</a>.</li> </ul> <h3>GitHub Actions<a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#github-actions">#</a></h3> <ul> <li> <a href="https://github.com/suzuki-shunsuke/pinact">pinact</a> has added a <a href="https://github.com/suzuki-shunsuke/pinact#skip-recently-released-versions"><code>--min-age</code> flag</a> to support cooldowns for GitHub Actions dependencies. </li> <li> Renovate and Dependabot already do a decent job of providing cooldowns for GitHub Actions updates, including support for hash-pinning and updating the associated version comment. </li> </ul> <h3>pre-commit<a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#pre-commit">#</a></h3> <ul> <li> <a href="https://github.com/j178/prek">prek</a> (a pre-commit implementation in Rust) has added a <code>--cooldown-days</code> option in <a href="https://github.com/j178/prek/releases/tag/v0.2.22">release 0.2.22</a> Thanks to <a href="https://github.com/hugovk">Hugo van Kemenade</a> for pointing this out to me! </li> </ul> <hr> <ol> <li> Security updates are the most obvious exception, but it also seems reasonable to me to allow people to encode exceptions for data-only dependencies, first-party dependencies, trusted dependencies, and so forth. It’s clearly a non-trivial and non-generalizable problem! <a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#fnref:exceptions">↩</a> </li> <li> For some definition of “fortunate”: clearly we want TTLs for vulnerability disclosures to be as short as possible in normal, non-malicious circumstances! <a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#fnref:fortunate">↩</a> </li> <li> Unlike GHSAs, which are typically assigned instantly. For better or worse however, CVE IDs continue to be the “reference” identifier for ecosystem-level vulnerability information propagation. <a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux#fnref:ghsa">↩</a> </li> </ol> <hr> Discussions: <a href="https://www.reddit.com/r/enosuchblog/comments/1plq3rm/dependency_cooldowns_redux/">Reddit</a> <a href="https://infosec.exchange/@yossarian/115713309903454408">Mastodon</a> <a href="https://bsky.app/profile/yossarian.net/post/3m7v336n7on2q">Bluesky</a> <hr> <a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns">Previously</a> <a href="https://blog.yossarian.net/2025/12/29/Some-flexibility-with-Go-s-sumdb">Newer</a> </body> Sat, 13 Dec 2025 00:00:00 UTCWe should all be using dependency cooldownshttps://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldownsTL;DR: Dependency cooldowns are a free, easy, and incredibly effective way to mitigate the large majority of open source supply chain attacks. More individual projects should apply cooldowns (via tools like Dependabot and Renovate) to their dependencies, and packaging ecosystems should invest in first-class support for cooldowns directly in their package managers.<body morss_own_score="2.632867132867133" morss_score="70.54671165902025"> <h1>ENOSUCHBLOG</h1> <h2>Programming, philosophy, pedaling.</h2> <hr> <h1> <a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns">We should all be using dependency cooldowns</a> </h1> Nov 21, 2025 Tags: <a href="https://blog.yossarian.net/tags#oss">oss</a>, <a href="https://blog.yossarian.net/tags#security">security</a> <hr> TL;DR: Dependency cooldowns are a free, easy, and incredibly effective way to mitigate the large majority of open source supply chain attacks. More individual projects should apply cooldowns (via tools like Dependabot and Renovate) to their dependencies, and packaging ecosystems should invest in first-class support for cooldowns directly in their package managers. Some resources for adding cooldowns: See <a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux">part two</a> as well for some responses to common questions about this post, as well as updates on how various ecosystems have adopted cooldowns. <hr> “Supply chain security” is a serious problem. It’s also seriously overhyped, in part because dozens of vendors have a vested financial interest in convincing your that their framing of the underlying problem<a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns#fn:problem">1</a> is (1) correct, and (2) worth your money. What’s consternating about this is that most open source supply chain attacks have the same basic structure: <ol> <li> An attacker compromises a popular open source project, typically via a stolen credential or CI/CD vulnerabilty (such as <a href="https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/">“pwn requests”</a> in GitHub Actions). </li> <li> The attacker introduces a malicious change to the project and uploads it somewhere that will have maximum effect (PyPI, npm, GitHub releases, &c., depending on the target). At this point, the clock has started, as the attacker has moved into the public. </li> <li> Users pick up the compromised version of the project via automatic dependency updates or a lack of dependency pinning. </li> <li> Meanwhile, the aforementioned vendors are scanning public indices as well as customer repositories for signs of compromise, and provide alerts upstream (e.g. to PyPI). Notably, vendors are incentivized to report quickly and loudly upstream, as this increases the perceived value of their services in a crowded field. </li> <li> Upstreams (PyPI, npm, &c.) remove or disable the compromised package version(s). </li> <li> End-user remediation begins. </li> </ol> The key thing to observe is that the gap between (1) and (2) can be very large<a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns#fn:gap">2</a> (weeks or months), while the gap between (2) and (5) is typically very small: hours or days. This means that, once the attacker has moved into the actual exploitation phase, their window of opportunity to cause damage is pretty limited. <img src="https://blog.yossarian.net/assets/supply-chain-attack-timeline.png"> We can see this with numerous prominent supply chain attacks over the last 18 months<a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns#fn:filippo">3</a>: <table> <thead> <tr> <th>Attack</th> <th>Approx. Window of Opportunity</th> <th>References</th> </tr> </thead> <tbody> <tr> <td>xz-utils</td> <td>≈ 5 weeks<a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns#fn:outlier">4</a></td> <td><a href="https://research.swtch.com/xz-timeline">Source</a></td> </tr> <tr> <td>Ultralytics (phase 1)</td> <td>12 hours</td> <td><a href="https://blog.yossarian.net/2024/12/06/zizmor-ultralytics-injection#appendix-rough-timeline-of-events">Source</a></td> </tr> <tr> <td>Ultralytics (phase 2)</td> <td>1 hour</td> <td><a href="https://blog.yossarian.net/2024/12/06/zizmor-ultralytics-injection#appendix-rough-timeline-of-events">Source</a></td> </tr> <tr> <td>tj-actions</td> <td>3 days</td> <td><a href="https://www.legitsecurity.com/blog/github-actions-tj-actions-changed-files-attack">Source</a></td> </tr> <tr> <td>chalk</td> <td>< 12 hours</td> <td><a href="https://cycode.com/blog/npm-debug-chalk-supply-chain-attack-the-complete-guide/">Source</a></td> </tr> <tr> <td>Nx</td> <td>4 hours</td> <td><a href="https://www.stepsecurity.io/blog/supply-chain-security-alert-popular-nx-build-system-package-compromised-with-data-stealing-malware">Source</a></td> </tr> <tr> <td>rspack</td> <td>1 hour</td> <td><a href="https://github.com/web-infra-dev/rspack/releases/tag/v1.1.8">Source</a></td> </tr> <tr> <td>num2words</td> <td>< 12 hours</td> <td><a href="https://blog.pypi.org/posts/2025-07-31-incident-report-phishing-attack/#impact-analysis">Source</a></td> </tr> <tr> <td>Kong Ingress Controller</td> <td>≈ 10 days</td> <td><a href="https://konghq.com/blog/product-releases/december-2024-unauthorized-kong-ingress-controller-3-4-0-build">Source</a></td> </tr> <tr> <td>web3.js</td> <td>5 hours</td> <td><a href="https://threats.wiz.io/all-incidents/solana-web3js-supply-chain-attack">Source</a></td> </tr> </tbody> </table> (Each of these attacks has significant downstream effect, of course, but only within their window of opportunity. Subsequent compromises from each, like <a href="https://www.wiz.io/blog/shai-hulud-npm-supply-chain-attack">Shai-Hulud</a>, represent new windows of opportunity where the attackers regrouped and pivoted onto the next set of compromised credentials.) My takeaway from this: some windows of opportunity are bigger, but the majority of them are under a week long. Consequently, ordinary developers can avoid the bulk of these types of attacks by instituting cooldowns on their dependencies. <h2>Cooldowns<a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns#cooldowns">#</a></h2> A “cooldown” is exactly what it sounds like: a window of time between when a dependency is published and when it’s considered suitable for use. The dependency is public during this window, meaning that “supply chain security” vendors can work their magic while the rest of us wait any problems out. I love cooldowns for several reasons: <ul> <li> They’re empirically effective, per above. They won’t stop all attackers, but they do stymie the majority of high-visibiity, mass-impact supply chain attacks that have become more common. </li> <li> They’re incredibly easy to implement. Moreover, they’re literally free to implement in most cases: most people can use <a href="https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cooldown-">Dependabot’s functionality</a>, <a href="https://docs.renovatebot.com/key-concepts/minimum-release-age/">Renovate’s functionality</a>, or the functionality build directly into their package manager<a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns#fn:pkgmanager">5</a>. This is how simple it is in Dependabot: <pre><code><table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 </pre></td><td><pre> version: 2 # update once a week, with a 7-day cooldown - package-ecosystem: github-actions directory: / schedule: interval: weekly cooldown: default-days: 7 </pre></td></tr></tbody></table></code></pre> (Rinse and repeat for other ecosystems as needed.) </li> <li> Cooldowns enforce positive behavior from supply chain security vendors: vendors are still incentivized to discover and report attacks quickly, but are not as incentivized to emit volumes of blogspam about “critical” attacks on largely underfunded open source ecosystems. </li> </ul> <h2>Concluding / assorted thoughts<a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns#concluding--assorted-thoughts">#</a></h2> In the very small sample set above, 8/10 attacks had windows of opportunity of less than a week. Setting a cooldown of 7 days would have prevented the vast majority of these attacks from reaching end users (and causing knock-on attacks, which several of these were). Increasing the cooldown to 14 days would have prevented all but 1 of these attacks<a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns#fn:apt">6</a>. Cooldowns are, obviously, not a panacea: some attackers will evade detection, and delaying the inclusion of potentially malicious dependencies by a week (or two) does not fundamentally alter the fact that supply chain security is a social trust problem, not a purely technical one. Still, an 80-90% reduction in exposure through a technique that is free and easy seems hard to beat. Related to the above, it’s unfortunate that cooldowns aren’t baked directly into more packaging ecosystems: Dependabot and Renovate are great, but even better would be if the package manager itself (as the source of ground truth) could enforce cooldowns directly (including of dependencies not introduced or bumped through automated flows). <hr> <ol> <li> The problem being, succinctly: modern software stacks are complex and opaque, with little to no difference in privilege between first-party code and third-party dependencies. <a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns#fnref:problem">↩</a> </li> <li> In part because of the prevalence of long-lived, overscoped credentials. Long-lived credentials let attackers operate on their own (comfortable) timelines; this is why <a href="https://docs.pypi.org/trusted-publishers/">Trusted Publishing</a> is such a useful (but not wholly sufficient) technique for reducing the attacker’s attack staging window. <a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns#fnref:gap">↩</a> </li> <li> Filippo Valsorda has an excellent compilation of recent supply chain compromises <a href="https://words.filippo.io/compromise-survey/">here</a>. <a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns#fnref:filippo">↩</a> </li> <li> The xz-utils attack is a significant outlier, both in its scope and the length of its window of opportunity. In this case, I’ve measured from the attacker’s first backdoored release (v5.6.0, 2024-02-24) to the time of rollback within Debian (2024-03-28). <a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns#fnref:outlier">↩</a> </li> <li> For example, pnpm’s <a href="https://pnpm.io/settings#minimumreleaseage"><code>minimumReleaseAge</code></a>. uv also has <a href="https://docs.astral.sh/uv/guides/scripts/#improving-reproducibility"><code>exclude-newer</code></a>, although this specifies an absolute cutoff rather than a rolling cooldown. <a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns#fnref:pkgmanager">↩</a> </li> <li> Notably, the only attack that would have stymied a 14-day cooldown is xz-utils, which is also the most technically, logistically, and socially advanced of all of the attacks. <a href="https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns#fnref:apt">↩</a> </li> </ol> <hr> Discussions: <a href="https://www.reddit.com/r/enosuchblog/comments/1p30gsd/we_should_all_be_using_dependency_cooldowns/">Reddit</a> <a href="https://infosec.exchange/@yossarian/115588225552391270">Mastodon</a> <a href="https://bsky.app/profile/yossarian.net/post/3m65jjftw6q2j">Bluesky</a> <hr> <a href="https://blog.yossarian.net/2025/09/22/dear-github-no-yaml-anchors">Previously</a> <a href="https://blog.yossarian.net/2025/12/13/cooldowns-redux">Newer</a> </body> Fri, 21 Nov 2025 00:00:00 UTC