Одновременно выпущены релизы PHP 4.4.4 (http://www.php.net/release_4_4_4.php) и 5.1.5 (http://www.php.net/release_5_1_5.php), в которых исправлен ряд ошибок связанных с безопасностью:- Возможность обхода safe_mode/open_basedir через функции error_log(), file_exists(), imap_open() и imap_reopen();
- Переполнение буфера через функции str_repeat() и wordwrap() на 64-битных системах;
- Возможность обхода ограничений open_basedir/safe_mode через функции расширения cURL;
- Переполнение буфера в расширении GD;
- Переполнение буфера через функцию sscanf();
- Проблемы работы ограничения memory_limit на 64-битных системах;
- Выход за допустимые границы в функции stripos().
Что касается PHP 5.2.0, вероятно релиз будет выпущен уже в сентябре.URL: http://ilia.ws/archives/124-PHP-Release-Bonanza.html
Новость: http://www.opennet.me/opennews/art.shtml?num=8136
>Возможность обхода safe_mode/open_basedir через функции error_log(), file_exists(), imap_open() и imap_reopen();
господи, они когда-нибудь это победят?
Победят. В PHP6 safe_mode не будет. И хорошо.
open_basedir тоже не будет? И переполнения буфера через это вдруг куда-то сами пропадут? :)
>open_basedir тоже не будет? И переполнения буфера через это вдруг куда-то сами
>пропадут? :)Рыгать на "безопасность". Для того есть Снорт (Свиное Рыло) и мод_секьюрити.
Сяжу на дрявнейшей версии PHP. До которой даунгрейдился методом тыка.
Чтобы РАБОТАЛО. Чего и всем желаю. ПХП и "безопасность" - вещи параллельные.
Давайте уже процессоры обвинять в том, что он вредные инструкции исполняет?
Если прог - баран, а адм - баран и не в силах замазать дыры за разработчиком ПХП-приложенич, то при чем здесь ПХП? Тогда уже ГнуСиСи плохой? Ведь он ПХП собирает?
То, как развивается язык, заставляет только вздыхать с грустью и скрепя сердце дальше работать...
Направление развития как раз правильное - safe mode, например, надо было уже давно выкидывать. Но, к сожалению, даже это PHP уже не поможет - конкурентам он проигрывает по всем параметрам. Поэтому нечего вздыхать - переходите на актуальные средства разработки.
А можно подробнее про альтернативы?
Особенно про те, что есть на серверах у практически _всех_ провайдеров. Perl/PHP - вот все, что можно выбрать на обычном shared-хостинге.
>А можно подробнее про альтернативы?
>Особенно про те, что есть на серверах у практически _всех_ провайдеров. Perl/PHP
>- вот все, что можно выбрать на обычном shared-хостинге.Собственно, Perl - отличная альтернатива.
например? на руби? или питон?
где нормальная альтернатива ЛЕГОМУ написанию ВЕБ-приложений? с нормальной интеграцией с HTML и заточкой под это?
Вообще-то, макаронообразная "интеграция" с html - это ненормально. Но если очень нужно, то на здоровье: http://search.cpan.org/search?mode=dist&query=mason
True. Или TT. Скомпилированные шаблоны хранятся в памяти и отдаются в 2 раза быстрее, чем статика.
http://www.template-toolkit.org/
Заточки - ето карашо. Но что делать с корп. рзработками. А сказать переходите легше всего.
Ну ребят, если один хостится на виртуальном хостинге, а другому нужно непременно ЛЕХКОЕ написание, да еще и `интеграция с HTML', пишите на PHP, флаг вам в руки.
Напрашивается аналогия с отечественным автомобильным рынком:
Чиниться в гараже, ремонт без комп. оборудования, дешевые запчасти и авто до 10 тыс. $. - у нас так полстраны живут. И скажу я вам, рынок этот огромен, миллиарды баксов крутятся, такой рынок нельзя игнорировать. Разработчиков сайтов на JAVA - на несколько порядков меньше.
Вот Zend'у бы программеров поаккуратнее, так вообще все проекты до 10.000$ были бы на PHP ;)
>Напрашивается аналогия с отечественным автомобильным рынком:
>Чиниться в гараже, ремонт без комп. оборудования, дешевые запчасти и авто до
>10 тыс. $. - у нас так полстраны живут. И скажу
>я вам, рынок этот огромен, миллиарды баксов крутятся, такой рынок нельзя
>игнорировать. Разработчиков сайтов на JAVA - на несколько порядков меньше.
>Вот Zend'у бы программеров поаккуратнее, так вообще все проекты до 10.000$ были
>бы на PHP ;)Аналогия не получается, потому что вопрос не упираеться в "дешёвый" php vs "дорогая" java. Есть масса рабочих возможностей между ними.
>>Напрашивается аналогия с отечественным автомобильным рынком:
>>Чиниться в гараже, ремонт без комп. оборудования, дешевые запчасти и авто до
>>10 тыс. $. - у нас так полстраны живут. И скажу
>>я вам, рынок этот огромен, миллиарды баксов крутятся, такой рынок нельзя
>>игнорировать. Разработчиков сайтов на JAVA - на несколько порядков меньше.
>>Вот Zend'у бы программеров поаккуратнее, так вообще все проекты до 10.000$ были
>>бы на PHP ;)
>
>Аналогия не получается, потому что вопрос не упираеться в "дешёвый" php vs
>"дорогая" java. Есть масса рабочих возможностей между ними.Так или иначе в конце-концов все упирается в бабло. Иными словами, в стоимость создания, поддержки и развития проектов. А все возможности, что потенциально заложены и частично реализованы в java - они не всем нужны.
>>Аналогия не получается, потому что вопрос не упираеться в "дешёвый" php vs
>>"дорогая" java. Есть масса рабочих возможностей между ними.
>
>Так или иначе в конце-концов все упирается в бабло. Иными словами, в
>стоимость создания, поддержки и развития проектов. А все возможности, что потенциально
>заложены и частично реализованы в java - они не всем нужны.
>
Я, в принципе, намекаю на то, что любой php-проект можно с незначительно большими начальными затратами реализовать используя perl/python. А java - это совсем другая история
>Я, в принципе, намекаю на то, что любой php-проект можно с незначительно
>большими начальными затратами реализовать используя perl/python. А java - это совсем
>другая историяЛюбую программу можно переписать на любом другом языке. В частности, php-программу в большинстве случаев можно переписать на perl'е, сохраняя стиль и архитектуру. Вопрос: а нужны ли те же грабли, только вид сбоку?
>Любую программу можно переписать на любом другом языке. В частности, php-программу в
>большинстве случаев можно переписать на perl'е, сохраняя стиль и архитектуру. Вопрос:
>а нужны ли те же грабли, только вид сбоку?Вопрос не понят. Если "грабли" - это вечные дырки в реализации, то перейдя на perl вы будете смотреть на них не "сбоку", а издали
>Вопрос не понят. Если "грабли" - это вечные дырки в реализации, то
>перейдя на perl вы будете смотреть на них не "сбоку", а
>издалиНа shared-хостинге что на перле, что на пхп - один хер, от юзеров на том же сервере не убережешься. А так, на своем, выделенном сервере, php мурлычет и ему пофиг до тех багов, что в нем иногда находят. Ну был бы перл там, разницы-то особой нет, кроме самой реализации. Perl никаких особых возможностей не подкинет, за пивом бегать тоже не будет, админу сервера гемороя от перла не меньше.
Лично из mod_php и mod_perl выбираю первый, как менее прожорливый в памяти и проще в настройке. А вообще - каждый выберет то, что ему по мазе :)
>>Вопрос не понят. Если "грабли" - это вечные дырки в реализации, то
>>перейдя на perl вы будете смотреть на них не "сбоку", а
>>издали
>
>На shared-хостинге что на перле, что на пхп - один хер, от
С такой философией, можно и firewall-ом не пользоваться. Ан нет! При ближайшем рассмотрении оказываеться, что хер таки не один. Больше дыр - вероятнее неприятности.>юзеров на том же сервере не убережешься. А так, на своем,
>выделенном сервере, php мурлычет и ему пофиг до тех багов, что
>в нем иногда находят. Ну был бы перл там, разницы-то особой
>нет, кроме самой реализации. Perl никаких особых возможностей не подкинет, за
>пивом бегать тоже не будет, админу сервера гемороя от перла не
>меньше.
За пивом - не будет, а вот геморроя - меньше, как минимум за счёт патчей
>>На shared-хостинге что на перле, что на пхп - один хер, от
>С такой философией, можно и firewall-ом не пользоваться. Ан нет! При ближайшем
>рассмотрении оказываеться, что хер таки не один.Интересно, вы и вправду будете размещать сколь-нибудь ценную информацию на shared-хостинге?
Если да - сообщите мне URL, может мне она пригодится ;)>>Perl никаких особых возможностей не подкинет, за
>>пивом бегать тоже не будет, админу сервера гемороя от перла не
>>меньше.
>За пивом - не будет, а вот геморроя - меньше, как минимум
>за счёт патчейРазве нормальный админ ставит подряд ВСЕ свежие патчи? ;)
Ну стоит у меня 4.3.11 - работает нормально, не падает, особых дыр нет. Так ведь и перл не обновляют до свежей версии на production-системе.
>Интересно, вы и вправду будете размещать сколь-нибудь ценную информацию на shared-хостинге?
>Если да - сообщите мне URL, может мне она пригодится ;)
>
Таки вы думаете, что взломы бывают только из-за ценной информации? Есть множество мелких хулиганов-kiddies, а за проблемы с дешёвыми экаунтами админ тоже отвечает.>Разве нормальный админ ставит подряд ВСЕ свежие патчи? ;)
>Ну стоит у меня 4.3.11 - работает нормально, не падает, особых дыр
>нет. Так ведь и перл не обновляют до свежей версии на
>production-системе.
Я имел в виду врачевание дыр.
> С такой философией, можно и firewall-ом не пользоваться. Ан нет! При ближайшем рассмотрении оказываеться, что хер таки не один. Больше дыр - вероятнее неприятности.Философия совершенно правильная, и firewall тут непричем.
Дело в том, что от safe mode многие ждут какой-то безопасности (_safe_ же, епты), которую тот мало того что не может предоставить, так еще и подставляет глупых разработчиков, на него надеющихся. Вместо того, чтобы настроить права и chroot, используют safe mode. Так что вероятнее неприятности как раз с PHP.
>настроить права и chroot, используют safe mode. Так что вероятнее неприятности
>как раз с PHP.Читайте внимательней! Этого мне не надо рассказывать.
К слову, на narod.ru форум и гостевуху готовую дадут - и не надо за уязвимостями следить.
да, ЛЕГКОЕ написание необходимо. вроде руби пойдет, но может ли он стать полноценной заменой пыхпыху?
я бы рад уйти от него, но не знаю куда...
Что значит "нормальная интеграция с HTML"? HTML::Template, например, это нормальная интеграция или нет?
Народ, чё вы кипишуете?
Проблемы не в языке а в реализации. Программерам ничего переделывать не нужно. А админ пересоберёт - тем более это процесс не архисложный. И факт, на хостинге "" не держат.
... корпоративные вещи ... не держат.
Не надо пытаться оградить целое поколение программистов от необходимости понимать то, что они делают.
Пишите все на C, в крайнем случае на Perl и все будет Ok.
На мой взгляд говорить об актуальности дыр не приходится, на мой лично взгляд важна скорость выпуска закладок, чем иметь 1 дырку, которая заплаткалась за несколько месяцев.