• Create PR with unit tests

Description

pacquet bugs splits the CLI spec on the last @ and treats the suffix as a registry tag/version,
so semver ranges like react@^18 are queried as literal tags (e.g. GET /react/^18) instead of
being resolved to a matching version like pnpm does. This causes lookups to 404 or derive the bugs
URL from the wrong manifest for common pnpm-style inputs.

Code

pacquet/crates/cli/src/cli_args/bugs.rs[R104-115]

+    let (package_name, tag) = parse_package_spec(spec);
+    let package_tag = match tag {
+        None => PackageTag::Latest,
+        Some(tag_str) => tag_str.parse::<PackageTag>().unwrap_or(PackageTag::Latest),
+    };
+    let package_version = PackageVersion::fetch_from_registry(
+        package_name,
+        package_tag,
+        http_client,
+        registry_url,
+        auth_headers,
+    )

Evidence

The Rust implementation derives package_name and tag via a last-@ split and then calls
PackageVersion::fetch_from_registry, which formats the request as
{registry}{encoded_name}/{tag}—this works for latest, exact versions, and dist-tags, but not
semver ranges. In pnpm’s reference implementation, bugs delegates to fetchPackageInfo, which
uses npm-package-arg parsing and resolves tag | version | range by selecting a matching version
from metadata before returning manifest fields.

pacquet/crates/cli/src/cli_args/bugs.rs[98-135]
pacquet/crates/cli/src/cli_args/bugs.rs[368-384]
pacquet/crates/registry/src/package_version.rs[251-283]
pnpm11/deps/inspection/commands/src/bugs/index.ts[60-70]
pnpm11/deps/inspection/commands/src/fetchPackageInfo.ts[26-87]

Agent prompt

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

## Issue description
`pacquet bugs` currently interprets the part after the last `@` as a dist-tag/version and calls `PackageVersion::fetch_from_registry(name, selector)`. This cannot implement pnpm’s behavior for semver *ranges* (and other npm-package-arg selectors), which require fetching metadata and selecting a version.
### Issue Context
Upstream pnpm’s `bugs` command calls `fetchPackageInfo(opts, packageSpec)`, which parses `packageSpec` using `@pnpm/npm-package-arg` and resolves `tag | version | range` by selecting the matching version from metadata.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/bugs.rs[98-135]
- pacquet/crates/cli/src/cli_args/bugs.rs[368-384]
### What to change
- Replace `parse_package_spec()` + direct `PackageVersion::fetch_from_registry()` with pnpm-equivalent parsing/resolution:
- Parse the spec using the existing Rust parsing stack (e.g. `pacquet_resolving_parse_wanted_dependency::parse_wanted_dependency`, similar to `docs`), and determine whether the selector is:
- tag (including custom tags)
- exact version
- semver range
- For semver ranges, fetch the packument/metadata (`Package::fetch_from_registry` or an equivalent full-metadata fetch already used elsewhere) and pick the matching version, then derive `bugs/repository` from that selected version’s manifest.
- If alias/unsupported spec types are provided, fail fast with a clear diagnostic (mirroring pnpm’s `INVALID_PACKAGE_NAME` behavior) rather than issuing a malformed registry request.

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

Description

PackageTag now accepts arbitrary custom tags, but PackageVersion::fetch_from_registry
interpolates {tag} directly into the request URL, so tags containing /, ?, or # can change
the effective request path/query and misroute authenticated registry requests. This can cause
incorrect lookups and expands the attack surface for request-target manipulation against the
configured registry origin.

Code

pacquet/crates/registry/src/package_version.rs[R262-266]

