Skip to content

libredb-studio: refresh the pinned tag to 0.16.1 and fix two template defects - #758

Open
yusuf-gundogdu wants to merge 6 commits into
kubero-dev:mainfrom
yusuf-gundogdu:update-libredb-studio-0.9.59
Open

yusuf-gundogdu wants to merge 6 commits into
kubero-dev:mainfrom
yusuf-gundogdu:update-libredb-studio-0.9.59

Conversation

@yusuf-gundogdu

@yusuf-gundogdu yusuf-gundogdu commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

What is this PR about?

Refreshes the LibreDB Studio service from the pinned 0.9.27 to 0.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_PASSWORD and JWT_SECRET carried 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_KEY is unset, JWT_SECRET is 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_PASSWORD is 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=production and marks its auth cookie Secure on 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=false is 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 at 0.9.27 too, and 0.15.0 was the first release that offered an override.

Also in this change

  • The description annotation named seven engines. It now matches what the image actually ships.
  • The installation annotation described the old credential behaviour. It now describes the current one.

How Has This Been Tested?

The service defaults from app.yaml (image, env vars, volume mount, container port) were brought up against ghcr.io/libredb/libredb-studio:0.16.1:

  • container reached a healthy state, /api/db/health answered {"status":"healthy","service":"libredb-studio"}
  • /api/storage/config answered {"provider":"sqlite","serverMode":true}
  • admin login returned {"success":true,"role":"admin"}, a wrong password returned HTTP 401
  • with AUTH_COOKIE_SECURE=false the login response carries HttpOnly; SameSite=lax and no Secure flag, which is what makes login work over plain HTTP
  • /app/data was written on the mounted volume, and after a restart the container returned healthy and login still worked
  • yamllint -c services/.yamllint reports one pre-existing line length warning and no new issues

ghcr.io/libredb/libredb-studio:0.16.1 publishes linux/amd64 and linux/arm64, matching the architecture annotation.

Checklist

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works. Not applicable: there is no test suite for service templates.

A note on the earlier body

An earlier version of this description said the bump was to 0.9.59 and 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 from 0.16.1.

@yusuf-gundogdu

Copy link
Copy Markdown
Contributor Author

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.

@cevheri

cevheri commented Aug 21, 2026

Copy link
Copy Markdown

any update ?

@yusuf-gundogdu yusuf-gundogdu changed the title libredb-studio: bump to 0.9.59 and declare supported architectures libredb-studio: bump to 0.14.1 and declare supported architectures Sep 7, 2026
@yusuf-gundogdu

Copy link
Copy Markdown
Contributor Author

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 ghcr.io/libredb/libredb-studio:0.14.1, published as a multi-arch manifest for linux/amd64 and linux/arm64, which matches the architecture annotation this PR adds. The diff is still a single line in services/libredb-studio/app.yaml.

No rush on our side. If anything about the template needs changing before it can go in, tell me and I will adjust it.

@yusuf-gundogdu yusuf-gundogdu changed the title libredb-studio: bump to 0.14.1 and declare supported architectures libredb-studio: refresh the pinned tag to 0.15.0 and declare supported architectures Sep 13, 2026
@yusuf-gundogdu yusuf-gundogdu changed the title libredb-studio: refresh the pinned tag to 0.15.0 and declare supported architectures libredb-studio: refresh the pinned tag to 0.16.0 and declare supported architectures Sep 17, 2026
@yusuf-gundogdu

Copy link
Copy Markdown
Contributor Author

Refreshed to 0.16.0, which is the current release. Nothing else in this PR changed.

@yusuf-gundogdu yusuf-gundogdu changed the title libredb-studio: refresh the pinned tag to 0.16.0 and declare supported architectures libredb-studio: refresh the pinned tag to 0.16.1 and fix two template defects Sep 20, 2026
@yusuf-gundogdu

Copy link
Copy Markdown
Contributor Author

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 user account could reach a connection restricted to admin. It matters on any instance more than one person signs in to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants