Slight API change in 4.6.10 and 4.7.4
The 4.6.10 and 4.7.4 releases saw the addition of a new default form field to protect against cross site request forgeries. This has consequences for 1. 4.6 modules and themes that output raw HTML forms Those forms will always fail for authenticated users. 2. 4.7 modules and themes that rely on a defined set of form fields to be present Certain modules and themes output only specific form fields. As they do not output the form_token, the form will always fail validation for authenticated users. In addition, certain modules unset a few form fields, then save the remainder of the form. These modules need to account for the new field. Tip: devise something robust. See for details: Converting 4.6.9 modules to 4.6.10 <http://drupal.org/node/90004> Converting 4.7.3 modules to 4.7.4 <http://drupal.org/node/89999> Converting 4.6.x themes to 4.6.10 <http://drupal.org/node/90021> Converting 4.7.x themes to 4.7.4 <http://drupal.org/node/90024> Kind regards, Heine Deelstra
"Heine Deelstra" wrote:
2. 4.7 modules and themes that rely on a defined set of form fields to be present
Certain modules and themes output only specific form fields. As they do not output the form_token, the form will always fail validation for authenticated users.
In addition, certain modules unset a few form fields, then save the remainder of the form. These modules need to account for the new field.
Is there some method for knowing _which_ modules will be affected? Is there some specific API/function/code which these affected modules use (and which can be searched/determined in the module files)? A security fix which breaks existing installations is rather, um, difficult to embrace. (Especially given that the security alerts are so vague that it's very hard to know if any given site is vulnerable. Security alerts with statements like "a site with a specially crafted URL" is too vague to assess the potential impact...what kind of "specially crafted site" or "specially crafted RSS feed" or "specially crafted URL"?) I'd be happy to apply the 4.7.4 update, but not before I know which modules (of the dozens we use) will be lost to this "fix". Any methods suggested for determining which modules will break is appreciated. -- inkfree
On 10/19/06, inkfree press <inkfree@gmail.com> wrote:
Any methods suggested for determining which modules will break is appreciated.
Well, in Heine's original message he linked to:
Converting 4.6.9 modules to 4.6.10 <http://drupal.org/node/90004> Converting 4.7.3 modules to 4.7.4 <http://drupal.org/node/89999>
Converting 4.6.x themes to 4.6.10 <http://drupal.org/node/90021> Converting 4.7.x themes to 4.7.4 <http://drupal.org/node/90024>
If you read those they show code that will break on an updated site. If you browse through your modules and theme for some of those pieces of code and they don't look right - you need to update them. I believe a list of affected modules is coming from the security team soon. Regards, Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses
I can't go to the links below in IE 7, ok in Firefox. It briefly flashes up but then goes away but leaves the left and right column, just no content. In fact all of Drupal.org is broken on IE 7. How many other themes are broken? A slightly modified (just colors and a few placement changes) Bluemarine works on IE 7, still 4.7.3 so without the 4.7.4 changes IE 7 is basically ok. (See www.ramapo2007.org) -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Greg Knaddison - GVS Sent: Thursday, October 19, 2006 10:09 AM To: development@drupal.org Subject: Re: [development] Slight API change in 4.6.10 and 4.7.4 On 10/19/06, inkfree press <inkfree@gmail.com> wrote:
Any methods suggested for determining which modules will break is appreciated.
Well, in Heine's original message he linked to:
Converting 4.6.9 modules to 4.6.10 <http://drupal.org/node/90004> Converting 4.7.3 modules to 4.7.4 <http://drupal.org/node/89999>
Converting 4.6.x themes to 4.6.10 <http://drupal.org/node/90021> Converting 4.7.x themes to 4.7.4 <http://drupal.org/node/90024>
If you read those they show code that will break on an updated site. If you browse through your modules and theme for some of those pieces of code and they don't look right - you need to update them. I believe a list of affected modules is coming from the security team soon. Regards, Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.6/486 - Release Date: 10/19/2006
"Walt Daniels" wrote:
In fact all of Drupal.org is broken on IE 7. How many other themes are broken?
Well, IE 7 just was released this week, so the answer is, probably, "Most of them will exhibit different behavior." Might I recommend the module "IE Destroyer", so that you will never have to worry with this problem again? :) -- inkfree
"Greg Knaddison - GVS" wrote:
On 10/19/06, inkfree press <inkfree@gmail.com> wrote:
Any methods suggested for determining which modules will break is appreciated.
Well, in Heine's original message he linked to:
Converting...
Thanks. I suppose the word "Converting..." stopped me, since I am not a module developer. I did not think more closely that this would also provide a general overview for module users (i.e., site admins) (which it may...I'll read more closely now.)
I believe a list of affected modules is coming from the security team soon.
Good. That would really seem like information which should have been prepared before the release, and then submitted or posted along with the update. I know this is the 'dev' list, and so converting modules and such is important for readers of this list. However, from a "user"/"administrator" point of view, "converting" modules is not on the radar. I would suggest "Updating and Converting..." instead of "Converting..." for future security releases. If a security update will _break a site completely_ then it seems prudent to include that information _right away_ so that folks don't go all willy-nilly updating when it's not a priority or when the benefits are not greater than the breakage which might occur. [It sounds, from the announcements, that the threat is so statistically impossible that it does not merit a 'Moderately critical' flag...which is a nonsensical phrase anyway. Something is either 'critical' or it is not, but it can not be "moderately critical". Perhaps it could be "moderately likely". Anyway, enough on this for this list. I digress.] Thanks to the security team for keeping things safe. We all _really do_ appreciate the work and the effort. (My mild complaints or observations about the announcement do not discount this work or the appreciation.) I did (just now) subscribe to the security announcement list, so that if I have any comments I can make them in a more appropriate place. I do not think I will apply this update to any of our Drupal 4.7.3 sites, since my understanding from the announcement is that the actual convergence of events needed to make any exploit is statistically unlikely...or at least so negligible as to not be worth the breakage which has been foretold. Thanks, Greg, for pointing me to some early reading. -- inkfree
On 19 Oct 2006, at 16:59, inkfree press wrote:
That would really seem like information which should have been prepared before the release, and then submitted or posted along with the update. I know this is the 'dev' list, and so converting modules and such is important for readers of this list. However, from a "user"/"administrator" point of view, "converting" modules is not on the radar.
We spent quite a bit of time preparing these patches, and debating the pro and cons. Heine et al have been a godsend. Sometimes, stuff like this happens, and when it happens, the reaction should not be to bash the security team, but to collaboratively focus on fixing the affected modules. That said, we're open for suggestions, and we'll take these into account in future. Also, if you want to play an active role in the security team, you can sign up by sending us an e-mail. -- Dries Buytaert :: http://www.buytaert.net/
On 19 Oct 2006, at 16:59, inkfree press wrote:
That would really seem like information which should have been prepared before the release, and then submitted or posted along with the update. I know this is the 'dev' list, and so converting modules and such is important for readers of this list. However, from a "user"/"administrator" point of view, "converting" modules is not on the radar.
"Dries Buytaert" wrote:
We spent quite a bit of time preparing these patches, and debating the pro and cons. Heine et al have been a godsend. Sometimes, stuff like this happens, and when it happens, the reaction should not be to bash the security team, but to collaboratively focus on fixing the affected modules.
No bashing here, Dries. No bashing at all. I said, with real appreciation:
Thanks to the security team for keeping things safe. We all _really do_ appreciate the work and the effort. (My mild complaints or observations about the announcement do not discount this work or the appreciation.)
I do take your point, however, and quite understand that these decisions were made with thoughtfulness and with concern. Small gripes about things aside, it appears that the affected list of modern modules is rather small (from what I read as posted here.)
That said, we're open for suggestions, and we'll take these into account in future. Also, if you want to play an active role in the security team, you can sign up by sending us an e-mail.
I don't know about "active role", but I do know about "passive role", which I addressed by subscribing to that list. I am not skilled at securing PHP or SQL, but I do have an interest in keep abreast of the issues and of the discussions as they happen. (Just prudence, so that I don't feel torn again between applying an update or breaking a slew of sites.)
I did (just now) subscribe to the security announcement list, so that if I have any comments I can make them in a more appropriate place.
So...I subscribed to the Security Announcement list (no posts since Thu, 19 Oct 2006 07:31:02 -0700 (PDT), however). Thanks for your reply. -- inkfree
On Oct 20, 2006, at 8:02 AM, inkfree press wrote:
I don't know about "active role", but I do know about "passive role", which I addressed by subscribing to that list.
you're slightly confused on the 2 lists people are talking about: 1) the security announcement newsletter. this is a broadcast-only list for all security announcements. all 90K+ users of drupal.org should be subscribed to this, if they know what's good for them. no discussion, low traffic, just the security alerts. 2) the "security@drupal.org" list. this is a closed list, that only the security team is subscribed to. however, anyone can post to it. this is where end users and contrib maintainers who discover or suspect a security issue can post it without it immediately being publicly disclosed to the world. it gives the people who know a chance to verify the hole, assess the threat, coordinate a response, and, where necessary, create a new set of releases. the security team uses this list amongst themselves to discuss things, along with the invite-only #drupal-security room on IRC. so, subscribing to the announcement newsletter isn't a "passive role" on the security team, it's the bare minimum for any sane site admin with a pulse. ;) what dries was talking about is that interested parties should send an email to security@drupal.org introducing yourself and explaining what kind of help you're prepared to give, and see what happens. hope that helps clarify. i, personally, am thrilled by the security team, their efforts, and the policies for security that drupal has adopted. i've suggested similar infrastructure and policy for other open source projects i'm involved in, now that i've seen the light. ;) as killes pointed out, drupal.org provides better security for users of their software than just about anything you can find anywhere, giant for-profit companies included. 10 cheers for heine and everyone else. that said, i think everyone is open to improvements, and i agree with the basic suggestions people are making. even though what we have is great, the Drupal Way(tm) is to keep making things better... ;) thanks, -derek p.s. for the record, i sent exactly such an introduction email to the security team about 1/2 year ago, and basically have never been contacted by them for anything. perhaps in the transition from chx -
heine, my offer was lost in the cracks. i have discovered security holes in project.module and made releases and sec. announcements for them back in april (when i first offered to be a more active member of the sec. team), but otherwise, i haven't had any direct interaction with the security team. if y'all are feeling understaffed and overworked, perhaps you could make better use of the people like myself who've already volunteered to help. maybe we need a security-volunteers@drupal.org list for this 2nd tier of developers: not the official team, but the (if i may say so) clueful people who want to help, and can be called upon to discuss patches, assess problems in contrib caused by new versions of core, whatever. just a thought.
On 10/20/06, Derek Wright <drupal@dwwright.net> wrote:
p.s. for the record, i sent exactly such an introduction email to the security team about 1/2 year ago, and basically have never been contacted by them for anything.
Ditto. perhaps in the transition from chx -
heine, my offer was lost in the cracks. i have discovered security holes in project.module and made releases and sec. announcements for them back in april (when i first offered to be a more active member of the sec. team), but otherwise, i haven't had any direct interaction with the security team.
Except I'm less experienced in finding problems than you, apparently.
if y'all are feeling understaffed and overworked, perhaps you could make better use of the people like myself who've already volunteered to help. maybe we need a security-volunteers@drupal.org list for this 2nd tier of developers: not the official team, but the (if i may say so) clueful people who want to help, and can be called upon to discuss patches, assess problems in contrib caused by new versions of core, whatever. just a thought.
This is an interesting idea. It would still have to be a list of relatively well trusted individuals to keep out someone who hopes to gain previews of security holes so they can take advantage of them. For the small amount it's worth, I like that idea if the preference is to keep security@ to just a small group of people. Regards, Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses
On Thu, 2006-10-19 at 08:09 -0600, Greg Knaddison - GVS wrote:
On 10/19/06, inkfree press <inkfree@gmail.com> wrote:
Any methods suggested for determining which modules will break is appreciated.
Well, in Heine's original message he linked to:
Converting 4.6.9 modules to 4.6.10 <http://drupal.org/node/90004> Converting 4.7.3 modules to 4.7.4 <http://drupal.org/node/89999>
Converting 4.6.x themes to 4.6.10 <http://drupal.org/node/90021> Converting 4.7.x themes to 4.7.4 <http://drupal.org/node/90024>
If you read those they show code that will break on an updated site. If you browse through your modules and theme for some of those pieces of code and they don't look right - you need to update them.
I believe a list of affected modules is coming from the security team soon.
Regards, Greg
dopry@bbox:~/public_html/drupal-4-7/public_html/sites/default/modules$ cat */*.module */*.inc | wc 15672 55392 508132 You mean browse through 15K lines of code? It's crazy to expect that of a site administrator. Remember we are developing for non-developers. This is the second security update the breaks things in the process of fixing them. Which isn't so good in my opinion. We need to take more time reviewing our security updates and testing them. If we are going to change core in a way that will break modules, the affected modules need to be identified and their maintainers notified so a concerted effort can be made to provide end-users a real security fix, not just a partial. It is unfair to expected administrators and end-users to edit a module file. If module X is a key element of my site, and the bug fix breaks it... You have just publicly disclosed a vulnerability in my site that I cannot address. If I am a simple site administrator and not a developer, what boat am I in now? I can fret until my required module is updated. That is about it. This kind of information also provides a targeting vector for script kiddies. drupal sites running module X are unlinkely to have applied patch y google: Drupal + Module X (or select css classes and ids from Module X) I think a reasonable order of disclosure would be --security team - analyze problems, determine scope of change and its impact --distro maintainters & module maintainers - give a set period for updates (1-2 days?) --public disclosure - release with notice of error - example of how to exploit - solution, and reasoning behind solution - links to patches and tar balls - parts affected by bug - parts affected by fix ----------------------------------------------------- I really appreciate the work you guys on the security team do. I'm just offering these as a suggestion for improvement. debian's older policy is a fairly good one, I'm not sure if its still current in their camp. http://lists.debian.org/debian-devel/1999/08/msg01933.html
Darrel O'Pry wrote:
dopry@bbox:~/public_html/drupal-4-7/public_html/sites/default/modules$ cat */*.module */*.inc | wc 15672 55392 508132
You mean browse through 15K lines of code? It's crazy to expect that of a site administrator. Remember we are developing for non-developers.
It is open source, ie it is part of the "scratch your own itch" movement. "your own" refers to developers.
This is the second security update the breaks things in the process of fixing them. Which isn't so good in my opinion. We need to take more
We of course did this just to piss people off...
time reviewing our security updates and testing them.
Thanks for volunteering for the security team...
If we are going to change core in a way that will break modules, the affected modules need to be identified and their maintainers notified so a concerted effort can be made to provide end-users a real security fix, not just a partial. It is unfair to expected administrators and end-users to edit a module file.
It is unfair to expect unpaid volunteers to provide better support than the security departments of multi-billion dollar companies. At drupal.org you at least _get_ security updates...
If module X is a key element of my site, and the bug fix breaks it...
Then you need to hold back the bugfix for a day or two while either you or somebody else fixes it. You still have an option to disable that module for that day or two.
You have just publicly disclosed a vulnerability in my site that I cannot address.
/etc/init.d/apache stop
If I am a simple site administrator and not a developer, what boat am I in now? I can fret until my required module is updated. That is about it. This kind of information also provides a targeting vector for script kiddies.
drupal sites running module X are unlinkely to have applied patch y google: Drupal + Module X (or select css classes and ids from Module X)
I think that this event is rather unlikely.
I think a reasonable order of disclosure would be --security team - analyze problems, determine scope of change and its impact
--distro maintainters & module maintainers - give a set period for updates (1-2 days?)
--public disclosure - release with notice of error - example of how to exploit
Weren't you the one who was concerned about script kiddies?
- solution, and reasoning behind solution - links to patches and tar balls - parts affected by bug - parts affected by fix
Yeah, get us some funding for a paid security team and you can get all this. We could even patch affected modules.
-----------------------------------------------------
I really appreciate the work you guys on the security team do. I'm just
I somehow doubt this.
offering these as a suggestion for improvement.
Which is totally pointless considering how understaffed we are.
debian's older policy is a fairly good one, I'm not sure if its still current in their camp. http://lists.debian.org/debian-devel/1999/08/msg01933.html
Policies don't make security releases. Cheers, Gerhard P.S.: I've seen a preliminary list of modules that will need some tweaking. Nothing really important was on that list.
On Thu, 2006-10-19 at 19:20 +0200, Gerhard Killesreiter wrote:
Darrel O'Pry wrote:
dopry@bbox:~/public_html/drupal-4-7/public_html/sites/default/modules$ cat */*.module */*.inc | wc 15672 55392 508132
You mean browse through 15K lines of code? It's crazy to expect that of a site administrator. Remember we are developing for non-developers.
It is open source, ie it is part of the "scratch your own itch" movement. "your own" refers to developers.
Umm yeah I'll volunteer. I'd patch my modules before a disclosure, if someone would be nice enough to let me know it needs to be done. I may even patch things that I don't maintain.
This is the second security update the breaks things in the process of fixing them. Which isn't so good in my opinion. We need to take more
We of course did this just to piss people off...
No at all you old curmudgeon :). I think we can be more careful and there can be a larger review team for security updates I'd be happy to participate in that.
If we are going to change core in a way that will break modules, the affected modules need to be identified and their maintainers notified so a concerted effort can be made to provide end-users a real security fix, not just a partial. It is unfair to expected administrators and end-users to edit a module file.
It is unfair to expect unpaid volunteers to provide better support than the security departments of multi-billion dollar companies. At drupal.org you at least _get_ security updates...
I'm only expect volunteers do their best, be open to suggestion, and respond with quality rebuttal if they're capable. I'm simply pointing out a problem I see in the process. I'm not suggesting a whole lot more in the way of work for the security team. I'm even offering suggestions for improvement and my time to assist.
If module X is a key element of my site, and the bug fix breaks it...
Then you need to hold back the bugfix for a day or two while either you or somebody else fixes it. You still have an option to disable that module for that day or two.
did you read the phrase 'key element'. eg) you operate an aggregator site using aggregator2, a bug fix two core changes the return value of feed parsing. The security team releases the update. Did the developers of the affected modules get notified, did they have a chance to prepare a new version to coincide with the security update release? grep is a powerful tool for finding these things and I hear its fairly stable at this point. My suggestion is to hold back the disclosure for a day or two while contrib module maintainers who care have an opportunity to bring their modules up to speed, and to provide time for a more thorough review of the suggested changes.
I think a reasonable order of disclosure would be --security team - analyze problems, determine scope of change and its impact
--distro maintainters & module maintainers - give a set period for updates (1-2 days?)
--public disclosure - release with notice of error - example of how to exploit
Weren't you the one who was concerned about script kiddies?
- solution, and reasoning behind solution - links to patches and tar balls - parts affected by bug - parts affected by fix
full disclosure means taking the time to fix an exploit internally, testing the fix, and fully disclosing the fix and the exploit so the community at large can verify and test your work. That includes inviting the script kiddies to test their stuff.
Yeah, get us some funding for a paid security team and you can get all this. We could even patch affected modules.
No, just contacting the maintainers and giving them a period before disclosure is sufficient. At that point it is no longer on drupal core, its security team, or core maintainers. Its on the head of the contrib maintainer. Its a grep and some emails, maybe 30 minutes of someones time if that.
I somehow doubt this.
I appreciate the work, regardless of your doubt. Otherwise, I wouldn't engage in this dialogue, provide my opinions, or look at other people's processes for an example.
offering these as a suggestion for improvement.
Which is totally pointless considering how understaffed we are.
Then why not let people know the security team is understaffed and recruit some people. I'm sure there are people with a vested interest in making sure that part of the machine runs well.
debian's older policy is a fairly good one, I'm not sure if its still current in their camp. http://lists.debian.org/debian-devel/1999/08/msg01933.html
Policies don't make security releases.
And bad security releases don't make very inviting platforms. I agree policies don't make releases, unfortunately I'm not a member of the security team, so neither do I.
Cheers, Gerhard
P.S.: I've seen a preliminary list of modules that will need some tweaking. Nothing really important was on that list.
Cool. It would be nice to make an effort to cover those before disclosure. It save the sec team from having to rush and gives a few days for testing waiting for contrib developers to get it together as well.
dopry@bbox:~/public_html/drupal-4-7/public_html/sites/default/modules$ cat */*.module */*.inc | wc 15672 55392 508132
You mean browse through 15K lines of code? It's crazy to expect that of a site administrator. Remember we are developing for non-developers.
and then you demand that the security team review all of contrib and find affected modules and notify those maintainers and track progress? perhaps you can tell us how many lines of code that is.
On Thu, 2006-10-19 at 17:25 -0400, Moshe Weitzman wrote:
dopry@bbox:~/public_html/drupal-4-7/public_html/sites/default/modules$ cat */*.module */*.inc | wc 15672 55392 508132
You mean browse through 15K lines of code? It's crazy to expect that of a site administrator. Remember we are developing for non-developers.
and then you demand that the security team review all of contrib and find affected modules and notify those maintainers and track progress? perhaps you can tell us how many lines of code that is.
I think asking a site administrator to dig through code is completely different than asking a developer who wrote a core patch to dig through code. Its an apples to oranges situation. How much review does a patch in the issue queue that changes an api have to go through to get committed? How many related details are brought up on average? It should be rare that any security update changes an API. If we do change an API it should be done with care. Major versions aren't released without a fair amount of contributed modules being up to date. Should it be any different for a security update? Will Drupal 5 be slammed out without someone seeing which contrib modules have be converted? I seem to remember both in the 4.6 and 4.7 release cycle, more so in 4.7 with FAPI, quiet a bit of concern about the state of contrib... and just to be a total smartypants... dopry@bbox:~/src/cvs/contrib-4.7/modules$ cat */*.module */*.inc | wc 278307 about 20 times as many lines as on my dev site.. and a quicklist of potentially affected modules in my 4-7 checkout... dopry@bbox:~/src/cvs/contrib-4.7/modules$ grep '<form' */*.module */*.inc chatbox/chatbox.module -Darren Oh flashcard/flashcard.module -suuch flash_filter/flash_filter.module -tomsys g2/g2.module -fgm image_pub/image_pub.module -pangloss imce/imce.module -ufku mlist/mlist.module -peterjohnhartmann typecheck/typecheck.module -suuch userlink/userlink.module -marcp webform/webform.module -ullgren weight/weight.module -jjeff disknode/disknode.info.tpl.inc -elmuerte family/import.inc -Sam Wilson securesite/securesite.inc -Darren Oh webcam/webcam_popup_window.inc -flow@www.my-flow.com and I took the time to dig up the drupal usernames of the projects maintainers maintainers.
On 10/20/06, Darrel O'Pry <dopry@thing.net> wrote:
On Thu, 2006-10-19 at 17:25 -0400, Moshe Weitzman wrote:
dopry@bbox:~/public_html/drupal-4-7/public_html/sites/default/modules$ cat */*.module */*.inc | wc 15672 55392 508132
You mean browse through 15K lines of code? It's crazy to expect that of a site administrator. Remember we are developing for non-developers.
and then you demand that the security team review all of contrib and find affected modules and notify those maintainers and track progress? perhaps you can tell us how many lines of code that is.
I think asking a site administrator to dig through code is completely different than asking a developer who wrote a core patch to dig through code. Its an apples to oranges situation.
How much review does a patch in the issue queue that changes an api have to go through to get committed? How many related details are brought up on average?
It should be rare that any security update changes an API. If we do change an API it should be done with care. Major versions aren't released without a fair amount of contributed modules being up to date. Should it be any different for a security update?
Will Drupal 5 be slammed out without someone seeing which contrib modules have be converted? I seem to remember both in the 4.6 and 4.7 release cycle, more so in 4.7 with FAPI, quiet a bit of concern about the state of contrib...
and just to be a total smartypants...
dopry@bbox:~/src/cvs/contrib-4.7/modules$ cat */*.module */*.inc | wc 278307 about 20 times as many lines as on my dev site..
and a quicklist of potentially affected modules in my 4-7 checkout... dopry@bbox:~/src/cvs/contrib-4.7/modules$ grep '<form' */*.module */*.inc
Thanks, but 4.7 modules may define as many forms by <form tags as they want. Those will never fail validation, quite unlike the situation on Drupal 4.6. Heine
You mean browse through 15K lines of code? It's crazy to expect that of a site administrator. Remember we are developing for non-developers.
I hope that some module / theme developers on this list, after reading my message, checked the modules and themes they maintain for potential problems. Which was the, perhaps not clear, intent of my message. Now, for those people who like lists: - 4.7 modules that do not call form_render on an entire form blockregion/blockregion.module links/links_weblink.module location/location.module reptag/reptag_ajax.inc (perhaps) userplus/userplus.module - searching for accidental saving of additional fields is not easy. - 4.6 modules that define at least on raw html form (via <form action ="" etc) backport bugbits chatbox customerror disknode ecommerce evaluation fckeditor fitb formproc gmap guestbook htmlarea htmltidy i18n image_pub phpbb2drupal qanda relationship securesite sxip trip_search typecheck vocab voting -4.6 themes that define at least one raw html form argeebee bidi blix bluemarine_smarty box_grey box_grey_smarty burnt connections democratica fancy foundation friendselectric gespaa greenmarinee gworks kubrick leaf leaf_smarty leaves lincolns_revenge manji mollio noprob Plain1 rdc reflection sands sands_css slash slurpee spreadfirefox - Modules containing forms without a form_id_submit or call_back_submit function. Note that these forms will continue to function. False positives / negatives may be present: actions activeselect administration advogato_import amazontools biblio bookmarks bookroll buddylist category chatbox chipin civinode cpanel currency cvslog decisions disknode easylinks ecommerce ejournal emailpage event export_dxml ezmlm fetchgals fileshare flexinode forward freemind fudforum g2 glossary gmap googlesearch google_pr graphstat image imagecache img_assist import_html interwiki legal links linksdb liquid listhandler location logintoboggan map mlist modauthmysql monitor nodevote notify nutch og_galleries path_access pontomail privatemsg project project_issue randomizer rcmail relationship relativity rsvp session_limit shootevents simplenews simpletest simple_access smileys smsgateway stock subversion syndication tasks taxonomy_block taxonomy_ezfilter taxonomy_filter taxonomy_image taxonomy_xml textlinkads timesheet tinymce trackback troll views webform weblinks weight wishlist wordfilter workspace
On Fri, 2006-10-20 at 00:05 +0200, Heine Deelstra wrote:
You mean browse through 15K lines of code? It's crazy to expect that of a site administrator. Remember we are developing for non-developers.
I hope that some module / theme developers on this list, after reading my message, checked the modules and themes they maintain for potential problems. Which was the, perhaps not clear, intent of my message.
Now, for those people who like lists:
- 4.7 modules that do not call form_render on an entire form
blockregion/blockregion.module links/links_weblink.module location/location.module reptag/reptag_ajax.inc (perhaps) userplus/userplus.module
- searching for accidental saving of additional fields is not easy.
- 4.6 modules that define at least on raw html form (via <form action ="" etc) backport bugbits chatbox customerror disknode ecommerce evaluation fckeditor fitb formproc gmap guestbook htmlarea htmltidy i18n image_pub phpbb2drupal qanda relationship securesite sxip trip_search typecheck vocab voting
-4.6 themes that define at least one raw html form argeebee bidi blix bluemarine_smarty box_grey box_grey_smarty burnt connections democratica fancy foundation friendselectric gespaa greenmarinee gworks kubrick leaf leaf_smarty leaves lincolns_revenge manji mollio noprob Plain1 rdc reflection sands sands_css slash slurpee spreadfirefox
- Modules containing forms without a form_id_submit or call_back_submit function. Note that these forms will continue to function.
False positives / negatives may be present:
actions activeselect administration advogato_import amazontools biblio bookmarks bookroll buddylist category chatbox chipin civinode cpanel currency cvslog decisions disknode easylinks ecommerce ejournal emailpage event export_dxml ezmlm fetchgals fileshare flexinode forward freemind fudforum g2 glossary gmap googlesearch google_pr graphstat image imagecache img_assist import_html interwiki legal links linksdb liquid listhandler location logintoboggan map mlist modauthmysql monitor nodevote notify nutch og_galleries path_access pontomail privatemsg project project_issue randomizer rcmail relationship relativity rsvp session_limit shootevents simplenews simpletest simple_access smileys smsgateway stock subversion syndication tasks taxonomy_block taxonomy_ezfilter taxonomy_filter taxonomy_image taxonomy_xml textlinkads timesheet tinymce trackback troll views webform weblinks weight wishlist wordfilter workspace
Wow your list is much better than mine. I bet it helps to know what you're looking for. :) Would it be remotely possible to make people who work on contrib aware of API changes before releases in the future? (Now, I'm just trying to be a pain in the arse. ;)
On Oct 19, 2006, at 4:05 PM, Heine Deelstra wrote:
Now, for those people who like lists:
Since nobody is saying it here, but everyone is probably thinking it.... Thank you, Heine, for compiling these lists! It's most useful! Laura
On Thursday 19 October 2006 17:05, Heine Deelstra wrote:
Now, for those people who like lists:
Thanks, Heine!
- 4.7 modules that do not call form_render on an entire form
<snip>
- 4.6 modules that define at least on raw html form (via <form action ="" etc) backport
<snip>
-4.6 themes that define at least one raw html form
<snip>
- Modules containing forms without a form_id_submit or call_back_submit function. Note that these forms will continue to function.
False positives / negatives may be present:
googlesearch
This module (of which I am maintainer) has one form, which explicitly targets Google's search API. It never actually posts back to Drupal itself. Is it safe to assume, then, that it's a false positive and doesn't pose a security risk? (If there's something I need to change, I will do so post haste, but it sounds like it's safe since the module does so little.) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
False positives / negatives may be present:
googlesearch
This module (of which I am maintainer) has one form, which explicitly targets Google's search API. It never actually posts back to Drupal itself. Is it safe to assume, then, that it's a false positive and doesn't pose a security risk? (If there's something I need to change, I will do so post haste, but it sounds like it's safe since the module does so little.)
Same with customerror.module. The grep on <form caught one of the patches that are included with it. This module does not suffer from this vulnerability, nor is it broken by the fix.
Heine Deelstra wrote:
The 4.6.10 and 4.7.4 releases saw the addition of a new default form field to protect against cross site request forgeries.
2. 4.7 modules and themes that rely on a defined set of form fields to be present To me, this just means any form 'myform' that has defined a theme_myform() function which DOESN'T have a form_render($form); at the end of it will need to be updated. IIRC there are probably not too many modules which do that. Am I correct there? So I think the small breakage is outweighed by the improved security.
Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com
On 10/19/06, Rob Barreca <rob@electronicinsight.com> wrote:
Heine Deelstra wrote:
The 4.6.10 and 4.7.4 releases saw the addition of a new default form field to protect against cross site request forgeries.
2. 4.7 modules and themes that rely on a defined set of form fields to be present To me, this just means any form 'myform' that has defined a theme_myform() function which DOESN'T have a form_render($form); at the end of it will need to be updated. IIRC there are probably not too many modules which do that. Am I correct there? So I think the small breakage is outweighed by the improved security.
Yeah... those where my thoughs after reading the upgrade post. Actually it was more like "Wasn't that something we where suppose to be doing anyways?" I do have a better idea of why there was a token now though. While breaking things this is really just bringing contrib module developers into line with core requirements where before they could get away with not doing it correctly. 232That seems fair, though I don't think anyone will argue that they wished this had happened in the initial release. That's life and nothing short of more eyes going over the code for security issues is going to help that. Don't look at me like that Gerhard, I'm not complaining or volunteering. ;) And more eyes is the driving idea behind open source so I think we're working in the right direction there even if we are short staffed. James
Heine Deelstra wrote:
The 4.6.10 and 4.7.4 releases saw the addition of a new default form field to protect against cross site request forgeries.
This has consequences for
1. 4.6 modules and themes that output raw HTML forms
Those forms will always fail for authenticated users.
2. 4.7 modules and themes that rely on a defined set of form fields to be present
Certain modules and themes output only specific form fields. As they do not output the form_token, the form will always fail validation for authenticated users. Perhaps the subtleties of English are getting in the way, but all modules and themes output only specific form fields; every field in an HTML form is a specific field. At first, I couldn't make any sense out of this, and so went to the web site, where the explanation was the same but the examples shed some light.
I think that what you're saying is that some modules and themes output an explicit subset of form fields from a $form. Or maybe more precisely, judging from the followup note by Rob Barreca, some modules and themes call form_render on an explicit subset of fields in a given $form, and never call form_render($form) to render the rest of the form. Is that correct? If so, does that complete characterize the problem, or are there other ways to trigger the incompatibility in 4.7.*, excluding totally unreasonable, contrived examples. Gary
In addition, certain modules unset a few form fields, then save the remainder of the form. These modules need to account for the new field. Tip: devise something robust.
See for details:
Converting 4.6.9 modules to 4.6.10 <http://drupal.org/node/90004> Converting 4.7.3 modules to 4.7.4 <http://drupal.org/node/89999>
Converting 4.6.x themes to 4.6.10 <http://drupal.org/node/90021> Converting 4.7.x themes to 4.7.4 <http://drupal.org/node/90024>
Kind regards,
Heine Deelstra
Or maybe more precisely, judging from the followup note by Rob Barreca, some modules and themes call form_render on an explicit subset of fields in a given $form, and never call form_render($form) to render the rest of the form. Is that correct? If so, does that complete characterize the problem, or are there other ways to trigger the incompatibility in 4.7.*, excluding totally unreasonable, contrived examples. That sounds correct to me. :)
Also, I suppose you could call form_render($form['form_token']) manually and not have to call form_render($form). Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Gary Feldman wrote:
Heine Deelstra wrote:
The 4.6.10 and 4.7.4 releases saw the addition of a new default form field to protect against cross site request forgeries.
This has consequences for
1. 4.6 modules and themes that output raw HTML forms
Those forms will always fail for authenticated users.
2. 4.7 modules and themes that rely on a defined set of form fields to be present
Certain modules and themes output only specific form fields. As they do not output the form_token, the form will always fail validation for authenticated users. Perhaps the subtleties of English are getting in the way, but all modules and themes output only specific form fields; every field in an HTML form is a specific field. At first, I couldn't make any sense out of this, and so went to the web site, where the explanation was the same but the examples shed some light.
I think that what you're saying is that some modules and themes output an explicit subset of form fields from a $form. Or maybe more precisely, judging from the followup note by Rob Barreca, some modules and themes call form_render on an explicit subset of fields in a given $form, and never call form_render($form) to render the rest of the form. Is that correct? If so, does that complete characterize the problem, or are there other ways to trigger the incompatibility in 4.7.*, excluding totally unreasonable, contrived examples.
Gary
In addition, certain modules unset a few form fields, then save the remainder of the form. These modules need to account for the new field. Tip: devise something robust.
See for details:
Converting 4.6.9 modules to 4.6.10 <http://drupal.org/node/90004> Converting 4.7.3 modules to 4.7.4 <http://drupal.org/node/89999>
Converting 4.6.x themes to 4.6.10 <http://drupal.org/node/90021> Converting 4.7.x themes to 4.7.4 <http://drupal.org/node/90024>
Kind regards,
Heine Deelstra
On 10/19/06, Gary Feldman <dpal_gaf_devel@marsdome.com> wrote:
Perhaps the subtleties of English are getting in the way, but all modules and themes output only specific form fields; every field in an HTML form is a specific field. At first, I couldn't make any sense out of this, and so went to the web site, where the explanation was the same but the examples shed some light.
I think that what you're saying is that some modules and themes output an explicit subset of form fields from a $form. Or maybe more precisely, judging from the followup note by Rob Barreca, some modules and themes call form_render on an explicit subset of fields in a given $form, and never call form_render($form) to render the rest of the form.
Is that correct? If so, does that complete characterize the problem, or are there other ways to trigger the incompatibility in 4.7.*, excluding totally unreasonable, contrived examples.
Almost. Those modules / themes may very well be rendering the entire form, but doing so by rendering known fields. As soon as the form is altered (either by hook_form_alter or a core update), they do not output the new field. Another possible incompatability relates to saved data:
In addition, certain modules unset a few form fields, then save the remainder of the form. These modules need to account for the new field. Tip: devise something robust.
participants (15)
-
Darrel O'Pry -
Derek Wright -
Dries Buytaert -
Gary Feldman -
Gerhard Killesreiter -
Greg Knaddison - GVS -
Heine Deelstra -
inkfree press -
James Gilliland -
Khalid B -
Larry Garfield -
Laura Scott -
Moshe Weitzman -
Rob Barreca -
Walt Daniels