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

[Markus Koschany]

Am 09.04.20 um 13:58 schrieb Stephen Kitt:
> Le 09/04/2020 13:44, Markus Koschany a écrit :
>> Am 09.04.20 um 13:24 schrieb Stephen Kitt:
>>> On Thu, 9 Apr 2020 12:37:03 +0200, Markus Koschany <apo at debian.org>
>>> 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 is a bit different: runescape downloads a binary the first time
>>> it’s
>>> run by any given user, so each user can potentially get a different
>>> binary.
>>> Checking orig tarballs (whether using a signing key or manually)
>>> produces a
>>> result which remains the same for all users...
>>
>> How is this any different? It is possible that tarballs from github.com
>> differ each time a user is downloading them, but we don't require
>> verification. Where is this documented in Debian Policy as a "must"
>> requirement?
> 
> Installing a Debian package doesn’t involve downloading a tarball from
> github.com or anywhere else. A packager downloads the tarball, vets it
> in some way or other (hopefully), and then uploads it to Debian
> infrastructure, where it is used to build the binary packages which
> users eventually download. After the initial upload, the contents don’t
> change, unless a new version is uploaded.

In general we offer users the opportunity to rebuild a package from
scratch. That sometimes includes precise instructions in README.source
and a get-orig-source target in debian/rules but we often just assume
that running uscan will download the same original tarball that is
shipped in Debian's archive. In many cases this assumption is not true
and users will get a different tarball. Nowhere do we enforce that the
data is identical.


> Put another way, when you install a Debian package, you get the exact
> same contents as any other user installing the same version of the
> package, and thus a certain amount of collective trust can be built.
> This isn’t necessarily the case with the runescape package.

Right, because the runescape package does neither qualify for main nor
contrib hence why it was put in non-free and for its purpose the level
of trust is sufficient.

>> Note that we are talking about a non-free game here. The user has to
>> trust the publisher and there is nothing Debian can do about it. We only
>> provide a simple helper script to download the binary, which is done
>> about a secure transport channel. This is just a little more convenient
>> than to download it directly with your favorite web browser.
> 
> Oh I know, we can’t do anything about trusting the publisher. The main
> issue is that if for whatever reason a compromised JAR is put in place
> on the upstream site, the runescape package will download it and run it
> without any warning. Even the TLS protection doesn’t do much since the
> download script doesn’t check the upstream certificate (so the site
> could be hijacked and it would still work).

As Simon has already pointed out, the binary hash/signature will
probably change due to updates or other minor changes. That makes
runescape prone to other RC bugs and any implementation to validate the
launcher should take that into consideration.

> Consider it this way: the packager will presumably check the package
> before upload, and we can consider the JAR at that point to be
> trustworthy (for some value of trustworthy). But there is absolutely no
> guarantee that the JAR which users will receive bears any resemblance to
> the JAR checked by the packager.

If someone wants to implement some form of verification, hash or
something else, please do. I still don't see why this issue is a Policy
violation and why everyone seems to require the same standards as in
main or contrib when the package is in non-free and does not have to
comply with each and every part of the DFSG. In my opinion the package
is very simple and sufficient for its purpose. A warning message may
help here too. Construing a Policy violation seems wrong to me.


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