Walkthrough

The default value of MaxUsers is changed from Unlimited to Disabled, so omitting auth.htpasswd.max_users in config now disables user self-registration. UserStore::in_memory gains a MaxUsers parameter; AuthState::load and AuthState::in_memory are updated accordingly. The error message, config.yaml, config tests, auth tests, and the test registry are all updated to reflect the new default.

Changes

Registration disabled by default

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested labels

product: pnpr

• X
• Mastodon
• Reddit
• LinkedIn

• Default missing "auth.htpasswd.max_users" to registration disabled (secure-by-default).
• Enforce the registration cap for in-memory user storage when no htpasswd file is configured.
• Update registry-mock/TestRegistry configs and add tests to preserve expected self-registration
 flows.

graph TD
  A["Operator YAML config"] --> B["build_auth_config"] --> C["AuthConfig max_users (default Disabled)"] --> D["AuthState::load"] --> E["UserStore (file/in-memory) w/ cap"] --> F["adduser: add_or_login"] --> G["Registration allowed/denied"]
  T["TestRegistry / registry-mock"] --> C

Loading

The following are alternative approaches to this PR:

1. Explicit boolean flag (e.g., auth.allow_registration)

• ➕ Clear intent and avoids overloading max_users semantics
• ➕ Can keep max_users purely as a cap when registration is enabled
• ➖ More config surface area and migration complexity
• ➖ Still needs careful defaults and interaction with existing configs

2. Keep current semantics but require explicit 'unlimited' token

