Walkthrough

The CLI now supports pacquet audit signatures. It adds p256, routes the subcommand through signature verification, fetches registry keys and packuments, renders audit results, and expands unit and end-to-end tests.

Changes

Signature audit support

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

• pnpm/pnpm#11405: Both PRs implement audit signatures by fetching registry signing keys and verifying ECDSA-P256 signatures from packument dist.signatures.
• pnpm/pnpm#12637: This PR overlaps the same CLI audit entrypoint and dispatches audit signatures through the new verification flow.

Suggested labels

product: pacquet

• X
• Mastodon
• Reddit
• LinkedIn

• Add pacquet audit signatures to verify installed packages against registry signing keys.
• Fetch registry keys and packuments, then validate dist.signatures over name@version:integrity.
• Emit pnpm-compatible text/JSON reports and exit 1 on missing/invalid signatures.

graph TD
  A["pacquet CLI: audit signatures"] --> B["Lockfile: package list"] --> C{{"Package registry"}} --> D["Fetch signing keys"] --> E["Fetch packument"] --> F["Verify ECDSA-P256"] --> G["Render report / JSON"]
  D -. "404/400 => skip" .-> G

  subgraph Legend
    direction LR
    _cli["CLI / module"] ~~~ _ext{{"External service"}}
  end

Loading

The following are alternative approaches to this PR:

1. Use `ring`/`webpki` for ECDSA verification

• ➕ Widely deployed crypto implementation with strong review pedigree
• ➕ Potentially fewer parsing/format pitfalls depending on supported encodings
• ➖ May complicate SPKI/DER handling and signature format compatibility vs pnpm behavior
• ➖ Harder to mirror pnpm’s exact acceptance rules if APIs are more restrictive

2. Treat malformed key/signature material as hard errors

• ➕ Stricter security posture; fails fast on unexpected registry data
• ➕ Simplifies reasoning about ‘silent’ non-matches
• ➖ Behavior would diverge from pnpm’s “one valid signature wins” tolerance
• ➖ A single bad key/signature entry could block auditing otherwise valid packages

Recommendation: Keep the current approach: using p256 plus tolerant per-signature handling best matches the stated goal (pnpm parity), preserves key-rotation behavior (“one valid signature wins”), and avoids making audits fragile to individual malformed entries. The considered alternatives either risk compatibility drift (different crypto APIs/encodings) or change failure semantics in ways that would surprise users coming from pnpm.

Enhancement (2) +721 / -11

audit.rsEnable 'audit signatures' subcommand and route packages to registries +87/-11

Enable 'audit signatures' subcommand and route packages to registries

• Adds a 'signatures' module and implements 'run_signatures' to collect installed packages from the lockfile, select per-package registries, and execute signature verification. Introduces 'ERR_PNPM_AUDIT_NO_PACKAGES' handling and rejects extra subcommand args for parity with pnpm behavior.

pacquet/crates/cli/src/cli_args/audit.rs

signatures.rsImplement registry keys/packument fetching and ECDSA signature validation +634/-0

Implement registry keys/packument fetching and ECDSA signature validation

• Implements the full 'pacquet audit signatures' flow: fetch '/-/npm/v1/keys' per registry, fetch and parse packuments per (registry,name), and validate 'dist.signatures' over 'name@version:integrity'. Produces pnpm-compatible missing/invalid/verified reporting (text + JSON), includes key-expiry consistency checks, and adds pnpm-aligned error codes for keys/packument failures.

pacquet/crates/cli/src/cli_args/audit/signatures.rs

Tests (2) +415 / -3

tests.rsAdd unit tests for signature verification and rendering behavior +156/-0

Add unit tests for signature verification and rendering behavior

• Adds focused unit tests for ECDSA verification, invalid/unknown-key reason selection, key-expiry behavior, URL encoding parity, timestamp parsing, and “no signing keys” output rendering.

pacquet/crates/cli/src/cli_args/audit/signatures/tests.rs

audit.rsAdd integration tests for 'pacquet audit signatures' against a mocked registry +259/-3

Add integration tests for 'pacquet audit signatures' against a mocked registry

