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

Thu Apr 9 19:06:33 BST 2020

Am 09.04.20 um 15:18 schrieb 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.

I was using the rebuilding the package from scatch example because your
requirement that upstream files must be verified against a signature or
hash is simply not true here. That we verify Debian packages in main and
contrib with apt-secure is a given and is also true for runescape.
However packages in main do not require software outside of the archive
to function. They are self-contained. Thus your comparison between the
runescape script in non-free and any package in main is flawed.

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

We do the same for runescape...

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

Correct. So the severity of this bug report should not have been release
critical.

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

Sure, you can put as many warnings in runescape as you wish but it is
still in non-free which is by definition _not part_ of Debian. This
alone is a stark warning for any Debian user and again the script is in
no way different than opening the website in your browser and
downloading the file manually. Do we require hashsums in Debian's
Firefox browser whenever someone downloads a file from the internet?

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

Sorry, but you seem to misunderstand my intentions. I don't feel any
necessity to keep the non-free section at all, maybe except for Linux
kernel drivers. However I feel responsible for all contributors who
contribute to Debian Games but who are no Debian developers yet. I hate
it when people only come out of the woodwork when they have to tell
people about their high standards and how everything ideally should be.
They usually have a strong opinion but rarely can back it up with
existing Debian Policy rules. That means every other opinion is as good
as theirs and a technical solution should be found together but not
forced onto each other.

I would have expected from you that you have raised this issue four
years ago when runescape was initially uploaded to the archive. Several
Debian developers have uploaded new revisions of this package since then
but now, suddenly, it is not good enough for Debian anymore, although it
has been working fine for the past years.

So when the quint essential message is, it is a matter of opinion and a
special form of verification is not mandated by Policy, then why don't
you work closer with the member of this team and help him to implement
the standard envisioned by you? That would be productive and helpful for
a change.

Regards,

Markus

-------------- 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/329107a9/attachment-0001.sig>