Fix SYSDBA.password not working in Firebird 3 images

[fdcastel]

Fixes #47.

Problem

In a Firebird 3 container started without FIREBIRD_ROOT_PASSWORD, SYSDBA cannot log in with the password from /opt/firebird/SYSDBA.password. Every Srp login fails with Install incomplete, please read the Compatibility chapter in the release notes for this version. This reproduces on every published FB3 image (all tags and distros). FB4 and FB5 are not affected.

Root cause: the FB3 installer sets the SYSDBA password it generates with gsec -add sysdba -pw <password> (setDBAPassword() in install.sh), and then writes that password to SYSDBA.password. FB3's gsec, libfbclient and libSrp.so link against libtommath.so.0 and libncurses.so.5/libtinfo.so.5, but our template only provided those in two RUN steps after ./install.sh -silent. During the build gsec failed with:

/opt/firebird/bin/gsec: error while loading shared libraries: libtommath.so.0: cannot open shared object file: No such file or directory

The installer's runSilent wrapper prints the error and continues. The image then ships the tarball's security3.fdb unchanged: no Srp user and no PLG$SRP table, since the Srp user manager only creates it when a user is first added through it. SYSDBA.password holds a password that was never set.

This went unnoticed because FIREBIRD_ROOT_PASSWORD (used in every README example) and FIREBIRD_USER both add users through Srp at container start, which creates the missing structures. No test covered a stock container.

Fix

• src/Dockerfile.template: the FB3-only libtommath.so.0 symlink and the libncurses5/libtinfo5 provisioning (D-017) now run inside the main RUN step, after the prerequisite apt-get install and before ./install.sh -silent. The installer's own gsec call then succeeds, so SYSDBA.password matches the real SYSDBA password. The provisioning logic is unchanged. It now reuses the main step's curl and apt lists, which that step's final purge/clean already removes, so the separate install/purge/clean commands are gone. As a side effect, FB3 builds no longer log Looks like standalone server failed to start. For FB4+ the new block is skipped by the FIREBIRD_MAJOR = 3 guard.
• src/image.tests.ps1:
  • New SYSDBA_password_file_allows_remote_login: a container with no environment variables must accept the SYSDBA.password credentials over inet:// (creating a database, then connecting to it), and reject a wrong password.
  • FIREBIRD_USER_can_create_user also checks that the SYSDBA.password credentials still work when only FIREBIRD_USER is set.
• DECISIONS.md: D-019 records the ordering constraint (amends where D-017's step sits).
• generated/: regenerated with Invoke-Build Prepare.

A separate commit bumps the Noble libncurses5/libtinfo5 pin from 6.3-2ubuntu0.2 to 6.3-2ubuntu0.3. archive.ubuntu.com has superseded 0ubuntu0.2 and it now returns 404, which breaks every FB3 Noble build (master included). Same kind of fix as 3f7921c.

Test plan

• Local: Invoke-Build Build + Invoke-Build Test for 3.0.14/noble: 27/27 green.
• Local: the two new or extended tests fail against the currently published firebirdsql/firebird:3.0.13 (Install incomplete / Your user name and password are not defined), so they catch the regression.
• Fork CI, targeted workflow_dispatch runs:
  • 3.0.14 / bookworm: 35879244703 — success
  • 3.0.14 / jammy: 35879453402 — success
  • 3.0.14 / noble: 35879631667 — success (validates the pin bump)
  • 4.0.7 / trixie: 35879822971 — success (regression check)
  • 5.0.4 / trixie, amd64 + arm64: 35879991989 — success (regression check)
• Fork publish-fork (all FB3 versions, trixie, build + full test suite before push): 35879036353 — success, full suite green for all six FB3 releases (3.0.9 → 3.0.14). Published as ghcr.io/fdcastel/firebird:3.0.x for the reporter to verify; the issue's exact repro (gsec -user sysdba -password "$PW" -di) now lists SYSDBA.

Known unrelated CI failure: bullseye

The push-triggered fork CI run (35878518319) fails on bullseye in the prerequisite apt-get install. deb.debian.org/debian-security returns 404 for the bullseye-security packages listed in its own index (curl, libcurl4, openssl, libicu67, libtommath1, …). A stock debian:bullseye-slim reproduces it with just apt-get update && apt-get install curl, with no Firebird involved. Bullseye LTS ended on 2026-08-31, so this looks like the archive transition of bullseye-security. It affects master equally and needs a separate decision (repoint to archive.debian.org, or drop/block bullseye). Because the fork CI's Build task stops at the first failed image, I validated the other distros with the targeted dispatch runs above.