Очередные дыры Друпала

Главные вкладки

Комментарии

Аватар пользователя adubovskoy adubovskoy 17 ноября 2016 в 17:13
1

Дыры есть везде. И когда их оперативно находят и есть устоявшийся механизм оповещения и реагирования, это лучше чем когда не находят) У друпала тут по сравнению с многими CMS куда лучше дела.

Аватар пользователя sergeybelya sergeybelya 17 ноября 2016 в 17:28

Я и не спорю. Но настораживает, что находят общие проблемы в ядрах семерки и восьмерки, что указывает на частичное использование старого кода в ядре 8-ки, что не есть хорошо.

Аватар пользователя gun_dose gun_dose 17 ноября 2016 в 17:32

Что значит не есть хорошо? Это основополагающий принцип прогресса - использовать старые наработки где-либо. В любой программе есть код из старых версий, в любой машине есть детали из предыдущих моделей. В том же линуксе нашли недавно уязвимость, которой лет 15 уже и которая успела попасть даже в андроид, хотя самого андроида и в помине не было, когда был написан уязвимый код.

Аватар пользователя sergeybelya sergeybelya 17 ноября 2016 в 17:36

Восьмерку представляли как абсолютно новый продукт и писали так долго, что могли бы весь код написать с нуля и отрефакторить. Сравнение с Линуксом не предсталвяется уместным, разного масштаба продукты. А тут уже не первый раз общие дыры в ядрах семерки и восьмерки.

Аватар пользователя goodboy goodboy 17 ноября 2016 в 23:48

По первой ссылке - Дрис пишет, что Друпал8 это круто и новая эра. Кто же спорит. Про девятку упоминаний не нашел.
По второй ссылке - человек с какого-то сайта пишет "This is just my personal opinion" и что Друпалу 9 не бывать. Такое мнение, да, бывает.
Что эти материалы доказывают, не совсем понимаю.

Хорошо, давайте по сути. В Друпал 8 ООП частичное и остались хуки, а в Друпал 9 декларируют, что полное ООП и без хуков. Это несправедливое утверждение?
По ссылке https://www.drupal.org/node/1509164
"This possible decision to entirely replace hooks is postponed to Drupal 9.
Until then, in Drupal 8, we basically have two systems in parallel"

Аватар пользователя adubovskoy adubovskoy 18 ноября 2016 в 0:00

все верно. это ничего не говорит про "проходную систему". Drupal8 это значительный релиз, он довольно надолго, им можно и нужно пользоваться. D9 будет еще лучше, несомненно. Иначе, это значит что следует назвать D9 "проходным" по сравнению с D10 и так до бесконечности.

Аватар пользователя goodboy goodboy 18 ноября 2016 в 1:26

Покажите, где я в моем комментарии http://www.drupal.ru/comment/680231#comment-680231 употребил слово "проходная" или "проходная система".

Были автомобили с ДВС, потом появились гибриды (Lexus RX 400h), потом электромобили. Вот этот лексус - переходная модель от бензино/дизельных авто к электромобилям? Допускаю, что есть статьи экспертов, которые утверждали, что появление электромобилей - это утопия. Появление гибридов - это прорыв? Конечно, сто лет были движки одного типа и тут такое.

Статья старая, да, это разве доказывает, что все переиграли. Вот Gabor пишет в http://hojtsy.hu/blog/2016-aug-09/there-will-be-drupal-9-and-here-why "After that Drupal 9 could just be about removing the bad old ways and keeping the good new ways of doing things and the first Drupal 9 release could be the same as the last Drupal 8 release with the cruft removed.". В вольном переводе - мы освободимся от наслоений дерьма и выйдем на сияющую дорогу таким образом, что первая версия D9 будет одновременно последней версией D8. Авторитетный автор, надеюсь.

Про версии D10 и т.д. Как правило, нечетные версии являются стабильными, а четные - переходными.

Аватар пользователя adubovskoy adubovskoy 18 ноября 2016 в 1:55

