mirror of
https://github.com/ZoneMinder/zoneminder.git
synced 2026-10-28 17:28:33 -04:00
Isaac ConnorandClaude Opus 5.5
cbc2eaa334
zmconfgen.pl wrote zm_create.sql's Config rows without the Private and System columns, so a database created from it had both at 0 for every option until zmupdate.pl -f rewrote the table from ConfigData. The web UI relies on Private to keep a secret out of the browser: skin.js.php exports every option that isn't Private as a JavaScript constant on every page, the login page included, and the Options page shows a Private value only to users who can edit System settings (GHSA-7g3f-93q8-fhwj). So on such a database ZM_AUTH_HASH_SECRET, which is enough to sign an admin token, was sent to anyone who loaded the login page. A fresh RPM install is one: the spec runs zmupdate.pl -f only on upgrade. Debian packages run -f on install. - zmconfgen.pl writes Private and System like saveConfigToDB() does. - ZoneMinder::Config::syncConfigFlags() sets each row's Private and System flags from ConfigData without touching its value, and zmupdate.pl calls it on every update, so an existing database is repaired the next time it is updated without needing -f. - skin.js.php never exports a password option, whatever its flag says. Tested with zm_create.sql generated from this tree, loaded into a scratch database: the fresh install has the 3 Private options and 1 System option ConfigData marks. With every flag zeroed, syncConfigFlags() set those 4 rows and on a second run changed none. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>