Увидел свет (http://www.joomla.org/announcements/release-news/5380-joomla...) релиз системы управления web-контентом Joomla 1.7.0 (http://www.joomla.org). Это первый релиз, выпущенный в рамках нового фиксированного цикла подготовки релизов, подразумевающего выпуск значительного релиза через каждые 6 месяцев. Поддержка прошлой ветки 1.6.x продлится до 19 августа, после чего выпуск обновлений с устранением уязвимостей будет прекращен. В ветке 1.7 реализован новый механизм быстрой установки дополнений, системные требования остались прежними - PHP 5.2+ и MySQL 5.0.4+.
Новый механизм обновления позволяет быстро проверить наличие новых версий Joomla и установленных расширений, предлагая установить обновление в один клик. В случае необходимости, все действия по изменению структуры базы теперь выполняются автоматически. Каталог с внутренними библиотеками вынесен в отдельный пакет и может использоваться отдельно от CMSИз других изменений можно отметить обновление визуал...
URL: http://www.joomla.org/announcements/release-news/5380-joomla...
Новость: http://www.opennet.me/opennews/art.shtml?num=31243
Джумлу всегда избегал именно из-за ее истории уязвимостей. Не то чтобы у других не было, но почему-то в большей части новостей о Джумле, на которые я натыкался, только о них и говорили. Как-то стремно.
Количество найденных уязвимостей у разныз CMS'ов как правило пропорционально популярности:
465 у джумлы http://secunia.com/advisories/search/?search=joomla
448 у друпала http://secunia.com/advisories/search/?search=drupal
293 у вордпресса http://secunia.com/advisories/search/?search=wordpress
105 у тайпо3 http://secunia.com/advisories/search/?search=typo3
Кроме общего количества, есть и другие критерии:Из приведенных выше URL'ов, из первых 25-ти уязвимостей Joomla (первая страница выдачи на Secunia) одиннадцать SQL injection, в то время как для Drupal из первых 25-ти - две SQL injection. И там и там - в модулях (не знаю входящих в поставку или нет).
Еще можно смотреть кто нашел уязвимость и опубликовал advisory. Для Drupal это часто сами разработчики, что подразумевает одновременное наличие исправления.
> Еще можно смотреть кто нашел уязвимость и опубликовал advisory. Для Drupal это
> часто сами разработчики, что подразумевает одновременное наличие исправления.Аналогично и для TYPO3; плюс если приходится подпрыгивать раз в два года, почитав почту, то это уже слишком часто.
Мои искренние пожелания группе разработчиков Joomla хоть когда-то понять, что функциональность без мысли о безопасности -- это подстава.
> предлагая установить обновление в один кликЗачем они делают эти велосипеды? Неужто кто-то под виндой будет сайт крутить. Лучше задружились бы с майнтейнерами в дистрах.
при чем здесь майнтейнеры, речь идет об обновления самой cms и плагинов из ее админки и это правильно, раньше не было нормального способа обновилять плагины. В WordPress все это делается из админки и это очень удобно
При том. Например в дебиане:# apt-cache search --names-only drupal
dh-make-drupal - Create Debian packages from Drupal modules and themes
drupal6-mod-i18n - i18n module for Drupal 6
drupal6-mod-inline - inline module for Drupal 6
drupal6-mod-ldap-integration - ldap_integration module for Drupal 6
...
drupal6 - мощная система управления контентом
...
drupal6-mod-xrds-simple - xrds_simple modules for Drupal 6
drupal6-mod-views-charts - views_charts modules for Drupal 6Большинство модулей вырезал чтобы простыни не было.
Так что и drupal и его модули устанавливаются пакетным менеджером, стандартным для дистрибутива способом. Соответственно получаем все плюшки с секурностью, простотой работы и т.д.
ясно, для тестовой установки или в случае если на сервере одна инсталяция Jommla этот подход хорош, но если несколько и притом разных версий то пакетный менеджер уже не справится, тем более что далеко не все плагины есть в репозитории.Вообще мне кажется порочной практика помежать в репозиторий такие спициализированные вещи как плагины cms например, этим должна сама cms рулить, WP отлично отслеживает доступность обновлений плагинов и ядра и обновляется одним щелчком в админ и это правильный подход, обновлять инсталяцию cms должен иметь право админ cms, а не админ сервера на котором она (и, возможно, еще тысячи таких как она установлены)
> если на сервере одна инсталяция Jommla этот подход хорошон хорош всегда =)
> но если несколько и притом разных версий то пакетный менеджер уже не справится
почему нет? с библиотеками и софтом справляется же. как раз наоборот очень удобно поддерживать последнюю версию.
> этим должна сама cms рулить
не должна. весь софт должен быть в репах
> тем более что далеко не все плагины есть в репозитории.
это как раз и есть поле для работы
> WP отлично отслеживает доступность обновлений
велосипед в этом и есть. учитывая дырявость веб проектов представляю что туда будет понаставлено =( Еще и за совместимостью плагинов следить ...
> обновлять инсталяцию cms должен иметь право админ cms, а не админ сервера
Как минимум обновляться она должна сразу после выхода патчей безопасности. Ну и например никто не мешает кнопку "Обновить" переделать так чтобы она вызывала обновление пакетным менеджером а не качала откуда-то непроверенную для дистра версию.
> еще тысячи таких как она установлены
вот вот.
1. 1000 копий жомлы разных версий, с разными плагинами =(, вместо одной, последней, стабильной.
2. А если надо установить плагин, то надо 1000 раз полазить по веб гую и дождаться скачивания?
вообщем как ни крути, подход не правильный. Подходит такая система тока если на сервере стоит одна - две инсталяции.Вообще в trac например сделано так: весь код устанавливается из пакета в одно место. А на каждый отдельную копию сайта есть конфиг в котором все прописывается и апач на него настраивается. Получается и обновления/плагины хорошо ставить и проектов на сервере может быть скока угодно, тока конфиг новый пиши под каждый из них. Ну и если чего то очень хочется, всегда можно в конкретный экземпляр ручками доставить.
довольно категорично, могбы возразить по всем пунктам, но возражу только по одному
> не должна. весь софт должен быть в репахкто его туда положит ? существует огромное количество плагинов на официальном ресурсе, кто будет для всех собирать пакеты ? даже если допустить что для основных расширений пакеты все-таки будут, то возникает вопрос в типе пакета - deb, rpm, etc при чем сами исходники абсолютно инварианты для любору дистрибутива => это ненужное умножение сущностей, но даже если и это не достаточно убедительно то рано или поздно обязательно наступит ситуация когда нужного расширения не окажется в репозиттории и его придется ставить по старинке, то есть оба подхода будут смешаны, можно конечно самостоятельно собирать пакеты для своего дистрибудтива и даже создать для этого свой репозиторий, только ради чего все эти усилия ? в большинстве случаев специализированый интсрумент лучше универсального, именно поэтому есть PyPI - the Python Package Index, Ruby gems, Pear etc и этот подход себя пока оправдывает
> кто его туда положит ?тот кто делает плагин или в полуавтоматическом режиме. Я же еще в первый пост писал "dh-make-drupal - Create Debian packages from Drupal modules and themes".
В общем буду тоже краток
> именно поэтому есть PyPI - the Python Package Index, Ruby gems, Pear etc и этот подход себя пока оправдывает
Все что поставлено отсюда превращается в помойку и адъ для админа. Но даже чаще просто забрасывается типа "работает - не лезь".
В общем эти каталоги хороши и нужны для собирания кода программистов в одном месте. Но дальше этот код надо адаптировать к конкретной системе, что, как правило, пропускается и заводится "на коленках" =( или пишутся какие-то костыли.
Подумайте о серверах на которых сотни пользователей, у каждого свои CMS. Сделано это для удобства _пользователя_.
Да я не спорю что для удобства пользователя. Все для них родимых и делается. Тока неправильно...
кто знает когда заканчивается время поддержки версии 1.5?
В апреле 2012