Should modules be marked "abandoned" if their releases are unpublished

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
greggles's picture

When a module maintainer is not communicating/fixing a security issue in a timely manner the security team needs to communicate about the problem in the module to site owners.

  • We send an SA which gets picked up by rss readers and e-mail subscribers and twitter
  • We unpublish the module releases so that the update.module will notify site owners that support for a module in use on their site has been revoked, this then notifies them to visit the project page for more information so...
  • We modify the project page adding a warning, suggesting alternatives, and marking the author and and maintenance state as abandoned

I think most of this makes sense and should stay as is (until/unless someone changes update module in core to do something smarter, but let's have discussion on it.

In particular, marking the project as abandoned makes it easier for someone to take it over, create and apply a security fix, and get the module working again. This, however, can be seen as taking away credit/control from the original author.

Should we mark projects as abandoned when we unpublish their releases?

Comments

Makes sense to me...

proindustries's picture

While I appreciate the concept of giving someone credit for their work - if people have reached out saying there's a security issue and given the author an appropriate time to respond, then the author has released liabilities, IMHO. Might be worth putting something like that in a notification to the author before marking abandoned.

I think marking the project abandoned is a good move - gives a very clear warning to newcomers interested in that project, and also a pretty loud cry for help to anybody currently using the module who wants to continue using it in the future.

Is there a view anywhere on d.o of abandoned projects? Might be useful for people who want to help contribute by picking up abandoned projects, dusting them off and returning to published state.

Posting code on drupal.org

Dave Reid's picture

Posting code on drupal.org has and always should be a privilege and not a right. If you are not able to respond to a security issue within a reasonable amount of time, it doesn't matter if you are an individual, a small company, or someone at Acquia - the module should get marked abandoned if you can't take care of it.

Senior Drupal Developer for Lullabot | www.davereid.net | @davereid

Privlege?

Michelle's picture

While I agree with you that it is not a right, I think "privilege" is a bit too far in the other extreme. It makes it sound like the drupal.org hosts/maintainers are doing the contrib module a favor for allowing them a place to donate their hard work for free to the community. LOL! I don't know about anyone else but personally, I feel like I'm the one doing the favor donating hundreds (thousands, maybe?) of hours of my life to build something for the community to use.

Responding to security issues is important, granted, but maintainers are people, too and not immune to screwing up. I think we've gotten a mentality around here that just because a project is GPL that the person who wrote it doesn't have any rights to it. While it's true that legally anyone can take the code and fork it or whatever I think that we need to be very careful about yanking control of someone's hard work away from them and it should always be a last resort.

Michelle

Marking them abandoned isn't enough.

grape's picture

Modules that aren't properly maintained, whether for security or support, negatively affect Drupal's reputation. Marking modules as abandoned would only further detract from Drupal's reputation by creating a sea of bug infested zombie modules. Removing them from the primary search results and decreasing the maintainer's privilege somehow would be two additional ways to send a strong message about the standards we choose to set and how we intend to protect the Drupal brand.

Marking them as abandoned

greggles's picture

Marking them as abandoned does remove them from the default search results.

I don't think we need to decrease the maintainer's privilege - what specific permission should be removed?

If we did that it would prevent them from fixing the problem. I'm all for getting information into the world but not in favor of being punitive for a security bug.

Good point on decreasing

grape's picture

Good point on decreasing privilege. I was thinking more broadly and hadn't thought of it in those specific terms.

Let`s look at it another way

MisterSpeed's picture

Lots of unwarranted assumptions here: that people are somehow derelict if they do not respond by an arbitrarily-set time frame (or, in this case, cancel their vacations and fly back home -- I am not committing code from a coffee shop in Cuba for example, no way no how, that's irresponsible -- heck I don`t even do it from coffee shops in my neighborhood !); that publishing code being a "privilege not a right" it can be subjected to arbitrary and changing measures, etc. All of which will lead to forgone conclusions.

I propose that we step back and look at the issue as a whole: if there is a security issue, how do we seek the awareness and involvement of the author while protecting the interests of the community ?

The interests of the community are clear here. There is an issue, it is published, the code should be unpublished the minute one knows about this. Not after asking the author for help. Right away. Hackers will not wait to find out of the author has been sufficiently warned before pouncing. A message should clearly be posted on the contrib page to that effect with a link to the issue, and a warning sent with the Drupal updates that there is a security issue worth looking into.

