Hi,
I’m the publisher of hanguliyagi (HangulIyagi), an independent Korean input method.
Revision 3 (1.9.14) was rejected in manual review with this comment:
The DBus names, org.freedesktop.portal.IBus and org.freedesktop.IBus, are too generic and instead should use a prefix that is specific to the upstream publisher.
Revision 4 (1.9.51) is the current build and is now in the manual review queue. I have posted the same explanation as feedback on that revision, and I’m posting it here too so it can be discussed. The slots in question:
slots:
ibus-name:
interface: dbus
bus: session
name: org.freedesktop.IBus
ibus-portal-name:
interface: dbus
bus: session
name: org.freedesktop.portal.IBus
I understand the guideline, but I would like to ask for this to be reconsidered, because in this case the names are not an application ID that I chose — they are the fixed endpoint of the IBus protocol.
First, to be clear: HangulIyagi is not IBus, not a fork of IBus, and not an IBus engine. It is an independent Korean input method written from scratch — its own Hangul composition engine, word dictionary, candidate window and XIM server. It does not link libibus, does not need ibus or ibus-daemon to be installed, and runs on systems where IBus is absent.
The only reason the IBus names appear is compatibility: HangulIyagi speaks the IBus D-Bus protocol, because that is the protocol applications already speak to input methods. The clients are not my code: they are the stock ibus GTK/Qt input-method modules and GNOME Shell’s IBus support that every desktop already ships, and Chromium’s IBus backend. All of them look up exactly org.freedesktop.IBus on the session bus (and Flatpak/sandboxed clients use org.freedesktop.portal.IBus). They have no setting for a different name.
So if I rename the slots to e.g. io.github.iyagicom.HangulIyagi, the snap still installs and passes review, but no application on the host can reach it — it would be a Korean input method that cannot type Korean anywhere. The GTK/Qt modules bundled inside the snap cannot help here, because host applications cannot load libraries from inside a strictly confined snap. Owning the IBus name is the only way this snap can do its job.
I’m aware this is a sensitive name (the owner receives the user’s keystrokes), so to limit the impact:
confinement: strict- the daemon has
install-mode: disable— installing the snap does not start anything or claim any name; it happens only after the user explicitly runssnap start hanguliyagi(and stops withsnap stop hanguliyagi) daemon-scope: user— it runs inside the user’s own session, the same context as a distribution’sibus-daemon- the snap has no network plugs
I also want to be upfront about one behaviour, so that nothing here is a surprise. In my unconfined deb package, when the daemon starts and finds another input method (typically the distribution’s ibus-daemon) already owning org.freedesktop.IBus, it sends that process SIGTERM and takes the name over. This is deliberate for the deb: a user who installs and enables HangulIyagi has chosen it as their input method, and we had real failures where an auto-activated ibus-daemon grabbed the name and left GNOME Shell and Chromium unable to type.
Inside the snap this cannot happen. The strict AppArmor profile only allows signals to be sent to the snap’s own processes (signal peer=snap.hanguliyagi.*), so the snap cannot terminate ibus-daemon or any other host process. What remains is the ordinary D-Bus behaviour: the name is requested with REPLACE_EXISTING, which only succeeds if the current owner registered it with ALLOW_REPLACEMENT; otherwise the snap keeps waiting until the name is free. If you would prefer, I can also remove the SIGTERM path from the snap build entirely, so that the snap never even attempts it.
If owning these names is not allowable for a third-party snap under any conditions, please let me know that as well (a clear “no” is fine too), and I will withdraw the snap and distribute through deb/rpm packages only — I’d just like to be sure before giving up, since an input method has no other way to work.
Thanks!