17 ноября 2016 в 16:44
В ядре Друпала с завидным постоянством продолжают находить дыры в безопасности, обновляйтесь:
https://www.drupal.org/blog/drupal-823-and-752-released
Очередные дыры Друпала
Главные вкладки
17 ноября 2016 в 16:44
Комментарии
Дыры есть везде. И когда их оперативно находят и есть устоявшийся механизм оповещения и реагирования, это лучше чем когда не находят) У друпала тут по сравнению с многими CMS куда лучше дела.
Я и не спорю. Но настораживает, что находят общие проблемы в ядрах семерки и восьмерки, что указывает на частичное использование старого кода в ядре 8-ки, что не есть хорошо.
Что значит не есть хорошо? Это основополагающий принцип прогресса - использовать старые наработки где-либо. В любой программе есть код из старых версий, в любой машине есть детали из предыдущих моделей. В том же линуксе нашли недавно уязвимость, которой лет 15 уже и которая успела попасть даже в андроид, хотя самого андроида и в помине не было, когда был написан уязвимый код.
Восьмерку представляли как абсолютно новый продукт и писали так долго, что могли бы весь код написать с нуля и отрефакторить. Сравнение с Линуксом не предсталвяется уместным, разного масштаба продукты. А тут уже не первый раз общие дыры в ядрах семерки и восьмерки.
Читал, что восьмерка переходная версия к девятке. Вот 9 будет полностью ООП, без хуков и без глюков.
Где читали?) Можно ссылочку?
На drupal.org где-то, ссылку не подскажу. А это не так на самом деле?
Да, есть мнение что это не так.
И ссылку на это мнение найду:
https://buytaert.net/drupal-8-0-0-released
https://www.ostraining.com/blog/drupal/drupal-9/
По первой ссылке - Дрис пишет, что Друпал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"
все верно. это ничего не говорит про "проходную систему". Drupal8 это значительный релиз, он довольно надолго, им можно и нужно пользоваться. D9 будет еще лучше, несомненно. Иначе, это значит что следует назвать D9 "проходным" по сравнению с D10 и так до бесконечности.
Покажите, где я в моем комментарии 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 и т.д. Как правило, нечетные версии являются стабильными, а четные - переходными.
ваша цитата "Читал, что восьмерка переходная версия к девятке. ", слово немного другое, да, ошибся) Но давайте не будем о словах конкретных. Я с тезисом не согласен. Вы намекаете на то что "восьмерка не готова". Да готова она, наметили план что выпилить к девятке, в девятке наметят план что выпилить к десятке и т.п.
>>Про версии D10 и т.д. Как правило, нечетные версии являются стабильными, а четные - переходными.
не совсем. почитайте https://www.drupal.org/core/release-cycle-overview .
Разговор начался с обновления безопасности друпала. ТС посетовал, что доколе будут дыры, а тем более, одинаковые дыры 7 и 8. Я и предположил, что это должно закончиться, когда процедурное наследие уйдет из друпала. Про переходы - я лично с 6 на 7 версию перескочил довольно легко и безболезненно, разница не такая большая. Анонсируется, что переход с 8 на 9 будет таким же простым. В восьмерке может сделали 90% всей тяжелой, но необходимой работы. Но изменений так много и так это надолго затянулось, что приняли решение выпустить 8, а чистая версия уже будет 9. Я могу спросить в той старой статье на drupal.org, все ли в силе, что декларировалось, может действительно это шутка.
Про четные-нечетные версии продуктов - это более широкое понятие. Вы устанавливали PHP 6, например? Связано с тем, что делается первая версия, потом вторая становится плацдармом к третьей и т.д. Борланд помнится, таким страдал, я пользовался только нечетными версиями. Отсюда предубеждение про четные версии. Да, может с друпалом это не так.
Ага, чётные версии - это вы майкрософту расскажите. Или убунту, у которых все лтс - тоже чётные.
Что касается неполного отказа от хуков: тут всё просто - если переписать всё с нуля и сделать совершенно по-новому, то все коммерческие разработчики с большой долей вероятности спрыгнут на что-то более знакомое им.
Убунту, видимо, с нулевой версии считает.
В убунту версия - это год и месяц релиза. И публикация лтс релизов в апреле чётного года - это чистая формальность.
Все верно, в этой статье есть упоминание об этом - http://internetdevels.ua/blog/interview-with-andypost-about-drupal-8 - https://s3.amazonaws.com/scrstorage/852px929256o26.jpg. К сожалению, internetdevels убрали русскую версию с сайта, я еще успел прочитать.
https://www.drupal.org/project/drupal/releases?api_version%5B%5D=39794
глянь на дату релиза))
Как только начнут работать над D9, появится ветка 10x, это всегда так)
может мне изменяет память, или это прикол такой был,
но в публикациях на орг - 9.x ветка появилась летом 12-го, а 8.x - летом 13-го.
ой, и правда.... tnx!)
Везде))
https://www.cvedetails.com/vendor/3496/Joomla.html
https://www.cvedetails.com/vendor/3116/Bitrix.html
(вот тут не понятно - у них в 16 все хорошо или просто заби(ы)ли)
https://www.cvedetails.com/product/18211/Djangoproject-Django.html
https://www.cvedetails.com/vendor/12043/Rubyonrails.html
https://www.cvedetails.com/product/2387/Drupal-Drupal.html
Таким образом вы предполагаете что написанный вами код лучше. Окей, не спорю. Но если проект сложный - то это означает что вы предполагаете что код всей вашей команды лучше, включая моменты смены сотрудников и т.п.. Вы очень оптимистичны.
При всем уважении,
здесь именно вы делаете весьма натянутое предположение о смысле вышесказанного.
Я в свою очередь просто скажу:
когда любая команда сопровождает свой код, а сообщество пользователей предоставляет отчеты о багах,
это лишь способствует повышению качества программного продукта.
Ни о чем ваша реплика, Александр,
не ведет она к конструктивному диалогу,
прошу вас, не нужно на нашем форуме заниматься троллингом))
Нет, это именно аргумент про безопасность.
Очень часто пользователи видят новость об уязвимости и тут их можно подловить и сказать "поэтому продукт плохой". Но часто, желая получить продукт того же качества, заказывая его у команды, качество которой они не могут отследить, они получают значительно более дырявый продукт чем тот что на готовой платформе.
У нас есть некоторая внутренняя статистика по хостингу, где видно что друпал не ломают, а самопис - иногда очень даже, доходило до смешного когда на некоторых формах не было валидации на пользователя и туда приходили боты. Конечно, когда заказчик заметил и предоставил отчет о багах, это поспособствовало повышению качества программного продукта.
Мне ли вам говорить, что использование "готового" продукта никоим образом не гарантирует
безопасность конкретного проекта в котором он используется?
В контексте разработки на базе drupal, его самыми узкими местами по безопасности
являются как раз непосредственные администратор(ы) и разработчик(и) конкретного сайта.
По моей статистике, я наблюдал самый высокий риск ошибок у групп,
использующих win и/или знакомых "только с друпал".
Почему так - имхо: win не стимулирует развитие ит грамотности,
"только что-то" сужает кругозор.
Ага)
А может кто по русски описать суть проблемы, устраненной в новых версиях? На сколько это опасно для не обновленных сайтов. Май инглишь из вери бэд
Прочитал на друогре но не понял ((
https://www.drupal.org/SA-CORE-2016-005
https://www.drupal.org/security-team/risk-levels
Если не хочешь в это вникать, просто обновись)
"просто обновись"... скажите пожалуйста мне всю ночь не спать о_О или можно пойти отдохнуть?..
Уровень "умеренно критический" это не "сверх критический",
но предполагается возможность удаленного использования бага.
проще сделать в три мин. drush up и спокойно спать.
но я не нагнетаю - не критично.
а перевести несколько абзацев с енгл., только на пользу))
Много сайтов, много хостингов (клиентских). В больше половины про драш могут только спросить: "это где растет или вы так меня обидеть хотите".
О как, я думал я один такой. Странно, что вам не посоветовали гнать в шею клиентов, у которых на хостинге нет ssh. У меня вот последний клиент, на хостинге с ssh - я только ломанулся ставить драш, а оказывается в течение тестового периода он недоступен. Весь теперь в непонятках.
жаль, много придется делать в ручную.
естественно, это лучше делать на свежую голову.
Приличные клиенты давно отрастили себе ssh
Действительно приличные клиенты обновляют свои сайты самостоятельно)
Если они обновляют, то ssh есть
Насколько критичны узявимости, кто подскажет? Думаю протестировать друпал на одном сайте.
Все же расписано на оф. сайте https://www.drupal.org/SA-CORE-2016-005
«Inconsistent name for term access query (Less critical - Drupal 7 and Drupal
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
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
A specially crafted URL can cause a denial of service via the transliterate mechanism.»
Если хотите друпал тестировать, то устанавливайте последние версии с закрытыми уязвимостями.