35

Hi. I don't know if this is done already, but after a rouge .deb file was uploaded to gnome-look (really long discussion here) http://ubuntuforums.org/showthread.php? ... 78&page=16 which was an extremely close call, it got me thinking that such a rouge file could be uploaded to kde-look, and be picked up by khotnewstuff, where people can install it with one click without thinking, and the rouge file could cause damage to the users files.

My idea is that any kde-look item should be manually audited before it actually arrives into the khotnewstuff listings.

I don't know if they do this already or not.

AFAIK khotnewstuff only downloads archives and extracts them into a theme folder, it never runs any scripts or installs applications

Scnd101 wrote:AFAIK khotnewstuff only downloads archives and extracts them into a theme folder, it never runs any scripts or installs applications

No, but since you can install plasmoid scripts (presumably for the purpose of running them), it's a good idea.

This is great in an ideal word but infeasible in practice. There are just too many submissions and too few people to check them all.

Agreed - however if kde-look as a "flag entry" feature, perhaps gethotnewstuff could display a warning if you attempt to download a flagged submission.

This is great in an ideal word but infeasible in practice. There are just too many submissions and too few people to check them all.

Well, one of three things needs to be done:
1. A review process for content accessible through khotnewstuff added.
2. Sandboxing of executable code in khotnewstuff-originated content.
3. Khotnewstuff being able to install only content containing no executable code.

Otherwise it's the best attack vector trojan authors could dream of.
In light of that, option 1 seems preferable, because option 2 would require a redesign of how plasmoids and other plugins work and probably wouldn't be done before KDE 5 or KDE 6.

Please see my article here for a detailed explanation why this _cannot_ work:


http://amarok.kde.org/blog/archives/115 ... ution.html

I agree with markey - which is why I suggested to have a "flag entry", which pushes the work to the people, but then again it will still affect a few people. In fact in hindsight I would suggest a "trusted" flag, where if let's say 10 different users mark it as safe to use others will know it is safe.

VCS is another good idea as well, but should belong on its own brainstorm idea - markey if you could be so kind?

extending on Moult's ideas of pushing the flagging/trusting to the community, I think it would be a good idea for both trusted AND non trusted flags, maybe 10 flags for trusted, but one untrusted flag brings up a warning for all who try to install it, until its audited internally.

Anonymous voting with such low thresholds as 1 and 10 is very prone to misinformation. You cannot depend on it for malware prevention for two reasons:
* It's easy for a malware author to get his script voted up
* Users will grade how the script looks and does its job, without noticing whether or not it performs malicious activities in the background.

Do you expect users to first install scripts via an easy interface, then hunt down the location of those scripts on the filesystem to read their source? At least if it was easy to review scripts before installing them, perhaps we could expect the more technical users to skim over them.

Linux distros have thousands of packagers working on their repositories, I don't see why it's supposed to be impossible for kde-look.org to have a couple reviewers. There just needs to be a more convenient review process than manually downloading and extracting tarballs.

Regarding the VCS idea - I don't see a difference between a VCS and a custom CMS like kde-look.org has. Both can gather the same amount of information about a submitter.

Quite honestly after reading indiva's comment I must say I agree wholeheartedly. In the long-run we definitely need quality control in all aspects of these community sites - it's unavoidable and should be done sooner than later.

Hold up people, you're forgetting something. Sure, it would be nice to have a quality control instance, but the fact is that it is practically impossible given the development frequenzy in an oss-community and the number of people willing to take the time doing such a thing.

However, the fact is that we pretty much already have quality control. That is us, the users!! The gnome-look experience showed us that Linux/FOSS is not immune to malicious software. However, what it also taught us, which a lot of people tend to forget, is how quickly those get discovered and neutralized in the community.

Sure, it's not stopping the malware from being posted and downloaded a few times before being discovered, but it sure is one of the most effective ways of minimizing the damage done (which is practically the only thing we can do). So repeat after me: WE ARE QUALITY CONTROL!

I think that a simple way to add/read comments by the users should be a valid compromise, just like, for example, android market works. A way to take away spam comments, could be the capability to add the tag "spam" by the users too.

We are KDE SC!

We are KDE SC!

Just to clarify - no we are not. We are KDE - the community. KDE SC is KDE's Software Compilation