install: send credentials embedded in a tarball URL as Basic authorization - #39025
install: send credentials embedded in a tarball URL as Basic authorization#39025robobun wants to merge 1 commit into
Conversation
…ation A dependency declared as http://user:pass@host/pkg.tgz (or a registry dist.tarball URL of that shape) was requested without any Authorization header. NetworkTask::for_tarball now splits the userinfo off the request URL and sends it as Authorization: Basic base64(user:pass), the header npm sends for such URLs. Credentials configured for the registry scope still take precedence when they apply to the tarball. The request URL no longer carries the userinfo, so the HTTP client's same-origin check keeps the header across a redirect within the host and error output prints the URL without the credentials.
|
Warning Review limit reached
Next review available in: 16 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
Comment |
|
Status: reproduced and fixed, waiting for CI.
|
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
I reviewed this PR and didn't find any bugs. Because it changes how Authorization headers are derived and sent for tarball downloads (credential handling, precedence vs. registry auth, redirect behavior), a human look would still be worthwhile.
Checked split_url_userinfo against scoped paths, empty userinfo, and multi-@ authorities — bounding on first /?# then last @ handles them.
Checked the HeaderBuilder two-pass count/append stays balanced for the URL-auth branch (debug_assert_eq!(content.len, content.cap) holds; npm-auth-type is correctly omitted).
Checked lifetimes: userinfo borrows the old url_buf and is fully consumed into a fresh Vec before the box is reassigned.
Checked that registry-scope credentials still win (header_count == 0 gate) and cross-origin redirects still strip the header (URL is requested without userinfo, so the existing origin compare works).
Extended reasoning...
Overview
The PR makes NetworkTask::for_tarball in src/install/NetworkTask.rs extract the userinfo from a tarball URL, send it as Authorization: Basic base64(userinfo), and request the URL without the userinfo. Two new helpers (split_url_userinfo, basic_authorization_from_userinfo) plus ~25 lines of integration in for_tarball. It adds 12 subprocess tests in test/cli/install/bun-install.test.ts and a doc line in docs/pm/cli/add.mdx.
Security risks
This is credential-handling code. The risks I looked for: leaking credentials to the wrong host (guarded — the existing HTTP client strips Authorization on cross-origin redirects, and stripping userinfo from the request URL means the origin comparison now works correctly for same-host redirects too), leaking registry credentials to a URL-specified host (unchanged — the origin match against the registry scope still gates send_auth, and registry credentials take precedence over URL ones when both apply), and printing credentials in error output (improved — the 401 error line now shows the URL without userinfo). The credentials sent are only those the user explicitly wrote in the URL for that host, or that a registry embedded in its own dist.tarball (in which case the registry already knows them). No new leak surface identified.
Level of scrutiny
High. Even though the change is small and closely follows npm's documented behavior (with a transcript against npm 11.16), it decides when and how an Authorization header is attached. Per the approval guidelines, auth-sensitive code should have a human sign-off regardless of apparent correctness.
Other factors
The implementation is careful: split_url_userinfo bounds the authority at the first /?# before searching for the last @, so /@scope/pkg paths are not misread (tested). The HeaderBuilder count/append two-pass stays byte-exact for the new branch (only Authorization counted and appended; npm-auth-type omitted for URL creds). Borrow of the old url_buf via userinfo ends before reassignment. Tests use local servers, port: 0, tempDir, await using, and concurrent stdout/stderr/exited drains, and cover the userinfo variant matrix, both linkers, redirects (same-host keeps, cross-host drops), the scoped-path guard, error-message redaction, and both precedence directions with registry credentials. No CODEOWNERS entry covers these paths. No prior human review comments to address.
|
Updated 10:28 AM PT - Aug 15th, 2026
❌ @robobun, your commit 25f7523 has some failures in 🧪 To try this PR locally: bunx bun-pr 39025That installs a local version of the PR into your bun-39025 --bun |
|
Folded into #38867. |
2 participants
Problem
"no-deps": "http://carol:s3cret@127.0.0.1:PORT/cdn/no-deps-1.0.0.tgz", is downloaded without anAuthorizationheader. A server that needs the credentials answers 401 and the install fails witherror: GET http://carol:s3cret@127.0.0.1:PORT/cdn/no-deps-1.0.0.tgz - 401(bun 1.4.0 andmain, hoisted and isolated linker). npm 11 installs the same package.json and sendsAuthorization: Basic Y2Fyb2w6czNjcmV0(base64("carol:s3cret")).http://token@127.0.0.1:PORT/x.tgz) does not reach the server at all: the request goes to the hostnametoken@127.0.0.1.NetworkTask::for_tarball(src/install/NetworkTask.rs) only ever attaches the registry scope's configured token or_auth, and only for npm packages whose tarball is on the registry's origin. Nothing reads the URL's userinfo, and the HTTP client does not either (it only turns the userinfo of a proxy URL intoProxy-Authorization). The misrouted username-only form comes frombun_url::URL::parse, which takestoken@127.0.0.1for the hostname when the userinfo has no:and a port follows (tracked separately; this change no longer depends on how that parser splits the authority).Fix
for_tarballsplits the userinfo off the request URL before anything else looks at it (split_url_userinfo: the authority runs from://to the first/,?or#, the userinfo is everything in it up to the last@, so the@of/@scope/pkg/-/pkg.tgzis not one) and sends it asAuthorization: Basic base64(userinfo)(basic_authorization_from_userinfo, which appends:when the userinfo has no password). The request URL is the URL without the userinfo._auth), they are still sent and the URL's are not. This is npm's order as well: npm-registry-fetch sets the header from the config, and node only derivesAuthorizationfrom the URL'sauthwhen the request has no such header.user:pass,user(sent asuser:),:passand a percent-encoded password (sent undecoded); transcript below. It is also how bun already treats credentials written into a registry URL (install: send credentials embedded in --registry and registry env var URLs #38796 stores the username and password bytes as given). pnpm was not available offline. Two spellings are deliberately not npm's: a second:inside the password is sent as written where npm percent-encodes it, and:token@in a tarball URL is Basic like npm rather than the Bearer that bun's registry URLs make of it; both are called out in the test table and in the code comment.bun_url::URL::originincludes the userinfo and the HTTP client compares origins to decide whetherAuthorizationfollows a redirect, so with the userinfo left in, a redirect to the same host would drop the header (verified: with only the header added, the redirect test below fails withauthorization: nullon the second hop). It also fixes the username-only form without touchingbun_url, and theGET <url> - 401line now prints the URL without the credentials. The cross-host rule is unchanged: the HTTP client strips the header on a redirect to another origin, same as for the registry token (test included).package.json, the lockfile, the task id and the cache key still use the URL as written. Documented indocs/pm/cli/add.mdx.test/cli/install/bun-install.test.ts,describe("credentials embedded in a tarball URL"): 12 tests, 10 of which fail on the unfixed build (the two guards, scoped path and registry credentials taking precedence, pass on both). The rest of the file is unchanged: the remaining failures locally are the tests that need the public internet, identical with the unmodified binary.cargo check -p bun_install,cargo clippy -p bun_install, rustfmt and prettier are clean.Background
package.jsonentry whose version is anhttp(s)://URL ending in.tgz/.tar.gz/.tar. Bun downloads it directly; no registry manifest is involved, so the registry's configured credentials never applied to it (Authorization::NoAuthorizationat the call sites inPackageManagerEnqueue.rs). Registry packages reach the samefor_tarballthrough their manifest'sdist.tarballURL withAllowAuthorization, which is the case where the registry scope's credentials can apply.user:password@part of a URL's authority (RFC 3986 section 3.2.1). HTTP never puts it on the wire; clients that honor it (npm through minipass-fetch, curl, browsers) convert it intoAuthorization: Basic base64(user:password).NetworkTask::for_tarballbuilds one HTTP request per tarball download:url_buf(the request URL) andheader_buf(the headers, built withHeaderBuilderin two passes,countthenappend, because the buffer is allocated exactly once in between). Retries reuse the same request, so the header is sent on every attempt.bun_url::URL::parseis the allocation-free splitter the HTTP client andfor_tarballuse; it is not a WHATWG parser. Itsoriginis a prefix of the input string, which is why it still contains the userinfo.npm 11.16 against a local server logging the Authorization header (same tarball, same package.json shape)
bun 1.4.0-canary.1 (eabb96d) for the first row: the server logs
auth=nulland bun printserror: GET http://carol:s3cret@127.0.0.1:PORT/cdn/no-deps-1.0.0.tgz - 401.