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