Proposal: Native Messaging Host Interface

Hi all,

I’ve been working today on trying to get the KeepassXC snap to be able to provide Native Messaging Host support without workarounds. For context, Canonical have proposed a patch to the XDG Desktop portals upstream to enable web browsers to call Native Messaging executable, although this is currently only widely available in Ubuntu 22.04+ distributions and those pulling the Ubuntu archives.

In order to get this to work, I’m having to use the personal-files interface. Despite this, the solution isn’t truly 100% portable as on Linux, a full path to the Native Messaging binary must be provided. This would be /snap/bin/keepassxc.proxy in Ubuntu, but on other systems like Fedora, /snap isn’t provided and although the snap doesn’t run in classic, users would have to create a symlink to /snap as if the instructions were to enable classic.

Ideally, I could imagine a specific interface that solves two specific issues:

  1. Personal-Files works but the maintainer must manually define the paths involved. Any change to the path will require a review. This might not occur that often but it feels to me having an interface where the paths can be added in the snapd code rather than the individual snaps would be superior design choice.
  2. Because of the sandboxing, the snap doesn’t know whether it is or isn’t running on a distribution where the host has /snap. This makes it difficult to support on distributions where this isn’t implicit.

I could imagine an interface that instead at a high level looks like:

plugs:
  browser-native-messaging:
    path: $SNAP/bin/native-messaging-agent
    browsers: - all
    allowed-extensions: [Chrome-extensions://1234]
    yada yada

With the snap backend then magically writing the relevant files and being responsible for cleaning them up.

N.B whilst I think this makes sense generally, I’d expect KeepassXC itself may prefer personal-files as users don’t necessarily want the functionality enabled by default (even when it has certificate authentication preventing unauthorised access). That said, I’d imagine most examples aren’t in the same league as password managers.

You can see my WIP in KeepassXC here Comparing keepassxreboot:develop...JGCarroll:snap-native-messaging · keepassxreboot/keepassxc · GitHub and I’m hoping to propose it to upstream soon. This branch successfully allows for the default snap provided Firefox and snap powered KeepassXC to interact via the Keepass Browser extension with no user involvement beyond the usual outside of snaps (on systems where /snap exists, at least).

Is there an appetite for such an interface? It’s strange that I’m proposing this without actually being able to use it in the example triggering the thought, but as I say, this feels like the kind of thing where snapd mediation is best placed to help out in the same manner as .desktop files, rather than the way I’m proposing KeepassXC do it for now (as I say, password manager is exceptional!).

2 Likes

I’m all for such interface to exist - will definitely make lives easier for users and developers alike. Plus, from architectural perspective, having laser-focused interface is IMHO better than trying to fit existing, not purpose-built interface to do what’s needed.

2 Likes

I think the best thing to discuss in the upcoming snapcraft clinic.

1 Like

I’d love to, but every Snapcraft clinic coincides with scheduled team meetings at work and I’d have to book holiday time off to ever attend them, which I wouldn’t be able to schedule at this point until August soonest :slight_smile:

1 Like

Okay, I’ll try to mediate then, It’s probably next week