Hello, for your information, I plan to release a new beta after both bugfix events. One such even is scheduled for tomorrow (http://drupal.org/ node/44182), and one such event is scheduled for next Tuesday (http:// drupal.org/node/45057). That means that the next beta release, beta 4, is one week away. There are still a number of showstopping bugs. It would be great if we could focus on these first. Some of the most pressing bugs include: - http://drupal.org/node/44610 - http://drupal.org/node/40762 - http://drupal.org/node/44011 - http://drupal.org/node/44563 - http://drupal.org/node/43220 - http://drupal.org/node/44165 - http://drupal.org/node/42277 Unless we can fix those bugs before beta 4 is released, we'll have to release a fifth beta release, which means we won't be able to release Drupal 4.7.0 for another month or so. Thanks, -- Dries Buytaert :: http://www.buytaert.net/
There are still a number of showstopping bugs. It would be great if we could focus on these first. Some of the most pressing bugs include:
- http://drupal.org/node/44610 - http://drupal.org/node/44563
Fixed as of today.
- http://drupal.org/node/43220 - http://drupal.org/node/44165
These two are cured by killing MIME magic. I am sorry, but that's the best we can do.
Awaits Souvent22's decision. If he does not, then I look at it tomorrow.
Either drumm takes this one over or I close it tomorrow.
I leave this to others. Dries, please show more release stoppers :) Regards, NK
Op woensdag 18 januari 2006 07:26, schreef Karoly Negyesi:
These two are cured by killing MIME magic. I am sorry, but that's the best we can do.
Note that already we have a potential security breah in our uploads. PHP is not very good at checking the uploads, Drupal is just a tad worse. Our server maintainer (a notorious security person) pointed me at it and proved that it is very easy to misconfigure drupal / or the server so that one opens up. Now, I agree with Gerhard, when he says that "it is certainly not our task to prevent apache misconfigurations". But in some extend that is the Microsoft way: "we cannot help it that people install insecure apps / plugins". In some extend. We should try to be as secure as possible in all configurations, in all environments. So killing MIME magic does not sound like a good idea to me. Since it takes our biggest upload securtiy away. Unless I am comlpetely wrong about the MIME, and in that case I sould love some explanation :) Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
So killing MIME magic does not sound like a good idea to me. Since it takes our biggest upload securtiy away. Unless I am comlpetely wrong about the MIME, and in that case I sould love some explanation :)
Little security is gained by using MIME magic. It's being used so that it's a bit harder (not much) to upload doctored MIME type stuff... The real security is in the following lines which adds .txt to everything text. If you upload a .GIF which is not an image but an XSS JS and the MIME is text/plain so that IE will go guessing MIME type be it damned forever then if (((substr($file->filemime, 0, 5) == 'text/' will stop the parade. I am prety confident about losing this recently introduced functionality. Regards NK
Op woensdag 18 januari 2006 11:39, schreef Karoly Negyesi:
Little security is gained by using MIME magic. It's being used so that it's a bit harder (not much) to upload doctored MIME type stuff... The real security is in the following lines which adds .txt to everything text.
Mime is indeed just a small improvement. but as stated before: we already have quite little seccurity: and 0.01 is indeed very small factor of 10. 10 + 0.01 is still ~10. but 0.01 added to 0.01 dubles the number 0.01 +0.01 = 0.02.In other words: it was a significant improvement, only because we (drupal) do far too little (security wise) in uploads and file.inc. Adding a small improvement to very little security makes it significantly more secure :)
If you upload a .GIF which is not an image but an XSS JS and the MIME is text/plain so that IE will go guessing MIME type be it damned forever then if (((substr($file->filemime, 0, 5) == 'text/' will stop the parade.
our .txt replacement is quite insecure. first and for all because it does the (never ever allowed in security land so I am told) opt-in security: Instead of only allowing certain known files to *not* be rewritten, it rewrites only a small subset of stuff that is possible runnable on a server. what about jar, rhtml (ruby), python etc. They are all let trough. we leave it to the admins to configure stuff corerctly, and don't really help them. However; this is all part of betteruplaod plans. But I am fine with you removing it. file.inc needs a lot of work anyway. So dioes uplod.module. Adding a little more work to that will not make a huge difference. People who are really concerned about their security should not lean on uplaod and file.inc anyway, but should add scripts and so behind it, on the server :) I was only raising this concern, because you are voting for removing a part of the little security we do have. -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
(never ever allowed in security land so I am told) opt-in security:
=== modified file 'includes/file.inc' --- includes/file.inc +++ includes/file.inc @@ -156,7 +156,10 @@ else { $file->filemime = $_FILES["edit"]["type"][$source]; } - if (((substr($file->filemime, 0, 5) == 'text/' || strpos($file->filemime, 'javascript')) && (substr($file->filename, -4) != '.txt')) || preg_match('/\.(php|pl|py|cgi|asp)$/i', $file->filename)) { + preg_match('/\.(.+)$/', $file->filename, $m); + $extension = $m[1]; + $allowed_extensions = variable_get('file_allowed_extensions', array('jpg', 'jpeg', 'gif', 'png', 'txt', 'html', 'doc', 'xls', 'pdf', 'ppt', 'pps')); + if (((substr($file->filemime, 0, 5) == 'text/' || strpos($file->filemime, 'javascript')) && ($extension != 'txt')) || !in_array($extension, $allowed_extensions)) { $file->filemime = 'text/plain'; rename($file->filepath, $file->filepath .'.txt'); $file->filepath .= '.txt'; From here, you take over. Regards NK
Op woensdag 18 januari 2006 12:36, schreef Karoly Negyesi:
(never ever allowed in security land so I am told) opt-in security: From here, you take over.
Alrright. that is at least an improvement. I missed it, *Sorry!* Last time I looked it was not there. Chx, please do not forget that not all of us are chxes. not all of us manage (or wish) to keep track of all the stuff going in and outof drupal in chaotic times like these. We appriciate it when you do that :) but we cannot expect it from everyone. Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
+1 for chxcloning.module
Chx, please do not forget that not all of us are chxes. not all of us manage (or wish) to keep track of all the stuff going in and outof drupal in chaotic times like these. We appriciate it when you do that :) but we cannot expect it from everyone.
Bèr
A real mistake is being made by developers who have modules for 4.6, are updating them to 4.7, yet have not tagged them as 4.6. The first time I encountered this was with the devel module. I submitted a task request to lock the 4.6 version, but it hasn't been done: http://drupal.org/node/35584 Now I've encountered the same problem with the sections module. The sections module is great for solving a number of specific problems, and people like to use it. It used to work with 4.6, but now it doesn't. Why? Because the same version (1.9), painstakingly and lovingly updated to use the Forms Api, is now in both the 4-6 and 4-7 branches. Disclaimer: I am a CVS noob. I have never tagged anything for 4.6 or 4.7, but I recently got instructions for Moshe on how to do this, and before I start porting any module to 4.7, I will make sure a 4.6 tag exists. If we don't take care of this problem now, while we're still pre 4.7 release, it will just be harder later to go back and repair the damage. Don't let your 4.6 modules go extinct because you didn't tag them. -Robert
On Wed, Jan 18, 2006 at 03:13:13PM +0100, Robert Douglass wrote:
Now I've encountered the same problem with the sections module. The sections module is great for solving a number of specific problems, and people like to use it. It used to work with 4.6, but now it doesn't. Why? Because the same version (1.9), painstakingly and lovingly updated to use the Forms Api, is now in both the 4-6 and 4-7 branches.
contrib cvs should allow branching, at least for main releases (4.6, 4.7 etc) [I think it does not?] More than default -4-6 and -4-7 tags would be nice too. -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus!
Robert Douglass wrote:
A real mistake is being made by developers who have modules for 4.6, are updating them to 4.7, yet have not tagged them as 4.6.
branched
The first time I encountered this was with the devel module. I submitted a task request to lock the 4.6 version, but it hasn't been done: http://drupal.org/node/35584
Now I've encountered the same problem with the sections module. The sections module is great for solving a number of specific problems, and people like to use it. It used to work with 4.6, but now it doesn't. Why? Because the same version (1.9), painstakingly and lovingly updated to use the Forms Api, is now in both the 4-6 and 4-7 branches.
That's probably because somebody used tags not a branch.
Disclaimer: I am a CVS noob. I have never tagged anything for 4.6 or 4.7, but I recently got instructions for Moshe on how to do this, and before I start porting any module to 4.7, I will make sure a 4.6 tag exists.
Funny, the instructions are in the FAQ.txt in the top level contrib directory for more time than I care to remember. :P
If we don't take care of this problem now, while we're still pre 4.7 release, it will just be harder later to go back and repair the damage. Don't let your 4.6 modules go extinct because you didn't tag them.
Branch. What you want to do is as follows: To properly branch your code perform the following in your local workspace. Modules: cvs tag -b DRUPAL-4-6 modules/mymodule Themes: cvs tag -b DRUPAL-4-6 themes/mytheme Note that branching is restricted to the 'modules', 'themes', 'theme-engines' and 'translations' directories. You can't branch your sandbox. (directly from the FAQ.txt) After that you will need to get a cvs checkput for the new branch and fix bugs in that version in this branch. Further development should be in cv HEAD only. Cheers, Gerhard
Op woensdag 18 januari 2006 16:52, schreef Gerhard Killesreiter:
That's probably because somebody used tags not a branch.
That is indeed the case. the druapal.org faq *in the handbook* used to tell us to use tags. GRR. I'll have a look later on. Care to file a bug against sections? Ber -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Robert Douglass wrote:
A real mistake is being made by developers who have modules for 4.6, are updating them to 4.7, yet have not tagged them as 4.6. The first time I encountered this was with the devel module. I submitted a task request to lock the 4.6 version, but it hasn't been done: http://drupal.org/node/35584
fyi - devel.module released a 4.6 branch 2 days ago - http://cvs.drupal.org/viewcvs/drupal/contributions/modules/devel/?only_with_...
Thanks Moshe! Moshe Weitzman wrote:
Robert Douglass wrote:
A real mistake is being made by developers who have modules for 4.6, are updating them to 4.7, yet have not tagged them as 4.6. The first time I encountered this was with the devel module. I submitted a task request to lock the 4.6 version, but it hasn't been done: http://drupal.org/node/35584
fyi - devel.module released a 4.6 branch 2 days ago - http://cvs.drupal.org/viewcvs/drupal/contributions/modules/devel/?only_with_...
I'm less than a noob. Trying to commit a patch for indexpage.module 4.6 got this message from the cvs: cvs commit: sticky tag `DRUPAL-4-6' for file `indexpage.module' is not a branch cvs [commit aborted]: correct above errors first! I've commited other patches to other modules for 4.6 before and got no problems. Is this anything related to your post? Can someone give me a quick hand on this? Thanks. Robert Garrigos Robert Douglass wrote:
A real mistake is being made by developers who have modules for 4.6, are updating them to 4.7, yet have not tagged them as 4.6. The first time I encountered this was with the devel module. I submitted a task request to lock the 4.6 version, but it hasn't been done: http://drupal.org/node/35584
Now I've encountered the same problem with the sections module. The sections module is great for solving a number of specific problems, and people like to use it. It used to work with 4.6, but now it doesn't. Why? Because the same version (1.9), painstakingly and lovingly updated to use the Forms Api, is now in both the 4-6 and 4-7 branches.
Disclaimer: I am a CVS noob. I have never tagged anything for 4.6 or 4.7, but I recently got instructions for Moshe on how to do this, and before I start porting any module to 4.7, I will make sure a 4.6 tag exists.
If we don't take care of this problem now, while we're still pre 4.7 release, it will just be harder later to go back and repair the damage. Don't let your 4.6 modules go extinct because you didn't tag them.
-Robert
On Wed, 18 Jan 2006 12:44:51 +0100, Bèr Kessels <ber@webschuur.com> wrote:
Op woensdag 18 januari 2006 12:36, schreef Karoly Negyesi:
(never ever allowed in security land so I am told) opt-in security: From here, you take over.
Alrright. that is at least an improvement. I missed it, *Sorry!* Last time I looked it was not there.
And it's not there either. I whipped it up quite quickly. I do not like the solution so much that I have not even filed in as an issue. Regards NK
participants (9)
-
Breyten Ernsting -
Bèr Kessels -
Dries Buytaert -
Gerhard Killesreiter -
Karoly Negyesi -
Moshe Weitzman -
piotr＠mallorn.ii.uj.edu.pl -
Robert Douglass -
Robert Garrigós Castro