In #2367319: Implement automatic background updates for highly critical security issues there has been some discussion about ways that something like the update module could give advanced notification that a critical update is coming.
Within the security team we're discussing when/how to pre-announce issues of different levels.
Here's a rough concept of the functionality for discussion:
The pre-announcements are likely to have very little details other than the date/time an update is coming and the severity. We might also limit our use of this mechanism to extreme cases.
Comments
Comment #1
gregglesComment #2
coltraneI propose that the goal should be expanded to be about improving security knowledge as it relates to a particular site.
Consider the issue at #2369383: Provide basic SA details in 'security update available' message which asks for detailed SA data within security update messages. The mechanism for alerting pre-announcements could piggyback on a system that shows expanded SA details, given shared development.
Comment #3
gregglesI agree that issue has a good goal, though it addresses the point after the issue is published rather than before so it can potentially leverage the existing content we have on d.o: a security advisory. If it turns out that there are synergies in combining them that works for me. Those synergies aren't immediately obvious to me, though.
Comment #4
masipila commentedHi,
I think that the pre-announcement functionality doesn't have to be more complex than it has to be:
In the rear case that the sec team thinks that a pre-announcement is needed (pre-auth remote exploit or something critical enough), all that we need IMO is to spread the word that a new highly critical security advisory + new release will be published on yyyy-mm-dd at hh:mm UTC.
I would say that this functionality would be all that is needed. I don't like the idea that the pre-announcement would include the affected contrib module name because this would give unnecessary heads up for the attackers to find the sechole before we have the fix available. There are some extremely widely used modules which are still small in terms of the amount of code so publishing the name of the module might already be too much information that we want to publish.
Let's not over engineer this one. I think that the only thing that we are trying to solve with the pre-announcements is to make sure that as many site maintainers would get the alert in time so that they can plan their schedules so that they are prepared when the SA is released.
Cheers,
Markus
Comment #5
corbacho commentedI like a lot this idea.
Could we add to this pre-announcement information about how to protect yourself (if possible)
Taking as example this Security Pre-announcement of Typo3:
Comment #6
timodwhit commentedI like this idea, I think it would be good to be able to add multiple users to the email string for the SA message.
For example you may have a sites email as: webmaster@example.com, but your devs is/are dev1@example.com/dev2@example.com. Webmaster might not be checked as often, but this would allow for the devs to be aware of it.
Just an idea.
Comment #7
omega8cc commentedThis feature would have to be forced as always enabled to be really effective, so it can't depend on the 'update' module, because this module can be disabled on production sites. But it is probably obvious already.
Comment #8
gpk commentedAgree strongly with #5 that the pre-announcement must include information about how to protect yourself. In the case of SA-CORE-2014-005, hackers would have already have identified thousands or millions of potential victim Drupal sites and had all their botnets primed, it would only have taken them a minute or two to engineer their attacks and start deploying them. How many site admins could have patched or upgraded all their sites in a time window of a few minutes?
In this case AFAICS the only protection would have been for all Drupal 7 sites in existence to be taken completely offline manually before the details of the vulnerability were revealed.
[Update] though one has to wonder, if a vulnerability is rated at the most critical level, would hackers have reasoned ... the vulnerability must be in database.inc...... and would they have found it......
Comment #17
dwwFYI: This is nearing completion at #3041885: Display relevant Security Advisories data for Drupal
Comment #18
phenaproximaThis very much seems like a duplicate of #3041885: Display relevant Security Advisories data for Drupal, so closing this out.