feat(meshcentral): restrict admin bootstrap and .env loading to debug builds (VS-28) #43

Merged

David merged 1 commit from feat/restrict-admin-bootstrap-debug-builds into main

2026-06-06 17:41:43 +02:00

David commented

2026-06-06 16:33:34 +02:00

Owner

VS-28: Restrict ADMIN_USERNAME/ADMIN_PASSWORD bootstrap and `./.env` loading to debug builds

Two dev conveniences in the meshcentral binary ran in every build, including the release binary shipped in the OCI image: the first-run admin bootstrap from ADMIN_USERNAME/ADMIN_PASSWORD, and unconditional ./.env loading via dotenvy. A production container could silently gain an env-credential site admin (siteadmin = 0xFFFFFFFF) and pick up a stray .env from its working directory; the bootstrapped user also made /api/setup return 404 before an operator saw the onboarding flow.

Changes

crates/meshcentral/src/main.rs: dotenvy::dotenv() is now #[cfg(debug_assertions)], so release binaries never read ./.env. The bootstrap module and the maybe_bootstrap_admin call are compiled out of release builds the same way. In the release path, if ADMIN_USERNAME or ADMIN_PASSWORD is present, a single warn! is logged pointing operators to setup mode (/api/setup) or meshcentral create-account. The check is a plain env read and does not pull in any bootstrap logic.
.env.example: the "First-run admin bootstrap (DEV ONLY)" block now states release binaries ignore these vars and do not read .env, and points to setup mode / create-account for production.
README.md: the setup-mode section notes the dev-only bootstrap is compiled out of release builds.

Mechanism is cfg!(debug_assertions) (no new feature flags or runtime knobs), which cleanly splits just dev from the --release OCI image. cargo test builds with debug_assertions on, so existing tests are unaffected.

Verification

cargo fmt --check: clean
cargo clippy --all-targets -- -D warnings: clean in both debug and release profiles (no dead_code from the cfg split)
cargo build -p meshcentral --all-targets: ok
cargo test --lib: ok

🤖 Generated with Claude Code

## VS-28: Restrict ADMIN_USERNAME/ADMIN_PASSWORD bootstrap and `./.env` loading to debug builds Two dev conveniences in the `meshcentral` binary ran in every build, including the release binary shipped in the OCI image: the first-run admin bootstrap from `ADMIN_USERNAME`/`ADMIN_PASSWORD`, and unconditional `./.env` loading via `dotenvy`. A production container could silently gain an env-credential site admin (`siteadmin = 0xFFFFFFFF`) and pick up a stray `.env` from its working directory; the bootstrapped user also made `/api/setup` return 404 before an operator saw the onboarding flow. ### Changes - `crates/meshcentral/src/main.rs`: `dotenvy::dotenv()` is now `#[cfg(debug_assertions)]`, so release binaries never read `./.env`. The `bootstrap` module and the `maybe_bootstrap_admin` call are compiled out of release builds the same way. In the release path, if `ADMIN_USERNAME` or `ADMIN_PASSWORD` is present, a single `warn!` is logged pointing operators to setup mode (`/api/setup`) or `meshcentral create-account`. The check is a plain env read and does not pull in any bootstrap logic. - `.env.example`: the "First-run admin bootstrap (DEV ONLY)" block now states release binaries ignore these vars and do not read `.env`, and points to setup mode / `create-account` for production. - `README.md`: the setup-mode section notes the dev-only bootstrap is compiled out of release builds. Mechanism is `cfg!(debug_assertions)` (no new feature flags or runtime knobs), which cleanly splits `just dev` from the `--release` OCI image. `cargo test` builds with `debug_assertions` on, so existing tests are unaffected. ### Verification - `cargo fmt --check`: clean - `cargo clippy --all-targets -- -D warnings`: clean in both debug and release profiles (no `dead_code` from the cfg split) - `cargo build -p meshcentral --all-targets`: ok - `cargo test --lib`: ok 🤖 Generated with [Claude Code](https://claude.com/claude-code)

David added 1 commit

2026-06-06 16:33:34 +02:00

feat(meshcentral): gate admin bootstrap and .env loading to debug builds

Check / fmt + clippy + build + tests (pull_request) Successful in 1m32s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

f8b31eece9

The first-run admin bootstrap (ADMIN_USERNAME/ADMIN_PASSWORD) and `./.env` loading were dev conveniences that still ran in release binaries, so a production container could silently gain an env-credential site admin and pick up a stray `.env` from its working directory. The bootstrapped user also made `/api/setup` return 404 before an operator saw the onboarding flow.

Gate both on `cfg!(debug_assertions)`: the `bootstrap` module and its call are compiled out of release builds, and `dotenvy::dotenv()` runs only in debug. Release builds that still have ADMIN_USERNAME/ADMIN_PASSWORD set log a single warn-and-ignore line (a plain env read, no bootstrap logic) pointing operators to setup mode or `create-account`. Debug builds (`just dev`, `cargo run`, `cargo test`) keep both behaviors unchanged. Updated `.env.example` and the README setup-mode section accordingly.

#VS-28