In this week's KDE Commit-Digest: The beginnings of a network management applet in Plasma, work on containments, and improvements in the "RSS" data engine and "Devices" applet. Initial support for saving changes to documents in Okular. A Kross-based scripting plungin in KLinkStatus. "Tip-of-the-day" and "Qt methods to avoid" checkers for the Krazy code quality reporting system. First steps towards a C++ parser in Umbrello. Work on projection independence in Marble. More maintenance and bux fixing in Kooka. Continued work in KHTML. Expanded support for subtitles and audio channel selection in Phonon (prompted by the requirements of Dragon Player). A rewritten "Todo" view in KOrganizer. Further work towards Amarok 2.0. "HTTP webseeding" in KTorrent. Kross-based scripting in KPlato, with support for "find in multiple documents" in KOffice. Caching support extended to all KDE card games. Improvements in KTurtle, KNetwalk, and Kubrick. Initial imports and work on the "Killbots" and "Astrododge" games. Import of "RSSNOW", an alternate RSS feed reader Plasmoid. The Step physics package moves from playground/edu to kdereview so that it can move to the kdeedu module for KDE 4.1. Read the rest of the Digest here.
Comments
Good grief, do any of you sleep? ;) `you', in this case, includes Danny. Thanks for the Digest, and thanks to all the developers for the ridiculously inhuman amount of work you put in!
of course danny sleeps, why do you think commits come out a week after they have been released. Well, in this case, over a week. Pity they don't hire a monkey, which would be a lot more efficient than Danny.
It's time dot gets rid of Danny and gets someone decent who can do this job. It's getting worse and worse
Writing articles for The Dot isn't a paid job. It is all done by people who use their free time to contribute to KDE. If you don't like that situation, you could hire a writer who creates articles and gets paid for it.
I guess this is supposed to be funny? Sorry, it's not. It sounds a lot like a frustrated Gnome user who is annoyed his community is unable to get such a large stream of quality development news to it's users. Not that there would be much to tell, of course...
Would someone be willing to post a screenshot of the new to-do view in KOrganizer?
agreed
hopefully someone finds the time to put up a few images of it :)
I'm hoping for a To Do plasma applet. I'm horribly easily distracted (look I'm on the dot right now) and it would be great to have something easily accessible and reminding me to "DO THIS NOW" (...other than my girlfriend).
Thanks.
Hi
This is an attached screenshot in bugzilla :
http://bugs.kde.org/attachment.cgi?id=23846&action=view (2008-03-10 11:49)
What did they re-write about it? It looks exactly like the to-do in KDE3 KOrganizer.
I think, first of all it is rewritten to use Qt4
I follow the new builds from time to time. I not that some of the plasma apps will kill the window manager, well the screen goes black, and all I can do is a ctrl+alt+delete.
I know this is not production code, but was wondering what the design philosophy of Plasma is.
Will Plasma be engineered to handle bad plasmoids and not seg fault or go into never land. Or does it expect all plasmoids to be good citizens and not crash.
KDE really looks great. by the way
Some plasmoids do have issues as the underlying api is changing a bit. However, when this happens (wont happen once the api has become more stable) you can hit alt-F2 and type plasma to get it back <-- (the reason krunner is separate from plasma).
Yes. But "Will Plasma be engineered to handle bad plasmoids and not seg fault or go into never land. Or does it expect all plasmoids to be good citizens and not crash."
If a Plasmoid written in native code crashes, it will take down the rest of Plasma (but not the "window manager", as the OP claims - I have no idea what's happening there) - this is unavoidable, and the statement "wont happen once the api has become more stable" is entirely false. Which is why scripted Plasmoids are so desirable: they are easy to write, easy to deploy, download and install, sandboxable if the scripting language allows it (Javascript/ QtScript are favoured here, as e.g. Python and Ruby do not have mature sandbox implementations) so that you can in theory fine-tune what resources each one can and cannot access/ modify, and you can guard against having them crash.
Have the plasma developers thought of the security implications of running native code? It wouldn't be good to run a plasma applet and have it rootkit the system!
For a "security guy", you sure don't have a good understanding of common terms. For reference, most apps that you are using right now - including your web browser, e-mail client, etc - are "native code".
Yes, but - unlike Plasmoids - the normal method of obtaining that code is not to download them from a random 3rd party on the internet, since they come with your distro. IMO, the different security concerns for Plasmoids arise from the fact that there's a lower "barrier to entry" to getting Plasmoids onto a users' desktop.
Probably why you're not supposed to download and run apps you don't trust.
Native code apps will always have to be either compiled from source (a power-user task), obtained from distro packages, etc - in other words, Plasma does *not* lower the barrier to entry of getting native code onto the users desktop. It is precisely as much of an increased security risk as Kicker applets were i.e. "barely at all".
Non-native code - which will hopefully form the bulk of 3rd party plasmoids - can, as mentioned elsewhere in this thread, be tightly sandboxed so that it can do no harm.
> in other words, Plasma does *not* lower the barrier to entry of getting native code onto the users desktop
It does. Security is not related here but things like a) the time needed to look at how it should be done and b) the time needed to get it working. Plasma helps with a) by providing good, clean and small interfaces Plasmoids need to implement and helps with b) by providing a fast way to test your code and cause of a) it's also not needed to write tons of code to get just something working.
All in all, it does help to lower the barrier to entry. If we look at scripting code aka Plasoids written or extended with scripts, then there is also no connection between security and barrier since it's not the main goal of most scripting languages to provide a secure sandbox but to get a solution out faster (aka without learning pointer-logic, without compiling, without being such static limited, etc.) an that's exactly what they (may) do in plasma as well :)
> in other words, Plasma does *not* lower the barrier to entry of getting native code onto the users desktop
It does. Security is not related here but things like a) the time needed to look at how it should be done and b) the time needed to get it working. Plasma helps with a) by providing good, clean and small interfaces Plasmoids can implement and helps with b) by providing a fast way to test your code and get it working and cause of a) the task shouldn't be that complex => lesser code needed to get the job done.
All in all, it does help to lower the barrier to entry. If we look at scripting code aka Plasmoids written or extended with scripts, then there is also no connection between security and entry-barrier since it's not the main goal of most scripting languages to provide a secure sandbox but to get a solution out faster (aka without learning pointer-logic, without compiling, without being such static limited, etc.) an that's exactly what they (may) do in plasma as well. Security, as in Plasmoids coming from untrusted sources, is only related for the deployment.
Yes, it has been considered. No plasma apps can not rootkit your system.
Double negative error.
... or a missingcomma. :-)
Are you *sure* it's an error?
I suspect it's not...
re security and sandbox;
Ruby comes with security-levels, Python can be extended using the RestrictedPython module (like Kross did in KDE3) or the Zope3 security-framework. But I wouldn't trust all of them to be _the_ solution. All they can do is to rise the time needed till some evil actions are possible.
btw, QtScript does not provide any kind of sandbox-model while KjsEmbed does remove the security logic from Kjs by extending it with potential insecure functionality. So, none of them is _the_ solution if it comes to security either. I guess Java or Kjs/WebCoreScript direct are the best / most secure ways to go here but even then I wouldn't trust them ;)
Actually QtScript provides the exact same sandbox as a browser. It's simply a matter of which objects you choose to expose. Ruby's security levels don't seem particularly well thought out when I looked at them either.
I was refering to http://labs.trolltech.com/blogs/2008/03/10/bind-aid/
Anon: "Is there any provision for sandboxing"
Kent: "Anon: Nothing yet. However, you’re free to remove e.g. the QFile and QDir constructors from the script engine after importing the bindings. We’re playing with offering more flexible/fine-grained ways of configuring the bindings though, will keep this in mind."
Sandboxing doesn't mean to just don't provide functionality that may insecure (else brainf*ck would be the most secure language followed by xslt :) but to be able to control and limit it. So, to e.g. allow to use QFile but to restrict it to reading from /home/friendly_user/for_my_gov_agency and writting to /home/president_bush/next_wars ;)
I guess the Java policy-framework is a very good example imho followed by the Zope3 security-framework.
> Ruby's security levels don't seem particularly well thought out when I looked at them either.
Cause of the only both vulnerabilities Ruby had in 2005 (CVE-2005-2337 and CVE-2005-1992) while e.g. Safari had 20 times as much?
>> Ruby's security levels don't seem particularly well thought out when I
>> looked at them either.
> Cause of the only both vulnerabilities Ruby had in 2005 (CVE-2005-2337
> and CVE-2005-1992) while e.g. Safari had 20 times as much?
The problem is one of design rather than implementation. To give an example, at a SAFE level of 2 you are prevented from doing File.chmod, but you're free to do Kernel.system("chmod +x blah").
> To give an example, at a SAFE level of 2 you are prevented from doing File.chmod, but you're free to do Kernel.system("chmod +x blah").
y, cause T2 is about "Ruby prohibits the loading of program files from globally writable locations." and has nothing to do with chmod+userfiles. Use at least T3 or even better T4.
but I agree that those "safe levels" are not really what someone may understand under sandbox too since it would still be needed to provide secure wrappers for things like readfile, chmod, etc. if they should be limited to defined locations :-( Same was the case with Zope2 RestrictedPython and since I still believe it's better to provide no security then false security, I just did removed it in KDE4 - the Zope3 solution really looks very good but is to huge to be adopted :-(
Guess my initial point of "none of them is _the_ solution if it comes to security" is still valid even if I wish that wouldn't be the case :-(
and before I forget it, there is the nice document "Sandboxing of Dynamic Code" around which does provide some good (but in the case of Python outdated) details related to that topic; http://rune.hammersland.net/tekst/sandbox.pdf
Another thing with the ruby safe levels is that they seem very oriented to web apps operating on untrusted data rather than apps embedding the interpreter operating on untrusted code. eg. only at a safe level of 4 is the script prevented from terminating your application.
> Guess my initial point of "none of them is _the_ solution if it comes to
> security" is still valid even if I wish that wouldn't be the case :-(
I think that's a pretty fair assessment. It's not the answer I'd like either though. :-(
The java security manager approach is the only real way I've seen to get truly fine grained control, and that is extremely complex and requires hooks in all your libraries. Even then it has been bypassed on a number of occaisions (possibly because it is too complex to test effectively).
> eg. only at a safe level of 4 is the script prevented from terminating your application.
Does you have a source for this? I ask cause, well, we are using Ruby and I never did note such behavior. What for sure is a bit annoying and probably related is that it's needed to wrap each C-functioncall into a secure-fallback function to catch exceptions explicit. If that isn't done and if the call throws an exception, the application will crash (same with T4 btw). The reason for that design was to maximize the performance by being able to select what C-functions may throw an exception (that needs to be catched) and which one are not. Guess that's very inline with the overall design-goal of Ruby to provide the fastest scripting-environment out there on earth.
> The java security manager approach is the only real way I've seen to get truly fine grained control, and that is extremely complex and requires hooks in all your libraries.
y, true. That's really one of the best solutions I saw so far but also comes with so much downsides. Very much like something like SE-Linux which if used wrong may provide more trouble then solving any.
> Even then it has been bypassed on a number of occaisions (possibly because it is too complex to test effectively).
and judging from the 1.6 showstopper-bug I run into (known since more then 2 years btw) I wouldn't wonder if there are no automated tests for such things at all :-/
> Does you have a source for this?
This is the best doc I've found on ruby safe levels (especially the table at the bottom):
http://phrogz.net/ProgrammingRuby/taint.html
> http://phrogz.net/ProgrammingRuby/taint.html
Thanks for that link and now I am impressed since at $SAFE>=2 it really says chmod should be prevented. Uh, I've to add. That's really new to me and its even more surprising it's written down in a book while being just not true/valid. Guess that was the last destroyed difference between books and TV :)
Re $SAFE>=4 and "Can't invoke exit, exit!, or abort." Neither exit or abort works if embedded, but exit! does and that even with SAFE==4. Hmpf, http://www.math.hokudai.ac.jp/~gotoken/ruby/man/function.html#exit_bang says unlike abort and exit the exit! function ignores any handlers. Fine :-( Anyway, added to my todo and will be fixed asap, thanks for that hint!
Yes, I checked the ruby source code too and the code matches this reference.
It would be good if KDE restarted Plasma if it crashes, like KDE 3 does with Kicker in some cases. Otherwise we reach the quality of Windows 9x where a poorly written component could crash the whole system - average users have no idea about "Alt+F2 plasma".
iirc it does auto-restart. Re win95; the whole OS could crash by any app and not only the desktop by it's plugins. So, probably it's more fair to compare with extensions that crash the WinExplorer (which is afaik responsible for the desktop), with a winamp-plugin that crashes whole of winamp or with a driver that oop's'es whole of linux.
Technically you are probably right, but from a non-technical user's point of view I presume that a Plasma crash equates to a complete system crash as his main (and probably solely) means of communication with the system are not available any more. If I had to hazzard a guess people who don't know how to launch plasma via krunner or are not familiar with virtual terminals will probably hit the reset button at this point.
> Technically you are probably right
is that different from practical? Sorry, failed to resist :)
> that a Plasma crash equates to a complete system crash as his main (and probably solely) means of communication with the system are not available any more
That's why it auto-restarts. Though before we move again to the beginning of the circle, I may like to point to 2 examples;
1. SuperKaramba
It's a plasmoid that can be run either _in_ process just like most (all?) plasmoids today OR _out_ of process. Right, both is possible and I can imagine that bigger and more complex plasmoids (so, e.g. whole applications rather then a clock or a status-display) can go the same way. Technical (and practical) it just does not make any sense to move e.g. a clock into an own process. See here also the last note at the bottom of http://ktown.kde.org/~seli/memory/desktop_benchmark.html
2. Trayicons
The trayion plasmoid does display those handy icons which are provided by an app and then embedded into the trayicon plasmoid. So, if a running app crashes it doesn't crash the trayicon-plasmoid and with it plasma.
So, you see. It is technical (and practical *g*) possible already. That the OP does now ask if the crashes he did run into are cause of the "design philosophy of Plasma" is even somewhat funny from the pov of someone who's still running KDE3 on his productive systems like suggested by the release-notes, blogs or even the mainstream-press. The problem is, that an answer like "no, it's cause KDE 4.0.2 isn't as rock stable as e.g. KDE3 kicker+applet are yet, but we are moving rather fast into that direction and once we are there your question will be solved" really does sound so reused, that it's hard to repeat that. Probably an answer like "no, crashes are not a design philosophy but an attitude to life" or "if you don't like that crash we can add a GUI-option to disable it" would offer some more variety of fun?! :)
Plasma already gets restarted when it crashes. There is some simple logic in there so it doesn't crash in an infinite loop though. It won't restart itself after a second crash.
If it behaves this way, it should save a "last known working configuration". My experience is that it didn't restart after a crash; I don't know why.
it doesn't restart if a crash happens within 10s of restarting. but then we install the crash handler again after 10s of running. this is usually enough to stop infinite recursions of doom.
The amount of work going into Akonadi & friends was really impressive. The API review will produce great long-term results, I'm sure, even if such cleanups require quite a lot of tedious work. A very exciting read, thanks to all devs.
It seem we will get fast and rich features web browser in kde 4.1. Does any one have the score of KHTML (development version) in Acid test version 3 ? what about the javascript benchmark in compare with firefox 3 beta 4?
Well, if the KHTML developers finally got over their giant ego and already ported WebKit into the KHTML framework, then it's 95/100 points: http://webkit.org/blog/167/webkit-gets-an-a-on-acid3/
While I too would like to see webkit used by kde and one common web platform, the khtml developers deserve better treatment. They seem to be helping out all over: http://webkit.org/blog/158/the-acid-3-test/
Yea, took the WebKit crew quite some time to finally include the CSS3 selectors patches by the KHTML developers (they were available for ages, but only with this ACID3 test there was interest from WebKit side to actually incorporate them).
I'm sure once it's easier to compare output of KHTML and WebKit within KDE the stream of merge patches between the two will increase. I just hope the WebKit side will be more forwardcoming in incorporating KHTML improvements then.
Agreed, the KHTML developers really deserve better treatment.
Without them, Konqueror in KDE 4.0.x would be unusable as web browser (KHTML crashed too often and rendered pages like ancient browser before they started fixing bugs for KDE 4, and now it is pretty solid). And I'm also sad that some people never appreciate what the KHTML developers have done, especially those who can only yell: "dump KHTML, use Webkit!"
I hope KHTML can remain alive, so that we have an alternative engine inside our own tree. I would also like WebKit to be used by KDE, but I guess having an engine that we have total control would be advantageous.