ваша цитата "Читал, что восьмерка переходная версия к девятке. ", слово немного другое, да, ошибся) Но давайте не будем о словах конкретных. Я с тезисом не согласен. Вы намекаете на то что "восьмерка не готова". Да готова она, наметили план что выпилить к девятке, в девятке наметят план что выпилить к десятке и т.п.

>>Про версии D10 и т.д. Как правило, нечетные версии являются стабильными, а четные - переходными.

не совсем. почитайте https://www.drupal.org/core/release-cycle-overview .

Аватар пользователя goodboy goodboy 18 ноября 2016 в 13:22

Разговор начался с обновления безопасности друпала. ТС посетовал, что доколе будут дыры, а тем более, одинаковые дыры 7 и 8. Я и предположил, что это должно закончиться, когда процедурное наследие уйдет из друпала. Про переходы - я лично с 6 на 7 версию перескочил довольно легко и безболезненно, разница не такая большая. Анонсируется, что переход с 8 на 9 будет таким же простым. В восьмерке может сделали 90% всей тяжелой, но необходимой работы. Но изменений так много и так это надолго затянулось, что приняли решение выпустить 8, а чистая версия уже будет 9. Я могу спросить в той старой статье на drupal.org, все ли в силе, что декларировалось, может действительно это шутка.

Про четные-нечетные версии продуктов - это более широкое понятие. Вы устанавливали PHP 6, например? Связано с тем, что делается первая версия, потом вторая становится плацдармом к третьей и т.д. Борланд помнится, таким страдал, я пользовался только нечетными версиями. Отсюда предубеждение про четные версии. Да, может с друпалом это не так.

Аватар пользователя gun_dose gun_dose 18 ноября 2016 в 13:27

Ага, чётные версии - это вы майкрософту расскажите. Или убунту, у которых все лтс - тоже чётные.

Что касается неполного отказа от хуков: тут всё просто - если переписать всё с нуля и сделать совершенно по-новому, то все коммерческие разработчики с большой долей вероятности спрыгнут на что-то более знакомое им.

Аватар пользователя gun_dose gun_dose 18 ноября 2016 в 22:37

В убунту версия - это год и месяц релиза. И публикация лтс релизов в апреле чётного года - это чистая формальность.

Аватар пользователя sergeybelya sergeybelya 18 ноября 2016 в 13:36

Все верно, в этой статье есть упоминание об этом - http://internetdevels.ua/blog/interview-with-andypost-about-drupal-8 - https://s3.amazonaws.com/scrstorage/852px929256o26.jpg. К сожалению, internetdevels убрали русскую версию с сайта, я еще успел прочитать.

Аватар пользователя multpix multpix 18 ноября 2016 в 0:45

может мне изменяет память, или это прикол такой был,
но в публикациях на орг - 9.x ветка появилась летом 12-го, а 8.x - летом 13-го.

Аватар пользователя multpix multpix 17 ноября 2016 в 17:54
Аватар пользователя adubovskoy adubovskoy 17 ноября 2016 в 18:41
2

Таким образом вы предполагаете что написанный вами код лучше. Окей, не спорю. Но если проект сложный - то это означает что вы предполагаете что код всей вашей команды лучше, включая моменты смены сотрудников и т.п.. Вы очень оптимистичны.

Аватар пользователя multpix multpix 17 ноября 2016 в 18:53

При всем уважении,

adubovskoy wrote:

Таким образом вы предполагаете что написанный вами код лучше.

здесь именно вы делаете весьма натянутое предположение о смысле вышесказанного.

Я в свою очередь просто скажу:
когда любая команда сопровождает свой код, а сообщество пользователей предоставляет отчеты о багах,
это лишь способствует повышению качества программного продукта.

Ни о чем ваша реплика, Александр,
не ведет она к конструктивному диалогу,
прошу вас, не нужно на нашем форуме заниматься троллингом))

Аватар пользователя adubovskoy adubovskoy 17 ноября 2016 в 19:18
2

Нет, это именно аргумент про безопасность.