• ➕ Preserves backward compatibility for operators relying on implicit unlimited
• ➕ Allows a deliberate opt-in to unlimited registrations
• ➖ Reintroduces a footgun if documentation/config examples are copied blindly
• ➖ Requires adding a custom YAML parsing token (since +inf doesn't parse as i64)

3. Disable adduser route by default unless explicitly enabled

• ➕ Strong separation between auth for token verification vs registration surface
• ➕ Reduces risk of accidental exposure even if caps are misconfigured
• ➖ Bigger behavioral/API surface change; could break clients expecting adduser availability
• ➖ Still needs cap enforcement once enabled

Recommendation: The PR’s approach (missing max_users => Disabled, and enforcing the cap in both file-backed and in-memory stores) is the best security tradeoff: it makes the unsafe default impossible while keeping the existing max_users mechanism as the single opt-in knob. The key additional win is closing the in-memory-store bypass so configuration intent is consistently enforced.

Bug fix (3) +39 / -24

auth.rsThread max_users into in-memory user store construction +17/-10

Thread max_users into in-memory user store construction

• Updates AuthState to pass the configured max_users into the in-memory UserStore when no htpasswd file is configured. Changes UserStore::in_memory to store the provided cap instead of hardcoding Unlimited, ensuring consistent enforcement.

pnpr/crates/pnpr/src/auth.rs

config.rsDefault missing max_users to Disabled and clarify semantics +15/-10

Default missing max_users to Disabled and clarify semantics

• Changes MaxUsers default to Disabled and updates the YAML-to-config mapping so an absent auth.htpasswd.max_users disables registration. Expands documentation to explain why pnpr deviates from Verdaccio’s implicit unlimited default and removes any YAML spelling for “unlimited”.

pnpr/crates/pnpr/src/config.rs

error.rsImprove error message for disabled registration default +7/-4

Improve error message for disabled registration default

• Updates RegistrationDisabled documentation and display string to reflect both cases: unset max_users (secure default) and explicit -1. Provides a clearer operator action: set a positive max_users to enable sign-ups.

pnpr/crates/pnpr/src/error.rs

Tests (3) +28 / -1

registry.rsOpt in to self-registration for TestRegistry fixtures +3/-0

Opt in to self-registration for TestRegistry fixtures

• Sets TestRegistry’s config to allow self-registration by explicitly setting max_users to Unlimited. Adds comments explaining why tests need registration enabled.

pacquet/crates/testing-utils/src/registry.rs

tests.rsAdd regression test for in-memory store registration cap +9/-0

Add regression test for in-memory store registration cap

• Adds a test asserting that the in-memory user store returns Forbidden when max_users disables registration. Documents the security invariant that missing htpasswd.file must not reopen sign-ups.

pnpr/crates/pnpr/src/auth/tests.rs

tests.rsUpdate config parsing expectations for opt-in registration +16/-1

Update config parsing expectations for opt-in registration

• Updates existing tests to expect Disabled when the auth block or max_users key is absent. Adds a new test to ensure an explicit htpasswd.file with missing max_users also disables registration.

pnpr/crates/pnpr/src/config/tests.rs

Other (1) +5 / -3

config.yamlMake mock registry explicitly enable registration +5/-3

Make mock registry explicitly enable registration

• Updates the bundled registry-mock configuration comments to reflect opt-in registration semantics. Sets max_users explicitly so integration tests can still create accounts.

pnpr/crates/pnpr/config.yaml

Description

pnpr falls back to the bundled DEFAULT_CONFIG_YAML when no config file exists, and this PR sets
auth.htpasswd.max_users: 1000 in that bundled YAML, which re-enables anonymous self-registration
for the default binary config. Because the same bundled config also sets `packages['**'].publish:
$authenticated and the registry mounts the adduser` endpoint, any unauthenticated client who can
reach the server can create an account, obtain a token, and publish/overwrite packages (until the
1000-user cap is hit).

Code

pnpr/crates/pnpr/config.yaml[R55-59]

+    # Maximum number of users allowed to self-register. Registration is
+    # opt-in: it stays disabled unless this is set to a positive number
+    # (set it to -1 to keep it disabled explicitly). This mock registry
+    # opts in so the test suite can create accounts.
+    max_users: 1000

Evidence

The bundled YAML is explicitly compiled into DEFAULT_CONFIG_YAML and used as the fallback config
source, and the registry router mounts the adduser route when the registry feature is enabled. The
bundled YAML sets both max_users: 1000 and publish: $authenticated on **, enabling the
anonymous-register-to-publish escalation if the server is reachable by untrusted clients.

pnpr/crates/pnpr/src/config.rs[19-40]
pnpr/crates/pnpr/src/main.rs[8-13]
pnpr/crates/pnpr/config.yaml[52-60]
pnpr/crates/pnpr/config.yaml[75-116]
pnpr/crates/pnpr/src/server.rs[280-305]
pnpr/crates/pnpr/src/server.rs[593-606]

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 bundled default config (`DEFAULT_CONFIG_YAML`) is used when no config file is found, but it currently opts into self-registration via `auth.htpasswd.max_users: 1000`. This undermines the goal of making self-registration opt-in by default, because exposing a default `pnpr` instance to untrusted clients still enables the `adduser` -> token issuance -> publish escalation path.

## Issue Context
- `DEFAULT_CONFIG_YAML` is compiled into the binary and used as a fallback when no `config.yaml` exists.
- The bundled YAML also includes `packages['**'].publish: $authenticated`, and the server mounts `PUT /-/user/org.couchdb.user:{name}` when the registry surface is enabled.

## Fix Focus Areas
- pnpr/crates/pnpr/config.yaml[52-60]

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

Description

AuthState::in_memory() hardcodes MaxUsers::Unlimited, but server::router()/try_router() build
routers with AuthState::in_memory() (in-memory auth) even when the registry surface is enabled,
bypassing the new opt-in default registration cap. Embedders using these helpers can unintentionally
re-open anonymous self-registration and token issuance (PUT /-/user/org.couchdb.user:{name}), which
combined with the default $authenticated publish policy enables anonymous-to-publisher escalation.

Code

pnpr/crates/pnpr/src/auth.rs[R129-140]

+    /// All-in-memory auth state for surfaces that never expose
+    /// registration: a resolver-only deployment (registry disabled, so
+    /// the adduser route is not mounted) and tests that don't care
+    /// about persistence. Registration is left uncapped here because no
+    /// untrusted caller can reach it; the production registration path
+    /// goes through [`Self::load`], which honors `auth.htpasswd.max_users`.
   #[must_use]
   pub fn in_memory() -> Self {
-        Self { users: Arc::new(UserStore::in_memory()), tokens: Arc::new(TokenStore::in_memory()) }
+        Self {
+            users: Arc::new(UserStore::in_memory(MaxUsers::Unlimited)),
+            tokens: Arc::new(TokenStore::in_memory()),
+        }

Evidence

The repo now defines the secure default as MaxUsers::Disabled (and YAML-absent maps to Disabled),
but AuthState::in_memory() still constructs an uncapped UserStore (Unlimited).
server::router()/try_router() use AuthState::in_memory() for embedders; when registry routes are
mounted, PUT /-/user/org.couchdb.user:{name} dispatches to add_user(), which calls
users.add_or_login() and then issues a bearer token. The bundled config’s default publish policy for
'**' is $authenticated, so any self-registered user can publish/overwrite packages.

pnpr/crates/pnpr/src/auth.rs[128-141]
pnpr/crates/pnpr/src/server.rs[148-168]
pnpr/crates/pnpr/src/server.rs[280-304]
pnpr/crates/pnpr/src/server.rs[592-606]
pnpr/crates/pnpr/src/server.rs[991-1030]
pnpr/crates/pnpr/src/config.rs[272-314]
pnpr/crates/pnpr/src/config.rs[945-983]
pnpr/crates/pnpr/config.yaml[75-116]

Agent prompt

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

## Issue description
`MaxUsers` now defaults to `Disabled` (registration opt-in), but `server::router()` / `server::try_router()` still use `AuthState::in_memory()`, and `AuthState::in_memory()` hardcodes `MaxUsers::Unlimited`. This re-enables self-registration for any embedder using these helpers, contradicting the new secure default.
## Issue Context
- Production `serve()` goes through `AuthState::load()` and is safe.
- The public `router()` helper is explicitly for embedders and can mount the registry surface (and thus adduser).
## Fix Focus Areas
- pnpr/crates/pnpr/src/auth.rs[128-141]
- pnpr/crates/pnpr/src/server.rs[148-168]
- pnpr/crates/pnpr/src/config.rs[272-314]
### Suggested fix approach
- Add an in-memory constructor that takes a cap (e.g. `AuthState::in_memory_with_max_users(max_users: MaxUsers)`), or change `AuthState::in_memory()` to use `MaxUsers::Disabled` by default.
- Update `server::router(config)` and `server::try_router(config)` to construct in-memory auth that *honors* `config.auth.htpasswd.max_users` (so the new secure default applies to embedders too).
- Update the doc comment on `AuthState::in_memory()` to avoid asserting registration is unreachable unless that is guaranteed by construction.

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

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

• ❄️ 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.