Linux.com

Using md5 or other (better) hash algorithms is a good way to be sure the package you download is a genuine one. Install only stable, md5-checked versions of servers for production, no development or cvs ! And check the md5 sums on several sites, pages...
OK a pirate could also try to change the md5 sums, but this task is a lot more difficult since :
- he would have to change the md5 sums on every location, web pages, ftp servers
- such kind of change would be fast to spot (faster than checking the source integrity).

#

Jem,

This has all happened before. Sendmail had the same thing only a year or two ago.

I have never heard an outcry claiming "this is what you get with open source code" because that's simply not accurate and there is a wealth of ways to prove that.

Commercial products have had similiar problems like shipping viruses, etc.

These things happen. It's the nature of an online world.

-Chris

#

Yes, but we wanted to report it, make sure everyone had the facts, and head off any potential blather from the usual proprietary peanut gallery about open source security.

There will always be security problems. I think we should be aware of all of them as soon as it's possible to get the information public.

-Jem

#

Sure it should be reported on...however, your writing was overly apologetic.

Let the peanut gallery fire off all it has. We can shoot right back, and our guns are loaded.

-Chris

#

With all the talent on-call to the free and opensource software community, I'd like to see a concentrated effort on tracking down the perpetrators and holding them responsible for their actions. In this regard, I would like to call on the maintainers of the site to coordinate a task force to track these crackers. Post logs.

I would dearly love to see that not only can FOSS hackers write good software, we can protect it as well.

#

Users should download Xaraya<nobr> <wbr></nobr>.9.10, available from <A HREF="http://www.xaraya.com/" title="xaraya.com">http://www.xaraya.com</a xaraya.com>.

#

First PostNuke is not at issue here. No one hacked a PostNuke site, pafilb is not included in PostNuke.

Second, sure download Xaraya and when you can't figure out how to use it then use something else that you can figure out and get to work.

#

Sure, install Xaraya - and lose your entire website (as the Xaraya site had to discover a while back). DOn't do as they did, and actually keep some backups of your site handy..

Xaraya - regularly at the bottom of reviews.

#

The author and various readers note that infiltration is not particularly a problem with the open source development model. In all development models, anyone with sufficient access to the development environment could compromise it. Larger organizations are more likely to be exposed to such compromises, if only because more people are involved. Moreover, there is a strong financial incentive for proprietary developers to put competing products at a disadvantage.

My view is that the open source model presents us with a perfect opportunity to work on the general problem of authenticating contributions to the code base. The results can equally be applied to closed source development, but I believe that the open source model is a more realistic setting in which to develop effective solutions. We begin with the assumption that much of the development infrastructure in an open source project lies outside the control of the project. So a given contributor may be a nice guy, and may have properly signed all his contributions, but if he has practiced poor security hygeine on his own system, his contributions may be tainted.

This problem is obvious in open source development. What's perhaps not so obvious is that closed source organizations are not exempt from the effects of poor security hygeine. In theory, security could be tighter in a closed environment, but in practice very few organizations are willing to undergo the inconvenience of rigorous "clean room" discipline. Indeed, it would be unwise to assume any level of security as characteristic of closed source environments. In my experience as a security consultant, I've noticed that closed source developers are often expected to maintain their own systems, they often have persuaded management to give them root on the servers, and they often work from home. The outsourcing of development work provides similar opportunities for compromise.

In the open source community, our advantage is that we can face this problem head on. It's a question of authenticating both developers and their systems. In a sense, it's about DRM as well, but not the kind of mandatory "digital restrictions management" that conspires to put our systems outside of our control. This would be a more advisory kind of DRM by which we could mutually negotiate on compliance to agreed security standards. My point is that we need to take the lead on these decisions for our own benefit, or else we may find that they have been made for us. And that's not in the spirit of open source at all.

#

Have opensource hosted md5sum servers (where the program maintainer would update the sum) apt-get or other package managers could go and check a long list of md5sums over several servers to ensure the package downloaded is the correct and untouched one? The idea that there would be too many sources for the sums being checked it would be impossible to crack and change every one of them.

#

"Review is boring and time consuming, and it's hard," said Steve Lipner, manager of Microsoft's security response center. "Simply putting the source code out there and telling folks 'here it is' doesn't provide any assurance or degree of likelihood that the review will occur."

Seems silly to hinge your whole premise on such a shakey assumption...

#