Monday, May 5, 2008

Reciprocal help for security

JP/CERT pointed security holes of a certain module of X2/XCL. The subject of us is how the community handles such security holes.

It's impossible that all developers avert miss of security holes. It's bad that developers don't feel anything from security holes. But, it's also bad that developers are afraid of miss and development. If someone doesn't support him, the volunteer developer may leave from freeware development.

JP/CERT pointed security holes and send patches to the developer. Therefore we don't need to consider how to handle security holes of the module that JP/CERT points. The subject that we're thinking is that the community can not do it.

My opinion is that the community should try to check source code and send patches, if at all possible. The XOOPS Cube needs to recover "the custom" that each developer supports each other. There are two issues that we have to break down for that.

1) Revilement (misplaced anger)
The developer who made a security hole feel crushed. So he is often offensive and insults a supporter who sends a patch to him. This is one of the causes that the community lost the reciprocal help of developers. A man who tries to send a patch has to keep strong heart. And, other developers should help the man.

2) Duty
It's nice that developers support each other. But, XOOPS Cube is citizen's project, so such supports are also volunteer. Unfortunately, the community often tries to change goodwill reciprocal help of developers to systematic duty (or institution). This is another cause that developers who are able to send a patch became tired. To lessen the psychological distress of developers, the project should push "feeling" that THIS IS VOLUNTEER PROJECT. And, if the community makes the feeling popular, that's great.

It's difficult to keep freeware activity, if the activity is unenjoyable. Security holes, the revilement and the duty are pain. The pain lets developers choose to cancel software development. A community often hopes to become big systematic organization. But, The organization needs to consider what the freeware activity is. XOOPS Cube defines it as anarchy. I think that we can recover the reciprocal help for security holes, because XOOPS Cube is anarchy. Here is not the duty at least.

The anarchism denies not voluntary establishment, but compulsory establishment.


mikhail said...

Hi, Master! :-) Maybe a off-topic: Is sad, for security websites, "CMS SECURITY HOLES" and "3RD PARTY MODULES SECURITY HOLES" are the exactly same thing. So, a commercial CMS can attack another CMS spreading security holes of old modules or creating modules with security holes and alerting the security sites about it (I mean, this situation just allows it, but I think hard to happens). For me, this is a kind of security issue that can damage the reputation of "clean" projects.


minahito said...

I agree your thought. We need to share such security holes and keep efforts to patch those. But, if we begin to divide secure modules and unsecure modules by "official" announce, it means that we will re-build XOOPS government. That's very very difficult problem.