Add LibreDB Studio (org.libredb.Studio)

[cevheri]

What

LibreDB Studio is an open-source (MIT) SQL IDE for PostgreSQL, MySQL/MariaDB, SQLite, SQL Server, Oracle, MongoDB and Redis, with optional AI query assistance using the user's own API key. The desktop build is a Tauri v2 / WebKitGTK shell that starts the same server every other channel ships as a local sidecar on a loopback port and shows it in a native window. Everything stays on the machine.

Packaged from the official libredb-studio-desktop_<version>_amd64.deb as extra-data, unpacked unmodified.

I am upstream — this is submitted by the LibreDB project, which builds and publishes the .deb being pinned. Happy to follow whatever you prefer for catalog.upstream_approved and the docs/upstream-approvals.md row; per the "approved by construction" precedent (io.github.todevelopers.GseProfiler, dev.adonm.zuko) I can add both in a follow-up commit here now that this PR exists, or leave it to you.

Why this fills a gap

Not on Flathub: https://flathub.org/api/v2/appstream/org.libredb.Studio returns 404, there is no flathub/org.libredb.Studio repository, and Flathub search returns nothing.

Full disclosure: we have a Flathub submission open at flathub/flathub#9538. Its test build is green on both arches; it is blocked on a policy question about AI-assisted development that has not been answered. I am not trying to slip past your not-already-on-Flathub gate — you may well consider a pending submission differently from a merged one, and I would rather you make that call with the facts. If it is accepted later, tell us and we will withdraw or de-list here without argument.

Practically, this also unblocks a channel Flathub cannot serve for us today: we ship an AppImage, which FlatPark does not accept, and the GUI .deb this PR pins was added specifically so a FlatPark package was possible.

Packaging notes

• bsdtar, not ar — org.gnome.Platform has no ar and no dpkg; verified by probing the runtime.
• The whole usr tree is kept, not just the binary: the shell resolves its resources as <exe dir>/../lib/<product name>, so usr/bin has to stay next to usr/lib/libredb-studio-desktop.
• Three payload pieces are asserted before the unpack is committed — the shell, the Node sidecar and payload/server.js. A partially unpacked tree that still launches would fail every query instead of failing loudly.
• pipefail is enabled behind a subshell probe. The unpack is a pipeline and plain set -e only inspects its last command. Flatpak verifies the extra-data digest before apply_extra runs, so a corrupt download cannot reach it, but a full disk mid-unpack can.
• WEBKIT_DISABLE_DMABUF_RENDERER=1 in the wrapper — without it the window paints blank under many drivers.
• Bundled Node runtime: the sidecar is Node 24.18.0, fetched at build time by packaging/linux/fetch-node.sh in our repo, which verifies it against sha256 digests checked into the repo and cross-checked against nodejs.org's SHASUMS. It ships as libredb-studio-node, not node, so the .deb cannot claim a path the distribution's nodejs package owns.
• x86_64 only for now, matching the rest of the catalog. We publish an arm64 GUI .deb too, so adding a second source later is cheap if you ever want it.

Sandbox

--share=ipc --share=network --socket=wayland --socket=fallback-x11 --device=dri, and nothing else. No --filesystem at all.

network is the core function: it connects to databases over TCP, including one on the host at 127.0.0.1, and to an AI provider only if the user configures one. policy.dangerous_permissions is empty.

The metainfo documents the three opt-in grants as flatpak override commands rather than pre-granting them: a SQLite file path, a database on a Unix socket, and ~/.ssh:ro for the SSH-tunnel feature. Those paths are typed into the connection form rather than chosen through the file-chooser portal, which is why they need an explicit grant — I have described that accurately rather than claiming a portal flow the app does not have.

One deliberate deviation from the playbook: the metainfo does not describe this as a community package, because that would be false — we maintain it. The required "repackages the official upstream build unmodified" wording is kept verbatim. Happy to change it if you would rather every entry read the same.

Verification

All four mandatory checks, run locally on Linux/X11 with org.gnome.Platform//50:

node scripts/read-descriptor.mjs registry/org.libredb.Studio/flatpark.yml   -> OK
node scripts/audit-descriptor.mjs registry/org.libredb.Studio/flatpark.yml  -> OK, no output
scripts/build-app.sh org.libredb.Studio                                     -> appstreamcli compose: Success!
scripts/check-apply-extra.sh org.libredb.Studio   -> "apply_extra OK as root with no capabilities"

appstreamcli validate passes with one pedantic hint, cid-contains-uppercase-letter. The id is intentional and matches our other channels.

Exercised on a real session, installing the built ref and launching it:

