Classic confinement request for mumps-studio

store-requests classic-confinement
1

name: mumps-studio

description:

A desktop IDE for developing and maintaining MUMPS/M applications, primarily for VistA healthcare systems. It supports local and remote development workflows, Git integration, and container-based MUMPS environments.

snapcraft:

https://github.com/AhmadAlkhalaileh/mumpsIDE/blob/main/snap/snapcraft.yaml

upstream:

https://github.com/AhmadAlkhalaileh/mumpsIDE

upstream-relation:

Maintainer and primary developer

interfaces:

Not applicable — classic confinement requested.

Reasoning:

Classic confinement is required because mumps-studio is a full-featured IDE that needs:

Access to projects in arbitrary filesystem locations

SSH access (~/.ssh) for remote MUMPS/VistA connections

Git integration using system git and user configuration

Interaction with local Docker containers

Execution of external development tools installed on the host

These requirements cannot be fully supported using strict confinement interfaces. Similar IDEs such as code, intellij-idea-community, and sublime-text are published with classic confinement.

2

Hello @AhmadAlkhalaileh, and a Happy New Year! :santa:

Although the snap falls under the IDE category, I wasn’t able to check the other criteria required for the classic confinement, as both of the provided links return a 404 error. Could you please check if everything is up and working? (#askForInfo)

1 Like
4

@yomonokio Hi, thanks for pointing that out!

The 404 issue was caused by the repository being private. I’ve now fixed the links and made the snap packaging and upstream information publicly accessible.

Updated links:

Please let me know if you need any additional information to continue reviewing the classic confinement request.

5

Hey @AhmadAlkhalaileh

It is plausible that there are technical reasons why mumps-studio needs classic to work properly in all scenarios, but please note that classic confinement is a sensitive matter and it is reserved for mature, well-known applications published by mature, well-known entities. As of today, I believe that mumps-studio doesn’t meet this criteria because of the following reasons:

  • The project seems to be very fresh, according to the upstream repository

  • The projects seems to have little/none community around according to upstream repository (contributors, issues, PRs, etc.)

  • I could not find evidences that the project has a strong enough user base currently

Thus, considering these factors, I think mumps-studio should not get classic confinement as of now.

1 Like
6

Hi @jslarraz thanks for the detailed feedback. I understand classic confinement is reserved for mature, widely-used applications and that mumps-studio doesn’t meet that bar yet.

I’m going to rework the snap to run under strict confinement and use the appropriate interfaces instead. If I run into a specific capability that cannot be achieved with existing interfaces, I’ll document the exact scenario and provide a minimal reproducer and justification.

If you have any recommendations on which interfaces you expect for this type of app, I’d appreciate the guidance. Thanks again for your time.

7

Thanks for your understanding!

Looking at the reasoning you provided these are some of the interfaces I guess your snap will need:

  • Access to projects in arbitrary filesystem locations
    • Usually home + removable-media is enough. It does not allow access to “arbitrary files”, however snap model really tries to enforce that projects are located inside the home directory (or removable media in some cases)
  • SSH access (~/.ssh) for remote MUMPS/VistA connections
    • This is granted by ssh-keys interface.
  • Git integration using system git and user configuration
    • You can use personal-files and/or system-files interfaces for this one
  • Interaction with local Docker containers
    • I think it is provided by the docker interface
  • Execution of external development tools installed on the host
    • This cannot be achieved using interfaces. Instead development tools should be staged in your snap via stage-packages

Most of these interfaces are super-privileged (personal-files, system-files, docker ) / expose sensitive information (removable-media, ssh-keys) and are not required for the core functionality of the snap. Thus, I think they should be connected manually by the user (so that they can decide) rather than auto-connected. You can use [snapctl](https://snapcraft.io/docs/using-snapctl) is-connected to detect if a concrete interface is connected or not and act accordingly.

Let me know if I can help with anything else.