DEV Community: Dhruv Agrawal

How a Trusted Extension Name Delivered an SSH Backdoor Through Cursor's Store

Dhruv Agrawal — Mon, 02 Nov 2026 05:32:13 +0000

On October 29, Cursor's extension marketplace served tampered builds of Anthropic's Claude Code extension, versions 2.1.312 and 2.1.313. They were live for about 11 hours. They added an attacker's SSH key to developers' machines.

Anthropic's systems were not breached. The official package was not breached either. The attacker, Anthropic said, "used access to Cursor's marketplace." In a statement quoted by BankInfoSecurity, Cursor said at most 5,000 users were affected.

To see how that is possible, follow the path an extension takes to your editor.

Delivery chain as described in Cursor's extension docs. The incident shows only that the copy Cursor's marketplace served was tampered with.

The delivery chain

Cursor is built on VS Code. It does not use Microsoft's extension marketplace. Its docs say it gets third-party extensions from Open VSX, an open extension registry. Downloads pass through Cursor's own marketplace proxy, which scans them for malware before serving them.

So a Claude Code update reaches you in four hops:

Anthropic builds and publishes the extension.
A registry stores it.
Cursor's marketplace serves it under the name anthropic.claude-code.
Your editor installs it and loads it.

You see the name at step 3. At step 4, your editor runs whatever step 3 served. If someone can change those bytes, the name still looks right.

What the tampered build did

StepSecurity compared a malicious build with the clean one. Its tampered extension.js was the official 2.1.312 bundle with a 7,386-byte loader added to the front. The file was about 3.6 MB. As StepSecurity put it, "The malicious build is the official extension in every respect except one."

In the 2.1.313 build, the new version number appeared only in the repackaged manifest. That made it look like a routine update.

The loader runs as soon as the editor loads the extension. No Claude conversation is needed. VS Code's own docs explain why that matters: "The extension host has the same permissions as VS Code itself." An extension can read your files, use the network and start processes.

Loader stages as listed in StepSecurity's analysis.

According to StepSecurity, the loader then ran six stages:

collected host details and the names of up to 40 secret-looking environment variables
added an attacker key to ~/.ssh/authorized_keys
tried to turn on the SSH server
tried to open a reverse SSH tunnel, retrying every 60 seconds
set up persistence so the tunnel restarts after a reboot or login
reported back to the attacker's server

StepSecurity says no credential values were read. Cursor notes that enabling SSH usually needs admin rights. The key and persistence could still land without them.

The evidence

Cursor's notice gives the window: about 2:27am to 1:35pm Pacific on October 29. Cursor removed the malicious versions, took its marketplace offline, rebuilt it and rotated keys. The Hacker News reports that Microsoft said the build was never published on the Visual Studio Marketplace or npm. StepSecurity verified the Open VSX copy of 2.1.312 as clean.

How the attacker got access to Cursor's marketplace has not been disclosed.

What to do

Check, don't assume. If you installed or updated Claude Code from Cursor's marketplace that day, follow Cursor's check steps. Look in authorized_keys for a key labelled svc-telemetry.
Updating is not cleaning. Anthropic has released 2.1.314. But security researcher Kevin Beaumont noted that the replacement versions, which auto-update, "do not remove the prior backdoors." Persistence and the SSH key must be removed by hand.
Add an install cooldown. Cursor lets team admins delay installs and updates until a version has been public for a set number of hours. The default is 0, meaning off. The malicious versions were live for about 11 hours.
Turn on signature checks if you can. Cursor lets Enterprise teams require valid Open VSX extension signatures before install.

Where this breaks down

The root cause is unknown, so the fixes above are guesses about which layer failed. No source says whether signature checking would have caught this build. That depends on whether the attacker could also sign or bypass signing, which nobody has said.

A cooldown helps only if someone spots the bad build before the delay runs out. It also delays good security fixes.

The weakest part of this post is its general lesson. Any store that serves you code could be the weak hop. But the evidence covers one incident in one marketplace, and its root cause is still undisclosed.

Takeaway

The extension name tells you who should have written the code. It does not tell you who last touched the bytes.

Which hops sit between your editor and the publishers you trust?

Sources

