Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system

[Manuel A. Fernandez Montecelo]

Hello Olek,

Em sáb., 8 de fev. de 2020 às 18:25, Olek Wojnar <olek at debian.org> escreveu:
> > I don't think taht using this package as an empty shell and a gateway to install
> > the "snap" package [1] is a valid use of the packaging system.
>
> Not only is this use listed in Policy [1] under the contrib section
> (where I'm moving the two packages I've done this with, pending NEW) but
> a number of other packages (in contrib) do exactly the same thing. Flash
> [2] being the obvious example. I'd also like to point out that I asked
> about this course of action back in December [3] and no one raised any
> concerns. So it's a little frustrating that after I've done all the work
> to convert the packages I'm now getting feedback saying I shouldn't have
> done it.

I am sorry that you made the work and noone told you about this.
Maybe I am in the minority and most people don't see it this way,
don't know.

I simply stumbled upon the package by chance, and I didn't have time
to follow mailing lists regularly in the last months, and I think that
I haven't read debian-games for years.


But to the point about the installation of snaps and "flash", as far
as I see it, there are two fundamental differences:

1) For flash, and I guess that most packages of contrib, the items
that are download are checksummed [1], so we know what the script
installs, and we have to manually approve new versions.  If the
download is known to be compromised, users will not install new
versions (and we can do removal of existing versions in some cases, if
we only find that it's a security problem after users install it, at
least in some cases).

  [1]https://sources.debian.org/src/flashplugin-nonfree/1:3.7/update-flashplugin-nonfree/

This does not happen with the installation of these snaps, as far as I
can see -- it will take whatever is there, the latest version, no
checksumming or pinning to known-good versions, and there's no
guarantee that if tomorrow someone takes over that package and
installs malware, that users installing it from Debian will not use
it.  Once users install the snaps, it's completely outside of Debian's
control, I think.


2) These kind of methods are done for special packages like firmware,
very popular apps like flash (at the time), etc, or *data* packages
from games.  It's a "known evil" thing to do, still we do it because
it's somewhat needed by many users -- nowadays you can easily live
without flash, but it was not so easy in the web 10 years ago; it's
impossible to install some computers without firmware, etc.

But I don't see the need to do it with a very marginal package like
Ember.  Either people are happy to run the older version from 2016, or
if not, they would have already updated it by some means, like maybe
using themselves the snap package.

So I don't think that it's worth promoting things that are a bit
against the philosophy of Debian/traditional distros, like snaps
(adding layers of overhead and duplication, and potentially security
vulnerabilities) due to a package with very low popcon and which use
is not critical, it's just a game.


3) Aside from that, I would be more OK with it if, before installing,
there were clear indications of what's going on for people that might
be unaware of what Snaps are, and that fail to notice the change in
description of the package.

As I understand it, there's no indication that you'll install a snap
package if you just do "apt-get upgrade".  That's the part that I
think it's more troubling, that you can end up installing snap
packages without even noticing -- maybe because you happened to have
"ember" installed in the past and you wanted to check it up one time
long ago, and are not even using it very actively in the last
months/years.

If you have something like a debconf question asking users if they
want to install the snap package, or invoke snap and you decide if you
want to install it or not without the configuration of the package
failing if you reject, etc, then I think that it's much more
reasonable.


> > Otherwise, if this was an accepted practice, we could start to have many
> > packages which are just a way to install snap packages, which can easily contain
> > security vulnerabilities and install not free software, specially if the version
> > is not restricted in some way.  And this not generally expected by users of
> > Debian, IMO.
>
> This is a fair concern. However, I think that users *do* expect this of
> packages in contrib. Pabs made a good argument in a different bug report
> about this issue and convinced me. I'm going with that.

This and cyphesis are the only packages that depend on snapd, which
are not app-managers from GNOME/KDE and the like, so I don't think
that users expect it? These are among the first cases that we do
something like this, unless we do it also with flatpaks or similar and
I failed to notice (which can easily happen, I have not been very
active lately on many fronts).

For games, most of the cases that I know of in which we have games in
contrib is because of free game engines or "clones" that need non-free
data from the original games or similar, not "snaps" or flatpaks or
similar.

(I have the impression that pabs misunderstood the intention and was
talking about upstream providing alternatives to snap, not Debian, but
let's not enter that territory.)


> > If users want to install Snap packages, they can always do so on their own.
>
> They can. I'm just trying to provide a transition path that will
> eventually lead to the main packaging of the updated upstream software.

What I am concerned about is that you're susbtituting a normal package
for a snap package and people might acquire it by upgrading it without
any notice, that's why I am raising the flag.

So, as I see it, while you provide a convenience to those who are OK
with it, you're providing a semi-hidden *inconvenience* to people who
don't want it to happen.

I know that your intention is to help those who want to keep Ember
installed and are OK with a snap package, but I wanted to raise the
flag and protect users from installing stuff without intending it and
without much of a notice.  At least, I would be surprised if that
would happen to me, that's why I am raising it.


Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>