upstream-relation: I am the maintainer and original author of the project
supported-category: debug tools
reasoning: This tool requires classic confinement because it instantiates the “wireshark” GUI software, as installed on the host system, with piped input, when called with the “–wireshark-live” flag, and this is a core feature (QCSuper/src/modules/pcap_dump.py at 2.1.0 · P1sec/QCSuper · GitHub) - It may also create temporary udev rules in order to block interference with ModemManager over the QCDM serial diagnostics interface
I understand that strict confinement is generally preferred over classic.
I’ve tried the existing interfaces to make the snap to work under strict confinement.
You can not really depend on outside software with a classic snap, even classic will need to bundle all potential things that are a hard requirement at runtime …
Even if your snap is classic it must be usable on any supported systems you can install it on, i.e. what happens on a fedora (gentoo, arch, debian, SuSE) laptop that has a QCom modem when you install and run this snap ?
Also, if you dynamically generate system config files like udev rules (which I think the classic confinement rules forbid but I’m not sure), what happens when you remove the snap, are you 100% making sure these are removed again ?
This is not a hard dependency (QCSuper can also, for example, just generate plain PCAP files, or fetch modem-related information), but is a core feature and advertised as such
Even if your snap is classic it must be usable on any supported systems you can install it on, i.e. what happens on a fedora (gentoo, arch, debian, SuSE) laptop that has a QCom modem when you install and run this snap ?
It works, QCSuper has been existing since 2018, it is cross-distribution and even cross-platform, i.e tested on Windows.
Also, if you dynamically generate system config files like udev rules (which I think the classic confinement rules forbid but I’m not sure), what happens when you remove the snap, are you 100% making sure these are removed again ?
The temporary udev rules, when it is possible to create these, are put into /run/udev/rules.d and are hence actually temporary.
As far as I understood, the reasons provided do not quite fit classic confinement requirements. As per the policy, this falls under the following unsupported criteria:
dependent software only available on host (ship in instead snap (eg, stage-packages, build from source))
This can be tackled using one of the following two things:
Bundle Wireshark within the snap
Same thing can be achieved using something like qcsuper | wireshark -k -i - . Every user of your application should be able to use this with enough documentation.
Would it be possible grant auto-connect for these interfaces in order to have QCSuper working on Snap with strict confinement for the moment? @reviewers
Also, have the corresponding plugs are present in snapcraft.yaml the snap with strict confinement can be upload but manual review is pending on the Store side.
Regarding the interference with ModemManager, the specific issue is that when ModemManager takes over a Diag-related serial port over /dev/tty{USB,HS}[0-9]* (which it automatically does by default) there will be no effective locking mechanism in place and ModemManager will just read half of the bytes from the device while QCSuper will read the other half, resulting in corrupted communication.
This is why the current (hackish) behavior of adding a temporary udev rule to /run/udev/rules.d/, and then reloading UDEV rules through udevadm + ModemManager through systemctl, in order to block ModemManager from accessing the QCDM port while leaving the other modem ports available when QCSuper is used to connect to an USB pseudo-serial QCDM port (in all cases the udev rule is removed when the process exits, or in case of unclean termination at system shutdown).
This hack is not used when QCSuper is used towards an ADB interface. This hack is made mandatory by the lack of effective device locking or tack-over mechanism across the Linux/ModemManager/QCSuper ecosystem.
Could it justify extended FS+DBus access, or classic confinement, or not?
If not, I guess that it would require to warn the users who uses Snap that they should perform this manually, even though this is not user-friendly? (QCDM is not critical functionality to ModemManager in any case, while it is to QCSuper)
As the other reviewers have explained, this snap is not a good candidate for classic confinement (#reject). Providing documentation or a script for the user to run on the host system, at their own risk, would be a more suitable solution.
In case you want to request specific privileged interfaces instead, please create a new post under the store-requests and privileged-interfaces categories to start a new thread there.