• Replaces the previous 'unsupported' assertion with end-to-end tests that drive the CLI against a mock registry, covering verified output, '--json' shape, missing and invalid signature exit code 1, registry-without-keys skip behavior, keys endpoint hard failure, no-packages error, and extra-argument rejection.

pacquet/crates/cli/tests/audit.rs

Other (2) +2 / -0

Cargo.tomlAdd direct 'p256' dependency for ECDSA-P256 verification +1/-0

Add direct 'p256' dependency for ECDSA-P256 verification

• Introduces 'p256' as a workspace dependency (with ecdsa/pkcs8) to support registry signature verification. This makes the crypto requirement explicit rather than relying on transitive resolution.

Cargo.toml

Cargo.tomlWire 'p256' into pacquet CLI crate dependencies +1/-0

Wire 'p256' into pacquet CLI crate dependencies

• Adds the 'p256' workspace dependency to the CLI crate so the new 'audit signatures' implementation can verify ECDSA-P256 signatures.

pacquet/crates/cli/Cargo.toml

Description

SignaturesError::{KeysNetwork,PackumentNetwork} formats and surfaces the raw reqwest::Error
({source}), which can include the full request URL; if the configured registry URL contains
user:pass@, those credentials can leak into terminal/CI error output. This bypasses the repo’s
existing redact_url_credentials convention used in retry/logging paths.

Code

pacquet/crates/cli/src/cli_args/audit/signatures.rs[R118-148]

+    #[display("Failed to request the registry keys endpoint (at {url}): {source}")]
+    #[diagnostic(code(ERR_PNPM_AUDIT_SIGNATURE_KEYS_FETCH_FAIL))]
+    KeysNetwork {
+        url: String,
+        #[error(source)]
+        source: reqwest::Error,
+    },
+
+    #[display("The registry keys endpoint (at {url}) responded with {status}: {body}")]
+    #[diagnostic(code(ERR_PNPM_AUDIT_SIGNATURE_KEYS_FETCH_FAIL))]
+    KeysBadStatus { url: String, status: u16, body: String },
+
+    #[display(
+        "The registry keys endpoint (at {url}) returned invalid JSON: {reason}. Response body: {body}"
+    )]
+    #[diagnostic(code(ERR_PNPM_AUDIT_SIGNATURE_KEYS_FETCH_FAIL))]
+    KeysInvalidJson { url: String, reason: String, body: String },
+
+    #[display(
+        "The registry keys endpoint (at {url}) returned an unexpected body. Expected an object with a keys array; got: {body}"
+    )]
+    #[diagnostic(code(ERR_PNPM_AUDIT_SIGNATURE_KEYS_FETCH_FAIL))]
+    KeysUnexpectedBody { url: String, body: String },
+
+    #[display("Failed to request the packument endpoint (at {url}): {source}")]
+    #[diagnostic(code(ERR_PNPM_AUDIT_SIGNATURE_PACKUMENT_FETCH_FAIL))]
+    PackumentNetwork {
+        url: String,
+        #[error(source)]
+        source: reqwest::Error,
+    },

Evidence

The new error variants embed and display reqwest::Error directly, while existing network retry
logging explicitly redacts formatted reqwest errors, implying they can contain credential-bearing
URLs. This makes the new audit-signatures errors a regression in secret redaction coverage.

pacquet/crates/cli/src/cli_args/audit/signatures.rs[115-148]
pacquet/crates/network/src/retry.rs[157-167]
pacquet/crates/network/src/auth.rs[460-466]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`SignaturesError::{KeysNetwork, PackumentNetwork}` currently includes a `reqwest::Error` as `source` and prints it via the derived `Display` (`... {source}`). `reqwest::Error` formatting can include the URL, so registries configured with embedded credentials (e.g. `https://user:pass@host/`) may leak secrets to stderr.
### Issue Context
The codebase already treats formatted reqwest errors as potentially credential-bearing and redacts them in retry logging.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/audit/signatures.rs[115-165]
### Implementation notes
- Ensure *all* user-facing formatting of the underlying reqwest error is passed through `pacquet_network::redact_url_credentials`.
- Also ensure the error cause-chain printed by miette cannot re-introduce the unredacted `reqwest::Error`. Options:
- Store a redacted string instead of `reqwest::Error` in these variants (drop source chaining for these cases), or
- Wrap `reqwest::Error` in a newtype whose `Display` redacts (and use that wrapper as the error source), so both the top-level message and the cause-chain are safe.
- Add/adjust a unit/integration test that sets a registry URL containing `user:pass@` and asserts the printed error output contains the redacted form (no userinfo).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

When fetch_packument returns Ok(None) (e.g. HTTP 404), verify_signatures ignores it and does
not record an invalid/missing result or increment audited. A registry that advertises signing keys
can thus omit packuments (404) and cause installed packages to be silently excluded from signature
auditing, producing a false-clean report.

Code

pacquet/crates/cli/src/cli_args/audit/signatures.rs[R207-215]

+        match packuments.get(&(pkg.registry.clone(), pkg.name.clone())) {
+            Some(Err(reason)) => {
+                result.invalid.push(issue(pkg, None, None, Some(reason.clone())));
+            }
+            Some(Ok(None)) | None => {}
+            Some(Ok(Some(packument))) => {
+                result.audited += 1;
+                process_version(pkg, packument, keys, &mut result);
+            }

Evidence

fetch_packument maps HTTP 404 to Ok(None), and the main auditing loop drops Ok(None) results
without producing any output entry, so packages can be excluded from the audit despite being
selected for packument fetching.

pacquet/crates/cli/src/cli_args/audit/signatures.rs[188-216]
pacquet/crates/cli/src/cli_args/audit/signatures.rs[461-512]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`fetch_packument` can return `Ok(None)` (notably on HTTP 404), and `verify_signatures` currently treats `Ok(None)` as a no-op. This allows packages from registries *with signing keys* to be silently skipped (not audited, not marked invalid), which can yield false-clean results.
### Issue Context
This command is a security verification gate; “registry has signing keys” should imply that every installed package from that registry either verifies, is missing a signature, or is invalid / unverifiable. A 404 packument for an installed dependency should be surfaced as an invalid audit entry (or at minimum counted as audited and reported as unverifiable).
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/audit/signatures.rs[207-216]
- pacquet/crates/cli/src/cli_args/audit/signatures.rs[461-512]
### Suggested fix
- Decide how to represent a missing packument (404) for an installed package:
- Prefer: record `invalid` with a clear reason (e.g. "Missing registry metadata for name@version" or "Packument not found (404)") and increment `audited`.
- Update the `match` in `verify_signatures` so `Some(Ok(None))` produces an invalid issue for the specific `pkg` (instead of being ignored).
- Optionally change `fetch_packument` to treat 404 as an error type that carries status/body (or keep `Ok(None)` but handle it explicitly in `verify_signatures`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

fetch_registry_keys and fetch_packument fully buffer attacker-controlled registry responses via
response.text().await without any size cap, allowing a malicious/compromised registry to drive
memory pressure or OOM during pacquet audit signatures. The buffered body is then parsed and
sometimes re-stringified, further multiplying CPU/memory cost on large responses.

Code

pacquet/crates/cli/src/cli_args/audit/signatures.rs[R479-483]

+    let status = response.status().as_u16();
+    let body = response
+        .text()
+        .await
+        .map_err(|source| SignaturesError::PackumentNetwork { url: display_url.clone(), source })?;

Evidence

The added code reads the full HTTP body into a String before any truncation and without checking
content length; this is attacker-controlled input from the registry. Existing code demonstrates
pacquet’s stance that remote size signals are untrusted and should be guarded to avoid crashing
allocations.

pacquet/crates/cli/src/cli_args/audit/signatures.rs[399-507]
pacquet/crates/tarball/src/lib.rs[330-365]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`fetch_registry_keys` / `fetch_packument` call `response.text().await` on registry-controlled endpoints with no explicit maximum size. This can OOM/crash the CLI (DoS) if the response body is extremely large.
### Issue Context
Other pacquet network ingestion paths treat remote size signals as untrusted and guard allocations to avoid abort/OOM. The signatures audit should similarly bound memory used for keys and packument bodies.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/audit/signatures.rs[399-507]
- pacquet/crates/cli/src/cli_args/audit/signatures.rs[539-541]
### Implementation notes
- Add a max-bytes limit for keys and packument responses (could be different limits). Prefer:
- Check `response.content_length()` and fail early if above limit.
- If unknown, stream bytes and stop once the cap is exceeded.
- Avoid `value.to_string()` on unexpected-body paths; use the already-read (and capped) raw body snippet for diagnostics rather than re-serializing potentially huge JSON.
- Consider deserializing directly from the raw JSON string into the target struct to avoid building/cloning a full `serde_json::Value` tree when possible.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

verify_signatures() fetches and parses every needed full packument and retains them all in a
HashMap before processing any package, which can significantly increase peak memory and slow large
audits. This is especially risky because packument bodies/parses can be multi‑MB in this repo’s own
resolver implementation.

Code

pacquet/crates/cli/src/cli_args/audit/signatures.rs[R184-199]

+    // Only fetch packuments for registries that advertise signing keys; a
+    // registry without keys is skipped entirely.
+    let needed: BTreeSet<(&str, &str)> = packages
+        .iter()
+        .filter(|pkg| keys_by_registry.get(&pkg.registry).is_some_and(|keys| !keys.is_empty()))
+        .map(|pkg| (pkg.registry.as_str(), pkg.name.as_str()))
+        .collect();
+    let packument_fetches = needed.into_iter().map(|(registry, name)| async move {
+        let result = fetch_packument(name, registry, config, http_client)
+            .await
+            .map_err(|err| err.to_string());
+        ((registry.to_string(), name.to_string()), result)
+    });
+    let packuments: HashMap<(String, String), Result<Option<Packument>, String>> =
+        futures_util::future::join_all(packument_fetches).await.into_iter().collect();
+

Evidence

The implementation builds packument_fetches for all needed (registry,name) pairs and join_all
collects them into a HashMap before any per-package processing begins. Separately, the resolver’s
full-metadata fetch path documents that packument parses can be multi‑MB, which makes retaining many
parsed packuments simultaneously a peak-memory risk.

pacquet/crates/cli/src/cli_args/audit/signatures.rs[165-215]
pacquet/crates/resolving-npm-resolver/src/fetch_full_metadata.rs[126-130]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`verify_signatures()` currently prefetches all packuments, stores them in a `HashMap`, and only then iterates packages to verify signatures. Because packuments can be large (multi‑MB) and the number of distinct `(registry, name)` pairs can be high in large monorepos, this increases peak memory usage and can degrade performance.
## Issue Context
This code is on a CLI audit path, but it’s still user-facing and can be run in CI on large dependency graphs.
## Fix Focus Areas
- pacquet/crates/cli/src/cli_args/audit/signatures.rs[165-215]
## Suggested approach
- Group `packages` by `(registry, name)` and collect the list of installed versions for that pair.
- Fetch one packument per group and immediately process all requested versions for that packument, then drop it (do not store all packuments in a global map).
- If you still need concurrency, use a bounded concurrency stream (e.g. `futures_util::stream::iter(groups).map(...).buffer_unordered(N)`) so only a limited number of packuments are held/parsed concurrently.
- Preserve current error semantics (keys endpoint fatal; packument failures recorded per affected packages).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

SignatureIssue.resolved is populated from the registry packument’s dist.tarball and emitted in
pacquet audit signatures --json, which can disclose sensitive URL userinfo or registry-provided
signed URL tokens into CI logs/artifacts when a package is missing/invalid.

Code

pacquet/crates/cli/src/cli_args/audit/signatures.rs[R228-263]

+    let version = packument.versions.get(&pkg.version);
+    let published_at =
+        packument.time.get(&pkg.version).and_then(serde_json::Value::as_str).map(str::to_string);
+    let dist = version.and_then(|version| version.dist.as_ref());
+    let integrity = dist.and_then(|dist| dist.integrity.clone());
+    let resolved = dist.and_then(|dist| dist.tarball.clone());
+    let raw_signatures = dist.and_then(|dist| dist.signatures.as_ref());
+
+    if raw_signatures.is_some_and(|value| !value.is_array()) {
+        result.invalid.push(issue(pkg, integrity, resolved, Some(malformed_reason(pkg))));
+        return;
+    }
+    let mut signatures = Vec::new();
+    if let Some(serde_json::Value::Array(elements)) = raw_signatures {
+        for element in elements {
+            let Ok(signature) = serde_json::from_value::<PackageSignature>(element.clone()) else {
+                result.invalid.push(issue(pkg, integrity, resolved, Some(malformed_reason(pkg))));
+                return;
+            };
+            signatures.push(signature);
+        }
+    }
+
+    if version.is_none() {
+        let reason = format!("Missing registry metadata for {}@{}", pkg.name, pkg.version);
+        result.invalid.push(issue(pkg, None, None, Some(reason)));
+        return;
+    }
+    let Some(integrity) = integrity else {
+        result.missing.push(issue(pkg, None, resolved, None));
+        return;
+    };
+    if signatures.is_empty() {
+        result.missing.push(issue(pkg, Some(integrity), resolved, None));
+        return;
+    }

Evidence

resolved is taken directly from the packument’s dist.tarball and stored into SignatureIssue,
which is then pretty-printed to stdout under --json.

pacquet/crates/cli/src/cli_args/audit/signatures.rs[44-58]
pacquet/crates/cli/src/cli_args/audit/signatures.rs[89-97]
pacquet/crates/cli/src/cli_args/audit/signatures.rs[228-263]
pacquet/crates/cli/src/cli_args/audit.rs[366-376]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`SignatureIssue.resolved` is filled from `dist.tarball` and serialized in `--json` output. If the tarball URL contains `user:pass@` or other sensitive URL components (common in some private registry/CDN setups), `pacquet audit signatures --json` will print them to stdout.
### Issue Context
- `resolved` is derived from registry-provided packument metadata (`dist.tarball`).
- The JSON report is intended for machine/CI consumption, where stdout is frequently persisted.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/audit/signatures.rs[228-263]
- pacquet/crates/cli/src/cli_args/audit/signatures.rs[366-380]
- pacquet/crates/cli/src/cli_args/audit.rs[366-376]
### Suggested fix
- Before storing `resolved` into `SignatureIssue`, redact URL credentials at minimum (e.g. `pacquet_network::redact_url_credentials(&resolved)`), so `user:pass@` cannot be leaked.
- If you want stronger protection, consider additionally stripping query/fragment for `resolved` in JSON output (or gating full URLs behind an explicit verbose/debug flag), but keep parity/contract expectations in mind.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The signatures report prints and JSON-serializes SignatureIssue.registry verbatim, which is
derived from Config::resolved_registries(); if a registry URL contains embedded user:pass@,
those credentials will be emitted to stdout/JSON. This can leak secrets into CI logs or stored
artifacts.

Code

pacquet/crates/cli/src/cli_args/audit/signatures.rs[R606-618]

+fn issue_table(issues: &[SignatureIssue], with_reason: bool) -> String {
+    use tabled::{builder::Builder, settings::Style};
+
+    let mut builder = Builder::default();
+    for issue in issues {
+        let package = red(&format!("{}@{}", issue.name, issue.version));
+        if with_reason {
+            let reason =
+                issue.reason.clone().unwrap_or_else(|| "Invalid registry signature".to_string());
+            builder.push_record(vec![package, issue.registry.clone(), reason]);
+        } else {
+            builder.push_record(vec![package, issue.registry.clone()]);
+        }

Evidence

The registry URL flows from config (resolved_registries → pick_registry_for_package) into
SignaturePackage.registry, is copied into SignatureIssue.registry, and is printed directly in
the table. The project includes a dedicated URL-credential redaction helper, showing that
credential-bearing URLs are an expected risk.

pacquet/crates/cli/src/cli_args/audit.rs[334-359]
pacquet/crates/cli/src/cli_args/audit/signatures.rs[368-381]
pacquet/crates/cli/src/cli_args/audit/signatures.rs[606-618]
pacquet/crates/network/src/auth.rs[460-466]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`SignatureIssue.registry` is populated from config registry URLs and is emitted in both human output (table) and `--json` output without redaction. Embedded URL credentials can therefore be exposed.
### Issue Context
The repo already has `pacquet_network::redact_url_credentials` to prevent leaking `user:pass@` in logs/errors; `audit signatures` should apply the same protection to its reporting output.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/audit/signatures.rs[368-381]
- pacquet/crates/cli/src/cli_args/audit/signatures.rs[606-618]
- pacquet/crates/cli/src/cli_args/audit.rs[334-359]
### Implementation notes
- Redact `registry` before printing in `issue_table()` at minimum.
- Prefer also redacting `registry` before JSON serialization (`--json`) to avoid leaking secrets to machine-consumed artifacts.
- Add a test that uses a registry URL like `https://user:[email protected]/` and asserts stdout/JSON does not contain `user:pass@` (and ideally matches the redacted form).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

verify_one base64-decodes and DER-parses the registry public key on every signature check, adding
avoidable CPU cost in the per-signature hot loop during large audits.

Code

pacquet/crates/cli/src/cli_args/audit/signatures.rs[R343-350]

+fn verify_one(public_key_base64: &str, message: &str, signature_base64: &str) -> bool {
+    let engine = base64::engine::general_purpose::STANDARD;
+    let Ok(key_der) = engine.decode(public_key_base64) else { return false };
+    let Ok(verifying_key) = VerifyingKey::from_public_key_der(&key_der) else { return false };
+    let Ok(signature_der) = engine.decode(signature_base64) else { return false };
+    let Ok(signature) = Signature::from_der(&signature_der) else { return false };
+    verifying_key.verify(message.as_bytes(), &signature).is_ok()
+}

Evidence

verify_one performs base64 decode and SPKI parsing every time it is invoked, and it is invoked
from the per-signature loop in verify_package_signatures.

pacquet/crates/cli/src/cli_args/audit/signatures.rs[285-330]
pacquet/crates/cli/src/cli_args/audit/signatures.rs[340-350]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Public keys are repeatedly decoded and parsed inside `verify_one`, even though keys are registry-level data reused across many package/version signature checks. This adds unnecessary CPU overhead (base64 + ASN.1/SPKI parsing) proportional to the number of signatures evaluated.
### Issue Context
- `verify_one()` is called from inside the per-signature loop.
- Registry keys are fetched once per registry and could be pre-processed once per run.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/audit/signatures.rs[285-338]
- pacquet/crates/cli/src/cli_args/audit/signatures.rs[340-350]
- pacquet/crates/cli/src/cli_args/audit/signatures.rs[165-220]
### Suggested fix
- When building `keys_by_registry`, additionally build a `HashMap<keyid, VerifyingKey>` (or `Result<VerifyingKey, _>` where invalid keys simply don’t enter the trusted set).
- Change verification to look up the pre-parsed `VerifyingKey` and only decode/parse the signature per entry.
- Keep current behavior where malformed key/signature material counts as a non-match (does not abort the audit).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The per-package packument lookup clones pkg.registry and pkg.name to build a temporary `(String,
String)` key on every iteration. This adds avoidable allocations proportional to the number of
audited packages.

Code

pacquet/crates/cli/src/cli_args/audit/signatures.rs[207]

+        match packuments.get(&(pkg.registry.clone(), pkg.name.clone())) {

Evidence

The main processing loop constructs a temporary owned tuple key for every lookup instead of using a
borrowed lookup path.

pacquet/crates/cli/src/cli_args/audit/signatures.rs[202-216]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`packuments.get(&(pkg.registry.clone(), pkg.name.clone()))` allocates two new `String`s for every lookup in the main loop.
### Issue Context
This runs once per audited `name@version` entry. For large lockfiles, it is measurable overhead and easy to avoid.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/audit/signatures.rs[199-216]
### Suggested fix
- Restructure `packuments` to allow borrowed lookups without cloning, e.g.:
- `HashMap<String, HashMap<String, Result<Option<Packument>, String>>>` and then `packuments.get(&pkg.registry).and_then(|m| m.get(&pkg.name))`.
- Alternatively, introduce a small key type that supports `Borrow` so `HashMap::get` can accept `(&str, &str)` without allocation.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.