| 1.3, другой_Аноним (?), 22:37, 20/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Джумлу всегда избегал именно из-за ее истории уязвимостей. Не то чтобы у других не было, но почему-то в большей части новостей о Джумле, на которые я натыкался, только о них и говорили. Как-то стремно.
| | |
| |
| |
| 3.14, solardiz (ok), 04:25, 21/07/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Кроме общего количества, есть и другие критерии:
Из приведенных выше URL'ов, из первых 25-ти уязвимостей Joomla (первая страница выдачи на Secunia) одиннадцать SQL injection, в то время как для Drupal из первых 25-ти - две SQL injection. И там и там - в модулях (не знаю входящих в поставку или нет).
Еще можно смотреть кто нашел уязвимость и опубликовал advisory. Для Drupal это часто сами разработчики, что подразумевает одновременное наличие исправления.
| | |
| |
| 4.19, Michael Shigorin (ok), 10:23, 26/09/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > Еще можно смотреть кто нашел уязвимость и опубликовал advisory. Для Drupal это
> часто сами разработчики, что подразумевает одновременное наличие исправления.
Аналогично и для TYPO3; плюс если приходится подпрыгивать раз в два года, почитав почту, то это уже слишком часто.
Мои искренние пожелания группе разработчиков Joomla хоть когда-то понять, что функциональность без мысли о безопасности -- это подстава.
| | |
|
|
|
| 1.6, rshadow (ok), 23:49, 20/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > предлагая установить обновление в один клик
Зачем они делают эти велосипеды? Неужто кто-то под виндой будет сайт крутить. Лучше задружились бы с майнтейнерами в дистрах.
| | |
| |
| 2.7, kem (?), 00:05, 21/07/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
 при чем здесь майнтейнеры, речь идет об обновления самой cms и плагинов из ее админки и это правильно, раньше не было нормального способа обновилять плагины. В WordPress все это делается из админки и это очень удобно
| | |
| |
| 3.8, rshadow (ok), 00:20, 21/07/2011 [^] [^^] [^^^] [ответить]
| +/– | |
При том. Например в дебиане:
# 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 и его модули устанавливаются пакетным менеджером, стандартным для дистрибутива способом. Соответственно получаем все плюшки с секурностью, простотой работы и т.д.
| | |
| |
| 4.9, kem (?), 00:26, 21/07/2011 [^] [^^] [^^^] [ответить]
| +/– | |
ясно, для тестовой установки или в случае если на сервере одна инсталяция Jommla этот подход хорош, но если несколько и притом разных версий то пакетный менеджер уже не справится, тем более что далеко не все плагины есть в репозитории.
Вообще мне кажется порочной практика помежать в репозиторий такие спициализированные вещи как плагины cms например, этим должна сама cms рулить, WP отлично отслеживает доступность обновлений плагинов и ядра и обновляется одним щелчком в админ и это правильный подход, обновлять инсталяцию cms должен иметь право админ cms, а не админ сервера на котором она (и, возможно, еще тысячи таких как она установлены)
| | |
| |
| 5.10, rshadow (ok), 00:56, 21/07/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> если на сервере одна инсталяция Jommla этот подход хорош
он хорош всегда =)
> но если несколько и притом разных версий то пакетный менеджер уже не справится
почему нет? с библиотеками и софтом справляется же. как раз наоборот очень удобно поддерживать последнюю версию.
> этим должна сама cms рулить
не должна. весь софт должен быть в репах
> тем более что далеко не все плагины есть в репозитории.
это как раз и есть поле для работы
> WP отлично отслеживает доступность обновлений
велосипед в этом и есть. учитывая дырявость веб проектов представляю что туда будет понаставлено =( Еще и за совместимостью плагинов следить ...
> обновлять инсталяцию cms должен иметь право админ cms, а не админ сервера
Как минимум обновляться она должна сразу после выхода патчей безопасности. Ну и например никто не мешает кнопку "Обновить" переделать так чтобы она вызывала обновление пакетным менеджером а не качала откуда-то непроверенную для дистра версию.
> еще тысячи таких как она установлены
вот вот.
1. 1000 копий жомлы разных версий, с разными плагинами =(, вместо одной, последней, стабильной.
2. А если надо установить плагин, то надо 1000 раз полазить по веб гую и дождаться скачивания?
вообщем как ни крути, подход не правильный. Подходит такая система тока если на сервере стоит одна - две инсталяции.
Вообще в trac например сделано так: весь код устанавливается из пакета в одно место. А на каждый отдельную копию сайта есть конфиг в котором все прописывается и апач на него настраивается. Получается и обновления/плагины хорошо ставить и проектов на сервере может быть скока угодно, тока конфиг новый пиши под каждый из них. Ну и если чего то очень хочется, всегда можно в конкретный экземпляр ручками доставить.
| | |
| |
| 6.11, kem (?), 01:11, 21/07/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
довольно категорично, могбы возразить по всем пунктам, но возражу только по одному
> не должна. весь софт должен быть в репах
кто его туда положит ? существует огромное количество плагинов на официальном ресурсе, кто будет для всех собирать пакеты ? даже если допустить что для основных расширений пакеты все-таки будут, то возникает вопрос в типе пакета - deb, rpm, etc при чем сами исходники абсолютно инварианты для любору дистрибутива => это ненужное умножение сущностей, но даже если и это не достаточно убедительно то рано или поздно обязательно наступит ситуация когда нужного расширения не окажется в репозиттории и его придется ставить по старинке, то есть оба подхода будут смешаны, можно конечно самостоятельно собирать пакеты для своего дистрибудтива и даже создать для этого свой репозиторий, только ради чего все эти усилия ? в большинстве случаев специализированый интсрумент лучше универсального, именно поэтому есть PyPI - the Python Package Index, Ruby gems, Pear etc и этот подход себя пока оправдывает
| | |
| |
| 7.12, rshadow (ok), 01:37, 21/07/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> кто его туда положит ?
тот кто делает плагин или в полуавтоматическом режиме. Я же еще в первый пост писал "dh-make-drupal - Create Debian packages from Drupal modules and themes".
В общем буду тоже краток
> именно поэтому есть PyPI - the Python Package Index, Ruby gems, Pear etc и этот подход себя пока оправдывает
Все что поставлено отсюда превращается в помойку и адъ для админа. Но даже чаще просто забрасывается типа "работает - не лезь".
В общем эти каталоги хороши и нужны для собирания кода программистов в одном месте. Но дальше этот код надо адаптировать к конкретной системе, что, как правило, пропускается и заводится "на коленках" =( или пишутся какие-то костыли.
| | |
| |
| 8.16, VoViK (ok), 11:39, 21/07/2011 [^] [^^] [^^^] [ответить] | +/– |  Подумайте о серверах на которых сотни пользователей, у каждого свои CMS Сделано... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
