5706498565
Five apps (mastodon, owncloud, mattermost, matrix, stoat) took their generated secrets from the compose-side generator tags PASSWORD_TAG_<n>/RANDOM_TAG_<n>/ HEX_TAG_<n>/VAPID_TAG_<n>. Those mint a fresh secret on every templating run, so a reinstall handed the app a new database password while its data volume kept the one initdb was given, and the app came back up unable to open its own database. Move them to <app>.config as RANDOMIZED* placeholders, reaching the compose via the #LIBREPORTAL|<APP>_<KEY>_TAG| mechanism tags_processor_app_config_values already provides. No new handler: the tag name is derived from the config key, so this is a config line plus a tag per secret. Generation is unchanged — still random on first install; the value is now remembered instead of re-rolled. Also fixes two things this exposed: - The RANDOMIZED* replacers matched unanchored. `sort -u` orders slots lexically (1, 10, 11, 2), so slot 1's pattern rewrote the prefix inside slot 10's placeholder and slots 10+ ended up holding slot 1's secret with a digit glued on — derivable, and invisible because the values weren't byte-identical. Anchoring with \b makes match order irrelevant. Verified at 20 slots across all four placeholder types: 64 keys, 64 distinct values, no prefix collisions. - generateRandomPassword drew from base64 without constraining the mix; measured over 2000 draws, 1 in 40 contained no digit at all. Retry until the result has both a digit and a letter, bounded so a pathological length can't spin. owncloud gains a fix in passing: its compose seeded the admin account from PASSWORD_TAG_2 while the WebUI displayed CFG_OWNCLOUD_ADMIN_PASSWORD, which was generated separately and never used. Both now read the same value. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
28 lines
1.2 KiB
Bash
Executable File
28 lines
1.2 KiB
Bash
Executable File
#!/bin/bash
|
|
|
|
replacePlainPasswords()
|
|
{
|
|
local file="$1"
|
|
|
|
# Only scan for placeholders that actually exist in the file.
|
|
#
|
|
# The \b on the substitution below is load-bearing once a file uses ten or
|
|
# more slots. `sort -u` orders these lexically — 1, 10, 11, 2 — so an
|
|
# unanchored `s/RANDOMIZEDPASSWORD1/<secret>/g` runs first and rewrites the
|
|
# RANDOMIZEDPASSWORD1 *inside* RANDOMIZEDPASSWORD10, leaving slot 10 holding
|
|
# slot 1's secret with a stray "0" on the end. Slots 10+ then share a secret
|
|
# derivable from slot 1, and nothing downstream notices because the values
|
|
# aren't byte-identical. The word boundary makes the match order irrelevant.
|
|
local existing_placeholders=$(runCfgOp grep -oE 'RANDOMIZEDPASSWORD[0-9]+' "$file" 2>/dev/null | sort -u)
|
|
|
|
if [[ -n "$existing_placeholders" ]]; then
|
|
while IFS= read -r password_placeholder; do
|
|
if [[ -n "$password_placeholder" ]]; then
|
|
local random_password=$(generateRandomPassword)
|
|
runCfgOp sed -i 's/'"${password_placeholder}"'\b/'"${random_password}"'/g' "$file"
|
|
checkSuccess "Updated ${password_placeholder} in $(basename "$file")."
|
|
fi
|
|
done <<< "$existing_placeholders"
|
|
fi
|
|
}
|