-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On 9/5/13 11:05 AM, Daniel Kahn Gillmor wrote: > 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.
Making something look ugly, removing usability and making it hard to get good usability just because you consider it a superfluity is not something I'm going to do. I know this is a common path to decisions in free-software, but is a path I'm not willing to take. > >> 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's very different. So different I actually haven't met the first person that uses the JS libraries packaged in Debian for big production systems. 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. The paradigm is clearly different in JavaScript. 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. This is a comparison of apples and pears. We are talking about JavaScript, a scripting language. > > Only in this case, we're talking about "statically linking" to an > internet resource that is delivered without any cryptographic > guarantees of integrity. So, if it's delivered using https is good enough for you? Or the paranoic-argument will be transferred to something like "but Google is a private third-party in which I don't trust"? > >> 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? And anyway, again, people is not using Debian's packages in production for JavaScript development. Doesn't that tell you something? > >> 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. I think this is actually a good solution. Sadly, I don't have the time to do it. If you make a patch for it I will implement it and send it upstream. > >> 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. Something easily fixable by just using the https version of it. > > 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; IF there's injection of code, which is not doable with https. the server > deploying that .js file could use it to display advertisements, Doubt they will. If that were the case shall we change the CDN, but it's not. (And if this were the case, no one would use them, honestly) could > read out the data in your powertop report to learn details about > your hardware; That endpoint is used not only by powertop but millions of sites around the globe. To learn those details from the powertop html you would need a targeted file. I don't think that's so important that Google will put that code into a js file that's easily readable in plain-text as it gets downloaded (unlike a binary) and is used, again, by millions of sites around the globe for different kind of stuff. it could modify the data as it displays so that you get the > wrong information; Idem my last paragraph. 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. Idem my last paragraph. 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? In that case just recommend our users to unplug the cord to their modems or just kill their WiFi. What about that? > >> 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. And isn't Debian works under the continuing goodwill and management of packages (even services and hardware that gets donated and/or rented) of people/companies anyway? They are bound to Debian's policies because of the license of the libraries, they don't need to sign a contract specific to Debian. I agree on using HTTPS. I agree, as well, that using jQuery is not a necessity for doing the usability stuff in the HTML. So if you make the patch for doing the same without using jQuery I will implement it and send it upstream to get applied. Kind Regards. - -- Jose Luis Rivas http://joseluisrivas.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREDAAYFAlIqvQ8ACgkQOKCtW8rKsRjvaQCfQ/ORCfTd3cQqe/Wx5Pzn2PUf JwoAoNrLbAOaEH7WCdTQWurBir5hTtUe =gmqt -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
