fix: load ./.env only when private and owned, add --env-file and AEGIS_ENV_FILE (SEC-04)

docs/configuration.md

@@ -1,9 +1,28 @@
 # Configuration
 
 All settings are environment variables. They are read case-insensitively from the process
-environment and from a `.env` file in the working directory (the environment wins). Unknown
-variables are ignored. A blank value (`KEY=` in `.env`) counts as unset for the optional
-secrets, URLs and paths. List values accept commas or whitespace as separators.
+environment and from an env file (the environment always wins). Unknown variables are ignored.
+A blank value (`KEY=` in the env file) counts as unset for the optional secrets, URLs and
+paths. List values accept commas or whitespace as separators.
+
+## Which env file is read
+
+The env file is never trusted just because it sits in the working directory: MCP clients start
+stdio servers inside the project they work on, which can be a cloned repository carrying a
+planted `.env` that switches off secret masking or the audit log or points `GITEA_URL` at
+another host. The file is chosen in this order:
+
+1. `--env-file PATH` of `serve` (and `setup`): used as given. It must exist and be a regular
+   file.
+2. The `AEGIS_ENV_FILE` environment variable: same rules.
+3. `./.env`, but only when it is a regular file (not a symlink), owned by the user running the
+   server, with no group or other permissions (mode 0600, which `setup` writes). Otherwise it is
+   ignored and one warning goes to stderr that says why and how to fix it:
+   `chmod 600 .env`, or pass `--env-file`.
+
+Real environment variables take precedence over every file. A missing `./.env` is silent.
+Containers pass settings as environment variables (`env_file:` in compose), not through the
+working directory.
 
 `.env.example` is the annotated template. `uv run aegis-gitea-mcp setup` fills one in for you
 (see [getting-started.md](getting-started.md)). Secret settings never appear in logs, errors or