3.44.2 docker image

[Benjamin Hatfield]

Greetings,

We are long time users of Tickets, over 10 years now, and working to upgrade our infrastructure, moving from our old Windows server to a Docker container in the cloud. When I recently set up the new server and installed the most recent Docker container, it reports to be v3.44.1. Is there a containerized version of 3.44.2 or did I make some sort of error in my build?

Best regards,

 - Benjamin

[Eric Osterberg]

Hi Benjamin,

Good news first: you didn't make a build error. Your container has the v3.44.2 codebase — you already have all 88 security fixes. What you ran into is a leftover version string in our Docker auto-installer that I never bumped when v3.44.2 was tagged. The version label was wrong; the code under it was current the whole time.

Here's what was actually happening: when the auto-installer first boots a fresh container, it writes the install version into the settings table. Two lines in docker-autoinstall.php hardcoded the string '3.44.1' (not 3.44.2) and never got updated. The displayed version comes from that DB value, so even though every PHP file in the container matched the v3.44.2 release, the UI reported the older number. The 3.44.1 → 3.44.2 → 3.44.3 jump in the displayed version is purely a label fix; you have not been missing security patches.

Fix is now shipped as v3.44.3. The container image is already published to GitHub Container Registry. You can update at your convenience with:

docker compose pull
docker compose up -d

New containers will display 3.44.3 from the start. For your existing container, the image upgrade alone won't rewrite the _version row in your database (the auto-installer only sets values on first boot). If you want the Config screen to reflect 3.44.3 without reinitializing, run one quick SQL:

docker exec ticketscad_db mariadb -u tickets -ptickets tickets \
  -e "UPDATE settings SET value = '3.44.3' WHERE name = '_version'"

Or, if you'd rather verify that your current container already has the v3.44.2 patches before you upgrade, here are two checks you can run right now:

# Show the version constant the source code declares:
docker exec ticketscad grep TICKETS_CURRENT_VERSION \
  /var/www/html/incs/versions.inc.php

# Confirm a specific v3.44.2 security patch is present
# (tables.php had its $_POST['table'] made safe with a whitelist):
docker exec ticketscad grep -c "whitelist\|sanitize_table" \
  /var/www/html/tables.php

If that second command prints >= 1, you have the 3.44.2 patches — which I'm confident you do, since the latest tag has been building from main continuously since April. The first command will say v3.44.1 on your current container (same root cause: that constant was never bumped either). After upgrading to 3.44.3 both checks will agree.

The structural improvement in this release is that the auto-installer now reads the version from one canonical source (incs/versions.inc.php) instead of hardcoding it. So future releases bump that one constant and the displayed version follows automatically — the drift that caused this bug can't happen again.

Release notes: https://github.com/openises/tickets/releases/tag/v3.44.3

Sorry for the confusion. Thanks for being on Tickets for 10+ years and for actually checking the version after the container build — that's exactly the right instinct, and it's the only reason we caught this.

If you have questions about the cloud migration itself (proxy/offline tile modes for outbound bandwidth, backup strategy in container land, anything else), I'm happy to help.

Best, Eric

--
You received this message because you are subscribed to the Google Groups "Open Source CAD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-source-c...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/open-source-cad/a55ce996-4a42-40b7-b002-fe244c855c21n%40googlegroups.com.