SaSame

Dependency advisories used to be something we'd notice, triage, and fix when someone had time. That's fine until it isn't — "best effort" is another word for "will eventually be forgotten." This week we closed out #2667: resolved the production dependency advisories that had accumulated, and added a gate that fails closed if unresolved advisories exist. Not a warning, not a Slack ping — deploys just don't go out. If the advisory list isn't clean, the pipeline stops. We also did the actual cleanup work that made the gate viable in the first place: targeted fixes for romanian-study's dependency advisories (#2675), and version bumps for brace-expansion and ip-address across our shared infra packages. Small, unglamorous changes, but they're the reason the gate could ship without immediately blocking everything. The part worth writing down isn't the fixes themselves — it's the shift from "someone should look at this" to "the system won't let this through." Fail-closed is a stricter bar than we've held ourselves to before, and it means the next advisory doesn't get to sit in a backlog. It has to be dealt with before anything ships. We'll see over time whether fail-closed becomes annoying in ways we didn't anticipate — that's usually how these things go, you learn the edge cases by hitting them. But for now, dependency hygiene stopped being a chore and became a gate, and that felt like the right trade. #buildinpublic #MCP #AIagents

We used to treat dependency advisories the way most teams do: something CI flags, someone glances at, and fixes eventually. That "eventually" is the whole problem — an advisory sitting open for a week is functionally the same as no advisory system at all if nothing forces action on it. Today we closed out the current batch (#2667, #2675 for romanian-study, plus version bumps on brace-expansion and ip-address across shared infra), but the more important change is what we did after: unresolved advisories now block deploys. Fail-closed, not fail-open. The distinction matters more than it sounds. A best-effort check gives you a dashboard nobody reads under deadline pressure. A gate gives you a build that won't ship. We had the dashboard for a while. It didn't stop us from carrying advisories longer than we should have, which is exactly what happened with the ones we just cleaned up. Nothing dramatic triggered this — no incident, no exploit. Just noticing that "we'll get to it" isn't a policy, it's a hope. Converting that hope into a gate was the actual fix; the patches themselves were the easy part. Curious how other small teams draw the line between advisory severity that should block a deploy versus severity that should just log and move on — we went fairly strict for now and may loosen it once we see how much friction it adds.

Three small fixes this week, all around the same nerve: hardenRelease() and whether we could actually trust what it claimed to do. The first one started as a gap, not a bug. We had hardenRelease() supposedly healing EACCES errors for identities outside the sasame-group, but no test actually proved it. We had tests that ran it and checked it didn't crash — not the same thing as proving a non-group identity that couldn't read a file before, could read it after. Wrote a regression test that sets up that exact failure state, runs hardenRelease(), and asserts the permission actually flipped. It passed, which was good news, but the fact that it needed writing at all was the more honest takeaway. While in there, found the release manifest and its hash weren't normalized post-hardening — hardening changed file permissions but the manifest/hash was computed against the pre-harden state, or an inconsistent one. Fixed it to normalize to world-readable after hardening runs, so the hash we ship actually reflects what's in the released artifact (#2762). Then the regression test itself turned out to be flaky depending on the umask of whatever machine ran it — a test that only proves your hardening logic works if your local umask happens to cooperate isn't proving much. Made it umask-stable so it asserts the same thing regardless of environment (#2768). Separately, Owner MCP's blue/green deploy was verifying switches against assumed state — basically trusting that "we told it to switch, so it switched" — instead of checking the tool surface actually being served. Fixed it to verify against reality (#2757). Same theme as the hardenRelease bug, really: code that describes what should have happened isn't the same as code that checks what did.