Request confinement ‘classic’ for j-nordvpn-manager

store-requests
1

Hi together,

for the snap https://dashboard.snapcraft.io/snaps/j-nordvon-manager I need to request confinement ‘classic’. This is needed because my application is a frontend GUI to the nordvpn snap on the end users system. I need to call the nordvpn command (/snap/bin/nordvpn). If you can give me another solution, how I can access this command in the ‘strict’ mode (without copying the complete nordvpn snap in my snap…), I would prefer that solution.

Thanks in advance,

mr

2

hi @com-mr-apps - just to confirm, does j-nordvpn-manager expect nordvpn to already be installed on a users system? or can it be shipped/bundled with the snap staging the snap?

3

Hi @cav

I currently designed j-nordvpn-manager in that way, that I show an error dialog, if ‘which nordvpn’ does not return the command.

Yes, the snap ‘nordvpn’ (or a manual installation of the application) is a requirement for my software and should be installed before as a prerequisite.

I don’t want to automatic install ‘nordvpn’ or include any 3rd party binary in my package - first, I’m not involved in any way in the NordVPN development , second - I want to separate their “backend” from my package, that the user can be sure I don’t hide a trojan etc. in my package. My complete package is at GitHub as open source available (still in the beginning, but “beta” is ready…). All what I would need to have is access to execute the ‘nordvpn’ command from my java application. Here is the link to the code with the commands I call: https://github.com/com-mr-apps/JNordVPNManager/blob/main/src/main/java/com/mr/apps/JNordVpnManager/nordvpn/NvpnCommands.java

If you need more information, don’t hesitate to ask me :slight_smile:

Thanks,

mr

4

hi @com-mr-apps, thank you for the info!

If the snap is depending on NordVPN on the host and it doesn’t ship it within the snap, it falls under the unsupported classic category of:

  • “dependent software only available on host (ship in instead snap (eg, stage-packages, build from source))”

In strict mode as well, there are also issues with accessing binaries on the host as the snap can then break confinement.

5

hey @com-mr-apps

I agree with @cav, i don’t think it is a case for classic. Maybe it is worth trying to involve the Nordpass upstream project. If they are interested in officially support third party front ends, they can expose the binary via a content interface and other snaps could connect to this interface to consume it

Thanks

6

Hi,

first of all I like - and fully support - the strict model. But always - even with ‘strict’ - users must be aware of the risks when they install software and assume own responsibility. But if this ‘strict’ model is so strict, that it limits required functionality there should be a solution provided. Currently the only “workaround” is the ‘classic’ model - where you try to implement an additional safety level with your review process, which I also fully support. But to call a specific command should not be a show stopper.

As I understand especially in the ‘classic’ model, the user must be always aware of the risks when he install the package (like on ‘native’ installations).

I guess, the way I want to supply my snap package is the most transparent way for the user to chose and check the risks. The snap is built on a tagged branch for everyone visible in Github, where everybody can look, what commands are called. The called nordvpn command is from a trusted source, which they already use and have installed by a snap or manually (my GUI doesn’t make any sense without the nordvpn installation).

I work over 35 years in software development product management and I know the process of asking another company to open a interface for 3rd parties. Yes, it could be a possibility, but costs time. My project is voluntary which I did in my free time - first for me - to make the administration of the VPN on Linux more easy. Now it’s at a level where I guess, I should share it with the community - and I thought, via the snap store I can reach a bigger audience and make the installation/use easier.

If you see in my application how it is now a bigger risk than for other ‘classic’ snaps, I respect your refusal of my request. I don’t need any further explanation and suggest to close this request, not to waste more time and energy from us on it. I guess your engagement here is also voluntary and want to thank you @cav @jslarraz for your work you do here :slight_smile:

Thanks for your understanding,

mr