These four read a credential that rotates with --schema, so unlike the roles
3c72c2002a moved onto platform_administrator they were already locked out
before that migration. Each wrote the password only at install time.
mediawiki passes --force to createAndPromote, which upstream documents as
'If account exists already, just grant it rights or change password'. The
password also leaves the host argv, which it previously entered directly. The
realign is gated on a new MEDIAWIKI_LOCAL_PASSWORD_LOGIN: with SSO on, oidc.php
sets wgPluggableAuth_EnableLocalLogin false, PluggableAuth then unregisters the
local password provider, and changeAuthenticationData answers 'ignored', which
createAndPromote turns into a fatal. Forcing the password unconditionally would
have broken every SSO-enabled deploy. Where local login is on the task reports
changed every run, because MediaWiki re-hashes unconditionally and offers no
verify primitive; a host-side digest marker was rejected because it would
survive a database reset and then skip the account creation.
pgadmin never re-read PGADMIN_DEFAULT_PASSWORD: the image exports it only when
/var/lib/pgadmin/pgadmin4.db is absent, and that path is a named volume. A new
manager-ops task waits for health and calls setup.py update-user. --admin is
mandatory there, because update_user reads data['role'] unguarded, and failures
such as 'User not found' exit 0, so the task detects success positively by the
User Details table. meta/services.yml gains name: pgadmin, without which
container_address hard-fails; it renders the same string entity_name already
produced, so no container is renamed.
suitecrm has no console command for an existing user's password, so the script
writes users.user_hash. SuiteCRM stores bcrypt over the md5 digest, not over the
plaintext, so hashing the plaintext would have locked the administrator out.
wordpress replaces the wp user update --prompt its own TODO.md proposed with
wp eval-file on stdin: the CLI cannot distinguish changed from unchanged and
trims the line it reads, while wp_check_password and wp_set_password do neither.
That TODO entry is removed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
kevinveenbirkenbachandClaude Opus 5