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 <a...@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.
signature.asc
Description: OpenPGP digital signature