Cursor, Security notice: malicious version of Anthropic.claude-code (October 29, 2026, updated October 30)
StepSecurity, Trojanized Claude Code extension delivered persistent SSH backdoor (October 30, 2026)
The Hacker News, Official Claude Code VS Code extension trojanized (October 30, 2026)
BankInfoSecurity, Cursor confirms Anthropic Claude Code extension compromised (October 30, 2026)
Cursor, Extensions documentation (accessed November 2, 2026)
Visual Studio Code, Extension runtime security (accessed November 2, 2026)

How PyTorch Became the Socket Every AI Chip Plugs Into

Dhruv Agrawal — Wed, 28 Oct 2026 03:03:41 +0000

On 19 October, AWS released TorchNeuron, which lets PyTorch run directly on its Trainium chips. A day later, Google and Meta released TorchTPU, which does the same for Google's TPUs. Both arrived at the PyTorch Conference, both are open source, and both connect to PyTorch through the same small hook.

That last part is the story. Two companies with no reason to coordinate reached the same conclusion: the road onto a working engineer's laptop runs through one extension point in PyTorch.

What happens when you call `.to("cuda")`

Write a + b on two tensors and PyTorch does not immediately add anything. It looks up a name, aten::add, in a table.

The part doing that lookup is called the dispatcher. It checks where the tensors live, reads a label off them — CPU, CUDA, and so on — and uses it to pick the function that actually does the addition on that hardware. Those hardware-specific functions are called kernels. A backend is a full set of kernels filed under one label.

PyTorch keeps one label deliberately empty: PrivateUse1. Any hardware vendor can claim it and register their kernels against it from their own repository, without needing their code accepted into PyTorch itself. TorchTPU registers there. TorchNeuron uses the same registration mechanism. A new chip becomes a new label, and model.to("tpu") is what that looks like from your code.

A backend is a set of kernels filed under one dispatch label. TorchTPU names PrivateUse1; AWS says only "PyTorch's built-in mechanism for registering new hardware". Sources: PyTorch blog; Amazon; InfoQ.

This replaces something clumsier. PyTorch on TPUs used to go through JAX, Google's other framework. The TorchTPU team is blunt: the old approach "shoehorn[ed] PyTorch into JAX's modus operandi." The new backend has no JAX in it at runtime, and it runs operations one at a time as you write them, which is how most people debug. The chip speaks PyTorch now, instead of being translated first.

The coverage looks real. Google tested 4,917 models from Hugging Face: 98% ran without crashing, and of those it checked closely, 97% produced the same numbers a GPU would. Amazon says it tests TorchNeuron against hundreds of thousands of models on every build.

Running is the easy half

Here is the TorchTPU team's own framing, caveat included:

"Porting a workload to TPU should be as simple as changing model.to("cuda") to model.to("tpu"). (One cannot achieve peak TPU performance with that simple change... however, the model should run out of the box.)"

Read the bit in brackets, because that is where the work actually is.

Illustrative: the bar shows the direction of each documented caveat, not a measured benchmark. Source: PyTorch blog, TorchTPU.

The numbers come out different. On CUDA, PyTorch multiplies in full 32-bit precision by default. TorchTPU defaults to a faster, lower-precision mode. Your model runs. Its output drifts.
The default network settings cost a third of your speed. TorchTPU ships with an option called "Skinny Collectives" switched on, which Google says can cost 30–40% end to end. Collectives are how chips pass results to each other while training.
Not every operation exists yet. Around 450 of PyTorch's built-in operations are supported. FlexAttention was not, in one of Google's own examples.
The process layout changes. TorchTPU runs one process per chip; JAX runs one per machine. Reinforcement-learning setups that share a chip between jobs need rework. torch.compile also cannot handle changing input shapes yet.

So the part that looked hard, getting the code to run, is nearly solved. The part nobody puts in a launch announcement is that your tuned kernels, your checked numbers and your network settings do not move with .to(). That is months of work per platform, and it is where lock-in actually lives now.

What to do

If you are evaluating other chips, stop scoring them on "does our model run." That question is becoming free. Score them on how much of your tuned performance survives the move.
Set precision explicitly in any comparison across hardware, or you will blame the chip for a default.
If you maintain a library that sits close to PyTorch, PrivateUse1 is the contract worth reading now. It is how your code reaches hardware you will never own.

Where this breaks down

Most of TorchTPU's performance numbers come from Google, and most of its examples do not compare against a GPU on equal footing. The 64-chip test against JAX/MaxText (1,828 against 1,937 tokens per second) is one of the few straight comparisons, and it is against JAX, not a GPU. The project calls itself "in active development." AWS does not mention CUDA at all. Putting these two releases in one frame is my argument, not either company's claim.