Очень часто пользователи видят новость об уязвимости и тут их можно подловить и сказать "поэтому продукт плохой". Но часто, желая получить продукт того же качества, заказывая его у команды, качество которой они не могут отследить, они получают значительно более дырявый продукт чем тот что на готовой платформе.

У нас есть некоторая внутренняя статистика по хостингу, где видно что друпал не ломают, а самопис - иногда очень даже, доходило до смешного когда на некоторых формах не было валидации на пользователя и туда приходили боты. Конечно, когда заказчик заметил и предоставил отчет о багах, это поспособствовало повышению качества программного продукта.

Аватар пользователя multpix multpix 17 ноября 2016 в 20:02

Мне ли вам говорить, что использование "готового" продукта никоим образом не гарантирует
безопасность конкретного проекта в котором он используется?

В контексте разработки на базе drupal, его самыми узкими местами по безопасности
являются как раз непосредственные администратор(ы) и разработчик(и) конкретного сайта.

По моей статистике, я наблюдал самый высокий риск ошибок у групп,
использующих win и/или знакомых "только с друпал".
Почему так - имхо: win не стимулирует развитие ит грамотности,
"только что-то" сужает кругозор.

Аватар пользователя void void 17 ноября 2016 в 21:15

А может кто по русски описать суть проблемы, устраненной в новых версиях? На сколько это опасно для не обновленных сайтов. Май инглишь из вери бэд Sad Прочитал на друогре но не понял ((

Аватар пользователя multpix multpix 17 ноября 2016 в 21:56

Уровень "умеренно критический" это не "сверх критический",
но предполагается возможность удаленного использования бага.

проще сделать в три мин. drush up и спокойно спать.
но я не нагнетаю - не критично.
а перевести несколько абзацев с енгл., только на пользу))

Аватар пользователя void void 17 ноября 2016 в 22:04

Много сайтов, много хостингов (клиентских). В больше половины про драш могут только спросить: "это где растет или вы так меня обидеть хотите".

Аватар пользователя goodboy goodboy 17 ноября 2016 в 22:37

О как, я думал я один такой. Странно, что вам не посоветовали гнать в шею клиентов, у которых на хостинге нет ssh. У меня вот последний клиент, на хостинге с ssh - я только ломанулся ставить драш, а оказывается в течение тестового периода он недоступен. Весь теперь в непонятках.

Аватар пользователя negociant negociant 23 ноября 2016 в 16:40

Все же расписано на оф. сайте https://www.drupal.org/SA-CORE-2016-005
«Inconsistent name for term access query (Less critical - Drupal 7 and Drupal Dirol

Drupal provides a mechanism to alter database SELECT queries before they are executed. Contributed and custom modules may use this mechanism to restrict access to certain entities by implementing hook_query_alter() or hook_query_TAG_alter() in order to add additional conditions. Queries can be distinguished by means of query tags. As the documentation on EntityFieldQuery::addTag() suggests, access-tags on entity queries normally follow the form ENTITY_TYPE_access (e.g. node_access). However, the taxonomy module's access query tag predated this system and used term_access as the query tag instead of taxonomy_term_access.

As a result, before this security release modules wishing to restrict access to taxonomy terms may have implemented an unsupported tag, or needed to look for both tags (term_access and taxonomy_term_access) in order to be compatible with queries generated both by Drupal core as well as those generated by contributed modules like Entity Reference. Otherwise information on taxonomy terms might have been disclosed to unprivileged users.

Incorrect cache context on password reset page (Less critical - Drupal Dirol

The user password reset form does not specify a proper cache context, which can lead to cache poisoning and unwanted content on the page.

Confirmation forms allow external URLs to be injected (Moderately critical - Drupal 7)

Under certain circumstances, malicious users could construct a URL to a confirmation form that would trick users into being redirected to a 3rd party website after interacting with the form, thereby exposing the users to potential social engineering attacks.

Denial of service via transliterate mechanism (Moderately critical - Drupal Dirol

A specially crafted URL can cause a denial of service via the transliterate mechanism.»
Если хотите друпал тестировать, то устанавливайте последние версии с закрытыми уязвимостями.