Основатель Anchor Hosting Остин Гиндер раскритиковал хостинг-компании за пренебрежение к тестированию главных релизов WordPress на реальных сайтах клиентов, утверждая, что инцидент с фатальной ошибкой WP Rocket, последовавший за выпуском WordPress 7.1 на прошлой неделе, является доказательством того, что хостинги не выполняют свою работу должным образом.
«Ни один веб-хостинг не тестирует ничего заранее», — рассказал Гиндер. – «Нет никаких причин отказываться от этого, но они просто плюют на все».
Гиндер, который в этом году стал довольно популярной фигурой в сфере безопасности WordPress благодаря своим громким открытиям, вчера опубликовал в блоге статью, в которой изложил свою точку зрения по данному вопросу. Он утверждает, что если бы хостинги (хотя бы один из них) тестировали WordPress 7.1 с реальным стеком плагинов во время бета-цикла, кто-нибудь обнаружил бы проблему совместимости WP Rocket еще до того, как она привела к сбоям.
Из 332 сайтов в сети Гиндера, работающих с WP Rocket, 124 перестали функционировать после обновления WordPress до версии 7.1. Для возникновения ошибки требовалось три условия: WordPress 7.1, WP Rocket и третий плагин – к примеру, Elementor Pro, который регистрирует целочисленные ключи фильтра. Сам по себе WP Rocket прекрасно работал с 7.1, но такое сочетание приводило к фатальной ошибке. Проблема была выявлена еще 6 июля, когда был открыт тикет на GitHub, во время бета-цикла, но оставалась без внимания в течение 6 недель.
Гиндер заявил, что критика в адрес WP Rocket была необоснованной: разработчики плагинов не имеют представления о том, как их код взаимодействует со всем спектром рабочих сред. Хостинги, напротив, обладают такой информацией.
«Авторы плагинов находятся в наихудшем положении, поскольку у них нет достаточных сведений. Хостинги же собирают огромный массив данных, но ничего с ним не делают», — добавил Гиндер.
Он назвал GoDaddy и Pressable примерами хостингов, которые должны публично делиться результатами своих собственных тестов, и заявил, что отсутствие каких-либо отчетов от хостингов по проблеме WP Rocket в GitHub является для него достаточным доказательством.
«Я самый маленький игрок здесь, и я вижу проблемы, а никто другой об этих проблемах почему-то не сообщает», — добавил он.
Сайдлоадинг ядра для тестирования релизов
Гиндер не просто выявил пробел – он разработал решение: bash-скрипт, который устанавливает следующий релиз ядра WP прямо на рабочий сайт, который уже имеет активированные плагины, тему и БД. Скрипт запускает новое ядро, выполняет проверку WP-CLI, отправляет curl-запрос к главной странице через localhost хоста и отслеживает фатальные ошибки PHP. Если что-то сломается, рабочий сайт останется нетронутым.
Гиндер опубликовал свой скрипт в открытом доступе, и в настоящее время он работает с Kinsta и Rocket.net, но может быть адаптирован и к другим хостингам.
Он отметил, что его подход решает реальную техническую проблему, которую тестовые среды не способны устранить. К примеру, клонирование ecommerce-сайта в тестовую среду чревато рисками срабатывания платежных процессоров, отправки email и другими побочными эффектами; подход с сайдлоадингом же позволяет протестировать реальную продакшн-среду без какого-либо влияния на клиентов.
Однако Гиндер признал, что одних инструментов недостаточно. Хостингам нужны люди, которые будут обрабатывать выявленные инструментами проблемы, к примеру, сбои триажинга, отправку баг-репортов авторам плагинов и т. д. «Потому здесь мы имеем еще и проблему персонала».
Проблема, о которой уже осведомлены разработчики ядра
Комментарии Гиндера лишний раз подсветили проблему, с которой уже борются разработчики ядра. На конференции WordCamp Europe в июне разработчики ядра обсуждали то, что в протоколе встречи было названо «хроническими проблемами с тестированием и обратной связью»; они отметили, что «слишком мало сайтов тестируют бета-версии/RC-версии для каждого релиза».
Вскоре после инцидента с WP Rocket независимый разработчик ядра Адам Сильверстайн предложил рабочий процесс GitHub Actions, который автоматически тестировал бы 100 самых популярных плагинов из каталога WordPress.org на невыпущенных версиях WP. Эта задача была включена в план разработки WordPress 7.2. Сильверстайн признал, что такой подход не выявил бы проблему с WP Rocket, поскольку это платный плагин, но отметил, что аналогичная фатальная ошибка может возникнуть в любом из бесплатных плагинов с WordPress.org.
Подход Гиндера устраняет пробел иного рода. Сильверстайн тестирует бесплатные плагины в CI. Гиндер же тестирует реальные продакшн-стеки с реальными данными, включающими премиум-плагины, кастомный код и специфические конфигурации, существующие только на лайв-сайтах.
Хостинги «сами заинтересованы в этом»
Начиная с марта, Гиндер раскрыл информацию о четырех атаках на цепочку поставок плагинов за один месяц, отследил 13-летнюю кампанию по внедрению бэкдоров и обнаружил критическую уязвимость RCE в Elementor Pro, которая принесла ему 15 600 долларов от Wordfence. При этом сам он поддерживает почти 3 000 сайтов WordPress.
На вопрос о том, чего бы он хотел добиться в плане тестирования WordPress, Гиндер ответил прямо.
«Нужно просто публично пристыдить хостинги. Все указывают пальцем на WP Rocket, но нет, у этой компании нет огромного массива данных – а у хостингов он есть. Хостинги заинтересованы в таком тестировании, но не делают его. Потому их нужно призвать к ответу. Это гораздо продуктивнее, чем критиковать авторов плагина, допустивших ошибку».
Гиндер добавил, что хостинги, которые заблаговременно тестируют релизы ядра на своих серверах, могут выявлять баги в плагинах и передавать информацию их разработчикам, что позволит снизить нагрузку на свою службу поддержки и увеличить качество услуг.
