Bug#956276: runescape: downloads unverified binary and runs it
On Thu, 9 Apr 2020 20:06:33 +0200, Markus Koschany wrote: > 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. For obvious reasons I don’t think there’s any point in continuing this discussion. Stephen pgp_t6fa6ue4V.pgp Description: OpenPGP digital signature
Bug#956276: runescape: downloads unverified binary and runs it
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 > 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
Bug#956276: runescape: downloads unverified binary and runs it
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 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
Bug#956276: runescape: downloads unverified binary and runs it
Le 09/04/2020 15:18, Stephen Kitt a écrit : [...] When a user installs a package in Debian, there’s a reasonable expectation that the user will get when the maintainer intended. Even Sorry, *what* the maintainer intended. [...]
Bug#956276: runescape: downloads unverified binary and runs it
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 >>> 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
Bug#956276: runescape: downloads unverified binary and runs it
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 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. 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. 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). 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. Regards, Stephen
Bug#956276: runescape: downloads unverified binary and runs it
Am 09.04.20 um 13:24 schrieb Stephen Kitt: > On Thu, 9 Apr 2020 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 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? 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. signature.asc Description: OpenPGP digital signature
Bug#956276: runescape: downloads unverified binary and runs it
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
Bug#956276: runescape: downloads unverified binary and runs it
On Thu, 9 Apr 2020 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 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... Regards, Stephen pgppUBzIp4quS.pgp Description: OpenPGP digital signature
Bug#956276: runescape: downloads unverified binary and runs it
Control: tags -1 moreinfo Am 09.04.20 um 11:36 schrieb Ivo De Decker: > package: runescape > severity: serious > > Hi, > > 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? Markus Koschany signature.asc Description: OpenPGP digital signature
Bug#956276: runescape: downloads unverified binary and runs it
package: runescape severity: serious Hi, 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. Cheers, Ivo
