Good day!
I have a very simple application ws2connect that I wanted to share with people as a snap package for their convenience.
I supposed that snap packages aimed to provide secured, always fresh and developer-maintained applications that could be easiely installed by a target customer. I was one of believer of the idea and even released my previous applications: fluent-amqp, monexec and redirect-to. That were a quite simple utilities released fully free of charge for system administrators and advanced users. With several attempts more or less I published applications.
Today, after a year of interruption, as I tried to release ws2connect (as mentioned above) and got unpredictable stop factor: requires a human check because application needs to access to home directory.
To be specific - I am not against human checks, but I am super confused about non-transparent documentation of plugs
: my damn simple application just can read file (for certificates), serve http/https server and connect to any UNIX/TCP/UDP/TLS hosts. What should I use in plugs? I donāt what to restrict users to use only home folder for their configurations files: maybe they what to use system folder or even external drivesā¦ But it three different kind of plugs! Same situations for network: application CAN be bound to any port, for HTTP or HTTPS protocol, it CAN connect to any hosts and in case of TLS connection it HAVE to access to system certificates that usually (but not always) located in /etc/certsā¦
Could you please recommend what kind of plugs I should specify?
I am sorry for a little bit emotional question, but that situations seems like will not help grow popularity of snap packages. At all. Restrictions feels to be too granular and complicated to use. Maybe itās āOKā to big stable packages but for utilities and small community driven packages itās really inconvenient. Just imagine: I would like to deliver latest updates to my customers using edge
channel for latest snapshots, however, in case of manual review it will be a bottleneck and super overload for reviewer. There are three future scenarios for reviewers for the situation: (a) decline packages (result: snap will not be used by authors), (b) inspect packages on high-level (result: no security impact of such checks - so the step is useless) or Ā© extreme delay for packages delivery (result: reduce interest from target customers - snap will not be used by authors).
Could you please describe plans how Snapcraft community plans to solve a problem described above?