backporting sec patches
Since I will need a longer life cycle... I know I'll have to support security patches for at least one more older release starting from 5.X. I know that patching your own 3, 4 web sites that lag behind is one thing, providing patches for a whole community is another thing. Providing security support for older modules it is even a larger task. Making proactive security assessment for older versions is absolutely out of my reach. As a minimum I could provide svn patches for security problems that have been discovered in newer versions and that apply to older versions. To make this effective I'd be informed in advance of the security problems that have been signaled to the sec team before they get public. I could start to take care of this in a *very* informal way. That means that I'll make aware people that they CAN'T relay on this service and see how it goes. Depending on how things go, it could be worth to learn something about the Drupal release mechanism, see if other people can help... etc... I don't know. What I think I can handle is: - getting informed in advance of DN and D(N-1) security problems in core - see if they need to be fixed in D(N-2) and publish a svn diff somewhere concurrently to the DN/D(N-1) public security announcement. - try my best to see if a module security problem can be fixed in older core and provide a patch What I know I won't be able to handle is assisting in fixing security problems in older modules or providing a full tar of an older patched version or manage DB update path. That in the hope that: - I could gain access to early warnings - someone will reach me in the task so that if one is busy/ill/etc... the other can still provide some support to the community, me included. If anyone is willing I could reach the sec team to get used to the way they operate now, make some enemies, call some names, help a bit fixing 5.X sec problems till 5.X will be obsoleted and evaluate in the light of my new experience if and how I can sustain what I proposed. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Ivan Sergio Borgonovo wrote:
Since I will need a longer life cycle... I know I'll have to support security patches for at least one more older release starting from 5.X.
Thank you for the offer. Openflows is doing something similar for Drupal 4.7 core.
I could start to take care of this in a *very* informal way. That means that I'll make aware people that they CAN'T relay on this service and see how it goes.
If people cannot rely on this service, how can they make the choice to skip upgrading for two releases?
What I know I won't be able to handle is assisting in fixing security problems in older modules or providing a full tar of an older patched version or manage DB update path.
Whether a burglar comes trough the door (core) or the window (contrib) doesn't matter much; you still loose your toys. This is why the sec team also started doing security announcements for contributed modules. In exchange for continuing support for 5.x what needs to happen (at least): - Dropping security support for all alpha, beta and dev releases. - Buy-in from the rest of the team. Regards, Heine
On Tue, 29 Apr 2008 23:31:21 +0200 Heine Deelstra <hdeelstra@gmail.com> wrote:
Ivan Sergio Borgonovo wrote:
Since I will need a longer life cycle... I know I'll have to support security patches for at least one more older release starting from 5.X.
Thank you for the offer. Openflows is doing something similar for Drupal 4.7 core.
I didn't understand perfectly their release policy... but well that's not different from what I was planning to do.
I could start to take care of this in a *very* informal way. That means that I'll make aware people that they CAN'T relay on this service and see how it goes.
If people cannot rely on this service, how can they make the choice to skip upgrading for two releases?
Because they don't have other choices other than Openflow? and I'm advertising what I'll do. I think that once you volunteer and advertise a service you take a responsibility. I advertise the service I can handle.
What I know I won't be able to handle is assisting in fixing security problems in older modules or providing a full tar of an older patched version or manage DB update path.
Whether a burglar comes trough the door (core) or the window (contrib) doesn't matter much; you still loose your toys. This is why the sec team also started doing security announcements for contributed modules.
People always says scratch your own itch. I've to refresh my security knowledge and I think I'll need to support Drupal for a little longer. Till now my sites depended on very few modules. If I'll see an announcement that involve a bug in a module but can be fixed in core I'll try to fix it. That could be a starting. It doesn't have to be official, it doesn't have to be hosted on drupal.org too. If I can be informed of security problems in current version before a public announcement is made I'll write a patch for D(N-2) and publish it somewhere.
In exchange for continuing support for 5.x what needs to happen (at least):
- Dropping security support for all alpha, beta and dev releases. - Buy-in from the rest of the team.
I'm planning to take care of just the latest D(N-2) and see how things go. People may complain because of lower performance introduced by a patch, the sec team may be not willing to wait my patch for the older version, I may find harder than expected... etc... I'd like to try and see. It could be a chance to understand better how things work internally and what is the release process. -- Ivan Sergio Borgonovo http://www.webthatworks.it
participants (2)
-
Heine Deelstra -
Ivan Sergio Borgonovo