Slashdot Mirror

> Basically, many good things will happen if you include the AJAX set of tools.

Riiiight! If you limit yourself to "the top 4 browsers" with their incompatible script hosts, DOM implementations and XSLT processors (does MSIE/MSXML even recognise the correct XSL mime type?) "Many good things will happen".

Of course they will sweet pea

There is now DOAP (description of a project) - a vocabulary / schema that allows to mark up such information.

It would be much more fun to have machine-readable links between different titles that forked one from another, etc. Uses can be starting from "maps" of software evolution mentioned in above and to other uses yet to be imagined. (Note: I do not know if DOAP allows to describe such parent-child relationships between software projects, but if such a property is needed I am sure someone will invent it).

P.S. Having information about abandonware would also be useful - but mainly if they'd also provide downloads and source code (where available). Although I doubt anyone will go to such extent to preserve abandonware.

I take him seriously. Edd Dumbill is an Editor at Large for O'Reilly Network, an author of three books for O'Reilly, and a GNOME contributor, and an excellent tech weblogger, among other things.

I take him seriously. Edd Dumbill is an Editor at Large for O'Reilly Network, an author of three books for O'Reilly, and a GNOME contributor, and an excellent tech weblogger, among other things.

I take him seriously. Edd Dumbill is an Editor at Large for O'Reilly Network, an author of three books for O'Reilly, and a GNOME contributor, and an excellent tech weblogger, among other things.

And if you want clearer fonts, following this instructions you would have it. It's worth the effort.

Looking at the source code to XML-RPC library in question, to me it's raises some disturbing questions.

From a design perspective, it's really bizarre the way they've chosen to use eval() in the first place.

For a given XML-RPC request or response, they parse the XML then generate PHP code on the fly, which later get's eval'ed. Aside from the fact that using eval() should trigger all sorts of security alerts in a developers head, especially when you're building a library for hooking up remote systems, there's no need to use eval() in the first place.

You can convert data types directly from XML into a PHP data structure then make use of things like call_user_func_array() to execute a callback function as needed. This approach is taken by The Incutio XML-RPC Library for PHP, for example, and there are others to chose from.

Two further things that are disturbing about this exploit.

First looking at the diff which patched the exploit here, all that's basically changed is replacing a single quote with a double quote. That may prevent this specific exploit but the use of eval() is still there and I'm not see any further stringent checks that the incoming input is valid / safe etc. Would not be surprised if there are other ways to "inject" code here.

Second and perhaps most disturbing is the source for this library has a long history going back to Usefulinc and Edd Dumbill. Believe this and the Perl Frontier-RPC libraries were the first two Open Source XML-RPC projects released and in many ways reference implementations in a manner that parallels Apache being a reference implementation for HTTP.

This exploint has taken a very long time to spot. Looking at the main projects CVS here, with the very first revision 1.1, back in "Mon Aug 27 19:21:25 2001 UTC" (and the code is older than that going back to 1999 I believe), it looks like this specific exploit was possible then.

These days Usefulinc are doing things Gnome related - i.e. you'd assume they are real developers not PHP script kiddies. The original developer, Edd Dumbill, is no fool. In Edd's defence, believe he began development before PHP 4.0.4, somewhere with PHP 3.x, which means things like call_user_func_array() was not available and perhaps eval() was required but that should have been revised by the current maintainers of the project as PHP matured.

What's more alot of people have used this code and (hopefully) it's also had alot of experienced eyes looking at it. Those who ported it to PEAR, for example, are not beginners.

But only now, six year laters, was the exploit found. Seems like not a proud moment for Open Source.

Looking at the source code to XML-RPC library in question, to me it's raises some disturbing questions.

From a design perspective, it's really bizarre the way they've chosen to use eval() in the first place.

For a given XML-RPC request or response, they parse the XML then generate PHP code on the fly, which later get's eval'ed. Aside from the fact that using eval() should trigger all sorts of security alerts in a developers head, especially when you're building a library for hooking up remote systems, there's no need to use eval() in the first place.

You can convert data types directly from XML into a PHP data structure then make use of things like call_user_func_array() to execute a callback function as needed. This approach is taken by The Incutio XML-RPC Library for PHP, for example, and there are others to chose from.

Two further things that are disturbing about this exploit.

First looking at the diff which patched the exploit here, all that's basically changed is replacing a single quote with a double quote. That may prevent this specific exploit but the use of eval() is still there and I'm not see any further stringent checks that the incoming input is valid / safe etc. Would not be surprised if there are other ways to "inject" code here.

Second and perhaps most disturbing is the source for this library has a long history going back to Usefulinc and Edd Dumbill. Believe this and the Perl Frontier-RPC libraries were the first two Open Source XML-RPC projects released and in many ways reference implementations in a manner that parallels Apache being a reference implementation for HTTP.

This exploint has taken a very long time to spot. Looking at the main projects CVS here, with the very first revision 1.1, back in "Mon Aug 27 19:21:25 2001 UTC" (and the code is older than that going back to 1999 I believe), it looks like this specific exploit was possible then.

These days Usefulinc are doing things Gnome related - i.e. you'd assume they are real developers not PHP script kiddies. The original developer, Edd Dumbill, is no fool. In Edd's defence, believe he began development before PHP 4.0.4, somewhere with PHP 3.x, which means things like call_user_func_array() was not available and perhaps eval() was required but that should have been revised by the current maintainers of the project as PHP matured.

What's more alot of people have used this code and (hopefully) it's also had alot of experienced eyes looking at it. Those who ported it to PEAR, for example, are not beginners.

But only now, six year laters, was the exploit found. Seems like not a proud moment for Open Source.

Looking at the source code to XML-RPC library in question, to me it's raises some disturbing questions.

From a design perspective, it's really bizarre the way they've chosen to use eval() in the first place.

For a given XML-RPC request or response, they parse the XML then generate PHP code on the fly, which later get's eval'ed. Aside from the fact that using eval() should trigger all sorts of security alerts in a developers head, especially when you're building a library for hooking up remote systems, there's no need to use eval() in the first place.

You can convert data types directly from XML into a PHP data structure then make use of things like call_user_func_array() to execute a callback function as needed. This approach is taken by The Incutio XML-RPC Library for PHP, for example, and there are others to chose from.

Two further things that are disturbing about this exploit.

First looking at the diff which patched the exploit here, all that's basically changed is replacing a single quote with a double quote. That may prevent this specific exploit but the use of eval() is still there and I'm not see any further stringent checks that the incoming input is valid / safe etc. Would not be surprised if there are other ways to "inject" code here.

Second and perhaps most disturbing is the source for this library has a long history going back to Usefulinc and Edd Dumbill. Believe this and the Perl Frontier-RPC libraries were the first two Open Source XML-RPC projects released and in many ways reference implementations in a manner that parallels Apache being a reference implementation for HTTP.

This exploint has taken a very long time to spot. Looking at the main projects CVS here, with the very first revision 1.1, back in "Mon Aug 27 19:21:25 2001 UTC" (and the code is older than that going back to 1999 I believe), it looks like this specific exploit was possible then.

These days Usefulinc are doing things Gnome related - i.e. you'd assume they are real developers not PHP script kiddies. The original developer, Edd Dumbill, is no fool. In Edd's defence, believe he began development before PHP 4.0.4, somewhere with PHP 3.x, which means things like call_user_func_array() was not available and perhaps eval() was required but that should have been revised by the current maintainers of the project as PHP matured.

What's more alot of people have used this code and (hopefully) it's also had alot of experienced eyes looking at it. Those who ported it to PEAR, for example, are not beginners.

But only now, six year laters, was the exploit found. Seems like not a proud moment for Open Source.

[1] http://usefulinc.com/edd/blog/contents/2005/04/29- gnome-no-fun/read
[2] http://galaxy.osnews.com/email.php?blog_id=979
[3] http://galaxy.osnews.com/email.php?blog_id=973
[4] http://www.rockerssoft.com/brockers/archives/00051 0.html
[5] http://it.slashdot.org/comments.pl?sid=150592&cid= 12627995

Phear my cool GNOME CVS desktop. Look at that top current Screnshot that I've taken. The Toolbars went through huge usability studies by experts. It's clean, consistent and integrates perfectly, this is the most clean desktop amongst them all.

Ok after I ended consistant puking let's use something better, something with serious future.

Oh by the way have another look here:

Edd Dumbill, valuable member and developer of the GNOME Desktop Environment, author of the "Mono: A Developer's Notebook" book, speaks up his mind about GNOME in one of his recent blog entries.

Mikael Hallendahl, valuable member and developer of the GNOME Desktop Environment speaks out his mind upon GNOME and if there is a possible future.

There are even other key GNOME people who think about stopping the work on their products. Read what Damien Sandras (author of GnomeMeeting) has to say.

Err, here is Edd's post. Whoops.

See this entry from Edd Dumbill, author of the (very good) book Mono, A Developers Notebook. Turns out that in the new release, IronPython was made to depend on features that make it incompatible with Mono. How shocking, once the developer got hired by Microsoft the program no longer works with Open Source. How unbelievably shocking this is. So out of character for Microsoft...

Bugzilla is a critical part of the Free Software process - many projects rely on it and benefit greatly from its use.

Depending on your needs, Bugzilla may be overkill for your own (inhouse) project. From what I read on various blogs, it's somewhat hard to administer and/or install. So if you need a bugtracking system, check out this commented list of alternatives. Most of the systems in the list are free.

Can't send picture messages without a camera. Can't sell my sister $2 ring tones unless the phone supports them. Ring tones is a billion dollar industry.

If you get a phone with Bluetooth, and your PC has it as well, you can use Bluetooth to transfer ringtones (MIDIs), pictures, themes, games, etc. Surprisingly, Gnome's Bluetooth subsystem works great, better, in fact, than Windows XP SP2.

Edd Dumbill has a list of (mostly) free issue tracking systems. It's a very good starting point.

One of the most interesting systems in that list is (IMHO) Eventum, by the company that produces the commercial version of MySQL. It only needs PHP and MySQL, and should therefore run well on Windows. Be advised that I haven't actually tried it though.

Don't forget the desktop conference going on upstairs at the same time, for the GUI people. Edd Dumbill's report is here.

how hard would it be to port between GTK# and Winforms?

This is where documentation would help tremendously. Particularly in the form of "porting from windows .net to Mono" guide. I hear there's a book coming out on developing with Mono which might help some of us.

First, thanks for linking to the Google cache of my site, I'm grateful.

Second, the link that was posted was my how-to for hacking for the P800, not the syncing as the link advertised. Syncing is a little more difficult, but I also wrote that up here: Synchronizing a P800 with Evolution

-- Edd

• Takes photos with inbuilt camera, which I can then transfer to my laptop.
  
• Syncronizes its contacts, Todo list and Calendar with Evolution.
  
• Allows me to read Slashdot via WAP on the tram into work.
  
• Add and edit entries in my Movabletype blog.
  
• Gets net access for my laptop wherever I am via GPRS (only about modem speed, and kinda expensive, but good enough for email on the road).
  
• Recieves wallpaper, ringtones, themes and java apps from my computer. Uses JPG, GIF, MIDI and Tar (yes, that tar).
  
• Looks very shiny.
  

Besides one screenshot in the link, which is going slow..

Here's one using sniffed rss traffic

and here's one with geo traffic.. (cool) There's a bit more info here

Besides one screenshot in the link, which is going slow..

Here's one using sniffed rss traffic

and here's one with geo traffic.. (cool) There's a bit more info here

Besides one screenshot in the link, which is going slow..

Here's one using sniffed rss traffic

and here's one with geo traffic.. (cool) There's a bit more info here

Zope is a very cool web application system, and while I don't know of Guido's specific contributions I have to assume that they were great. Still, I'm confidant that Zope will carry on.

For those not familiar with Zope, it is a web application server written entirely in Python. It features an object database that, for example, lets you create an image object, and then call it from other code to automatically build your image tag based on the dimensions and title of the image stored in the object.

It's open source, developed both by the Zope community and the Zope corporation. There are at least two kick ass, open source content management systems built on top of Zope Corp's content management framework that I know of: Plone and Silva. There are a ton of add-on products that are downloadable too.

Zope does have a pretty steep learning curve, if you don't do stuff with "real" web applications (stuff that needs access control lists, user management, templating, etc) it might not be right for you, but it's great for bigger applications. Edd Dumbill talks in a recent blog entry about why Zope is worth learning and DevShed (which runs on Zope) has a good overview.

Guido and Dan Farmer are both smart guys and I'm sure that we can expect good things.