Takeaway

The moat was never CUDA the language. It was the thousands of hand-tuned kernels underneath it, and PrivateUse1 is the agreed-on door for building a rival set.

If switching chips costs one line of code and three months of tuning, is that portable?

Sources

PyTorch blog: Introducing TorchTPU — 20 Oct 2026
Amazon: TorchNeuron brings PyTorch to AWS Trainium — 19 Oct 2026
InfoQ: Google and Meta open-source TorchTPU — 25 Oct 2026

How Running Out of Memory Became a Server Takeover in PHP

Dhruv Agrawal — Tue, 27 Oct 2026 10:19:24 +0000

"The server would have to run out of memory first." That sounds like a reason to file a bug under not urgent.

On 21 October, two bugs that start exactly that way were published as critical. Both let someone on the internet, with no account and no password, run commands on the server. Both have been in PHP since version 5.4.

They are called PHP2Shell. Wiz Research, who found them, demonstrated working attacks against WordPress, Drupal and Joomla.

How they work is worth following even if you never touch PHP, because the same shape turns up anywhere code handles one request after another.

Why running out of memory is dangerous

PHP does not start a fresh process for every visitor. It keeps a pool of workers alive, and each handles request after request. Between them, PHP throws away the memory that request used and starts clean. That cleanup is the only reason one visitor's data does not end up in the next visitor's page.

Running out of memory interrupts the cleanup halfway. The memory gets thrown away. But some of PHP's long-lived variables are still pointing at it. The request is dead; the pointers it left behind are not. Whoever lands on that worker next inherits them.

That is the whole trick, in four different places.

The same worker serves the next visitor. Source: Wiz Research, PHP2Shell.

Take the clearest one. While PHP receives an uploaded file, it records the progress in the session. Make it run out of memory right there, and the pointer to the session ID is left aimed at memory that has already been freed.

Freed memory does not stay empty. The attacker sends more requests to refill it with bytes of their choosing, then sends one more upload. The worker follows that old pointer, reads whatever sits there now, and writes it into the session cookie it sends back.

You make a request. The server replies with a piece of its own memory, in a cookie. Wiz notes this works even on sites that never start a session.

Server memory, handed back in a cookie. Source: Wiz Research, PHP2Shell.

That gets the attacker information. The same memory error leaves a second thing behind: the bookkeeping PHP uses to rebuild saved objects from text. Someone who controls the freed memory controls structures PHP still believes are real. The leak tells them where things sit; the stale bookkeeping lets them corrupt it. Together: code execution, no login.

The second CVE is the same idea in two more spots. PHP keeps a pointer to the last crash report and forgets to clear it, so the next request that prints a warning follows it somewhere it should not. And in OPcache, the shared cache of compiled scripts, a failed allocation can leave one worker handing another a pointer to the wrong kind of object — inside memory every worker shares.

The part that should bother you

A PHP core developer saw the first signs of this in 2024, during an earlier security audit, and could not turn it into a working attack. A fair call at the time.

Then in August 2026, three separate parties reported the same underlying bug within two weeks: Calif, OpenAI and Wiz. Wiz credits AI models for making the work practical, though that is its own account, not a measurement anyone else checked.

The PHP Foundation's write-up is more useful. Its security team decides by consensus. That stalled the fix for months, and the Foundation calls it a "structural failure." It is switching to majority votes. It has also published 15 CVEs since 1 July while sorting through more than 100 invalid or duplicate reports.

What to do

Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If someone else hosts your PHP, check they have. Sansec published stopgap mitigations, including blocking file uploads at the web server, if you cannot update today.
Then look at your own code that outlives a single request: thread pools, reused serverless containers, anything pooled. When a request dies halfway through, what does it leave behind? Same bug, different language.
Stop treating "nobody has exploited it yet" as a severity input. It measures how much effort was available the day someone triaged it. That number has moved.

Where this breaks down

These attacks need things to line up: a way to force the memory error, the right configuration, and the right timing to win the race for freed memory. "Decades old and exploitable today" is true. "Trivially exploitable everywhere" is not, and I have not seen a public exploit.

Takeaway

Error paths are code too. Just the code nobody profiles, nobody fuzzes hard, and nobody reads twice.

Which error path in your system have you never actually watched run?

Sources

