[jsokol]

Summary

Targets testing (the RC branch; promotion to master is a separate step). Merged up to date with testing after #178 (APACHE_MAX_REQUEST_WORKERS); the only conflict was the workflow's test-step list, where all steps are kept.

Addresses #83. Adds file_env to the simplerisk-minimal entrypoint: for each supported variable, VAR_FILE=/run/secrets/<name> loads the value from that file (trailing newline stripped), following the convention used by the official MySQL/MariaDB/WordPress images.

• Supported: DB_SETUP_USER/PASS, SIMPLERISK_DB_HOSTNAME/PORT/USERNAME/PASSWORD/DATABASE, SIMPLERISK_CSRF_SECRET, MAIL_USERNAME/PASSWORD, ADMIN_USERNAME/PASSWORD
• Setting both VAR and VAR_FILE, or an unreadable _FILE path, exits with a clear error
• Runs before the "Docker-managed config" detection, so a _FILE-only setup still triggers config provisioning
• _FILE vars are unset after loading; README gets a "Secrets" section with a compose example

Hardening included (credential values with metacharacters)

Secrets from a secret manager commonly contain ", ', \, $, backticks, &, | and newlines. Several existing sinks mishandled those, so they are fixed here:

1. mysql setup/delete interpolated values into a bash -c string -> now an argv array (mysql_setup), password via MYSQL_PWD, SQL on stdin with escaped string literals/identifiers.
2. csrf-secret.php wrote the secret into a double-quoted PHP string -> now an escaped single-quoted string. (A secret that relied on $/escape interpolation previously broke; it is now taken literally.)
3. sed_escape broke on newlines, and config.php defines did not escape '/\ -> config_define PHP-escapes then sed-escapes; sed_escape uses parameter expansion.
4. apply_mail_setting passed the DB password on the command line (visible in ps) -> MYSQL_PWD, and values are escaped with sql_str_escape.
5. Mail settings were silently skipped on MySQL 8: apply_mail_setting forced --ssl-mode=DISABLED, so caching_sha2_password refused the app user's first login ("Authentication requires secure connection"). Reproduced on the published 20261020-001 image with plain passwords. It now uses the client default (PREFERRED, TLS when the server offers it).

Verification

Built the image from this branch and ran it against mysql:8.0 with secrets mounted as files, using hostile values (e.g. app password a"b$(touch /tmp/PWNED)c'd\e&f|g;h, DB user sr"user):

• DB_SETUP=automatic: schema loaded, app user created, 155 tables, admin user created from ADMIN_PASSWORD_FILE, HTTPS returns 200
• config.php and csrf-secret.php evaluate in PHP back to the exact secret values; the app user logs in to MySQL with the hostile password
• No injected command executed (/tmp/PWNED* absent in app and MySQL containers)
• DB_SETUP=delete removes the database and user; a hostile DB name (db"x'y) and user (u'"x) are created exactly
• PID 1 (supervisord/Apache) has no secret or _FILE variables in its environment
• VAR + VAR_FILE together, and a missing file, exit 1 with a clear message
• Mail settings on a fresh MySQL 8 (cold auth cache): plain-password scenario that failed on 20261020-001 now stores all four settings; with hostile secret files the stored phpmailer_password/phpmailer_username match the files byte for byte (hex compared)
• test_file_env.sh, test_escaping.sh and Add APACHE_MAX_REQUEST_WORKERS to simplerisk-minimal #178's test_set_apache_workers.sh pass in an image built from the merged tree (bash 5.2 / GNU sed); all run in container-validation; end-to-end scenarios re-run on the merged image

Known limitations / out of scope

• The DB password still lands in plaintext in config.php (and the CSRF secret in csrf-secret.php); this keeps secrets out of the container environment and compose files, not off the container's disk.
• The full-stack simplerisk image is unchanged (it generates its own DB passwords).
• The official mysql image's own entrypoint cannot take a root password containing ' or \; unrelated to this change.

🤖 Generated with Claude Code