Request for personal-files access for boxwallet

one for each dir that starts with a dot in its name …
(note that i don’t think “accessing random config dirs of classic apps” is enough to get classic confinement granted (but i’m not a reviewer))

Thanks. That might end up being an issue for my users then.

At the moment, when they want to choose a “coin” to work with, they simply run boxwallet coin and then choose the coin they’re interested in.

However, if they’ve installed via a snap, I presume they’re going to have to issue another command via sudo first?

It would be much easier for them, if they just entered --classic to start with, then they could use the app as designed?

Thanks

Richard

the criteria for getting classic granted are here:

see point 5 in the unsupported list …

the only approach i see here is to add a bunch of persional-files interfaces for the known dirs … you could ask for auto-connection of these or add a command-chain yad popup that tells your user to connect them before proceeding to start the app … or add a wrapper to the boxwallet coin launcher in your snap that tells them …

Thanks for your time responding to my requests.

I think I’ll request auto-connection of the personal-files interfaces then, because I know, at the time of a release, exactly what “coins” are currently supported.

How do I go about requesting for auto connection?

Richard

add the interfaces, try them out (i guess you should call for some testers that use the respective coins you want to support :slight_smile: ), upload your snap with the interfaces added and change this topic into an auto-connect request …

ok, will do.

Thanks for your help, and sorry, I can’t work out how to change the topic.

Richard

Perhaps you could write some documentation that explains how users can migrate their cryptocurrency wallets to be controlled by your snap?

It’s not at all obvious that a user would expect a snap to automatically have access to the sensitive data of all the crypto-currency wallets they might have installed previously.

Note that this kind of isolation has benefits too: if you’re storing wallets in the boxwallet snap’s private data area, then it won’t be visible to other strictly confined snaps (even if they plug the home interface).

there is that little pencil icon next to it …

Personal-files is meant for configuration that clearly belongs to the software in the snap. Also in this case we cannot know whether some configuration for other software belong to a previous installation. So I think it would not be appropriate to auto-connect such usages of personal-files.

The documentation states:

The personal-files interface is typically used to provide read-only access to top-level hidden data directories within a user’s real home directory in order to support importing data from existing applications where the snap is the clear owner of the target directory.

The last part generally applies, especially for auto-connection decisions.

About classic, it sounds this snap would install other software. That’s part of the not supported use cases for classic. Though more limited in scope it should be classified under:

  • 3rd party installer snaps (eg, for native packages, appimages, flatpaks, snaps, etc)
2 Likes

Could someone give me an example of the command that the user would have to enter, to enable my snap to access to ~/.divi directory please?

Thanks

Richard

An example of the command a user would run to provide your snap (if it was strictly confined) access to the ~/.divi directory would be something like

$ sudo snap connect boxwallet:dot-divi-foo

Thanks for your reply.

I’m trying to relate your command above, to these settings in my goreleaser.yml file, and whilst I appreciate it’s not scnapcraft, I wonder whether it would shed any relevance to your sudo snap connect command above?:

personal-files:
  read:
    - $HOME/.divi
  write:
    - $HOME/.divi 

I’m wondering what the command would be for the user?

Thanks, again, for all of your help.

Richard

first of all the reviewers would ask you to give it a more descriptive name:

plugs:
  dot-divi-rw:
    interface: personal-files
    read:
      - $HOME/.divi
    write:
      - $HOME/.divi

your snap could then use snapctl is-connected dot-divi-rw to find out if it is connected … if it isn’t you could then pop up a message or if running on commandline you could print a text like:

This application needs RW access to ~/.divi, please run: sudo snap connect boxwallet:dot-divi-rw to allow it

1 Like

@ogra FYI, we don’t normally include the access mode in the interface name, so for this it would just be dot-divi

1 Like

Hi,

When I run the command:
sudo snap connect boxwallet:dot-divi-rw
I’m getting:
error: snap "boxwallet" has no plug named "dot-divi-rw"

Any ideas what I’m still doing wrong?

Thank you

Richard

well, did you use my code snippet in you snapcrft.yaml ? (also … is your snapcraft.yaml anywhere public ?)

did snap install throw any errors during a local (–dangerous) installation of the snap ?

Hi,

I’m using a tool called GoReleaser, which does things a bit differently. I’ve just made an adjustment, to hopefully add the interface in now, and it’s been flagged as waiting for manual approval, so as soon as it’s cleared, I’ll give it another test.

Thank you

Richard

did you make the name change that @alexmurray suggested (drop -rw from the name) ?

also, i’m not sure how goreleaser works (i plainly use snapcraft for my builds locally or https://snapcraft.io/build) but doing tests locally with installing the snap with the --dangerous option to snap install ... helps for seeing if it actually works as expected before going into any reviews …

Yes, I did that as well. Thank you.

Richard

I’ve got is working separately using snapcraft now, and it seems to be working fine. However, I’m getting confused by the build-on and run-on parts.

Basically, I need it to be built separately for i386,amd64,armhf and arm64 and I need it to run on those separate platforms as well.

How can I specify that they all need to be separately built for each arch? When I try, I get a multi.snap output?

Thanks

Richard