npm installer HTTPS guard accepts insecure registry URLs

[afurm]

Component

Other: npm package postinstall fallback

Description

npm/src/install.mjs intends to reject non-local http:// registry and tarball URLs unless ALLOW_INSECURE_REGISTRY=true is set. The rejection is currently thrown inside a broad try block and then swallowed by the matching catch, so the guard silently accepts the same insecure HTTP URLs it is meant to reject.

The affected path is the manual fallback downloader used when the platform-specific optional dependency is unavailable. Registry configuration, registry metadata, and redirects all pass through makeRequest, which calls ensureSecureUrl before selecting NodeHttp or NodeHttps.

Minimal reproduction of the current guard behavior:

function ensureSecureUrl(urlString, purpose) {
  try {
    const url = new URL(urlString)
    if (url.protocol === 'http:') {
      const allowInsecure = process.env.ALLOW_INSECURE_REGISTRY === 'true'
      if (!['localhost', '127.0.0.1', '::1'].includes(url.hostname) && !allowInsecure) {
        throw new Error(`Refusing to use insecure HTTP for ${purpose}: ${urlString}`)
      }
    }
  } catch {
  }
}

ensureSecureUrl('http://example.com/@foundry-rs/forge', 'registry URL')
// accepted

Expected behavior:

• non-local http:// URLs are rejected by default
• http://localhost, http://127.0.0.1, and http://[::1] remain valid for local registry development
• ALLOW_INSECURE_REGISTRY=true remains an explicit override
• invalid URL strings can still fall through to the request layer as before

Version

Current master at 57755895027876db34b5bf4bcc7473cb949cd9c7.

Operating System

All platforms.

[zerosnacks]

Hi @afurm, thanks for your contribution. Is this an actual issue you are facing? If so, how does it impact you?

[afurm]

Thanks for checking. I’m not hitting it in my own install; I found it while reviewing the npm fallback installer.

Impact: the code intends to reject non-local http:// registry/tarball URLs unless ALLOW_INSECURE_REGISTRY=true, but the rejection is swallowed by the same catch used for URL parse errors. So that HTTPS guard is currently not enforced. Integrity metadata still limits impact, so this is mainly a transport hardening fix.