![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
There is a module (which I will not link) which is a duplicate of another, providing functionality that is absolutely crucial to every high performance Drupal site. Now, aside from the dubious claims it being faster than the original (it has been proven not to be and so now there are only indirect claims of it on the project page), it have proposed to replace the original instead of cooperating and, worst of all, it made a syntax error in a stable release. Stable releases are under the security team umbrella. For me, this situation is not acceptable. When I filed an issue in protest (which, to be fair, did not mention the security angle), the security team leader have said "I think it's fine to ignore this issue". I have no avenue left to protest but to resign from the security team. Once again, it's not really the specific module that is the problem it's just a symptom. We need to tear down the walls on who can create projects as it is clearly visible that they do not help at all and at the same time we need to change the role of the team and make it very clear that most modules are not under the security team umbrella. Discussions have happened about this for years now but I feel the time has run out. I am glad I could help this last eight years.
Commenting on this Story is closed.
Chx,
Glad you were there all these years and introduced me to the wonders of Drupal security.
Stable releases are under the "security umbrella" to have a clear policy Drupal users can rely on. If a module has a release, you'll always be sure to get a security announcement + update (or EOL) even if you are the only site using it.
- Heine
Rather than continue membership in a role where you actually had a chance to change the policy, you resigned to a state where you'll have no chance to change the policy. Sounds like you had no intention of putting forth such effort in the first place and that you're making a public tantrum just to demoralize Greg, another volunteer. The tiny team of security volunteers can't be involved in every Drupal module - there are too many modules and too few volunteers. If the policy of hosting modules on drupal.org gets harder, you risk fragmenting the hosting of modules in a central place, ending up with them all over the internet. Then tools like drush have diminished value.
Why is it the security teams responsibility to police duplicate modules? If you didn't mention the security risks in its release, was it any surprise that they brushed it aside?
I think people play too many mind games instead of cutting through the BS to get things accomplished. This is just more grandstanding that takes focus away from fixing the actual problem that pissed you off in the first place.
And the above comment is right - if you block or make creating modules on Drupal harder than it already is, people who can't be approved will downshift to GitHub to host their code. That would have ill effects on great centralized tools like Drush.
First off, I know which module you're talking about and I followed the discussion over combining efforts that ultimately went nowhere.
There are *lots* of duplicate modules, some of which were also created due to communications problems between maintainers, or created under a "ours is better" hand-waving pretense (Services vs Web Service Client, anyone?), so why is this any different? Another maintainer comes along, says their module is better, let them continue work on it and maybe some collaboration / inter-operability can happen, otherwise let the best module win?
You haven't explained whether there actually *is* a security problem in the new module, therefore your reason to complain about it under the auspice of the security team is disingenuous.
Lastly, as someone else mentioned, duplicate modules & maintainer cat-herding is outside of the security team's jurisdiction / auspice, so why are you even mentioning the security team?
-Damien
... it seems to me that syntax errors in a stable release are a clear indicator of quality / testing or the lack of thereof and so it's reasonable to assume that security holes will follow. And it also seems that the whole process of "project applications" is completely useless, alas.
This isn't the first time that a module has had a "whoopsie" release, and won't be the last – at least the maintainer released a fixed release the *next* day, versus many situations where "stable" releases of some of the most used modules having major bugs with RTBC fixes sitting idle for over a year. I really feel like you are blowing this out of proportion.
-Damien
It's not completely useless. Why are you so black and white on everything? Its not a complete, success so its a complete failure? If anything, it's been a boon for Drupal keeping duplicated module counts relatively low compared to every other platform out there.
You can't say the security team is a giant failure because they did not see the criticalness of a syntax error in a bug report you submitted while redacting what the security issue is there. They don't exist to police duplicate code - they exist to protect from security exploits. I don't understand why you didn't fully disclose that to bring urgency to it instead of just dance around it, creating drama while dragging the team through it.
Just all set egos aside, and collaborate on the issues. We all have a passion for this, even when we say we don't.
Damien, very well said.
Also, don't forget that all modules are GPL2 code, there's nothing stopping someone from just copying the code from module B to module A, e.g. https://drupal.org/node/2068469
I tried to post here before but was blocked by the spam filter.
The blog post doesn't really make sense, but anyway, thank you for your work with the Security Team for so long. It deserves more gratitude.
Seriously, chill. This "duplicate" module is not a duplicate, it's an alternative. It's both fine and useful: alternatives are giving the user choice between two different ways of achieving the same goal. And please be polite, the legacy module this alternative is cloning is desesperatly unmaintained and feature freezed.
Resigning from the security team has absolutly nothing to do with this, it's just your choice as an answer facing the fact that you are angry.