The "i like this module" issue!

Great!
Although it might be a bit premature to say this (just played around for a couple of minutes), the module seems to work flawlessly and adds IMHO much needed (basic!) functionality that I'm definitely going to use, thanks a lot and please keep up the work!
The english might need a bit of polishing, though - would be fine if a native speaker could give it a little linguistic review before going out of beta...

Hi Eugen! I like your modules! Buy you a beer at DC Essen!

++1 great work!

+1 I find if very useful for collaboration systems. Just tried it on openAtrium and works great so far.

Great module! It's really nice to have this functionality in a full maintained module. Thanks!

Ahoy!

Really great module, thanks. :)

This module is a MUST HAVE in environments where people collaborate!

Great module, thank you so much!

Nice work thanks.

Saved me a lot of time, reading and searching :) really great module :)

Awesome, Thank u guys

Thanks so much for this, I really like this module and how clean it is.

great module, makes drupal become much more well suited for large user bases

Completely necessary module (it should be an option in drupal core)! Thanks for the great work on making it available to Drupal!

Agree. In fact, it is in the core of Joomla! and it is a must for a site with several writers.

Absolutely, I agree. Essential module. Thanks so much!

Any plans for a D7 version of this module?

Yes, I plan on getting a D7 version as soon as I can. I would like to get it this week if possible.

i like this module

like this module! Works fairly well, but is still a little quirky. Very excited to see continued development on it. It's essential to my project.

hehe, I like an issue just to tell you how much we like your module.

Our boss had an issue moving from joomla to Drupal cause joomla does this kind of locking OOB. We very quickly found this module and played with it and it worked perfectly as we expected :D! Well done!

Yes, this has been a great module. We have been using content_lock-6.x for quite a while and wonder what to do now that it is no longer supported.

@izmeez from http://drupal.org/project/content_lock

• Choose another, actively maintained module instead
• Fix the module and then contact the security team to have your version reviewed and the project handed over to you following the abandoned project process
• Hire someone to fix the security bug so the module can be re-published (see this guide on how to hire a Drupal site developer)

I'm really interested about what happened because AFAIK security issues (except this one) is not discussed publicly.

I just wonder, you and your co-maintainer refused to fix this security issue because of conflict with / attitude of the Drupal security team or because you don't have time / resources?

Thx for clarification.

My personal feeling about this is that I'm sorry that module is not supported anymore because of conflict with the Drupal security team..

I hope so that rfay's talk / initiative about Drupal governance will make this kind of situations not happen in future.

Unbelievable. Drupal overlords need to get real. This is a critical piece of functionality for any real CMS.

Eugen - thanks for your explanation.

When I first read that red flag on http://drupal.org/project/content_lock I thought that I really need to switch to another module to prevent concurrent editing. But I found none. Then I thought about where the vulnerability could be where a CSRF could attack. It really seems to only at the link for removing the editing lock.
Then my next thought was "so what". Then the editing lock would be gone. But for that I would have to click on such a "CSRF link" that I received through other means (e-mail or instant messaging) while editing a node. Which is veeeeeery unlikely to happen.

I tend to keep that module installed - and ignore the "unsupported" state.

Thanks for the great locking functionality.

Richard.

Sad, very sad... I absolutely understand the arguments of both sides. Both are "right" (in a certain way) and that's, well, bad!
What can I (a poor boy from Brazil) say here? I'm speechless ... I'll try: I use this module in an intranet (.org) with 1.200 with users... taking the words of @mshick:

This is a critical piece of functionality for any real "community" CMS.

I love Drupal... and this module.
(Forgive my poor English)

I think that preventing people from downloading the component is way overkill. Putting a warning on the module page that is has a possible security issue, and that people should download at the own risk would have been sufficient. Taking away our freedom to download the module is way to heavy-handed by the Drupal overlords. Please put the download links back.

I really appreciate the thoughts people have shared here over the past two days. I am left wondering if the Drupal Security group are seeing this discussion or if it will be necessary to draw their attention to this?

I just did that: http://groups.drupal.org/node/218139

I think that preventing people from downloading the component is way overkill.

If someone really wants it, they can get it from git. It's just the links on the project page that was removed. If someone isn't able to use git then they likely shouldn't be using insecure modules anyway. Someone sufficiently informed to make the decision on whether the risk is acceptable can get it from git.

First, I'd really like to get the module back to a supported state and hope we can focus on that goal.

As to whether this is "really a security issue" - there is no doubt in my mind that it is. The purpose of the module is to lock content so another user cannot edit it. It is possible for a malicious user to trick an admin into unlocking all the nodes, for example using a page full of images like:

<img src="http://localhost:8082/admin/content/node/content_lock/release/8" >
<img src="http://localhost:8082/admin/content/node/content_lock/release/9" >
<img src="http://localhost:8082/admin/content/node/content_lock/release/10" >

An argument that this is not a security issue is that the module provides an improvement over Drupal core and therefore a bug in it shouldn't count as security, but I don't see the logic in that argument. We also have modules that add encryption features to Drupal (something core doesn't handle). If the encryption modules failed to securely encrypt the data wouldn't we consider that a vulnerability?

There is a patch to fix the problem in the private security.drupal.org issue queue that EugenMayer has access to. I hope EugenMayer will take that patch, review it, confirm it fixes the issue and commit it. If not, then someone else could follow the unsupported project process to take it over and start maintaining it.

So, your security argument is:

It is possible for a malicious user to trick an admin into unlocking all the nodes...

Lets look at the cunning plan of our malicious user:

1. the "malicious user" login in order to manipulate the content
2. now he trick the admin with his malicious code to unlock all the nodes
3. all the nodes are unlocked now - time to start his malicious actions...
4. hm, lets see
5. he writes greggles an email and ask him what to do next, as he has the same normal privileges he had before

i don't have any permissions on content_lock, neither to edit nor push any code

Blocking your ability to push code was a mistake in the process. Our documentation on how to mark a project unsupported doesn't include removing the maintainers and that shouldn't have happened. I've re-granted permission to push code to the project which is how it always should have been.

Wow, give them a break. He said locking you out was a mistake and has since been fixed. And it wouldn't have even happened if you had been willing to fix the security issue. The security team has a tough job and stuff like this just makes it harder. So you're going to take your balls and leave because you don't want to secure your module? Seriously?

I'm not aware of any hidden agenda, either toward the content_lock maintainers as individuals or against the project itself, as a motivator for the security team's action.

The security team has decided over the years through internal discussion, and feedback from the community and feedback from the broader security researcher community that if a project maintainer does not respond to our requests to fix a bug we will create an SA for the project and mark the releases as unsupported. That policy is documented in our handbook pages and we welcome discussion of those policies in the security best practices g.d.o group. We are currently working through a long backlog of modules that are in the state of "have a security issue, the maintainer is not responding" and we are doing the unfortunate work of marking those projects as unsupported. You can see:

• 4 modules January 11th 2012: SA-CONTRIB-2012-006 XSS and CSRF in Multiple Modules - Supercron, Taxotouch, Admin:hover, Taxonomy Navigator no longer supported
• 2 modules March 7th: SA-CONTRIB-2012-031 - Multiple Modules Unsupported - UC PayDutchGroup - Information leakage and Multisite Search sql injection
• 6 modules March 14th: SA-CONTRIB-2012-036 - Multiple Modules Unsupported

Marking a project as unsupported is a last resort and probably the least enjoyable part of the team's responsibility (at least as far as I'm concerned). It's least enjoyable because it leaves the users without a clear upgrade solution and often frustrates the maintainers (our goal is to support and enable maintainers, not act as a police force).

Just because you don't think it's a security issue doesn't mean you are exempt from the process. The last time I got dinged on one of my modules, I didn't think it was a big deal, either, and I grumbled a lot but I complied and life went on. I didn't go off in a huff and treat the security team like crap on the way out. When you put your modules on here, you agree to follow the rules and one of those is to comply with the security team. If you can't handle that, well, I guess github is better for you but really sucks for all the users of this module.

no discussion on that allowed.

Discussion was possible on the security.drupal.org issue.

The reason the project was marked unsupported was lack of response from the module maintainers. I agree it's a low-risk issue, but it's a CSRF issue nonetheless and is easy to solve.

Eugen, lack of trust is really big issue, especially to team as Drupal SA team - I'm sure that thing like this will probably never happen again.

But, SA team responded here, stating that they made mistake in the process (we are all humans, we made mistakes, no?) - and stating that they intent is to help module developers, not fight with them and chase away from d.o. There is even patch for this security issue.

I would really like that we all are able to get on with this and continue to make Drupal & d.o awesome. Can we? Please.

P.S.
I assume that you didn't make this module available @ d.o because of your personal benefit - in the first place - but because of community. As you can see in this issue community is very supportive, can you strike back with the same force? :)

@Michelle: "...treat the security team like crap..." - oh come on. Your work for Drupal in all respect, but in this thread you only spread emotions instead of facts. Eugen clearly stated that he complies with the SA process. Now he left, no need to kick after him like you do. And one developer more or less carries no weight on d.o., does it?

Regarding the "CSRF issue" of unlocking nodes: I didn´t read anything about the risk - even if it is a only "low-risk issue".

What exactly is the risk besides unlocking the nodes for further edit?

Well, when I see someone say that the security team is untrustworthy and doesn't investigate properly, yeah, I've got some emotions to respond with. I'm not a robot. I may not always agree with how they do things but I'm sure glad they are there and I think they do the best they can.

Well, it sure has been quite a day in this queue.
I hope people have a chance to step back from this and look again.

This is a good queue as it has tried to thank people for the work they have done in producing useful modules like this and no sour ending will take that away. We have certainly found this module very useful.

I also appreciate the work done by the security team and others behind the scenes to make the Drupal environment as good as it is. And I appreciate the willingness to come into this issue thread, apologize for mistakes that were made and still focus on what they believe needs to be reviewed.

Personally, I would not like to see chunks of the Drupal community break off and go separate ways on github. Maybe, if it was possible to just bring in a case of beer. An offer I will gladly deliver any time if eugen, ohnobinki, greggles, michelle taps me on the shoulder.

Thanks

Izzy

Hi @all,

oh my god... i had found a second security issue... if you present the admin a link like node/3/delete i can DELETE THE NODE! - Sorry but in this case the SA Team has it work to be taken seriously... someelse reported them as Security Issue but it is no security issue. If this can be clear so why... this hard steps ? I can fully understand EugenMayer.

Short sayed:
- Thank you for your work
- Thank you for your consistently act

Thanks
Blackice2999

As my grandma would say:

@SecurityTeam! Have mercy! Forgive us! Save us from the darkness of optimistic locking!

@EugenMayer and @ohnobinki! Have mercy! Forgive us! You are remarkable people! Please, take a step back and think about the thousands of people who will ask:
- Has the Drupal pessimistic locking?
And they have the answer:
- No, not more, our savior is gone... we are lost... we are in GIT limbo....

The Drupal world needs some love and forgiveness at this point... amem!

Not a Security Issue. This is a Bug yes. But Security No.

And seems like the users of the module agree with the maker. I think this module should be reinstated. With an issue created about that problem with low priority.

Once again. NOT A SECURITY ISSUE.

We like the module and most likely will use it at some stage when we get related complains. Once we start using it we will actively contribute with bug reports and where possible also with patches.

deleted

This module is a must have. Please have the issues fixed and the module reinstated !!

Oh dear, what a pity, not only has this module gone, but also WYSIWYG image upload and Jquery UI Dialog. They're only related by having the same author, EugenMayer, and don't appear to have any security problems at all.

Yes, any contributor is not really mature doing that and we cannot trust on people who put his personal interest over all. If you pretend with it bother security team that's not the way, actually deleting your modules only betray to 2859 wysiwyg_imageupload / 4149 jquery_ui_dialog / 2238 tagging users who trust on you.

Start looking for alternatives...

Title back, sorry.

I'm very sad. I used all those modules and I think EugenMayer is a smart guy. I can remember so many times I read his participation over many issues.
However I can perfectly understand SA Team position because the rules are rules and they can't make exception just because someone bashes on, but I found the way some people here have treated Eugene a little cold, that is not very fair as he's a real usefull contributor and the mistake made locking him out would make everyone angry.

I can understand that at this point and with people sticking in their position is impossible to find out a solution. And this is sad! This is frustrating, breaks armony and is how wars begin! It's completely out from the spirit I love of this community.

Great module!

Sorry, I cannot understand SA Team position at all.

Its not about security, its only about rules and their processes.

If content_lock has a security issue, which the SA Team still insists on, then Drupal Core has a security issue of this kind in all its realeases. Eugen had proven the CSFR logout exploit of all versions of Drupal.

Beware: Its so dangerous, that the admin team edited his comment in order disarm the exploit, but you can use this security exploit in all Drupal releases at any time!

If the SA Team is serious about making no exceptions, then they also have to classify the existing "Logout CSRF" as an security issue which has to be fixed.

The logout thing is a problem but one without an easy fix. The issue on this project has a very small patch already done and sitting there waiting for the maintainer who decided instead to go ballistic on the secteam. Not the same thing.

Thanks.
Maybe now this should go offline?
Could those involved have a face to face or something?

Hi,

It seems that both thematics are the same... If one is a securityhole the other is ist too so if there is a Patch for the Logout thematics it need also Applied if Not the Core System Must be Marked with an Security issue ... If Not? Hmm than i Miss the consequenze handling of the Core sa team... So in fact the sa team has handled this issue different and dont said that they have make a misstake

I really don't care whether this is a security issue. I don't use the module. I care about the character assassination of the security team. If I'm wrong about how hard it is to fix the logout issue then fine. I've just heard that it's difficult. It doesn't matter. Two wrongs don't make a right. You were given a fix and, instead of just applying it, decided to throw a hissy fit, insult the secteam, and then take your code elsewhere. And your justification for that is that is that core has a problem, too?

The security team has likely stopped responding because they are busy and you've wasted enough of their time. I will happily stop commenting if people stop making the secteam out to be either incompetent or malicious.

@all: Please, this is really becoming nonsense..

Thx.

@Michelle: Every comment from you of this kind made the handling of this security issue looking more dubious, or as you name it "incompetent / malicious", because it has to be backed with emotions and FUD instead of facts.

@AndreU: If the fact that I have emotions and care about people being unjustly attack bothers you so much, I suggest you simply stop reading my posts because, whether you like it or not, I care about people and will defend them when I am able.

This whole thing is full of people over reacting and not seeing things from other points of view and has gone on too long now.

@Drupal SA Team. You made a mistake in disabling the module that has a low impact bug not a security issue. Please for the sake of the Drupal community would you be big enough to try and mend bridges and come to some resonable agreemebt with EugenMayer.

@EugenMayer. Yes you were wronged by the SA Team but is it really that bad that everyone else has to suffer from you being upset with them. Surely there is a way you can sit down and have a chat with them and come to some agreement both are happy with. I think you have over reacted a little bit on the issue and that there is a better way about going about this.

@Michelle I think it is time you just stop commenting on this post because your comments are not helping the situation. I normally have respect for the things you have to say but not this time. Not saying that us others are helping either. (Not taking myself out of the equation either) but yeah we need to try and sort this out now and stop arguing against each other.

I think I can say this for everyone on the drupal community that we do not want to see all the work EugenMayer disappear off it just because of a disagreement with the Drupal SA Team. For the sake of everyone please talk to each other and sort something out.

I'm not going to respond to the individual claims of of #73 as most have already been replied to.

And thats why they never should be allowed to act that impulsive as an individum.

During the 3 weeks the issue was private you never responded. During the 1.5 weeks since it has been public you've posted over 20 times in public locations claiming things like our process "ripped" your code away or that we were impulsive. There is nothing impulsive about our process: we give maintainers deadlines and wait for responses (even to say "I disagree") and if we get no response we can only interpret that to mean the module is not supported.

Everything that has been done to your modules (the security process, the policy related to projects with no code hosted on d.o) is pulled directly from policy documents in the drupal.org handbooks. If you can't abide those then why did you check the checkbox in your profile saying you would? In case you forgot it, that agreement says (attached screenshot as well):

To use Drupal's version control systems you must agree to the following:
I will only commit GPL V2+-licensed code and resources to Drupal code repositories.
I will only commit code and resources that I own or am permitted to distribute.
I will cooperate with the Drupal Security Team as needed.
I have read and will adhere to the Drupal Code of Conduct.
I agree to the Drupal Code Repository Terms of Service.

@omaster: I have already said I would stop commenting if the attacks on the security team stopped. Perhaps your efforts should be focused there instead attempting to shut me up? I was already intending to stop commenting on my own, not because other people don't like it, but because I was done (barring any fresh attacks), but addressing me by name is going to draw me right back in again.

It's pretty simple. Quit telling me to shut up, which just annoys me as I have as much right to speak as anyone and quit attacking the security team which makes me want to defend people I care about, and I will happily move on all by myself as I have many other things to do and don't actually give two hoots about this module nor where it's hosted.

Hi @all,

sorry but slowly, the whole just ridiculous... nobody keep the focus on the problem... this run into a big troll thread... ( i know my answer can be seen also as it )

