Posted by greggles on November 14, 2012 at 8:30pm
We've currently got a policy about which holidays are important enough to Drupal's userbase that we don't do an advisory on a Wednesday near those days, but this policy didn't get a ton of discussion before being agreed to.
The dates are:
- Drupalcons
- Thanksgiving in the USA (fourth Thursday in November).
- December (Christmas/Hanukkah)
- The end/beginning of the Gregorian year in general (i.e. around new year's)
I think we can all agree on Drupalcons, but what about the other dates? Are there any we should add that affect a large percent of Drupal's users? It's worth noting that Thanksgiving is the biggest holiday in the USA and always falls on a Thursday, so even though it only affects the USA it feels like a reasonable holiday for us to avoid.
Comments
Some Muslim Holidays (official off days for Turkey)
http://en.wikipedia.org/wiki/Eid_al-Adha
http://en.wikipedia.org/wiki/Eid_al-Fitr
by the way, Muslims don't use Gregorian Calendar.
http://kutlukod.com
Thanks for sharing that. Can
Thanks for sharing that. Can you provide some sense of how major those days are (i.e. how likely is it that people will be offline?). Can you also give a sense of what percent of Drupal's user base would be affected?
knaddison blog | Morris Animal Foundation
December?
It's a little unclear whether "December" really means the whole month or not.
Clearly, releasing anything the last week of that month would be a bad idea, but what about other times? For example, this year the core security release window (third Wednesday of the month) is on December 19 - does anyone think that enough people will already be on vacations by then that we should skip that too?
Regarding Hanukkah, I don't think there's actually any reason to care about that. It's not a holiday where people tend to take off from work (even religious Jews don't, since there's no religious prohibition on working during those days). Rosh Hashanah and Yom Kippur are the biggest deals among Jewish holidays, but they are 2 days and 1 day respectively so are less likely to badly conflict with a Wednesday release. (Probably the worst case would be a security release late on the day on a Wednesday on a year where Rosh Hashanah happens to start on Wednesday night and go through Friday afternoon.) I would say those are worth evaluating individually on a year-to-year basis, which I believe we already did in practice this year.
I know there are some
I know there are some companies that have a "no code releases from Thanksgiving to January 6th" kind of policy given that the time period is generally busy in people's personal lives and for retailers.
I'm open to us having core and contrib releases in December, though I do think we should avoid the ~23rd to January ~3rd time period.
I think we have to take the releases we can get when we get them, so if someone is available to fix their module during that time period we should let them roll ahead.
I'm surprised we're not getting more feedback about dates to avoid so far - maybe the one or two loud complainers from the past overstate the importance of a holiday-day release.
knaddison blog | Morris Animal Foundation
I understand the logic of why
I understand the logic of why it's nice to avoid releasing news/code during times when people may be more prone to miss it or act on it.
However, I think the onus is on community to pay attention to the security team, not the other way around. Most of us that care setup filters to stay atuned.
I'm just not sure crackers/automated scripts care what the date is.
My two cents. Either way, the security team does a great job and I appreciate greggles revisiting this issue.
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
Yeah, that's my concern is
Yeah, that's my concern is that crackers will see the news but the rest of the community won't.
The reason I think we do have to cater to the installed base, at least somewhat, is that bad publicity for Drupal's security record hurts us all. Unfortunately public opinion doesn't care about the details they just hear "Drupal sites got hacked" and think "Drupal is insecure."
knaddison blog | Morris Animal Foundation
Publish updates as soon as possible
Yes, I see it that way too.
I want my Drupal sites to be secure. If there is a (known) security issue, I don't want to have to wait until holidays in any country/culture are over, if the security team could fix it beforehand. I'm not so much worried about issues that are already exploited (that's often easy to check if your site is affected), but about exploits happening secretly. So therefor every fix could be vital.
If you host a site, you are responsible for it – not only on working days, but 365/24. If you pay someone to care for your site's updates, you are paying this person exactly because it might be possible to have to update on December 25.
And even we'd have a policy that only allows certain security updates on various holidays, it could be possible that a critical update is necessary, and therefor you'd need to be alert anyway.
So I'm strongly favoring: Publish updates as soon as possible.
Maybe just the really bad ones?
I wonder if maybe the answer is to limit patches on holidays to those exploitable without an account or admin privileges? Those ones need to be released immediately so they can be patched, but they're fairly rare. The typical 'this bug is mitigated by the fact that it's only exploitable by user with XXX permission [that only our trusted administrators have]' can wait.
Just my 2 cents from the peanut gallery. Great job by the security team.
That's an interesting idea,
That's an interesting idea, though I would actually take the opposite conclusion :)
One thing to keep in mind is that most security issues are known to the team for some amount of time more than 2 weeks when they are released to the world. And yet most security issues are not actively being exploited. If issues are being actively exploited then all bets are off and we tend to release as soon as possible (including deviating from a Wednesday if that seems appropriate).
However, an issue that is not being exploited and is very damaging and can be exploited by anonymous - that seems like a case where we should wait until folks are around to do the update. For example - a remote php execution issue in a contributed module wasn't being exploited before the release but within a few months it is now being exploited. The latest releases become fodder for the blackhats of the world to make attacks.
We have a bit of a coordination problem because it takes at least the module maintainer and a security team member who are available on tuesday afternoon/Wednesday morning to do a release. So the more days we can open up as possible coordination times the better.
Given that background/insight, maybe it makes sense to allow the release issues that are below a certain level of criticality AND where there is a mitigating factor that makes it unlikely to be exploited.
knaddison blog | Morris Animal Foundation
What do other open source projects do?
I think we should look outside Drupal at other open source communities and see how they also handle security advisories. I'm just looking at the history of something like wordpress, and I've seen security updates out of them right between Christmas and New Year (http://wordpress.org/news/2010/12/3-0-4-update/ or even http://wordpress.org/news/2012/01/wordpress-3-3-1/ this year) along with new release candidates on Jan. 1. And it would be interesting to hear from others on their approach.
Severity matters. If its a
Severity matters.
If its a vague security hole where (for example) multiple hierarchical taxonomy might cause unrestricted access to nodes with two or more taxonomy terms attached. Then I say it can wait. However, if going to www.example.com/user/admin?q=edit allows anonymous users to edit user 1. Then that is something that needs to be addressed immediately.
Also, sitting on a patch is very rarely a good idea, we don't want to get java's reputation. http://arstechnica.com/security/2012/09/yet-another-java-flaw-allows-com...
It's really interesting to me
It's really interesting to me that I have the reverse perspective on this.
In my opinion we should only rush to release a critical issue during a holiday if there is some reason to believe that it's being exploited. Otherwise the risk of leaving sites not-upgraded and vulnerable AND leaking the vulnerability details to the world feels too high.
I do like BTMash's point about seeing what other projects do.
knaddison blog | Morris Animal Foundation
I should have followed up on
I should have followed up on this thread sooner. I talked with a few of my coworkers who are involved in various other open source projects (puppet, openstack ... primarily not involved in the Drupal community) along with maintaining our university server infrastructure (server os, application upgrades, etc). They're pretty much in agreement with @greggles for a few reasons (unless it is a massive security hole that can be easily exploited, leave it to once people are back and settled from the holidays, whatever set of dates that entails):
I was initially more on the side of @frobdfas and side more with @greggles after the conversations.
Excellent to hear - thanks
Excellent to hear - thanks for doing that research!
Greg
knaddison blog | Morris Animal Foundation