• window paints (not blank), and the workspace, connection list, schema browser, SQL editor and results grid all render
• the embedded SQLite sample database loads and returns rows
• a PostgreSQL connection over TCP connects (5 ms) and SELECT 1 returns rows; a multi-row query returns 3 rows
• app data lands under ~/.var/app/org.libredb.Studio/ and nowhere else
• ldd reports zero missing libraries inside the sandbox for both the shell and the sidecar
• apply_extra deletes the 77 MB .deb after unpacking

Not exercised: Wayland (tested under X11 only), the arm64 build, and the AI features (they need a third-party API key). The SSH-tunnel and local-SQLite paths were not tested through a flatpak override, only reasoned about from the sandbox definition.

[jing2uo]

Thanks for a genuinely well-prepared submission — the packaging notes made this fast to verify. I checked out the branch and re-ran everything from scratch rather than taking the PR body's word for it. Summary: technically clean and ready — verified below. (Merged; the metainfo wording was adjusted before merge.)

Verified locally (not just re-quoted from the PR)

Check	Result
read-descriptor.mjs / audit-descriptor.mjs	OK, exit 0
check-approvals.sh	approvals doc ↔ registry flag in sync
resolve-update.sh	resolves to the exact version + URL pinned in the manifest
sha256 dc9ff0af…	byte-for-byte match against upstream's published .deb.sha256
release 0.9.62	tagged, and libredb-studio-desktop_0.9.62_amd64.deb really exists
check-apply-extra.sh	passes as root with all caps dropped (the real system-install path)
.deb contents	the three asserted payload pieces are present; the Node binary ships as libredb-studio-node, not node, so it can't claim a distro-owned path
icon	256×256 PNG, matches the hicolor/256x256 install path

What I liked

• Clean sandbox: --share=ipc --share=network, wayland + fallback-x11, --device=dri, and no --filesystem at all; dangerous_permissions: []. The three optional grants (SQLite file, Unix socket, ~/.ssh:ro) are documented as flatpak override instead of pre-granted — exactly the scoping we want.
• apply_extra.sh is above average: the pipefail subshell probe, --no-same-owner, LC_ALL=C to silence the bsdtar locale noise, and the three payload assertions before the tree is committed. The whole-usr-tree staging is the correct handling for a Tauri app whose resources resolve relative to <exe dir>/../lib/<product>.
• WEBKIT_DISABLE_DMABUF_RENDERER=1 matches our established WebKitGTK convention.

[jing2uo]

@cevheri — separately from the review above, I just wanted to say thank you.

FlatPark is a small, solo-funded project, so having an upstream maintainer show up, do the packaging properly, and disclose everything openly — the pending Flathub submission included — means a lot to me. You clearly read the existing packages and the guide before writing yours, and it shows in every file. That kind of care is exactly what makes this project worth running.

Thanks for the trust, and for the work. I'll be glad to have LibreDB Studio in the catalog. 🙏

[jing2uo]