thanks at all who tried to find a solution and dont tried to play bullshit bingo.
Dennis

unsubscribe

(Are we allowed to say it when it's to unfollow?)

What are you doing here? Maintaining your public relations and reputation?

I'm making sure that when you mis-state facts it is clarified and corrected so others have the reality of the situation. The only mistake I'm aware that the security team made in this process was revoking your commit privileges and yes, I acknowledged that mistake and apologize.

Perhaps a better question is what are you doing here?

I tested the new releases that Ohnobinki created yesterday and published them. Ohnobinki is now the maintainer of the module.

Thank you for the new releases.
Now, if there is some way for the resentments to be resolved; may be it will take a little time, maybe some jokes, ...

I am able to download 6.x-2.7 using the link on the project page but not using drush.
With drush I am getting the following errors:

uasort() expects parameter 1 to be array, null given pm.drush.inc:1291 [warning]
Invalid argument supplied for foreach() pm.drush.inc:1294 [warning]
Invalid argument supplied for foreach() pm.drush.inc:1303 [warning]
uasort() expects parameter 1 to be array, null given pm.drush.inc:1291 [warning]
Invalid argument supplied for foreach() pm.drush.inc:1294 [warning]
Invalid argument supplied for foreach() pm.drush.inc:1303 [warning]
------- RELEASES FOR 'CONTENT_LOCK' PROJECT -------
Release Date Status

Do I just need to be more patient?

@izmeez - I rebuilt the xml history, but it needs some time to trickle through all the caching in front of it. Should be fully ready "soon." At worst in 12 hours.

Thank you soooooo much for bringing this module back to life!!!! This module is essential to me and contrary to what was posted on the homepage previously, there are no other modules that have the same capabilities (that I could find anyway). Now I can sleep better at night knowing the security vulnerability has been patched. Thanks again!

I use this module, thanks for your work.

Just adding my thanks for updating this module! It's also a really important part of our project.

This situation is bizarre, really.

@EugenMayer, I agree with most of what you said, but I think you need to put into your head that all of this continues because you cannot forgive for an error that was already apologized for by the security team.

Stop. Come back. The community appreciates your work. Let's keep it that way.

@EugenMayer, look:

I agree with you, and I think the security team missed this one. It's not a security issue. But they must keep a strong position in whatever they decide, due to the nature of their work.

Moving your code elsewhere will not help you, will not help the security team, will not help the community. It will be a silent protest only properly interpreted by the ones that read this issue thoroughly.

I will ask you one last time to consider staying.

+1 Eugen stay :-)
+1 everyone stay friends :-))

perfect module.. like++

@Lisias: I hadn't intended to comment further on this issue but, since you decided to barge in and dredge up a painful issue that had already quieted down over two weeks ago and then call me out by name:

• This is not simply a "technical/procedural". The maintainer unjustly attacked the security team, which is made of real people, not robots, in multiple public places. He started the venom and I defended them but with limited venom of my own. I did not attack him, just his actions.
• The code in question is GPL. He has no legal right to demand it not be used. So the "his work, his copyright, his code" doesn't fly. He contributed his code to the community and that is a conscious decision to give up some rights to it that can't be undone just because you get mad about something.
• I really don't care if you care about my emotions. I don't know you. You're just some stranger that decided to come in and troll up a closed discussion.
• If you're looking for a perfect community where everyone always gets along and never a harsh word is said, move along. We are real people here and real people have emotions. I suggest you look for a community of robots.

You're right. I should have said "ask", not "demand". And, I suppose, you do have the right to ask just was we have the right to ignore the request. I had just woken up and used an inflammatory word where it was unnecessary. I apologize.

My intent was not to get back into the original argument but rather counter the accusations of this new person who has decided to kick a nest of sleeping hornets.

@Lisias, the Drupal community is very different than other OS communities around, I can assure you of that.

If different for good or bad, you decide.

"Drupal. Come for the software, stay for the community."
That's our slogan. I can guarantee to you, with all my heart that the Drupal community is the best OS community that I participated in (I participated in a lot of communities, believe me).

In such a large and warm community, arguments and threads like this one happen every now and then... You would be doing a huge mistake to ditch Drupal because of this single thread. A huge mistake.

@EugenMayer: If you are going to attack a sincere apology then clearly there is no point in further discussion.

I have a weakness for responding when I am called out by name but I am going to make a concerted effort to be done with this. It ended two weeks ago. It should have stayed ended.