On 09/04/2013 09:43 PM, Jose Luis Rivas wrote: > Because it's not a requirement to see `powertop.html`. If the file is > not found then it's not giving errors which put `jquery` in the > `suggests` field. Less people is installing suggestions than have > internet while loading and HTML.
If it's not a requirement to see it, then all the more reason to avoid
interacting with a third-party server for a superfluity. Users with no
(or intermittent) 'net connections can at least make the choice to
install libjs-jquery when they are installing the machine, as can users
*with* robust 'net access.
> Won't do that. In the package-management paradigm of Operating Systems
> there's no sane way to keep up with how JavaScript libraries work.
Sorry, but there's nothing magical about javascript that makes js
libraries somehow immune to the various issues that other libraries
have. It does take work to declare and maintain a stable API while
patching security holes as they are discovered. And it takes work on
behalf of the user of a library to choose and depend on a stable version
of the API. Hard-coding a particular version of a library (e.g. by
embedding it) is the equivalent of static linking, which we agree is a
bad idea in other applications.
Only in this case, we're talking about "statically linking" to an
internet resource that is delivered without any cryptographic guarantees
of integrity.
> I do development on JavaScript primarily at work, and I can't use
> packaged js-libs because of this, so I refuse to suggest people to
> waste their time. To handle JavaScript libraries there's already two
> sane-ways: use either NPM or Bower. Most of this is transparent to the
> user unless is using a local file (which is the case in this report)
> and when using a local-file the suggested way is using a public CDN
> (which is what is being done).
afaict, neither NPM nor Bower does cryptographic authentication of the
code they fetch from the 'net, and neither of them appears to be
committed to supporting a stable API while also patching security fixes.
We've managed to do all of the above with most other libraries within
debian for years now. Why should we ignore these same code-management
issues for any package just because it's javascript?
> That's how it works, the primarily exploits from JavaScript are
> reading cookies which are not accessible if you are using file://.
> This is served from a public repository widely used, and the use of
> jQuery is limited to show and hide elements;
If the legitimate use of jQuery is only for showing and hiding elements,
maybe the best thing is just to patch to avoid jquery entirely and use
native, cross-platform DOM. Even if you think jQuery is the "best" way
to do this, i strongly doubt that the jQuery API for showing and hiding
elements will change at this point, so the concern about what happens if
debian moves libjs-jquery from 1.7 to 1.10 seems moot.
> not only that, there's no
> input of data in it. So, what's the security risk?
If the code is fetched over the network, then whoever is serving the
code (including any other machine on your LAN, if they decide to spoof
traffic) can inject arbitrary code in the .js file. There are lots of
other exploits to be had from arbitrary javascript besides reading cookies.
What other security risks are there? well, anything that your browser is
vulnerable to; e.g. flash objects, webGL craziness, hooks into <audio>
or <video> elements to exploit your installed codecs, etc; the server
deploying that .js file could use it to display advertisements, could
read out the data in your powertop report to learn details about your
hardware; it could modify the data as it displays so that you get the
wrong information; it could even embed malicious shell code in the text
that makes it look like this powertop report is suggesting the user
should run as root in order to decrease power consumption. i'm sure you
can use your imagination to come up with other attack vectors. We have
a way to avoid exposing the user to any of them. Why not take it?
> And is serving free-software, there's no ties on licensing nor liberty
> using a CDN;
at the moment, assuming there is no interference with the network path,
you are correct. But this choice makes the output from a package in
debian main depend on the continuing goodwill and management of services
that are not bound by the policies of debian main.
I think this is a bad idea.
Regards,
--dkg
signature.asc
Description: OpenPGP digital signature