How to warn the author ? In this case many e-mails may have been sent on the issue that triggered this discussion, but I only became aware of it once Greggles e-mailed me directly at my work e-mail address and put "SuperCron" in the title of the message. Even then it could have been lost as spam or any other way. Now some may argue that "the author is responsible for reading 100% of their e-mails" and like all oughts, shoulds and musts it may sound reasonable from a perfectionist's position but it is seldom met as a very high standard in reality. We are not core contributors. We are contrib contributors. The volume of mail we get on any SuperCron issue (besides kudos) is so minimal that I will venture to say that months may go by without us hearing anything about it. This is a different reality from the deep involvement of a core contributor for whom every message may be deeply meaningful. In our case we are subscribed to a bunch of groups and I go read them when I need to take some time off from coding and clients; list mail all goes to the same inbox along with e-mails about the other technologies that we use. The Drupal e-mail flow is not for contrib authors a mission-critical flow of e-mails. I believe that this is why the community has already set a precedent to flag high-importance messages. In the case of an abandoned module, people are required to cut above the noise level and to use the Drupal.org messaging system. If this device, which leaves traces and logs, is used for something of middling importance, should it not follow that it must then also be used for highly important issues ? That the same method which raises ownership conversations above the noise level for contrib authors (as this mechanism was especially made for and quite fits their reality) should also have the same effect or raising above the noise level for those issues as well ? Because when it comes to abandonment other standards than those arbitrarily set for each and every circumstance should be used. Here`s an indication that the author has left the Drupal community: they do not log in to Drupal.org nor do they see their messages, ever. This is a clear, objective, absolute demonstration of an absolute lack of care, no questions about it.