The PHP Foundation: today's security release and how we're strengthening PHP security — 21 Oct 2026
Wiz Research: PHP2Shell — Oct 2026
Sansec: PHP2Shell research notes and mitigations — 21 Oct 2026

How a Key Leaked in May Shipped Malware in October

Dhruv Agrawal — Mon, 26 Oct 2026 09:44:07 +0000

On 27 May 2026, someone committed a config file to a public repository by mistake. Inside it was the master key — the admin password, in effect — for one of LiteLLM's internal services. They rewrote the git history to hide it, and everyone moved on. Nobody switched the key off.

It was first used on 10 October. That is 136 days later.

Read what follows slowly, because nothing in it is clever. No bug, no zero-day. Every step is a key or token that still worked long after anyone needed it.

The chain

LiteLLM is an open-source gateway: one service your apps talk to instead of calling OpenAI, Anthropic, Bedrock and the rest directly. It routes requests, tracks spending and manages keys — which also means it holds every AI provider key a company owns.

The leaked key unlocked an internal tool for letting AI agents open pull requests. When the attacker called it, the tool handed back a GitHub token belonging to an account that owned the whole organisation. Nobody had limited what that token could do. LiteLLM's write-up says it "was not associated with a service account and was not scoped down." It could do anything, anywhere in their GitHub.

With that token, the attacker pushed a throwaway job into LiteLLM's main repository. GitHub Actions jobs can read the repository's secrets. So this one read them and posted them to a URL the attacker controlled: six, including a second maintainer's personal token. A second job took a third maintainer's. Both were deleted minutes later. Two days on, another round took fourteen more from the private repositories, including Anthropic, OpenAI and Bedrock keys.

Each step is a credential that outlived its purpose. Source: LiteLLM postmortem, 23 Oct 2026.

Then they waited nine days.

On 21 October they pointed LiteLLM's release pipeline at a fake copy of the repository: Berri-AI/litellm, with a hyphen, instead of the real BerriAI/litellm. Branch protection blocked the change. The owner token overrode it.

Publishing a release takes two people: one to start it, one to approve. The approver is normally a locked-down account tied to an office machine. That rule had been relaxed days earlier so any two engineers could do it. The attacker held three maintainers' tokens, so they started the release with one and approved with another — LiteLLM thinks to keep the audit log looking ordinary.

The poisoned version went up on PyPI and Docker. A researcher spotted it twenty-seven minutes later. PyPI pulled it within two hours.

The part that catches people

The bad package installed three files. One is cook.pth, and that extension is the whole story.

A .pth file in site-packages normally just lists extra folders for Python to search. But it has an old compatibility feature almost nobody thinks about. If a line in that file begins with import, Python runs it. Not when you import the package — at startup. The docs say these lines "are always run at Python startup... regardless of whether a particular module is actually going to be used."

A .pth line beginning with import is run by Python's site module at startup. Source: Python docs, site.

So the stealer never waited to be imported. It ran whenever any Python process started on that machine: your script, a test run, an unrelated project.

Including this one:

pip install --upgrade litellm

pip is itself a Python program. Running it starts Python, which runs the stealer again, before the upgrade fixes anything.

What to do this week

Find the files without starting Python: find / -name 'cook.pth' -o -name 'sitecustomize.py' 2>/dev/null. Delete them and any matching .pyc files before you run pip.
Assume everything on that machine is gone, not just the AI keys. The stealer read cloud credentials, SSH keys, browser data, your database URL, and the config files for Codex, Claude, Gemini and Cursor.
Pin container images by digest, not tag. latest, main-latest and main-stable all pointed at the bad build.
Go find keys nobody needs any more. That is the root cause, and the only item here you can act on before an incident rather than after.

Where this breaks down

Calling this "just credentials" undersells one thing. The relaxed two-person rule mattered. Had the approver still been that locked-down office machine, three stolen tokens would not have been enough. The control was doing real work, right up to the moment someone loosened it for convenience.

LiteLLM has said some of its early updates were wrong and more changes are coming, so treat this timeline as the best account so far.

Takeaway

Revoking a leaked key is not cleanup you do later. It is what decides whether a mistake in May becomes malware in October.

What is the oldest credential still working in your infrastructure, and would you know if someone used it?

Sources

LiteLLM postmortem: v1.107.0 compromise attack chain — 23 Oct 2026
GitHub issue #47826, Upwind research — 21 Oct 2026
Socket: attack timeline, workflows 11 days earlier — 23 Oct 2026
Python docs: the site module and .pth files

