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

[Stephen Kitt]

Le 09/04/2020 14:47, Markus Koschany a écrit :
> 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:
[...]
>> 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.

We’re not talking about rebuilding the package (at least, I wasn’t).

When a user installs a package in Debian, there’s a reasonable 
expectation that the user will get when the maintainer intended. Even if 
they choose to rebuild the package, the typical "apt source" invocation 
will retrieve the source last used to build the Debian package, *not* 
the upstream source.

Incidentally, there is one place where we do enforce that the orig 
tarball doesn’t change: when uploading to the archive... So there is 
that expectation somewhere. All the effort that went into pristine-tar 
also suggests that at least some people care about it in other 
circumstances too.

>> 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.

The fact that a package is in non-free isn’t a blank cheque for it to do 
anything it wants; Policy 2.2.3 still requires packages in non-free to 
“meet all policy requirements presented in this manual that it is 
possible for them to meet”. I disagree with the level of trust involved 
but that’s a matter of opinion.

Now to answer your initial question, as far as I can tell there is no 
Policy requirement that packages which download third-party files verify 
the contents.

>> 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.

Not necessarily: note that I said “without any warning”. The package 
could check the downloaded JAR against a signature, and if there’s a 
mismatch, warn the user before running it. That wouldn’t make the 
package prone to RC bugs.

>> 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.

I agree that as things currently stand, this is a matter of opinion. I 
do however tend to think that we can hold the distribution to a higher 
standard than that strictly mandated by Policy, in particular because 
most of Policy is written within a certain framework (packages which are 
fully contained within the archive) and ignores issues such as this one.

And of course no one is asking *you* to do anything ;-).

Regards,

Stephen