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

[Olek Wojnar]

Hmm.. some good points to ponder. Thanks! Let me think on that a little
and I'll respond more fully.

-Olek

On 2/9/20 5:12 PM, Manuel A. Fernandez Montecelo wrote:
> 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>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-games-devel/attachments/20200209/f21d090b/attachment.sig>