Most Package Managers Won't Stop a Tampered Download by Default

Dhruv Agrawal — Fri, 23 Oct 2026 17:22:37 +0000

Keegan Ryan of the security firm Trail of Bits set up a fake compromised package server and pointed 25 popular package managers at it. Two of them, Go and vcpkg, verified every package they downloaded, even without a lockfile. Without one, the other 23 installed whatever they were given.

Lockfiles didn't rescue most of them either.

The test

Ryan routed each tool's traffic through a proxy that could rewrite downloads, then installed quickstart projects with default settings, with and without a lockfile. An attack counted as a success if the injected code ran. The threat model assumes any web-facing server, such as a registry or a mirror, can be compromised, but backend secrets like private signing keys can't.

The lockfile is the safety net, and it's mostly unplugged

A lockfile pins every dependency's exact version and, ideally, a hash: a fingerprint the download has to match. Fewer than half of the 25 tools checked those hashes by default.

All 25 package managers, by default behavior. Source: Trail of Bits, October 14, 2026.

Nine verify when a lockfile is present, including npm, pnpm, Cargo, uv and Yarn. Five can verify, but only with extra steps. The last nine don't verify lockfile hashes at all, or the check doesn't apply to them.

Checks that don't stop anything

Tools with no check are the obvious failures. The sneakier ones run a check and install anyway:

Pub (Dart and Flutter) detects a hash mismatch, installs the package anyway and updates the lockfile to match, unless you pass --enforce-lockfile. Some Flutter commands run pub get too, and can overwrite the lockfile unless called with --no-pub.
pnpm overwrote the lockfile on a mismatch until version 11.4, in May 2026, so the tampered package simply became the new truth.
Composer (PHP) locks a Git commit, then downloads a ZIP archive it never checks against that commit.
CocoaPods hashes the package spec but fetches the source by Git tag, which a compromised host could serve with different contents.
cpanminus (Perl) still connects to its repository over plain HTTP by default.

Four outcomes when the download and the lockfile disagree. Only the green one protects you.

Why the defaults are like this

None of this is hidden; it's documented behavior. Lockfiles were built for reproducible installs, and as Ryan notes, reading them through a supply-chain lens "is a recent interpretation that can be at odds with their original design." Strict pinning also has a cost: every update, security fixes included, needs a lockfile change.

Go shows the alternative. It checks every hash against a signed checksum database that works like a transparency log, which makes targeted tampering much harder, at the cost of concentrating trust in a single private key. It was the only tool that verified every download and checked signatures by default. As Ryan puts it, "Package signing is in a similar state now to where HTTPS was a decade ago."

What to do this week

Commit your lockfile, at least for applications. Norms for libraries vary by ecosystem.
Install in strict mode in CI: npm ci, pnpm install --frozen-lockfile, uv sync --locked, pip install --require-hashes -r requirements.txt (with hashes generated by pip-compile --generate-hashes) or dart pub get --enforce-lockfile.
If your tool needs extra steps, take them: the conda-lock library for Conda, a verification-metadata.xml file for Gradle, the RestorePackagesWithLockFile property for NuGet.
If your tool is in the last group, don't treat its lockfile as a security control. Maven can check signatures against trusted keys with the third-party pgpverify-maven-plugin. Beyond that, the fallback Conan's developers suggest applies widely: if integrity is critical, run your own repository server.

Then test it: change one hash in your lockfile on purpose and confirm CI fails.

Caveats

Each tool was tested with one package, one version and one platform, Ubuntu, and some setups, like PowerShell and CocoaPods on Ubuntu, don't reflect typical use. The study shows that reasonable defaults can leave you exposed, not that every setup is.

Verification comes before detection

Most supply chain tooling hunts for packages already known to be bad. This study is about the step before that: making sure the package you got is the package you asked for. For most of the 25 tools, that check is off by default or missing. Where it exists, turning it on is about the cheapest security win you'll find.

If you check what your package manager does on a hash mismatch, I'd like to hear what you find.

Sources

Package managers have an integrity problem, Keegan Ryan, Trail of Bits, October 14, 2026

Anthropic Replaced Git. The Interesting Part Is the Merge Queue.

Dhruv Agrawal — Mon, 19 Oct 2026 11:15:35 +0000

