Обратная сторона систем распространения приложений в обход дистрибутивов
16 июня 2016 года
Кайл Кин (Kyle Keen), один из мэйнтейнеров дистрибутива Arch Linux, обратил внимание на проблемы, связанные с внедрением систем самодостаточного распространения приложений для Linux, таких как продвигаемая компанией Canonical технология snap. По мнению Кайна, идея прямой сборки и поставки пакетов разработчиками приложений может привести к проблемам с качеством и безопасностью.
Мэйнтейнеры пакетов в дистрибутиве не только выполняют техническую работу по сборке, но и являются важным связующим звеном, не допускающим вольностей со стороны поставщиков ПО и способным самостоятельно решить проблему, не дожидаясь её устранения в основном проекте. Мэйнтейнеры помогают избежать проблем в ситуации неадекватных решений разработчиков, таких как прекращение поставки важных возможностей, встраивание недопустимой функциональности (например, показ рекламы, майнинг биткоинов, включение кода для передачи статистики третьим лицам) или удаление пакетов из репозитория (например, случай с удалением из npm).
Кайл полагает, что наблюдаемое ныне добропорядочное поведение upstream-проектов лишь следствие строгого контроля со стороны мэйнтенеров дистрибутивов. Именно поэтому в Linux не наблюдается наводнение сборками, содержащими шпионские и рекламные вставки, а также бесцеремонно внедряющимися в другие приложения, например, без спроса устанавливающие свои панели и плагины в web-браузеры.
Кайл Кин попытался выделить основные мифы, связанные с выгодами прямой поставки ПО:
- Утверждение: Изоляция приложения в sandbox-контейнере позволит защититься от недобросовестных поставщиков.
Реальность: Изоляция блокирует лишь часть угроз, но не может ограничить этические злоупотребления. Возможно мэйнейнеры могут не заметить некоторые технические ошибки, которые будут блокированы в sandbox, но они точно заметят уловки нечистых на руку производителей (например, мэйнтейнер не согласится принять мобильное приложение с реализацией фонарика или темы оформления, требующих доступа к сети и телефонии);
- Утверждение: Мэйнтейнер является дополнительным промежуточным звеном, замедляющим доведение до пользователя устранений уязвимостей;
Реальность: Часто мэйнтейнеры выпускают исправления раньше, чем выходит обновление от производителя, особенно если проблема выявлена в совместно используемых библиотеках. Дистрибутив может в один заход решить проблему во всех приложениях, использующих уязвимую библиотеку, просто обновив это библиотеку в системе, без ожидания когда производитель пересоберёт свою программу (многие атаки совершаются из-за поставки в составе программы устаревших библиотек).
- Утверждение: Универсальные пакеты позволят производителям не заботиться об особенностях каждого дистрибутива.
Реальность: Производители и без того не учитывают особенности дистрибутивов, так как эту работу берут на себя мэйнтейнеры пакетов, а производителям остаётся рассмотреть включение в upstream предложенные мэйнтейнерами исправления. Более того, мэйнтейнеры берут на себя достаточно большую работу по поддержке пользователей, снимая с производителей нагрузку по первичной обработке сообщений об ошибках и позволяя заниматься работой, а не выяснением многочисленных деталей почему программа у пользователя работает не так как ему хочется.
- Утверждение: Каталоги-магазины приложений (App Stores) являются реинкарнацией традиционных репозиториев дистрибутивов - централизованное размещение программ, удобный поиск, простая установка и автоматические обновления.
Реальность: Отсутствие поддержки системы зависимостей, непригодность для распространения системных программ и автоматизированные проверки, не исключающие добавление вредоносного ПО;
- Утверждение: Достаточно создать каталог-магазин приложений и миллионы разработчиков наполнят его своими программами.
Реальность: Смартфоны появились в ситуации большой нехватки приложений. Пользователей сразу стало очень много и только потом подтянулись разработчики со своими предложениями программ. В таких условиях разработчикам сходило с рук встраивание вредоносных функций, рекламы и кода для отслеживания пользователей;
- Утверждение: Унифицированный формат пакетов поможет увеличить качество программ в Linux, так как позволит снять нагрузку по подготовке отдельных пакетов для каждого дистрибутива.
Реальность: Простота создания пакетов никак не может повлиять на качество ПО, так же как замена рукописного текста использованием клавиатуры не может повысить грамотность. Решение проблемы очень простое - достаточно написать хорошую программу и открыть её код, и каждый дистрибутив сам создаст для себя пакеты.
- Утверждение: Самостоятельный выпуск пакетов разработчиками программ снизит дублирование работы между дистрибутивами.
Реальность: Разные дистрибутивы существуют из-за разных предпочтений пользователей. Например, пользователи Puppy Linux хотят чтобы из программы было вырезано всё лишнее и были применены все возможные оптимизации. В Live-дистрибутивах для увеличения срока службы Flash требуется отключить автозапись. Пользователи Ubuntu хотят получить максимум функциональности и плагинов. Пользователи LFS и Gentoo предпочитают самостоятельно собрать программу из исходных текстов.
Само по себе создание пакета не составляет труда. Основные усилия уходят на исправление ошибок, которые остаются неисправленными в основном проекте, и, так как патчи общедоступны, они вполне успешно совместно используются разными дистрибутивами;
- Утверждение: Можно избежать многих ошибок, так как разработчик лучше разбирается в своей программе и более опытен, чем мэйнтейнер.
Реальность: Чтобы не оскорбить разработчиков, Кайл Кин предложил поверить ему на слово, что это не всегда так, и предпочёл не приводить конкретные примеры.
- Утверждение: Прямая поставка ПО от производителя не содержит лишних звеньев в цепочке доверия и лучше для пользователей.
Реальность: Это справедливо до тех пор, пока сам производитель не решит добавить что-нибудь. Те, кто не доверяет мэйнтейнерам, могут самостоятельно проверить их работу, повторив сборку. Выявить вносимые дистрибутивом изменения значительно проще, чем выявить скрытые изменения производителя.
Источники
править
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.