PackageKit waved 1500 packages through unchecked

1. Opening Claim

Arch Linux states the malware incident is under control. The scope is more than 1500 packages. That is the position on record. “Under control” is a belief held by the project, not a verified closed state. A control status declared without stated verification is an assertion. It is not a confirmed condition.

The named failure point is the package management layer. The input identifies it as PackageKit and describes it as permitting software installation without verification. If that description holds, the install path trusts package content by default. A trust-by-default install path does not enforce a boundary. It moves code into an execution context without validating what the code is or where it came from. That is not a control. That is a delivery channel.

The figure that matters is scope. More than 1500 packages are in scope. The input does not state how many were malicious, how many installations were affected, or how the packages entered scope. Those values are not confirmed. What is confirmed is that the count was large enough for the project to declare an incident and to describe the response as containment. An install path with no verification step applies the same trust to one package and to fifteen hundred. That uniformity is a property of the path, and it is the only property the stated facts support.

2. The Original Assumption

The design assumes the default package source is trustworthy. Under that assumption, installation does not require verification, because the source is treated as safe by definition. The input states the package management layer allows unrestricted installation without verification. That is the assumption rendered as behavior: no check, because no check was treated as necessary.

The second assumption is competence. The input states the model relies on assumptions of user competence, and that those assumptions can be exploited. In practice this places the verification decision on the user. The user is expected to judge what is safe to install. A control that depends on every user making a correct trust decision every time is not enforcing anything. It is documenting an expectation.

These are design assumptions, not enforced controls. An enforced control rejects input that fails a check. An assumption permits input and treats the check as unnecessary. The input describes a path that permits installation and performs no verification. Under the principle that a system will eventually do whatever it permits, an install path that allows unverified code will execute unverified code. The timing of that event is not confirmed. The outcome is structural.

3. What Changed

The declared state moved from no known compromise to a known compromise across more than 1500 packages. Arch Linux now states it believes the incident is under control. That is the externally observable change: a public position that an incident exists and that the project considers its response effective.

What is observable is limited to two things. The project’s statement that the incident occurred and is believed contained. The scope figure of more than 1500 packages. Everything beyond that is not confirmed. The entry vector is not confirmed. The technique is not confirmed. Dwell time is not confirmed. The number of affected installations is not confirmed. Whether the incident is contained in fact, rather than in belief, is not confirmed.

The trust state did not survive the event. The default source carried malware into scope. The package management layer, as described, did not prevent this, because it performs no verification. A control that does not verify cannot detect this class of event. It follows that “under control” describes the response, not prevention. Prevention did not occur. The boundary that should have rejected unverified content was not present in the install path, so there was nothing to reject it. State it plainly: the control did not fail under load. It was not a control.

4. Mechanism of Failure

The mechanism is the location of trust. The input states the package management layer permits installation and performs no verification. Trust is therefore bound to the source, not to the package. Content authenticated by origin enters the execution context without a check against the content itself. The observable behavior is movement of code from the source into a running state with no verification step between the two. That gap is the mechanism. It is not a defect in a control. It is the absence of one.

The second component is delegation. The input states the model relies on assumptions of user competence and that those assumptions can be exploited. This places the only trust decision on the user. A human deciding what is safe to install is not an enforcement point. It is a request for judgment. The install path does not reject input that fails a check, because there is no check. It accepts input and records that the user approved it. Approval is not verification. The mechanism treats them as equivalent.

This mechanism does not degrade with scale. The same absent verification applies to one package and to more than 1500. The path does not weaken under volume, because there was no enforcement to overwhelm. Whether the entry vector for the stated incident has been closed is not confirmed. What is confirmed is the property of the path as described: it assigns identical trust to every artifact it delivers. A mechanism that cannot distinguish a clean package from a malicious one will pass both. The 1500 figure is that property measured, not a separate failure.

5. Expansion into Parallel Pattern

The pattern is source trust standing in for content verification. Any delivery path that validates where something came from, and not what it is, carries the mechanism described here. The origin is authenticated once. Every artifact served from that origin inherits the authentication without being checked itself. This is the same structure as the install path in the stated incident. Trust is granted at the channel and never revalidated at the payload. One trusted source gates many artifacts, and none of the artifacts are verified on their own terms.

Automation expresses this pattern at machine speed. The stated facts identify user competence as the only trust decision. Remove the human from that decision and nothing replaces it, because nothing else was enforcing. A path that depends on a person approving each install has no gate once the approval step is automated. This follows directly from the mechanism. If the single check is a human judgment, then the check exists only while a human is in the path. The principle holds in both directions. Automation scales the delivery and scales the absence of verification with it.

The blast radius follows from the same structure. When trust is bound to a source, a compromise of that source is inherited by everything downstream of it. The input states the incident erodes trust in the entire system. That is the mechanism observed at its endpoint. The number of artifacts is not the cause. The cause is that one origin was trusted to speak for all of them. More than 1500 packages share a single trust decision, so a failure at that decision is a failure across all of them. The pattern is not specific to one package manager. It is present wherever origin authentication is treated as a substitute for verifying the thing being delivered.

6. Hard Closing Truth

A path that permits unverified code is not a control. The project states the incident is under control. That statement describes the response and the project’s belief about it. It does not describe prevention, because the mechanism as described performs no verification and therefore prevents nothing. Whether the incident is closed in fact, rather than in belief, is not confirmed. A control status declared without stated verification remains an assertion.

What must now be true is narrow and specific. Verification must bind to the artifact, not to the source. Each package must be validated before it enters an execution context, on its own content, independent of where it came from. The user must not be the enforcement point, because a trust decision delegated to human judgment is not enforced. Trust must be validated at the boundary every time, not assumed once at the origin. Identity is the boundary. A boundary that does not reject content failing a check is not a boundary. It is a label on a path that passes everything.

If a system permits an action, the action will occur. The scope of more than 1500 packages is the system doing what its install path allowed. Whether that path now enforces verification is not confirmed. Until it does, the condition described is the condition that exists, and containment of an incident is not correction of the mechanism. The control did not fail. There was no control. Define the boundary, enforce it on every artifact, and stop relying on the user to hold a line the system declined to hold.