Failed to Update Database and Host

[Tom Elliott]

@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:

• dev-branch (1.5.10) — https://github.com/FOGProject/fogproject/pull/1398
• working-1.6 — https://github.com/FOGProject/fogproject/pull/1397

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.

[Tom Elliott]

@maxcarpone I would ask you, if you’re daring/willing (it’s considered beta but uses the same pipeline with a lot more modern ui, I need people testing, and Fog_newb can likely attest the new ui look and feel though I think they ran into an issue and needed to get functional right away so the snapshotted back)

Upgrade to working-1.6.

I have a goal (along with @JJ-Fullmer ) to try to get working-1.6 to be master/stable branch by October.

1.6 has been “stagnant” since around 2017 and was in relatively stable grounds back then even.

With AI (as you undoubtly can see I’m using to help drive some things) it’s allowed us to get a lot more coding/refactoring and will hopefully present a much better experience of things on the UI side. Without testing I cannot fix UI bugs though.

AI can do some cool things, but it doesn’t know what “wrong/right” looks like, and JJ and I are only 2 people.

There are others on working-1.6 but more feedback is always good.