Как обижаются программисты
Эта красивая абстрактная штука — граф зависимостей, он показывает, сколько пакетов устанавливает один только npm
Мы часто используем в своих проектах утилиты и библиотеки с открытым исходным кодом. В расчете на своевременное обновление эти ресурсы не включаются в проекты, а подключаются из разных репозиториев. Например, на многих ресурсах используются шрифты из Google Fonts или библиотеки скриптов вроде jQuery.
Эти ссылки включаются в проекты программистами почти автоматически, а многие ресурсы требуют предустановленных фреймворков и библиотек. Да, это удобно и быстро, однако такая практика может привести к нехорошим ситуациям.
«Раз в 1000 лет и палка стреляет»
В марте этого года случилась довольно неожиданная ситуация, связанная с одним из довольно известных пакетных менеджеров — Kik. Главным действующим лицом ситуации стал программист Азер Кочулу, на счету которого более 250 опубликованных open source утилит. Юрист фирмы Kit просил переименования утилиты kik, распространяемой Кочулу через NPM (Node.js), настаивая на том, что Kik — зарегистрированный знак. Кочулу в резкой форме отклонил требование. Позже с ним уже связалось руководство компании, отвечающее за работу NPM, с предложением пойти на компромисс в данной ситуации, но и тут согласия не было достигнуто. Разработчик настаивал на своём названии. В результате утилите изменили название без разрешения её создателя.
На странице в medium.com программист написал о том, что он «понял, что NPM — место, где корпорации сильнее людей. Когда я создавал ПО, я не знал об одноименной компании. Я люблю open source, но NPM больше не будет тем местом, где я буду размещать свои разработки». После чего разработчик удалил 272 опубликованных пакета.
Последствия были весьма неожиданными и не заставили себя долго ждать: посыпались проекты, которые зависели от этих утилит. За ними — следующие зависимые от пострадавших и далее связанные с ними. Данный эффект домино наблюдали и фиксировали в больших количествах администраторы NPM. Самое большое количество ошибок вызвала простая функция, написанная на JavaScript — left-pad. Она заполняла нулями или пробелами левую часть в строке. Функцией пользовались также в Babel и в самом Node. И даже после опубликования копии left-pad неким героем, последствия устраняли порядка 2-х часов. Данные о понесенных убытках с трудом можно себе представить.
«Пока гром не грянет…»
Так как данный коллапс затронул много областей, это активизировало деятельность многих умов и заставило других людей обратить внимание на имеющиеся проблемы. К примеру, инженер из Google Сэм Сакконе (Sam Saccone) обнаружил уязвимость в том, что к катастрофе может привести не только удаление пакетов из NPM, но и добавление вредоносных вариантов тоже может вызвать коллапс. Обнаруженная уязвимость получила идентификатор в CERT, и была выявлена раньше, чем Кочулу совершил своё импульсивное действие, но только после него проблемой заинтересовались всерьез.
Инженеры npm не знают пока способов решения проблемы, потому как у компании просто отсутствуют необходимые ресурсы для проверки всего загружаемого кода и надеются на доброжелательность людей сообщества.
Выход и вывод
Нижеприведенные практические советы кому-то могут показаться паранойей, но, как показала практика, раз в тысячу лет и палка стреляет, а данная ситуация наглядно демонстрирует, насколько уязвимым и хрупким является то, что мы не задумываясь, автоматически применяем в работе.
Поэтому весьма полезно:
- иметь у себя копию того, что используешь в работе;
- своевременно бекапить, обновлять и сохранять копии и базы;
- четко продумывать безопасность ключевых областей, от которых зависит стабильность и надежность проектов и ресурсов;
- и уж конечно необходимо учитывать не только технические риски, но и человеческий фактор — сделать затруднительным или невозможным удаление тех областей, без которых могут пострадать другие связанные с ними части.
Теперь вы знаете, как делать нехорошо. Научиться делать правильно: курс по разработке на Node.js.