Supplementary verification — org.libredb.Studio (PR #158)

Following up on the earlier review with a strict, static-only pass of the
docs/pr-review.md runbook, plus, since this is already merged, a set of
checks against the copy actually installed on the maintainer's machine. The
earlier review reached the right verdict but was run as contributor-side build
verification (it executed check-apply-extra.sh and resolve-update.sh); this
pass re-derives the same conclusion without running any script shipped in the
PR, and fills the runbook rows that pass had skipped (submitter provenance,
artifact safety inspection, IOC scan).

Verdict: PASS. No hard-fail rows. Tier 2 (official upstream prebuilt),
established submitter.

Filled runbook template

Legend: ✅ pass · ⚠️ note · ➖ N/A. Tier 2 = official prebuilt.

#	Check	Verdict	Evidence
0	Static-only; artifacts as bytes in isolated dir; nothing executed	✅	this pass ran no PR script; .deb fetched to scratchpad, listed before extract, extracted --no-same-owner --no-same-permissions
1.1	Classified	✅	new app, registry/org.libredb.Studio/ (9 files, +390)
1.2	High-scrutiny surface?	✅	no .github/·scripts/·config/·signing touched. resolve-update.sh is in a brand-new app dir → routine. Also docs/upstream-approvals.md +1 row (ledger, validated by check-approvals.sh)
2.1	Submitter account	✅	cevheri since 2015-05-10 (11y), 270 public repos, 172 followers; first PR to flatpark
2.2	Source repo	✅	libredb/libredb-studio created 2025-12-23 (~7 mo), 127★, MIT, not fork/archived
2.3	Commit identity	✅	cevheribozoglan@gmail.com, well-formed, consistent across both commits
2.4	Timeline plausible	✅	repo 7 months old; release 0.9.62 published 01:03Z, PR opened 01:36Z — release-then-submit, not account→repo→release-in-hours
2.5	Trust tier	✅	established
2.6	Artifact provenance tier	✅	Tier 2 — vendor's own GitHub release, repackaged unmodified
3.1	Sources pinned per type	✅	extra-data sha256 + size: 77678262 (non-zero)
3.2	finish-args no escape perms	✅	no --talk-name=org.freedesktop.Flatpak, no --filesystem=host//; no --filesystem at all; --share=network justified (core)
3.3	policy: honest	✅	proprietary: false (MIT), dangerous_permissions: [] (none used)
3.4	build-commands install-only	✅	5× install -D (wrapper/desktop/metainfo/icon/apply_extra); no patch/sed/recompile of payload
3.5	Source URLs = genuine upstream	✅	github.com/libredb/libredb-studio
3.6	app-id matches vendor	✅	org.libredb.Studio ↔ libredb.org (appstream cid-uppercase hint intentional)
3.7	update.command simple relative path	✅	./resolve-update.sh
3.8	Download host = official upstream	✅	asset on github.com/libredb/…, not submitter's personal namespace
3.9	Optional caps opt-in, not pre-granted	✅	SQLite path, unix socket, ~/.ssh:ro documented as flatpak override in metainfo; absent from finish-args
3.10	PR body attests build+install+launch, gaps named	✅	window paints, sqlite loads, PG-over-TCP SELECT 1; gaps named (Wayland/arm64/AI untested)
4.1	No runtime fetch-and-exec of arbitrary code	✅	node runtime bundled inside vendor .deb; no curl|bash, no runtime installs
4.2	resolve/apply scripts reviewed as code	✅	resolve-update.sh: curl GH API → jq-select libredb-studio-desktop_*_amd64.deb → emit JSON; no hashing/rewrite/eval. apply_extra.sh: bsdtar unpack + 3 payload assertions + rm; no network, no payload edit
4.3	Endpoints noted; no broad fs×network combo	✅	endpoints: GitHub (update), user-configured DB/AI over TCP; no filesystem grant to combine with network
5.1	sha256 == manifest pin	✅	re-fetched bytes → dc9ff0af242dd00afbda720291b7bd655886972056a9545fe90c144fbdfb3382 == pin
5.2	Inspected per type; no traversal/symlink/setuid	✅	.deb listed: 3684 entries, no absolute/.. paths, no setuid/setgid, no symlink escapes; maintainer scripts: none (only control+md5sums)
5.4	Shipped artifact == official download; payload unaltered	✅	hashed bytes are the official release asset; build installs only wrapper/metadata
5.5	Bundled "official" prebuilts hash-verified	⚠️	node libredb-studio-node + native .node addons live inside the vendor .deb; trusted transitively via the Tier-2 vendor artifact, not independently re-hashed against nodejs.org here. PR states build-time verification against nodejs.org SHASUMS
5.6	IOC scan clean	✅	no reverse-shell/miner/stratum//dev/tcp; no autostart/cron/systemd persistence; ELF set = better-sqlite3, sharp/libvips, ssh2 crypto, cpu-features (all map to declared features), no unexpected embedded ELF; no RPATH/RUNPATH on either binary; IP-like tokens = ASN.1 OIDs (1.3.101.112 = Ed25519) + JS test fixtures
6.1	Purpose legal & policy-compliant	✅	SQL IDE; no piracy/malware/trademark
6.2	Non-FOSS not a rejection reason	➖	MIT anyway
7.1	Overall	✅	PASS
7.2	Hard-fail triggers	✅	none

Local-machine verification (installed copy — beyond the static runbook)

The runbook is deliberately static and never launches the app; these checks are
possible only because the PR is merged and installed here.

• Installed: app/org.libredb.Studio/x86_64/stable, version 0.9.62, origin
  flatpark, commit 52ff5a0. Installed size 78.8 kB → confirms the extra-data
  model (77 MB .deb fetched + unpacked at install, not carried in the ostree commit).
• Enforced sandbox (deployed metadata [Context]):
  shared=network;ipc / sockets=x11;wayland;fallback-x11 / devices=dri —
  no filesystems= line at all. The package grants zero filesystem, exactly
  as reviewed. (x11 is the normal expansion of --socket=fallback-x11.)
• Where the "extra" grants come from: flatpak info --show-permissions also
  shows xdg-download, xdg-config/fontconfig:ro, LANG, FONTCONFIG_FILE —
  these are the machine's own global override (overrides/global, applies to
  every Flatpak app), not anything this package requests. Confirms the "no
  pre-granted filesystem" claim on the real install.
