Bug#956276: runescape: downloads unverified binary and runs it

[Simon McVittie]

On Thu, 09 Apr 2020 at 12:37:03 +0200, Markus Koschany wrote:
> Am 09.04.20 um 11:36 schrieb Ivo De Decker:
> > It seems runescape downloads a binary and runs it, without verifying its
> > integrity. At least the download happens using https, but no other
> > verification is done.
> 
> Could you quote the relevant part of Debian Policy, that requires
> verification (and what kind of verification) of downloaded files. Is
> downloading of verified orig tarballs now a requirement or is it still
> just sufficient to download the tarball and verify its integrity by hand?

This isn't about an .orig tarball. The runescape package does not actually
contain the non-free Runescape game; it's a downloader/launcher, which
downloads https://oldschool.runescape.com/downloads/jagexappletviewer.jar
and runs it using a Java interpreter. See:
https://sources.debian.org/src/runescape/0.6-2/src/runescape.sh/
(runescape-launcher would have been a more appropriate name for the
package, but it's a bit late for that now.)

I would personally say this would be a lot more appropriate
to install via something like Flatpak or Snap that has OS-level
sandboxing. https://flathub.org/apps/details/com.jagex.RuneScape and
https://snapcraft.io/runescape are both available. The Snap is more
feature-complete than this package, by fetching both the latest client
("Runescape 3") and the older Java client ("oldschool Runescape") on
first run, whereas this package only includes the older Java client. The
Flatpak seems to be just Runescape 3, if I'm understanding its packaging
files correctly; it fetches a known-good version out-of-band during
installation, as Flatpak "extra data" that is checked against a known hash.

If we assume that a .deb for "oldschool Runescape" in the Debian
contrib/non-free archive areas is desirable, then it's difficult to see
how else this particular package could work, assuming the downloadable
file is non-distributable. The URL to the downloadable file isn't
versioned, so presumably it will change during the lifetime of a
Debian stable release, which would invalidate any stored hashes in the
Debian package. This also makes it unsuitable to be handled as Flatpak
"extra-data" or packaged by game-data-packager.

    smcv