+        let encoded_name = pacquet_network::encode_package_name(name);
+        let url = format!("{registry}{encoded_name}/{tag}");
let network_error = |error| NetworkError { error, url: url.clone() };
let mut request = http_client.acquire_for_url(&url).await.get(&url).header(

Evidence

The PR makes arbitrary tags possible and then uses the tag string directly in the registry URL
format, which means reserved characters in tags can alter the request target.

pacquet/crates/registry/src/package_tag.rs[5-30]
pacquet/crates/registry/src/package_version.rs[251-275]
pacquet/crates/cli/src/cli_args/bugs.rs[96-113]

Agent prompt

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

## Issue description
`PackageTag` can now represent arbitrary dist-tags (e.g. `beta`, `next`). That tag value is formatted into the registry URL path as `{registry}{encoded_name}/{tag}` without percent-encoding the tag. Tags containing reserved characters (notably `/`, `?`, `#`) can mutate the request target (extra path segments, query injection), and since auth headers are attached to the URL, this can result in authenticated requests being sent to unintended endpoints on the same registry origin.
### Issue Context
- `PackageTag` parsing now never fails and will treat non-semver strings as a tag.
- Registry fetch builds a URL by string formatting and uses it both for the request and auth-header lookup.
### Fix Focus Areas
- pacquet/crates/registry/src/package_version.rs[262-274]
- pacquet/crates/registry/src/package_tag.rs[6-27]
- pacquet/crates/cli/src/cli_args/bugs.rs[102-113]
### Suggested fix
- Encode the tag as a single URL path segment before formatting the URL, e.g.:
- `let encoded_tag = pacquet_network::encode_uri_component(&tag.to_string());`
- `let url = format!("{registry}{encoded_name}/{encoded_tag}");`
- Add a regression test covering a tag containing `/` (should become `%2F`) and `?` (should become `%3F`) so the request path remains a single segment.

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

Description

get_bugs_url_from_registry converts PackageVersion::fetch_from_registry failures into
diagnostics without redacting the request URL, so a credential-bearing --registry/config value
(e.g. https://user:pass@host/) can be printed to terminal/CI logs on network/JSON errors. This
expands secret-exposure surface area via the new bugs command’s error paths.

Code

pacquet/crates/cli/src/cli_args/bugs.rs[R80-96]

+    let (package_name, _tag) = parse_package_spec(spec);
+    let encoded_name = encode_package_name(package_name);
+    let package_version = PackageVersion::fetch_from_registry(
+        &encoded_name,
+        PackageTag::Latest,
+        http_client,
+        registry_url,
+        auth_headers,
+    )
+    .await
+    .into_diagnostic()
+    .wrap_err_with(|| format!("fetch package info for \"{package_name}\" from the registry"))?;
+
+    let manifest = package_manifest_from_version(&package_version);
+    pick_bugs_url(&manifest)
+        .ok_or_else(|| BugsError::NoBugsUrlForPackage { package: package_name.to_string() }.into())
+}

Evidence

The new bugs command calls PackageVersion::fetch_from_registry(...).await.into_diagnostic()?, so
any RegistryError::Network will be displayed. PackageVersion::fetch_from_registry builds `url =
format!("{registry}{name}/{tag}") and wraps reqwest failures as NetworkError { url }`;
NetworkError’s Display is Failed to request {url}: {error}, which will include any embedded
credentials in registry. Existing CLI code (e.g. audit signatures) demonstrates the intended
mitigation pattern by redacting URLs/reasons before surfacing them.

pacquet/crates/cli/src/cli_args/bugs.rs[74-96]
pacquet/crates/registry/src/package_version.rs[252-282]
pacquet/crates/registry/src/lib.rs[18-24]
pacquet/crates/cli/src/cli_args/audit/signatures.rs[400-425]

Agent prompt

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

## Issue description
`pacquet bugs <pkg>` propagates `pacquet_registry::RegistryError` through `IntoDiagnostic`, and the underlying `NetworkError` `Display` includes the full request URL. If the registry base URL contains embedded credentials, those secrets can be printed in the diagnostic chain.
### Issue Context
Other CLI paths (e.g. `audit signatures`) explicitly call `redact_url_credentials(...)` before including URLs/reasons in user-visible errors; the new `bugs` command should do the same.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/bugs.rs[74-96]
- pacquet/crates/registry/src/lib.rs[18-24]
- pacquet/crates/registry/src/package_version.rs[252-282]
- pacquet/crates/cli/src/cli_args/audit/signatures.rs[400-425]
### Suggested fix approach
1. In `get_bugs_url_from_registry`, replace the `.into_diagnostic()?` propagation with explicit error mapping that **does not** print the raw `RegistryError` as a source if it contains URLs.
2. Pattern-match `RegistryError::Network(NetworkError { url, error })` and build a new diagnostic using:
- `redact_url_credentials(&url)` for the displayed URL
- `redact_url_credentials(&error.to_string())` for the displayed reason
- carry the original error only if you’re sure it won’t re-emit the raw URL; otherwise store it as a non-source string (like `audit/signatures.rs` does).
3. Ensure the resulting diagnostic still has an appropriate error code (existing commands often use `ERR_PNPM_REGISTRY_ERROR`-style codes for registry failures).

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

Description

open_url() prints the derived bugs URL verbatim, so inline user:pass@ credentials coming from
package.json or registry metadata can be leaked into terminal output/CI logs. The URL is then also
passed through to the browser launcher without redaction/stripping.

Code

pacquet/crates/cli/src/cli_args/bugs.rs[R282-287]

+fn open_url(url: &str) {
+    println!("{url}");
+    let result = open_url_in_browser(url);
+    if let Err(err) = result {
+        tracing::debug!(target: "pacquet_cli", %err, "could not open browser");
+    }

Evidence

The derived URL can come directly from manifest bugs (returned as-is when it parses as http(s))
and is printed verbatim by open_url(). The repo already treats user:pass@ in URLs as sensitive
and provides a redaction helper used by ping before printing.

pacquet/crates/cli/src/cli_args/bugs.rs[141-150]
pacquet/crates/cli/src/cli_args/bugs.rs[282-287]
pacquet/crates/cli/src/cli_args/ping.rs[70-78]
pacquet/crates/network/src/auth.rs[460-479]

Agent prompt

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

## Issue description
`pacquet bugs` prints the bugs URL to stdout via `println!("{url}")`. If the URL contains embedded basic-auth (`https://user:pass@host/...`), those credentials are leaked into terminal output and CI logs.
### Issue Context
The repo already has a dedicated credential redaction utility (`pacquet_network::redact_url_credentials`) and uses it before printing untrusted URLs in other commands (e.g. `ping`).
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/bugs.rs[282-287]
- pacquet/crates/cli/src/cli_args/bugs.rs[141-165]
### Expected fix
- Redact credentials before printing (at minimum).
- Prefer also stripping userinfo before launching the browser (parse with `url::Url`, clear username/password, and open the cleaned URL), since bug tracker URLs should not require embedded credentials.
- Reuse the existing redaction helper (`pacquet_network::redact_url_credentials`) to match established repo behavior.

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

Description

open_url() prints a bugs URL derived from attacker-controlled registry/package.json data without
stripping control characters, enabling terminal escape/control-sequence injection when users run
pacquet bugs . The repo already has a sanitize() helper specifically to prevent raw escape
sequences reaching the terminal, but it isn’t used here.

Code

pacquet/crates/cli/src/cli_args/bugs.rs[R282-287]

+fn open_url(url: &str) {
+    println!("{url}");
+    let result = open_url_in_browser(url);
+    if let Err(err) = result {
+        tracing::debug!(target: "pacquet_cli", %err, "could not open browser");
+    }

Evidence

The new command prints a URL directly to stdout, and that URL originates from untrusted package
metadata. The repository already includes a dedicated sanitizer to strip control characters
specifically to prevent terminal escape sequences from untrusted metadata, and it’s used in other
registry-facing code paths but not in bugs.

pacquet/crates/cli/src/cli_args/bugs.rs[275-288]
pacquet/crates/cli/src/cli_args/sanitize.rs[3-17]
pacquet/crates/cli/src/cli_args/dist_tag.rs[424-440]

Agent prompt

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

## Issue description
`pacquet bugs` prints a URL to stdout via `println!("{url}")` without sanitizing control characters. Since the URL is derived from attacker-controlled manifest/registry metadata, this allows terminal escape injection.
### Issue Context
The CLI already has `cli_args::sanitize::sanitize()` with explicit intent to prevent stored/registry-derived metadata from emitting raw escape sequences.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/bugs.rs[282-287]
- pacquet/crates/cli/src/cli_args/sanitize.rs[3-17]
### Suggested fix
- Use the existing sanitizer when printing, e.g.:
- `use crate::cli_args::sanitize::sanitize;`
- `println!("{}", sanitize(url));`
- Consider also sanitizing the string passed to the browser launcher (or at least reject/strip control chars) to keep behavior consistent across stdout and side effects.

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

Description

On Windows, open_url_in_browser() runs Command::new("rundll32.exe"), which relies on Windows
executable search order and can be hijacked by a malicious rundll32.exe placed in the working
directory of an untrusted project. This enables code execution when a user runs pacquet bugs
inside that directory.

Code

pacquet/crates/cli/src/cli_args/bugs.rs[R311-320]

+#[cfg(target_os = "windows")]
+fn open_url_in_browser(url: &str) -> std::io::Result<()> {
+    // Pass the URL as a direct argument to rundll32; it is never fed through
+    // cmd.exe, so shell metacharacters in the URL (e.g. `&`, `|`, `^`) cannot
+    // be re-parsed as command separators.
+    std::process::Command::new("rundll32.exe")
+        .args(["url.dll,FileProtocolHandler", url])
+        .stdout(std::process::Stdio::null())
+        .stderr(std::process::Stdio::null())
+        .spawn()?;

Evidence

The code explicitly spawns rundll32.exe by name, not by absolute path, which is sufficient to
establish reliance on Windows search-path resolution for executable lookup.

pacquet/crates/cli/src/cli_args/bugs.rs[311-321]

Agent prompt

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

## Issue description
The Windows URL opener uses `Command::new("rundll32.exe")` with a bare executable name. On Windows this can resolve via the standard search order (including the current working directory), enabling binary planting/hijacking.
### Issue Context
This is a new process-execution surface introduced by the `bugs` command. The URL argument is not the problem here; the executable resolution is.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/bugs.rs[311-321]
### Suggested fix
- Resolve and invoke the absolute path to the system `rundll32.exe` instead of relying on search order.
- Commonly: `%SystemRoot%\\System32\\rundll32.exe` (obtain via `std::env::var("SystemRoot")`/`WINDIR`).
- If the environment variable is missing, fall back to `C:\\Windows\\System32\\rundll32.exe` or return an error.
- Consider also setting `.stdin(Stdio::null())` for consistency with stdout/stderr suppression.

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

Description

get_bugs_url_from_registry percent-encodes the package name and passes the encoded value into
PackageVersion::fetch_from_registry, which also uses that name for scope-aware auth header
lookup. This breaks scope detection for @scope/pkg (now @scope%2Fpkg), causing missing or wrong
credentials for private scoped registries.

Code

pacquet/crates/cli/src/cli_args/bugs.rs[R104-112]

+    let (package_name, _tag) = parse_package_spec(spec);
+    let encoded_name = encode_package_name(package_name);
+    let package_version = PackageVersion::fetch_from_registry(
+        &encoded_name,
+        PackageTag::Latest,
+        http_client,
+        registry_url,
+        auth_headers,
+    )

Evidence

The bugs command encodes package_name and passes it as name into the registry fetch; the
registry fetch uses name both to construct the URL and to select an auth header. Auth scope
detection requires a literal / in @scope/pkg, so encoding to @scope%2Fpkg prevents scoped
credentials from matching.

pacquet/crates/cli/src/cli_args/bugs.rs[98-120]
pacquet/crates/registry/src/package_version.rs[252-273]
pacquet/crates/network/src/auth.rs[197-237]
pacquet/crates/network/src/auth.rs[311-321]

Agent prompt

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

## Issue description
`pacquet bugs` encodes scoped names for the URL path, but the encoded string is also used as the package name for auth selection, which relies on the *raw* `@scope/pkg` form (with a literal `/`). This prevents package-scope credential matching and can break private scoped package lookups.
### Issue Context
- `encode_package_name("@scope/pkg")` returns `"@scope%2Fpkg"`.
- `AuthHeaders::for_url_with_package(..., Some(pkg_name))` uses `pkg_name.split_once('/')` to infer a scope; the encoded name no longer contains `/`.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/bugs.rs[104-115]
- pacquet/crates/registry/src/package_version.rs[252-273]
- pacquet/crates/network/src/auth.rs[197-237]
### Proposed fix
- Pass the **raw** `package_name` for auth scope detection, while still using the **encoded** name in the request URL path.
- Prefer fixing this at the registry client layer so all callers can safely fetch scoped packages:
- Change `PackageVersion::fetch_from_registry` to accept the raw name and internally percent-encode only for the URL path, but pass the raw `name` to `auth_headers.for_url_with_package(&url, Some(raw_name))`.
- Update any existing callers that might already pass encoded names to pass raw names instead (and add a regression test for scoped auth selection during a scoped package version fetch).

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

Description

BugsArgs::run computes one registry_url from config.registry (or --registry) and uses it for
all package lookups, ignoring per-scope registry routing. This breaks multi-registry setups (e.g.
GitHub Packages for @org/*) and diverges from upstream behavior which picks the registry per
package name.

Code

pacquet/crates/cli/src/cli_args/bugs.rs[R57-68]

+            let registry_url =
+                normalize_registry_url(self.registry.as_deref().unwrap_or(&config.registry));
+            let http_client = build_registry_client(config)
+                .wrap_err("build the network client for registry requests")?;
+
+            for spec in &self.packages {
+                let url = get_bugs_url_from_registry(
+                    spec,
+                    &registry_url,
+                    &http_client,
+                    &config.auth_headers,
+                )

Evidence

The new bugs command hardcodes a single registry URL for all lookups. The codebase already
provides a scope-aware pick_registry_for_package helper and uses it elsewhere, and the upstream
TypeScript implementation picks the registry per package.

pacquet/crates/cli/src/cli_args/bugs.rs[51-73]
pacquet/crates/lockfile/src/resolution.rs[360-389]
pacquet/crates/cli/src/cli_args/outdated.rs[124-138]
pnpm11/deps/inspection/commands/src/fetchPackageInfo.ts[47-56]

Agent prompt

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

## Issue description
`pacquet bugs` uses only the default registry (or a single CLI override) for all package specs, rather than routing by scope. This causes scoped packages that are configured to use a different registry to be queried against the wrong endpoint.
### Issue Context
The repo already has scope-aware registry routing logic (`pick_registry_for_package`) and other commands use it (e.g. `outdated`). Upstream pnpm uses `pickRegistryForPackage(opts.registries, packageName)` inside `fetchPackageInfo`.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/bugs.rs[52-73]
- pacquet/crates/lockfile/src/resolution.rs[360-389]
### Proposed fix
- If `--registry` is provided, keep current behavior (force all lookups to that registry).
- Otherwise, for each `spec`:
1. Parse out `package_name`.
2. Compute `registries: HashMap<String, String> = config.resolved_registries().into_iter().collect()`.
3. Select the registry via `pick_registry_for_package(&registries, package_name, Some(spec))`.
4. Normalize the selected registry URL and use it for that package’s fetch.
- Add an integration test that sets `@scope:registry=...` and verifies the request goes to the scoped registry host.

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

Description

repository_to_issues_url routes hosted shorthands through try_hosted_git_shorthand, but
split_user_project only strips a trailing .git and leaves #/? intact. Inputs like
github:owner/repo#main or owner/repo.git#main therefore produce malformed URLs (e.g.
https://github.com/owner/repo#main/issues), so pacquet bugs opens the wrong page or a broken
URL.

Code

pacquet/crates/cli/src/cli_args/bugs.rs[R228-262]

+fn try_hosted_git_shorthand(s: &str) -> Option<String> {
+    if let Some(rest) = s.strip_prefix("github:") {
+        let (user, project) = split_user_project(rest)?;
+        return Some(format!("https://github.com/{user}/{project}/issues"));
+    }
+    if let Some(rest) = s.strip_prefix("gitlab:") {
+        let (user, project) = split_user_project(rest)?;
+        return Some(format!("https://gitlab.com/{user}/{project}/issues"));
+    }
+    if let Some(rest) = s.strip_prefix("bitbucket:") {
+        let (user, project) = split_user_project(rest)?;
+        return Some(format!("https://bitbucket.org/{user}/{project}/issues"));
+    }
+
+    // `owner/repo` shorthand — only when no ':', '//', or '@' is present,
+    // to avoid matching git+https://, git@, etc.
+    if !s.contains(':') && !s.contains("//") && !s.contains('@') {
+        let (user, project) = split_user_project(s)?;
+        return Some(format!("https://github.com/{user}/{project}/issues"));
+    }
+
+    None
+}
+
+/// Split a `user/project` string, stripping a trailing `.git` suffix.
+fn split_user_project(s: &str) -> Option<(&str, &str)> {
+    let s = s.trim_end_matches(".git");
+    let slash_pos = s.find('/')?;
+    let user = &s[..slash_pos];
+    let project = &s[slash_pos + 1..];
+    if user.is_empty() || project.is_empty() {
+        return None;
+    }
+    Some((user, project))
+}

Evidence

The new shorthand path runs before URL parsing, so fragments/queries are never stripped for
shorthand-derived URLs; split_user_project only trims .git. Pacquet’s own hosted-git parser
explicitly separates a #committish fragment, indicating these suffixes are expected in shorthand
inputs, and pnpm’s upstream implementation delegates these cases to hosted-git-info.

pacquet/crates/cli/src/cli_args/bugs.rs[167-262]
pacquet/crates/resolving-git-resolver/src/hosted_git.rs[148-206]
pacquet/crates/resolving-npm-resolver/src/parse_bare_specifier/tests.rs[244-254]
pnpm11/deps/inspection/commands/src/bugs/index.ts[86-106]

Agent prompt

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

## Issue description
`try_hosted_git_shorthand()` builds issues URLs directly from the raw shorthand string, but `split_user_project()` only removes a trailing `.git`. When the repository string includes a fragment/query (commonly `#main`), that suffix becomes part of the generated path (e.g. `.../repo#main/issues`).
## Issue Context
- This affects hosted shorthands (`github:owner/repo#main`, bare `owner/repo#main`) and can also affect the SCP-style SSH branch (`[email protected]:owner/repo.git#main`).
- Pacquet already has hosted-git parsing logic that treats `#committish` as a separate component.
## Fix Focus Areas
- pacquet/crates/cli/src/cli_args/bugs.rs[173-262]
## Recommended fix
1. Before calling `split_user_project()` (and before `.trim_end_matches(".git")`), strip any `#...` fragment and `?...` query from the shorthand input.
- For example:
- `let base = s.split_once('#').map(|(a, _)| a).unwrap_or(s);`
- then similarly strip `?`.
2. Apply the same stripping to the SCP-style SSH path branch (`git@host:path.git#ref`).
3. Add unit tests in `pacquet/crates/cli/src/cli_args/bugs/tests.rs` covering at least:
- `repository_to_issues_url("github:owner/repo#main") == Some("https://github.com/owner/repo/issues")`
- `repository_to_issues_url("owner/repo.git#main") == Some("https://github.com/owner/repo/issues")`
- `repository_to_issues_url("[email protected]:owner/repo.git#main") == Some("https://github.com/owner/repo/issues")`
(Alternative: reuse `HostedGit::from_url()` from `pacquet/crates/resolving-git-resolver` and ignore committish when constructing the issues URL.)

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

Description

get_bugs_url_from_registry passes scoped package names (e.g. @scope/pkg) unescaped into
PackageVersion::fetch_from_registry, which constructs {registry}{name}/{tag} and yields
/@scope/pkg/latest. Registries/CDNs that require scoped names to be a single encoded path segment
(@scope%2Fpkg) will 404, breaking pacquet bugs @scope/pkg.

Code

pacquet/crates/cli/src/cli_args/bugs.rs[R103-114]

+    let (package_name, _tag) = parse_package_spec(spec);
+    let package_version = PackageVersion::fetch_from_registry(
+        package_name,
+        PackageTag::Latest,
+        http_client,
+        registry_url,
+        auth_headers,
+    )
+    .await
+    .into_diagnostic()
+    .wrap_err_with(|| format!("fetch package info for \"{package_name}\" from the registry"))?;
+

Evidence

The new bugs command uses PackageVersion::fetch_from_registry with the raw package name; that
registry fetcher formats the request URL by concatenation without encoding. Elsewhere in the repo,
registry URL construction explicitly requires encoding scoped names (to avoid 404) and tests assert
requests are made to /@scope%2Fpkg.

pacquet/crates/cli/src/cli_args/bugs.rs[97-118]
pacquet/crates/registry/src/package_version.rs[251-283]
pacquet/crates/resolving-npm-resolver/src/registry_url.rs[1-12]
pacquet/crates/resolving-npm-resolver/src/fetch_full_metadata/tests.rs[95-147]

Agent prompt

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

## Issue description
`pacquet bugs` registry lookups build a URL with an unencoded scoped package name (contains `/`). This produces request paths like `/@scope/pkg/latest` instead of `/@scope%2Fpkg/latest`, which can fail against registries/CDNs that canonicalize paths.
### Issue Context
The repo already documents and tests that scoped package names must be percent-encoded for registry URL paths.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/bugs.rs[97-118]
### Suggested fix
- Encode the package name for the URL path before the request (preserve the *raw* name for auth scope selection).
- Option A (localized): build the request URL using `pacquet_resolving_npm_resolver::registry_url::encode_pkg_name_path` / `to_registry_url`, then append `/latest`.
- Option B (more general): update `pacquet_registry::PackageVersion::fetch_from_registry` to accept raw names and internally percent-encode the name when composing the URL, while still passing the raw name into `AuthHeaders::for_url_with_package`.

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

Description

open_url_in_browser on Windows runs cmd /c start  with a URL derived from package.json or
registry metadata; URLs containing & (valid in query strings) will be interpreted by cmd.exe as
command separators, enabling arbitrary command execution when a user runs pacquet bugs on Windows.
This introduces an RCE path from attacker-controlled package metadata to shell execution.

Code

pacquet/crates/cli/src/cli_args/bugs.rs[R309-316]

+#[cfg(target_os = "windows")]
+fn open_url_in_browser(url: &str) -> std::io::Result<()> {
+    std::process::Command::new("cmd")
+        .args(["/c", "start", url])
+        .stdout(std::process::Stdio::null())
+        .stderr(std::process::Stdio::null())
+        .spawn()?;
+    Ok(())

Evidence

The Windows implementation passes the URL to cmd /c start (shell parsing), and the URL is derived
from manifest/registry fields. The repo’s executor code explicitly calls out that shell-wrapped
Windows invocations are unsafe due to argument escaping/CVE history, supporting that this is a
recognized dangerous pattern.

pacquet/crates/cli/src/cli_args/bugs.rs[51-72]
pacquet/crates/cli/src/cli_args/bugs.rs[139-160]
pacquet/crates/cli/src/cli_args/bugs.rs[309-316]
pacquet/crates/executor/src/shell.rs[14-17]

Agent prompt

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

## Issue description
On Windows, the URL opener uses `cmd /c start <url>` with an unquoted URL that originates from untrusted manifest/registry data. In `cmd.exe`, metacharacters like `&` are parsed as command separators unless safely quoted/escaped, which can lead to command injection.
## Issue Context
- The URL comes from `pick_bugs_url()` reading `bugs`/`repository` fields (registry metadata and local manifests are attacker-controlled per repo security model).
- The repo already documents that shell-wrapped Windows invocations are unsafe due to argument re-escaping risks (see executor shell selection comments).
## Fix Focus Areas
- pacquet/crates/cli/src/cli_args/bugs.rs[280-317]
### Suggested fix direction
Prefer a non-shell Windows launcher (e.g. `explorer.exe <url>` or Windows API `ShellExecuteW`) so the URL is not interpreted by `cmd.exe`. If you must keep `cmd start`, pass a *single* `/c` command string that safely quotes the URL and includes an empty title, e.g. `cmd /d /s /c start "" "{url}"`, ensuring the URL is inside quotes.

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