@maxcarpone You found it, and you were right. The & was the whole thing. It’s now fixed in
code, so you can put your original password back.
First, a correction to my earlier reply. I said the boot-menu password was
involved. It isn’t — the credentials you type during full registration are
entered in the FOS init and posted to service/auto.register.php, which is a
completely different path. Ignore that part of what I wrote.
What was actually wrong. Registration-with-deploy was HTML-escaping your
password before comparing it against the stored hash.
The registration handler read the username and password out of the request
after running it through a shared helper (stripAndDecode()) whose last step
is htmlspecialchars(). That is the right thing to do to a value you’re about
to print into a web page, and exactly the wrong thing to do to a value you’re
about to check against a password hash. So a password containing any of
& < > " '
reached the password check as its HTML entity form — yours was compared as
&... — and could never match. A leading or trailing space was lost too.
And your timing was exactly right. You said it worked up to 1734 and broke
by 2390. The escaping was added in 1.5.10.1830 (commit 05403ee0,
19 May 2026), which sits right inside that window. It was part of a
security-hardening change, and applying that sanitiser to a credential was an
unintended side effect of it.
That also explains everything else you saw:
- a brand new user worked, because you’d have given it a simple password
with none of those characters in it
fog worked in the web UI, and at service/checkcredentials.php, because
neither of those goes anywhere near that helper- only registration-with-deploy said “Invalid Login”
For anyone else finding this thread: it is not a keyboard-layout problem,
which is where I’d have looked next. Accented characters pass through untouched
— they aren’t HTML specials. It’s specifically those five characters.
Fixed on both branches, both merged:
The decode now lives in one place that registration and checkcredentials.php
share, so the two can’t disagree about the same password again, and it no longer
escapes anything. Verified end to end rather than by reading the code: real
POSTs to service/auto.register.php against a real database, on the unfixed
tree and the fixed one. Passw0rd is accepted by both; a password with an &
is rejected by the unfixed tree with your exact “Invalid Login” and accepted by
the fixed one.
Once you’re on a build carrying that, your original & password will work
again. No need to keep the changed one.
Still outstanding — the two MariaDB instances. That’s unrelated to this bug
and I’d still like it sorted, because two database servers on one box is a real
problem waiting to happen:
systemctl list-units 'maria*' 'mysql*'
ss -lntp | grep -E '3306|mysql'
If both are listening, the one FOG is talking to is whichever
/var/www/fog/lib/fog/config.class.php points at — and the other one is holding
a stale copy of your data that will look convincingly real the first time
something connects to it by accident.
On the blank/null task rows from your earlier queries: on your box there
were zero active ones. The blanks are completed and cancelled history for
hosts and images deleted over the years (about 300 hosts and 459 images since
2017), which is expected and harmless. The reaper added in this round only
touches tasks that are still active and can no longer run, so it won’t go near
that history.