• Extra-data integrity: deployed metadata checksum == manifest pin.
• Inside the sandbox: all three payload pieces present
  (libredb-studio-desktop, libredb-studio-node, payload/server.js);
  ldd reports zero missing shared libraries for both binaries —
  independently reproduces the PR's ldd attestation on the shipped runtime.

Note on the earlier review

The conclusion stands (PASS), but for the record the first pass executed
check-apply-extra.sh and resolve-update.sh — i.e. it ran PR-supplied scripts,
which the docs/pr-review.md rule of engagement (static-only) forbids. This
supplementary pass re-derived every safety-relevant row without running any of
them.

[cevheri]

Thank you — and the supplementary pass is genuinely useful to read. Catching that your own first review had executed PR-supplied scripts, and then re-deriving every safety row without them, is a level of rigour I did not expect from a solo project. Noted for our own reviews.

One thing I can close properly: row 5.5, the bundled Node runtime trusted transitively rather than independently re-hashed.

You do not have to take our word for it. The digests are pinned in-repo at packaging/linux/fetch-node.sh, not read from a downloaded checksum file, precisely so a compromised SHASUMS256.txt cannot move them:

NODE_VERSION="24.18.0"
NODE_SHA256_X64="55aa7153f9d88f28d765fcdad5ae6945b5c0f98a36881703817e4c450fa76742"
NODE_SHA256_ARM64="58c9520501f6ae2b52d5b210444e24b9d0c029a58c5011b797bc1fe7105886f6"

Those match https://nodejs.org/dist/v24.18.0/SHASUMS256.txt for node-v24.18.0-linux-{x64,arm64}.tar.xz. So a static check is possible without running anything of ours: extract usr/bin/libredb-studio-node from the .deb and compare it against the bin/node inside the official tarball — same bytes, since the build only copies it and renames it. The rename is deliberate: a .deb owning /usr/bin/node collides with the distribution's own nodejs package.

The native addons (better-sqlite3, sharp/libvips, ssh2 crypto, cpu-features) are npm prebuilts compiled during our release build rather than vendor downloads, so there is no upstream digest to pin for those — your ELF-set observation that they all map to declared features is the right check there. Worth saying plainly since it is the weaker half of that row.

Two smaller notes, in case they are useful for the ledger:

• The x11 in sockets= is, as you say, the normal expansion of --socket=fallback-x11; we do not request --socket=x11.
• The 78.8 kB installed size is the whole point of the extra-data model for us: our .deb is 77 MB mostly because it carries a full Node runtime and a Next.js server payload, and none of that belongs in an ostree commit.

I have installed from flatpark here to check the published path end to end: version 0.9.62, origin flatpark, [Context] with no filesystems= line, app launches and the embedded SQLite sample returns rows. Our own docs now point users at FlatPark alongside the AppImage and the .deb.

On the pending Flathub submission — nothing has moved there, and the offer stands unchanged: if it is ever accepted, say the word and we will withdraw or de-list here rather than have LibreDB Studio sitting in two catalogs against your guidance.

[jing2uo]

Thanks — the in-repo pinned digests close row 5.5 properly. Digests written into the build script rather than read out of a downloaded SHASUMS256.txt is exactly the property that matters, and the usr/bin/libredb-studio-node ↔ bin/node byte comparison makes it checkable statically, without running anything of yours. Saying plainly that the native addons are the weaker half of that row is worth more to me than a sentence that would have papered over it.

The last paragraph is the part I want to correct, though.

There is no such requirement, and no such guidance from me. "Not on Flathub" is a filter I apply to myself when deciding whether a new app is worth the work — everything here installs with flatpak install either way, and the runtime always comes from Flathub, so when Flathub already serves an app well, packaging it again is usually just duplicated effort on my side. It is a prioritisation heuristic for new submissions, not a rule about what may stay.

A small number of FlatPark apps do overlap with Flathub, deliberately:

• io.github.kukuruzka165.materialgram — I packaged it because it needs runtime 49, and getting that upgraded elsewhere is more trouble than carrying it here.
• com.interactivebrokers.ibkrdesktop and com.longbridgeapp.LongbridgePro — I maintain both, and I want updates to reach users faster than the Flathub push gets them to me.

The cases where I actually de-list are: upstream does not permit redistribution, or the app has gone unmaintained for a long time. Neither applies to you.

Being trusted like this is an honour, and having FlatPark listed in your official docs alongside the AppImage and the .deb is rare exposure for a project this size. So I would be glad to see LibreDB Studio stay in FlatPark long term, even if the Flathub submission is accepted — for as long as you want it here. Nothing needs to be withdrawn.