nesbitt.io

Latest posts

• 100 Posts

  Mar 09, 2026Andrew Nesbitt

  I didn’t expect to make it here. Back in November 2025 I was on a call talking about how we should document more of how package managers work so people can more easily build tools to consume the data within them, and one attendee suggested we didn’t need to do that because their open source software provided everything you would need. This was pretty frustrating, so started rage documenting packag

• If It Quacks Like a Package Manager

  Mar 08, 2026Andrew Nesbitt

  I spend a lot of time studying package managers, and after a while you develop an eye for things that quack like one. Plenty of tools have registries, version pinning, code that gets downloaded and executed on your behalf. But flat lists of installable things aren’t very interesting. The quacking that catches my ear is when something develops a dependency graph: your package depends on a package t

• Announcing New Working Groups

  Mar 07, 2026Andrew Nesbitt

  FOR IMMEDIATE RELEASE Contact: [email protected] Subject: Open Source Foundations Consortium Announces Seven New Working Groups Embargo: None The Open Source Foundations Consortium (OSFC) has formed seven new working groups for open source ecosystem governance. The working groups were approved by the OSFC Steering Committee following a six-month consultation period during which fourteen comm

• .gitlocal

  Mar 06, 2026Andrew Nesbitt

  I was building a CLI tool that records sensitive info in a dot folder, and went looking for best practices to avoid those folders being accidentally committed to git. To my surprise, git doesn’t really provide a way for tool builders to declare that their files shouldn’t be committed. That got me thinking: what if there was a file you could drop in your dot folder, or a comment you could add to th

• Package Manager Magic Files

  Mar 05, 2026Andrew Nesbitt

  A follow-up to my post on git’s magic files. Most package managers have a manifest and a lockfile, and most developers stop there. But across the ecosystems I track on ecosyste.ms, package managers check for dozens of other files beyond the manifest and lockfile, controlling where packages come from, what gets published, how versions resolve, and what code runs during installation. These files ten

• Package Managers Need to Cool Down

  Mar 04, 2026Andrew Nesbitt

  This post was requested by Seth Larson, who asked if I could do a breakdown of dependency cooldowns across package managers. His framing: all tools should support a globally-configurable exclude-newer-than=<relative duration> like 7d, to bring the response times for autonomous exploitation back into the realm of human intervention. When an attacker compromises a maintainer’s credentials or takes o

• Package Management is Naming All the Way Down

  Mar 03, 2026Andrew Nesbitt

  Package managers are usually described by what they do: resolve dependencies, download code, build artifacts. But if you look at the structure of the system instead of the process, nearly every part of it is a naming problem, and the whole thing works because we’ve agreed on how to interpret strings at each layer and because a registry sits in the middle translating between them. Registries When y

• Transitive Trust

  Mar 02, 2026Andrew Nesbitt

  Ken Thompson’s 1984 Turing Award lecture, Reflections on Trusting Trust, described a C compiler modified to insert a backdoor into the login program, then modified again so the compiler would replicate the backdoor in future versions of itself without any trace in the source. The source was clean, the binary was compromised, and the only way to discover the backdoor was to rebuild the entire compi

• Downstream Testing

  Mar 01, 2026Andrew Nesbitt

  The information about how a library is actually used lives in the dependents’ code, not in the library’s own tests or docs. Someone downstream is parsing your error messages with a regex, or relying on the iteration order of a result set you never documented, or depending on a method you consider internal because it wasn’t marked private in a language that doesn’t enforce visibility. Hyrum’s Law s

• npm Data Subject Access Request

  Feb 28, 2026Andrew Nesbitt

  From: Data Protection Officer, npm, Inc. (a subsidiary of GitHub, Inc., a subsidiary of Microsoft Corporation) To: [REDACTED] Date: 26 February 2026 Re: Data Subject Access Request (Ref: DSAR-2026-0041573) Response deadline: Exceeded (statutory: 30 days) Dear Data Subject, Thank you for your request under Article 15 of the General Data Protection Regulation (EU) 2016/679 to access all personal dat