libredb-studio: refresh the pinned tag to 0.16.1 and fix two template defects - #758
yusuf-gundogdu wants to merge 6 commits into
Conversation
|
Hey @mms-gianni, I think this one is only waiting on your review to unblock now. It's the LibreDB Studio template bumped to 0.9.59 plus the supported arches, branch is current with main so nothing to rebase. Could you give it a look when you're next in the repo? Happy to change anything that looks off. |
|
any update ? |
|
Refreshed the pinned tag to 0.14.1. The branch still targeted 0.9.59 from July, so merging it as it stood would have shipped a stale image to Kubero users. The image is No rush on our side. If anything about the template needs changing before it can go in, tell me and I will adjust it. |
|
Refreshed to 0.16.0, which is the current release. Nothing else in this PR changed. |
…d secrets and fix login on plain HTTP
|
Updated to 0.16.2, which is the current release. 0.16.2 closes a cross-account authorization defect (GHSA-3wh2-8x78-jfw4, scored 8.8): a connection id supplied in a request could select another session's already-authenticated database provider, so a |
What is this PR about?
Refreshes the LibreDB Studio service from the pinned
0.9.27to0.16.1, the current release, and fixes two defects in the template that are independent of the version.1. The template shipped shared secrets
ADMIN_PASSWORD,USER_PASSWORDandJWT_SECRETcarried literal placeholder values that are published in this catalog, so every install that did not edit them ran on credentials anyone can read.That was already poor practice, but at 0.16.x it became a real exposure: when
STORAGE_ENCRYPTION_KEYis unset,JWT_SECRETis also the key that seals saved connection passwords, connection strings, TLS client keys and SSH keys. A shared value means stored credentials are sealed under a key everyone knows.All three are now empty. The app generates a strong admin password and a strong JWT secret on first start and prints the admin password to the pod log once.
USER_PASSWORDis optional and the lower privilege account exists only when the operator sets it. An operator who wants to choose their own values can still fill them in before deploying.2. Login looped on a fresh install
The app runs with
NODE_ENV=productionand marks its auth cookieSecureon any non loopback host. Kubero creates the ingress with TLS off by default, so the browser was served over plain HTTP, discarded the cookie, and login bounced back to the sign in page with the correct password and no error.AUTH_COOKIE_SECURE=falseis now set, with a note in the installation annotation telling the operator to switch it to true once the app is on HTTPS. This is not a regression from the bump: the behaviour existed at0.9.27too, and0.15.0was the first release that offered an override.Also in this change
How Has This Been Tested?
The service defaults from
app.yaml(image, env vars, volume mount, container port) were brought up againstghcr.io/libredb/libredb-studio:0.16.1:/api/db/healthanswered{"status":"healthy","service":"libredb-studio"}/api/storage/configanswered{"provider":"sqlite","serverMode":true}{"success":true,"role":"admin"}, a wrong password returned HTTP 401AUTH_COOKIE_SECURE=falsethe login response carriesHttpOnly; SameSite=laxand noSecureflag, which is what makes login work over plain HTTP/app/datawas written on the mounted volume, and after a restart the container returned healthy and login still workedyamllint -c services/.yamllintreports one pre-existing line length warning and no new issuesghcr.io/libredb/libredb-studio:0.16.1publisheslinux/amd64andlinux/arm64, matching the architecture annotation.Checklist
A note on the earlier body
An earlier version of this description said the bump was to
0.9.59and reported a test run against that image, and gave "ARM users were being filtered out" as the reason for the architecture annotation. Both are wrong and I am correcting them rather than leaving them in the record. The annotation is display only metadata in Kubero, nothing filtered on it, and the test evidence above is from0.16.1.