Plug request for armaria snap

store-requests
1

Hey all,

I am working on getting an app I’m building called Amaria published to snapcraft. For reference the code for it can be found here: https://github.com/jonathanhope/armaria.

The app is a bookmarks manager that stores the bookmarks 100% locally by utilizing SQLite database. One of the goals of this app is to have many different interfaces into the bookmarks database including browsers. The only way that browser extensions can interact with the file system is something called native messaging hosts. The host itself is installed with the snap, but in order for the extension to communicate with the snap an app manifest needs to be installed.

They need to be installed into a particular directory. Documentation about the Firefox directory is here: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_manifests. I have defined two plugs that allow the CLI component to install the app manifest for Chrome and Firefox. The idea is that if someone wants to use Armaria + Firefox they would connect the plug for the .mozilla/native-messaging-hosts and then use the CLI itself to add the JSON file. The process for Chrome would be similar.

Consequently I am requesting access to the personal files interface for the armaria snap.

2

Hey @intheflatfield,

I really like the concept behind armaria, it looks pretty cool to me.

If I understood it correctly, you are requesting write access to .mozilla/native-messaging-hosts and .config/google-chrome/NativeMessagingHosts for armaria via manually connecting the required personal-files interfaces.

Write access to dot-folders is very sensitive/powerful and we must be very cautious to grant it, especially when the directory don’t clearly belong to the snap. However, in this situation, considering that you are requesting manual connection and the requested directories seem to be intended to be filled by third-party applications like armaria I’ll give a +1.

Note: if you can know the name of the file beforehand (i.e. .mozilla/native-messaging-hosts/armaria.json it will be better to narrow the scope of the personal files interface)

3

That was my original plan. However when I was testing in fresh VMs I found that those folders might not exist. So the CLI has to to effectively do a mkdir -p for those folders before it writes the app manifest out.

Thanks for taking a look. All of the information in your post is correct.

1 Like
4

+1 from me as well for the manual connection of the personal-files interface for armaria.

Correct me if I looked at the wrong revision of the snapcraft.yaml, but it would also be good to update the personal-files plug instance names with the formatting mentioned in the https://snapcraft.io/docs/personal-files-interface page.

5

I adjusted the naming to the following:

  • dot-mozilla-armaria
  • dot-chrome-armaria

I believe that matches the linked naming.

6

I would even drop the snap name from the plug name as well and adjust them slightly to match the path of the request, e.g

  • dot-mozilla-armaria → dot-mozilla-native-messaging-hosts
  • dot-chrome-armaria → dot-config-chrome-native-messaging-hosts
7

Ah I got you now. The names in the code base now match those names.

1 Like
8

There is historical precendent for allow snaps to install native messaging connectors - both in the users home directory via personal-files (Autoconnect ‘browser-extension-connector' plug for 'passy') and globally via system-files (System-files under .mozilla/native-messaging-hosts) - in either case, since this allows for a possible sandbox escape, publisher vetting will need to be performed (even for manual connection).

1 Like
9

I assume in the case I am the publisher. Is there anything I have to do on my end to initiate the vetting process?

10

Hey @reviewers,

Am I already in a queue for the next steps? Or is there something else I have to do?

Thanks!

11

@intheflatfield there is nothing you need to do on your side - one of the reviewers should contact you soon to kick off the process.

12

I’m taking over publisher vetting for this one.

@intheflatfield could you please get back to my private message. Thanks.

13

The publisher is now vetted.

Once the plug names are updated (see the suggestions from @cav ) I’ll proceed and grant the access. Thanks.

14

Thanks for taking care of the vetting!

I did try and update the interface names based on that article. See them here: https://github.com/JonathanHope/armaria/blob/main/.goreleaser.yaml#L235.

I have:

  • dot-mozilla: $HOME/.mozilla/native-messaging-hosts
  • dot-chrome: $HOME/.config/google-chrome/NativeMessagingHosts
  • dot-chromium: $HOME/.config/chromium/NativeMessagingHosts

Do those still need adjusting? Happy to make whatever adjustments are needed.

Thanks!

15

So, I’d make the following changes in order to have the names in a correct formatting:

  • dot-mozilla → dot-mozilla-native-messaging-hosts
  • dot-chrome → dot-config-google-chrome-native-messaging-hosts
  • dot-chromium → dot-config-chromium-native-messaging-hosts

Thank you!

16

Please note that in the latest version of your snap you have: armaria-dot-chrome and armaria-dot-mozilla. (please correct me if I’m wrong)

17

I realized that I had never actually gotten my CI pipeline to publish snaps.

I uploaded a new version with the naming from @sahnaseredini.

18

thanks @intheflatfield , the revision looks good. Just one small change on icon field, it does not need to be specified in the yaml file. You can place icon in meta/gui/icon.png and it will get picked automatically.

If you can remove the icon field in the yaml file it will be great and pass the review automatically

Regarding the personal-files interface, +2 for, 0 against. Granting manual connect for personal-files interface to this snap. this is now live.

1 Like
19

Thanks for the heads up. I took a stab at that in the latest revision. I also added an icon via the portal.

20

I’ve published successfully a couple of times. Thank you everyone for getting this taken care of!

1 Like