Why are a package page's linked repository, stars and download count weak evidence of authenticity?

## Where package-page metadata comes from When a package is published, most of what you later see on its page is copied out of the uploaded archive's own manifest: description, homepage, repository URL, licence string, and often the README rendered inline. The registry stores what it was given. It generally does not fetch the repository, does not check that the repository contains this package, and does not check that the archive corresponds to anything in it. Badges are images fetched from URLs the publisher chose. Stars are not a registry concept at all — they live on the source forge, attached to the repository, and are displayed alongside the package only because the package claimed that repository. **Starjacking** is the exploitation of that gap: publish a package under a near-miss or invented name, but declare the repository of a genuinely popular project. The package page now shows a mature README, a long commit history one click away, a licence, and a star count in the thousands. Every human trust signal agrees. So does anything automated that scores packages by popularity — a ranking, a "trusted if widely used" rule, an internal dashboard that surfaces "reputable" candidates. Picture a crate published to a public crate index whose README, repository link and displayed stars are copied wholesale from a well-known crate. A reviewer opening the page sees the real project's documentation. The asset under attack here is unusual and worth naming in an interview: it is not customer data or availability, it is **the trust signals themselves**. Once reputation can be pointed at arbitrary artifacts, every downstream decision built on reputation degrades at once. ## Why download counts fail too - They can be inflated cheaply, since installs are unauthenticated fetches and mirrors and CI runs count. - They are a lagging indicator of the attack succeeding: a squat that is working produces exactly the rising curve people read as reassurance. - They measure the *name*, not the current *version*. A long-standing package whose maintainer account was taken over carries its whole historical count into its first malicious release. ## What is actually evidence Keep the three artifacts straight, because interviewers probe this exact confusion: - an **SBOM** tells you *what is inside* an artifact; - **provenance** tells you *how it came to be* — which source repository, which commit, which build system produced it; - a **signature** tells you *who vouches for it*. Starjacking is an attack on the "where did this come from" question, answered with unverified metadata. Provenance answers the same question with metadata that is cryptographically bound to the artifact's digest and signed, so the claim can be checked rather than believed. Concretely, in descending order of strength: 1. **A signed provenance attestation** whose subject digest matches the artifact you are about to install and whose predicate names the source repository and commit — checked against the identity you *expect* to see. Verifying only that some valid signature exists is a classic non-control: any attacker can sign their own artifact. 2. **Publisher identity and its history.** Who is allowed to publish under this name, how long have they held it, did ownership or the maintainer set change recently? 3. **Archive against source.** Does the published archive correspond to the tagged commit in the repository it claims? Any divergence is decisive. 4. **Corroboration from the project's own side.** Does the real project's documentation or release notes name this package and this publishing namespace? Reputation asserted by the *claimed* project's own channel is worth far more than reputation displayed next to the claim. ## The operating lesson Do not build automation on signals the registry does not verify. If an internal gate auto-approves packages above a popularity threshold, an attacker's cheapest move is to satisfy that threshold with borrowed metadata rather than to defeat any cryptography. Signals that a publisher can assert about themselves are useful for *sorting*; only signals bound to the artifact's digest are useful for *deciding*.