In May 2026, Anthropic merged about 2,500 changes a day into its main codebase. By September it was more than 30,000. Anthropic says Claude's ability to write code is "what put us in this situation in the first place." Git stopped fitting, so they replaced it.

You probably don't need to replace Git. But one decision in their write-up applies to almost any team adding coding agents, and it's about the merge queue.

Merges per day in Anthropic's monorepo, May vs. September 2026. Source: Anthropic Engineering.

Why Git stopped fitting

Git assumes clients that keep a full copy of the history and work offline. That's perfect for people. Anthropic's clients are mostly machines: "nearly all of our clients were agents and jobs that are online by definition." They run on the order of 25 million CI checkouts a day against a main-branch history of almost 100 GB, and at the peak it took several hundred internal Git mirrors to keep up.

So a team of seven built Scion, which flips the model. The server creates commits, performs merges and rebases, and answers history questions, while clients fetch only what they need. Anthropic reports an infrastructure footprint 200x smaller in CPU and memory than the old mirrors, and CI checkouts in seconds instead of minutes. The migration took five months.

The write-up is just as clear that Scion is "by no means a suitable replacement for git for general use." It only makes sense for enormous monorepos, and it needs its own code review, code search and CI.

The merge queue decision

A merge queue is the line in front of main. Each change is tested against the latest main plus everything queued ahead of it, then lands. The industry-standard version holds a global lock on the repository while it does that, and it's how most teams keep main green.

Anthropic writes that a proper merge queue "doesn't make much sense at agent scale," and asks: "What does CI even mean when hundreds or even thousands of changes can merge while tests are running?" They couldn't make the global lock work at their volume, so instead of making the line faster, they moved the check. They "invested in post-merge and pre-deploy automated testing." The gate that matters now sits before production, and when concurrent changes conflict, Claude can typically fix them faster than a person would notice.

Before: changes wait one at a time behind a global lock. After: no global lock, and the real gate sits before deploy.

Find your one-at-a-time step

Every delivery pipeline has a step where changes wait for each other: the merge queue, a required human review, a single shared staging environment. When agents multiply how much code your team produces, that step hurts first.

The reflex is to make it faster with bigger runners, more reviewers or another staging box. Sometimes that's enough. The better question is the one Anthropic asked: does this check need to sit here at all? Moving a gate to where it doesn't block everyone can beat any speedup.

To find yours, trace one change from commit to production and circle every place where it waits for another.

Where this breaks down

Scale. Most teams will never see 30,000 merges a day, and Anthropic admits its "ability to spend tokens for internal use far exceeds what any other business would realistically want to spend." If your queue isn't hurting, leave it alone.
Risk. Testing after merge means main can be broken for a while. That only works if pre-deploy checks are reliable and conflicts get fixed fast.
Source. Every number here comes from Anthropic's own engineering blog, with no independent measurement.

The real bottleneck

Strip out the version control details and this is a story about one part of a system getting 12x faster while the rest didn't. Anthropic expects this class of problems to become "more commonplace over the next six to 12 months." Find your one-at-a-time step before then.

Where is it in your pipeline: the merge queue, code review, or somewhere else?

Sources

Redesigning source control at Anthropic, Anthropic Engineering, October 13, 2026 (updated October 15, 2026)

DEV Community: Dhruv Agrawal

How a Trusted Extension Name Delivered an SSH Backdoor Through Cursor's Store

The delivery chain

What the tampered build did

The evidence

What to do

Where this breaks down

Takeaway

Sources

How PyTorch Became the Socket Every AI Chip Plugs Into

What happens when you call .to("cuda")

Running is the easy half

What to do

Where this breaks down

Takeaway

Sources

How Running Out of Memory Became a Server Takeover in PHP

Why running out of memory is dangerous

The part that should bother you

What to do

Where this breaks down

Takeaway

Sources

How a Key Leaked in May Shipped Malware in October

The chain

The part that catches people

What to do this week

Where this breaks down

Takeaway

Sources

Most Package Managers Won't Stop a Tampered Download by Default

The test

The lockfile is the safety net, and it's mostly unplugged

Checks that don't stop anything

Why the defaults are like this

What to do this week

Caveats

Verification comes before detection

Sources

Anthropic Replaced Git. The Interesting Part Is the Merge Queue.

Why Git stopped fitting

The merge queue decision

Find your one-at-a-time step

Where this breaks down

The real bottleneck

Sources

What happens when you call `.to("cuda")`