About this thread: it is meant as a public discussion with Jolla about one specific Harbour rule. It is not the place for general discussion of the app. For that, please use this thread. Thank you for helping keep this one focused.
Hi @Jolla team,
I maintain Piirit, a native Delta Chat client for Sailfish OS. The package passes every Harbour validator check except one, and that one can’t be fixed within the app in a way I’d consider legitimate.
So I submitted the app via Harbour today, full knowing that it will likely be rejected. That being said, I would like to make the case for amending the rule. Not for this specific case, for everyone.
The issue
Piirit is a Silica/QML front end. All messaging, networking and cryptography is done by upstream’s deltachat-rpc-server, which Piirit bundles and starts as a subprocess, communicating with it over JSON-RPC on stdio. It is installed at:
/usr/libexec/harbour-piirit/deltachat-rpc-server
Harbour allows ELF files only in two places: /usr/bin/<NAME> and *.so under /usr/share/<NAME>/lib/. A second executable fits neither, so rpmvalidation.sh reports three errors for it (check IDs 1.2.1 and 1.6.7): installation not allowed, ELF binary in wrong location, and file must not be executable. Everything else in the package validates, built with SDK 5.2.0.15.
Why this can’t be fixed on the app side
There are three ways to embed the Delta Chat core:
| Option | Current upstream API? | Buildable with the Sailfish SDK? |
|---|---|---|
libdeltachat.so (C interface) |
No, being deprecated | Yes |
deltachat-jsonrpc crate, in-process |
Yes | No: needs Rust 1.89, the SDK ships 1.75 |
deltachat-rpc-server subprocess (current) |
Yes, what upstream recommends | Yes |
About the bundled binary
To help assess the risk:
- It is upstream’s official release build, unmodified, fetched by a script that pins both the version and SHA-256 checksums (
scripts/fetch-rpc-server.sh). Its source is MPL-2.0. - It is only ever started by the app, as a child process, so it runs under the same Sailjail sandbox and permissions as the app itself. It has no .desktop file, is not on
PATH, and has no setuid/setgid bits or unusual file modes. - It is statically linked against musl and depends only on the kernel.
Proposal
The one-executable rule seems to predate upstream projects shipping a self-contained helper binary as their recommended integration. I’d suggest allowing, for example:
- ELF executables in a single app-private directory, such as
/usr/libexec/<NAME>/or/usr/share/<NAME>/libexec/, - subject to the same conditions as the main binary where they apply (no setuid/setgid, no group/world-writable modes, dynamically linked libraries against the allow-list),
- and possibly flagged for manual review in QA, rather than rejected automatically.
I’m not attached to the specifics. 
My understanding is that @vige was at least open to entertaining the idea.
Would love to hear your thoughts!
