21–30 of 180 posts
This fix is an opt-out with a compilation flag. Also, I don't know much about Chromium development process, so it might be irrelevant, but I only see source updates, without any updates in the documentation.
Earlier quoted context omitted.
Do what by accident? Of course the intent was to include the blob. If Debian wants to get rid of it it should patch Chromium or request it to be made configurable (which is what happened). But the tinfoil hattery is completely baseless.
But you do understand that Chromium is supposed to be open source, right? So, if the intent was to include a binary, closed source blob into an open source project, that could be called malicious.
Chromium is and has always been an open source project in name only.
From the comments on the debian bug, this appears to have been fixed in Chromium. https://code.google.com/p/chromium/issues/detail?id=491435
Strange how they "fixed" it by making it opt-out rather than opt-in, given the culture collision here. Google really likes NaCl a lot for being a feature with almost no third party adoption.
I advise not reading that bug, some of the later comments will give you brain cancer. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909#51 Downvotes? So you agree with this? "I seriously consider the good faith of an such upstream which does these kinds of things" "But basically secretly downloading it leads to the question of possible malicious intent (and everyone knows that Google&Co. do voluntarily and/or…
Since no one really know which binaries have been downloaded there and what they actually do, and since it cannot be excluded that it was actually executed, such systems are basically to be considered compromised
A closed source binary being silently downloaded and executed without explicit action by the user or notification to the same is a security incident.
Many people are used to it because of all the training received by the "Java Auto Update", "Google Update Helper" and similar software receiving blank permission to monitor, download and execute closed source software with the same permission as the logged in user.
Despite of that a person that goes to the lengths of using Debian (instead of Ubuntu) and Chromium instead of Chrome certainly expects more from their sources than to allow this kind of behaviour.
It is a security incident and should be treated as one both by Debian and by the community in general.
Earlier quoted context omitted.
Strange how they "fixed" it by making it opt-out rather than opt-in, given the culture collision here. Google really likes NaCl a lot for being a feature with almost no third party adoption.
That's the point. It's strong vendor lock in because NaCl is unadoptable by their competition.
But even if they did go down that route, NaCl is licensed under BSD, so even Microsoft could add NaCL to IE if they wanted to. That's some pretty weak vendor lock-in.
I advise not reading that bug, some of the later comments will give you brain cancer. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909#51 Downvotes? So you agree with this? "I seriously consider the good faith of an such upstream which does these kinds of things" "But basically secretly downloading it leads to the question of possible malicious intent (and everyone knows that Google&Co. do voluntarily and/or…
The tone was inflammatory but the sentiment is valid. Quoting: Since no one really know which binaries have been downloaded there and what they actually do, and since it cannot be excluded that it was actually executed, such systems are basically to be considered compromised A closed source binary being silently downloaded and executed without explicit action by the user or notification to the same is a security inci…
Whereas source code being downloaded, compiled and run is not? Or a script being downloaded and run?
Earlier quoted context omitted.
That's the point. It's strong vendor lock in because NaCl is unadoptable by their competition.
It's really hard to create vendor lock in on a feature nobody uses. But even if they did go down that route, NaCl is licensed under BSD, so even Microsoft could add NaCL to IE if they wanted to. That's some pretty weak vendor lock-in.
A bit surprised that there is no security CVE report attached. Debian policy is that binaries are vetted by a debian developer, sorted into Main, Contrib and Non-free, cryptographically signed and later verified by the client package system. The bug could allow arbitrary code to be installed and run without any of the above process if someone MitM the connection between the binary file and the client.
From my POV, the thing that's actually bothersome about this issue is that a closed-source blob is automatically inserted into a project that I -and others- had understood to be completely open-source.
The fact that the Chromium Google Hotword code was later made opt-out -rather than opt-in- through a build-time configuration option is similarly troubling.
[0] IIRC, Chromium does support enterprise TLS snooping/interception devices, but those certs have to be loaded into Chromium before such devices will work.