Now if there is no care, then what ? The code is unpublished and a warning has been sent, there is no immediate risk factor involved and no emergency to advance the code's functionality towards a resolution. Dealing with security is an absolute requirement. Code advancement in contrib is not, otherwise we`d have published and agreed-upon standards to that effect (make a commit every X months or else !) Marking a module as abandoned is taking a step that goes way beyond the immediate and objective necessity:

  1. It serves to ostracise the author (anyone is welcome here EXCEPT the gal or guy who wrote the code in the first place) which is completely unwarranted;
  2. It sends a clear message; abandonment in English has a lot of highly negative connotations that mark the intent, character and qualities of the contrib author, qualifications that I would venture none of you are empowered to nor welcome to make, and certainly not in public; according to thesaurus.com (I`ll use it as a cultural guide here as "abandon" does not carry as much weight in my native French as it does in English, where it is far more dramatic), abandon entails "careless disregard for consequences", as well as "disregard", "licentiousness", "recklessness", "thoughtlessness", "wildness" and even disloyalty. When you unilaterally determine (even as the author is responding to e-mails) that a module has been abandoned, and mark the module as such, you indicate for the whole world to see that those are the qualities (and level of care) the author has put forward. You signify intent, you signify tort, you signify that whoever wrote this code is exhibiting those qualities and may do so as part of their general qualities. You signify to the users of the module that the author has abandoned them, hurting any and all relationships built in the process. In this case, it also cost me a contract that actually went to one of the companies represented by a member of the security team (I do not signify intent here -- I've met all of you and/or only heard great things -- but this certainly adds injury to insult, and a more moderate process would maintain the appearance of justice, especially for contrib authors less involved than I, and would prevent future issues from devolving into personal battles that are less likely to start if it starts with the author not being so publicly insulted).

I believe that this statement is excessive, unwarranted, unwelcomed, and does not resolve any of the objective issues at hand, while a more conciliatory and respectful approach would.

We all know that the security team has to deal with thousands and thousands of modules, and that its methods and processes will evolve accordingly (it cannot operate as it does when the list of modules balloon up to the hundreds of thousands in a half decade for instance); this is also why, beyond avoiding the loss of contributors to the Drupal community, it should consider the conciliatory and inviting methods that I propose above, which meet all of its objectives while retaining goodwill.

There are a rapidly growing

grape's picture

There are a rapidly growing number of outdated, unmaintained and often irrelevant modules available on Drupal.org. I would venture that in many cases of un-maintained modules the people who wrote the code have moved on to other interests or jobs and have no connection whatsoever with Drupal. It is a fact of life with open source projects.

Many improvements have been made to the processes and structure of the project in the past three years to help fix what was broken and prepare for even more growth. The issue of maintaining the vitality of an aging collection of contrib modules is a serious issue. It is this task, in my opinion at least, that this thread is addressing. I don't think anyone is advocating being arbitrary or callous, but rather looking to bring efficiency to an area where there is ample room to optimize the process.

Open source developers have never been particularly tolerant of people resting on their laurels. Being a committer to a project, as Dave said above, is a privilege and not a right. With every privilege comes the responsibility to do things that allow us to keep the privilege. That level of responsibility is what makes being a module maintainer an elevated position of trust and privilege worth defending.

This thread should not also

MisterSpeed's picture

This thread should not also tackle much larger issues; the wider the issues the less likely they are to find a resolution. Let's instead focus on the issue at hand and if you would like to open a broader issue please create a thread for it.

Regarding committing code

greggles's picture

Regarding committing code from a coffee shop

  • You can use drupal.org over https
  • All git commits are over ssh

So there is no security issue preventing use of our system from a less reliable network.

A message should clearly be posted on the contrib page to that effect with a link to the issue, and a warning sent with the Drupal updates that there is a security issue worth looking into.

Do you also suggest this policy for Drupal core and views? That would cause unnecessary panic among the million+ sites using core. Until there is a fix available (or a reasonable amount of time has passed) security issues should remain confidential. We don't disclose details of the issues right away, in part based on this previous poll, so the idea we would create the issue right after sending the SA is also not possible.

If you do not like the word abandoned then I can easily agree with you. It is overly negative and we should fix that. Please propose a better word.

Another status?

Michelle's picture

Perhaps we need a status that has the effect of removing from search results as does abandoned but is something like "hiatus - pending security fix"? I agree that marking something abandoned is not a good course of action for this unless it has gone without resolution for quite a while. Having a less "final" sounding status would be good for situations such as this.

Michelle

How long is quite a while? A

greggles's picture

How long is quite a while? A month? 2 months?

Our current policy is 1 month - I'm open to tweaks to that.

In general we are more liberal than a month (especially if the maintainer has at least responded to the initial contact). However in this case the vulnerability was already publicly disclosed which made us stick closer to the 1 month timeline.

Time

Michelle's picture

Well, if we had an alternate like I proposed, then it could stay that way longer before being marked abandoned. A few months even. The net effect is the same of unpublished code, no search results, and a big warning. The only difference is it wouldn't be listed as abandoned until it's 100% sure that the maintainer is just not coming back.

Michelle

Orphanage

rjbrown99's picture

How about calling it an orphaned module as a new status before it is abandoned? That means the current parents are deadbeats and it's up for adoption but needs a bit of work before it is turned back out into proper society. I like Michelle's proposal.

Or... anyone who applies for a new git account on d.org has to go fix a security bug from the orphanage first? :)

.

Michelle's picture

Cute, but that's really saying the same as abandoned. The idea is to have a grace period where it's kept isolated to keep people safe without taking the drastic step of assuming its creators no longer care about it.

Michelle

Regarding response to SAs:

MisterSpeed's picture

Regarding response to SAs: This poll would relate to properly filed SAs that can be kept private; in the case of SuperCron the advisory was posted outside of the Drupal channels on the Full Disclosure security list. In cases where the divulgation is already public, then I would advise and support the course of action outlined above; not disclosing the issue from the site does nothing to obfuscate or minimize it: it is already out there and visible to the target audience most likely to find a good use for it. Now rules that are absolute are absolutely impossible to apply in absolutely every case, so for heavily trafficked modules the Security team should exercise its discretion, which would be more available as it would allow it to be deeply focused on the exceptions.

Coffee shops: some countries like those that I am likely to visit are off the beaten path and are often under heavy surveillance. In this case you can fairly assume that all publicly-available PCs are key-logged, radios of any kind (including wifi) are forbidden (in fact when you use one someone in uniform shows up pretty quickly and courteously asks you to shut it down, and obviously look interested in confiscation), and one often gets security warnings on browsers that are nearly comical, for example that your bank has suddenly began issuing 48 bit SSL certificates. d.o.'s measures will not help in such extreme circumstances. I'm a skydiver, high mountaineer and scuba diver -- apart from the first activity the rest are not usually practiced in rich democratic countries, and in some having your own laptop in plain sight is a great way to significantly shorten your lifespan. As there are no requirement from contrib users that they remain in G7 countries at all times (and even then China is chancy -- the Northern area has very similar realities), then the rules that we apply must allow flexibility for the full range of human endeavors.

Label: I actually find Michelle's suggestion to be absolutely on the spot (wish I could click that + more than once); "on hold -- pending security fix" says everything that is meaningful in this context, and taking the module out of search will reduce the noise factor for searchers uniquely interested in looking for a solution -- those interested in the module itself rather than a general solution to their problem are likely to type in the project URL directly or find it from the user profile.

Security

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: