Почему я сворачиваю свою работу над Debian
От переводчика: этот текст — перевод записи в личном блоге Михаэля Штапельберга (Michael Stapelberg) видного open source-разработчика (профиль GitHub), который внес значительный вклад в развитие Debian.
Этот пост было сложно написать с эмоциональной точки зрения, но я и не ограничился «коротким письмом, потому что у меня не было времени». Пожалуйста, перед прочтением этого текста учтите, что пишу я его с лучшими намерениями и не ставлю себе целью демотивировать или принизить вклад кого-то из разработчиков. Скорее, я хочу объясниться, почему мой уровень разочарования превысил все допустимые значения.
Debian был частью моей жизни на протяжении 10 лет.
Несколько недель назад, на посвященной Debian встрече, проходившей в Цюрихе, я встретился со своими старыми друзьями, которых не видел много лет. Когда я уже ехал домой на велосипеде, меня осенило, что все обсуждаемые нами темы так или иначе сводились к тому, что мы обсуждали с ними в прошлый раз. Мы дискутировали о достоинствах systemd, который вновь привлек внимание участников open source сообщества, затронули тему процессов в Debian. Кульминацией стало обсуждение демократии как таковой и соответствующие теоретические и практические ошибки. Но, на самом деле, это уже чисто швейцарская тема.
Это не обзор прошедшего митапа, я просто хочу объяснить, что побудило меня задуматься о своем текущем отношении к Debian и подходит ли он мне.
Итак, я принял решение, которое должен был принять давно: я сворачиваю свое участие в развитии Debian.
Что это значит?
В ближайшие недели произойдет следующее:
Если у вас возникнут вопросы или какие-то задачи, считайте, что я в бессрочном отпуске. Я постараюсь принимать участие в каких-то административных вопросах (например, передачи разрешений) и задачах, адресованных лично мне, но только если это не займет много времени.
Почему?
Когда я только присоединился к работе над Debian, я еще учился, то есть у меня было много свободного времени. Теперь, спустя пять лет работы фулл-тайм, я многому научился — как в плане того, как и что работает в крупных проектах по разработке программного обеспечения, так и в плане понимания своих личных предпочтений в компьютерных системах. Сейчас я четко отдаю себе отчет в том, на что я трачу ту небольшую часть свободного времени и что у меня остается в конце дня.
Каждый из следующих разделов будет посвящен вещам, причиняющим мне как разработчику боль. Список этот приводится в произвольном порядке. Некоторые из этих проблем влияют друг на друга, например — если бы изменения системы проводились качественнее, у нас был бы шанс на то, что пакеты будут легче обрабатываться машиной.
Процесс изменений в Debian
Последние несколько лет моя текущая команда работала над различными реорганизациями по всей кодовой базе (затрагивая тысячи проектов), поэтому мы получили множество ценных уроков, как эффективно эти изменения вносить. Меня раздражает то, что Debian во всех смыслах работает практически противоположным образом. Я ценю то, что каждый проект отличается, но я думаю, что многие далее перечисленные мою пункты применимы к Debian целиком.
В Debian разработка пакетов направляется в нужное русло с помощью документа, который называется «Debian Policy», либо же его программным вариантом «Lintian».
Несмотря на то, что lint очень удобен для получения быстрого прямого или локального/автономного фидбека, еще лучше вообще не требовать пользоваться таким инструментом. Например, команда C++, которая вводит новый флаг защиты для всех пакетов, должна быть в состоянии сделать свою работу прозрачной и для меня (судя по профилю GitHub, основным языком Михаэля является Go, — прим. пер.).
Вместо этого сейчас все пакеты делаются «грязно» (ориг. — lint-unclean): все сопровождающие должны прочитать, что это за новая вещь, как она может сломаться, влияет ли она на их работу вообще и если да, то как именно. Потом надо вручную запустить некоторые тесты и, наконец, отказаться от изменений. Все это — множество накладных и выполняемых вручную механических операций между пакетами.
В модели Debian решение о раскатке новинки ложится на сопровождающих пакетов, а не на разработчиков. На моей основной работе мы обнаружили, что эффективнее делать наоборот: если написанное изменение затрагивает значительную часть пользователей, то именно разработчики должны принимать решение о необходимости его внедрения. Такой подход делает развитие проекта более эффективным и сокращает временные и трудозатраты. Конечно, существуют исключения, например, на крупных участках, где используются языковые фишки, о которых должны позаботиться соответствующие владельцы-кураторы, но важно то, что по умолчанию все должно быть иначе, нежели есть сейчас.
В Debian отсутствуют инструменты для внесения крупных изменений: программно сложно работать с раздробленными пакетами и репозиториями (об этом детальнее в разделе ниже). Наиболее близким событием к дефолтной «отправке изменения на ревью» является процесс открытия баг-репорта с прикрепленным к нему патчем. Мне казалось, что существующий процесс принятия баг-фикса слишком сложен, и я начал работать над мерж-ботом, но интерес к нему проявил только Гвидо и никто больше (по всей видимости, автор говорит о Гвидо agx Гюнтере, еще одном Debian-разработчике, — прим. пер.).
Если выражаться литературно, то реакция на пуши и, соответственно, получение обратной связи проходят медленно. Там просто нет сроков. Иногда я получаю электронные письма, уведомляющие меня о том, что отправленный мною несколько лет назад (. ) патч наконец-то смержили. Это растягивает недельные проекты на много лет, что для меня является мощным демотиватором.
Любопытно отметить, но практика черепашьей онлайн-активности проецируется и на офлайн-культуру, а я не хочу обсуждать достоинства systemd спустя 10 лет после того, как впервые услышал о нем.
Ну и наконец, любые изменения могут быть застопорены несогласными, которые в итоге отказываются идти на сотрудничество. Мой каноничный пример подобной ситуации — rsync. Куратор отказался от моих патчей, добавляющих в пакет поддержку debhelper, исключительно из собственных убеждений.
Предоставление такой степени личной свободы отдельным сопровождающим мешает всем нам, участникам проекта, повысить уровень абстракции сборки Debian, что, в свою очередь, усложняет инструментарий разработки.
Как бы все это выглядело в идеальном мире?
Фрагментированный рабочий процесс и инфраструктура
Обычно Debian предпочитает децентрализованные подходы, а не централизованные. Например, отдельные пакеты хранятся в отдельных репозиториях, а каждый репозиторий может использовать любой SCM (обычно git и svn) или вообще не использовать. Плюс, каждый репозиторий может быть размещен на любом сайте. Конечно, и содержимое каждого репозитория также слегка различается от команды к команде, да даже и внутри команды.
На практике нестандартные варианты хостинга используются достаточно редко, так как они не оправдывают свою стоимость, но достаточно часто, чтобы причинять огромную боль при попытках автоматизировать процесс внесения изменений в пакеты. И вот вместо того, чтобы использовать API GitLab для создания запросов на мерж, вам надо разработать совершенно другую, более сложную систему, которая работает с периодически (или постоянно!) недоступными репозиториями, абстрагирует различия в доставляемых патчах (отчеты об ошибках, запросы на слияние, запросы на извлечение) и прочее, и прочее…
Радикально отличающиеся процессы разработки — это не просто проблема пустой траты рабочего времени. Я участвовал в долгих разговорах о различных процессах разработки git во времена DebConf 13 и понял, что и тогда велись подобные дискуссии.
Лично я не могу держать в голове достаточно подробностей о различных методологиях разработки. Каждый раз, когда я прикасаюсь к пакету, который работает не так, как мой, я очень расстраиваюсь, потому что мне приходится заново изучать аспекты его работы.
Я заметил подобную фрагментацию рабочего процесса в моей собственной команде по пакетированию Go и попытался исправить это с помощью внесения предложений об изменениях в workflow, но не смог их реализовать. Отсутствие эффективной автоматизации и малый темп изменений в инструментарии, несмотря на мою готовность тратить собственное время и энергию, убивали любую мотивацию.
Устаревшая инфраструктура: загрузка пакетов
Когда вы хотите сделать пакет доступным в Debian, вы загружаете файлы с подписью GPG через анонимный FTP. Существует несколько видов заданий (the queue daemon, unchecked, dinstall и другие), которые выполняются по фиксированному расписанию (например, dinstall выполняется в 01:52 UTC, 07:52 UTC, 13:52 UTC и 19:52 UTC).
Я подсчитал, что в зависимости от времени суток вы можете подождать более 7 часов (. ), прежде чем ваш пакет будет установлен.
Но хуже всего для меня то, что обратная связь асинхронна относительно загрузки. Мне нравится что-то сделать, покончить с этим и перейти к следующему заданию. Текущая настройка требует длительного ожидания и, по сути, дорогостоящего переключения между задачами без веских на то технических причин. Вы можете заметить, что несколько минут не имеют большого значения, но когда все время за день, которое я могу потратить на Debian, измеряется минутами, это имеет огромное значение для восприятия собственной производительности и удовлетворенности от проделанной работы.
Последнее сообщение, которое я могу найти об ускорении этого процесса — пост Георга Ganneff Яспирта от 2008 года.
Как бы все это выглядело в идеальном мире?
Устаревшая инфраструктура: багтрекер
Я боюсь взаимодействовать с трекером ошибок Debian. Debbugs — это кусок кода прямиком из 1994 года, который сейчас используется только Debian и проектом GNU.
Процессы Debbugs основаны на использовании электронной почты, то есть проходят асинхронно и громоздко. Несмотря на то, что он работает на самых быстрых машинах, которые мы имеем на проекте Debian (ну так мне сказали, когда эта тема в последний раз поднималась), его веб-интерфейс загружается крайне медленно.
Примечательно, что веб-интерфейс на bugs.debian.org доступен только для чтения. Настроить рабочую зону электронной почты для reportbug (1) или вручную работать с вложениями — довольно серьезный челлендж.
По каким-то причинам, которых я не понимаю, каждое взаимодействие с debbugs приводит к созданию множества цепочек писем.
Помимо технической реализации я также никак не могу запомнить различные способы, в рамках которых Debian использует псевдопакеты генерации для ошибок и процессов. Нужны они мне слишком редко, чтобы я наконец-то уложил это все в голове и запомнил, как именно они функционируют и используются, но я периодически с ними сталкиваюсь, так что это разнообразие раздражает.
Как бы все это выглядело в идеальном мире?
Устаревшая инфраструктура: архивы email-переписок
Меня сбивает с толку тот факт, что в 2019 году у нас по-прежнему нет удобного инструмента для просмотра архивных цепочек обсуждений в почте. Так широко, как в Debian, Email и цепочки писем нигде больше не используются, так что это даже несколько иронично. Использование Gmane вроде и решало эту проблему, но его доступность за последние несколько лет была, мягко говоря, урывистой (сейчас, на момент написания этого поста, он вообще не работает).
Я пытался создать многопоточный архив, но наши лист-мастеры не впечатлились и отказались поддерживать проект.
Машинам сложно работать с Debian
Хотя очевидно, что с пакетами Debian можно работать программно, этот опыт сложно назвать приятным. Все кажется медленным и громоздким. Я выбрал три небольших примера, чтобы проиллюстрировать мою позицию по этому вопросу.
debiman нуждается в помощи от piuparts в проведении анализа альтернативного механизма каждого пакета по отображению страниц документации, например, PSQL(1). Это потребовалось, так как сценарии модифицируют альтернативную базу через вызов shell-скриптов. Но без фактической установки пакета вы не узнаете, какие изменения он вносит.
pk4 должен поддерживать свой собственный кеш для поиска метаданных пакета на основе его имени. Другие инструменты анализируют базу данных apt с нуля при каждом вызове. Правильный формат базы данных или, по крайней мере, двоичный формат обмена будет иметь большое значение для этого процесса.
Debian Code Search хочет как можно быстрее получать новые пакеты. Раньше использовался инстанс fedmsg, но его больше не существует. Неясно, откуда получать уведомления о новых пакетах и где лучше всего их получать.
Сложный билд-стек
Тут можно просто почитать мой пост «Инструменты сборки пакетов Debian». Меня действительно беспокоит тот факт, что рост числа инструментов не считается проблемой.
Debian — это болезненный опыт для разработчика
Большинство поднятых мной вопросов касаются опыта разработки Debian, но, как я недавно описал в своем посте «Опыт дебага в Debian», опыт разработки с использованием Debian также оставляет желать лучшего.
У меня есть больше идей
Статья получилась достаточно объемной, но я надеюсь, вы получили приблизительное представление о моей мотивации.
Хотя выше я описал ряд конкретных недостатков, последний гвоздь в крышку гроба — это отсутствие позитивного прогноза на будущее. У меня есть другие идеи, которые кажутся мне действительно убедительными, но, исходя из того, как продвигались мои предыдущие проекты, я не думаю, что смогу реализовать что-либо из них в рамках проекта Debian.
Я намерен опубликовать еще несколько постов о конкретных способах по улучшению операционных систем в своем блоге. Так что заглядывайте.
Ну и наконец, я надеюсь, что этот пост вдохновит кого-нибудь, в идеале — группу людей, на то, чтобы сделать жизнь разработчиков Debian лучше.
Еще раз о deb пакетах
Подготовка
Чтобы начать создавать deb пакеты, нужно установить несколько пакетов:
Подготовка папки с исходниками
Для того, чтобы dh_make и другие утилиты могли работать с папкой с исходниками, нужно привести ее в специфичный вид.
Папка должна называться имяпакета-версия. Т.е. если у меня есть папка Plugins с программой версии 0.1, то я создаю папку с именем plugins-0.1.
Теперь нужно создать архив с этой папкой. Архив должен содержать в имени *.orig.tar.gz, т.е.:
Последний подготовительный шаг, это создание в папке с исходниками папки debian со множеством служебных файлов. Чтобы это сделать, нужно выполнить команду:
В процессе выполнения этой команды будет задан вопрос о том, какой тип архива мы создаем, самый простой это single.
Настройка пакета
Вся настройка пакета происходит путем редактирования файлов в каталоге debian. Рассмотрим те файлы, которые будем использовать:
changelog
Данный файл содержит историю изменения пакета и текущую версию пакета. Посмотрим на его содержимое:
В начале идет название пакета — libvksplugins, затем его версия. Версия делиться на две части символом «-». Первая часть показывает версию программы в пакете, вторая «ревизию» пакета. Ревизия это версия пакета, т.е. если раньше такого пакета не было, то ревизия равна 1. Если же пакет с такой версией программы уже был, но в нем произошли изменения, то ревизия увеличивается.
Слово unstable показывает, что пакет является не стабильным, т.е. он не был протестирован должным образом на машинах пользователей.
Надпись urgency=low показывает срочность изменения. Т.к. срочности нет, то значение равно low. Если бы, мы делали пакет для исправления серьезной уязвимости или ошибки, то значение можно было бы установить в high.
После первой строки идет пустая строка, а за ней первая запись:
В Debian, changelog используется для автоматического закрытия ошибок в системах отслеживания ошибок в программных продуктах. Т.к. в данном случае, я не использую такую систему, то эта строка принимает вид:
Последняя строка является подписью человека, сделавшего запись. В ней содержится имя и адрес, а также дата изменения.
После установки deb пакета, файл changelog устанавливается в
control
Файл debian/control является главным конфигом, при создании deb пакета. Вот пример такого файла:
Видно, что файл разбит на секции при помощи пустых строк. Каждая секция описывает один пакет, создаваемый из папки с исходниками. Рассмотрим их по порядку:
Source Данная секция говорит о том, что нужно создать пакет исходных кодов. Параметром указано libvksplugins, это значит, что пакет исходных кодов будет называться libvksplugins.
Priority Эта секция устанавливает приоритет пакета. Т.к. система может прекрасно обойтись без нового пакета, то значение секции установлено в optional. Т.е. этот пакет не обязателен для установки. Подробнее о приоритетах написано здесь.
Maintainer Эта секция описывает контакты человека, создающего пакет. Ее формат довольно прост и дополнительного описание не требует.
Build-Depends Одна из самых важных секций, устанавливающая зависимости пакета. Зависимости, указанные в данной секции должны быть выполнены, чтобы можно было собрать пакет. Т.е. список зависимостей для сборки и установки могут отличаться.
Видно, что в зависимостях стоят debhelper (>= 9), cmake. Зависимость debhelper (>= 9) ставиться для всех пакетов по умолчанию. Она нужна для корректной работы программ вида dh_*.
Второй элемент cmake был добавлен потому, что папка с исходниками содержала файл CMakeLists.txt, т.е. для сборки используется система сборки CMake. Для того, чтобы узнать, какие зависимости есть у программы, можно почитать ее документацию. Кроме этого, можно воспользоваться командой dpkg-depcheck. Данная команда должна запускаться так:
Но, т.к. при использовании CMake нет скрипта конфигурирования, то я использую ее так:
Из примечательных тут можно отметить:
cmake
qt4-qmake
libqt4-dev
Остальные являются зависимостями данных. Причем, cmake уже есть в списке зависимостей сборки. В принципе, можно его оставить как есть или указать используемую версию:
При этом в CMakeLists.txt указана версия cmake, которую нужно использовать:
Я думаю, что разработчику виднее, и поэтому указываю версию из CMakeLists.txt. Для Qt 4 все понятно с номерами версий, но для очистки совести проверим и их версии:
Т.е. для Qt 4 указываем версию 4.8.6:
Standards-Version Версия стандарта, в соответствии с которым создан файл. Это значение не нужно менять.
Section. Секция для пакета, т.е. группа пакетов, выполняющая одну задачу. В Политике Debian разделе 2.4 этот вопрос описан более подробно.
Homepage Домашняя страница проекта. Т.к. данный код писал я и у него нет страницы, просто удаляю эту строку.
Vcs-* Ссылки на репозитории проекта. Их у меня тоже нет, поэтому удаляю эти строки.
Другие пакеты После секции файла, где описывается пакет с исходниками, идут секции, которые описывают другие пакеты, создаваемые из пакета с исходниками. Схема создания пакетов:
Из схемы видно, что из исходников программы, я хочу получить 4 пакета:
Мой персональный ответ на данный вопрос, заключается в том, что такое разбиение помогает структурировать программу по тому, как я хочу с ней работать. Для разработки я поставлю dev пакет, а для использования нет.
Кроме описанных выше пакетов, можно создать dbg пакет с отладочной сборкой программы. Это может пригодиться, если программа падает и у Вас есть под рукой отладчик. Однако, я так и не смог понять как это делать. Документация не дает ответа на этот вопрос. Если делать так как описано в ней, то я либо получаю пустой пакет либо получаю кучу ошибок при сборке.
Схема на рисунке выше показывает, что пакет с исходниками называется libvksplugins_source, однако, в файле control указано, что пакет с исходниками будет называться libvksplugins. На самом деле, он действительно будет называться libvksplugins, а пакет с бинарниками, будет называться libvksplugins… deb. Суть этой путаницы в том, что пакет с исходниками представляет собой tar архив и служебные файлы, тогда как пакет бинарников это архив с расширение deb.
Настройка пакета библиотеки Посмотрим внимательно на описание пакета библиотеки:
Для пакетов, содержащих скрипты или тексты, нужно указывать значение как all.
Третья строка, описывает зависимости создаваемого пакета. Вот как она описана в 4й главе Руководства начинающего разработчика Debian:
Т.е. эта строка говорит о том, что сборщик пакета сам определит зависимости.
Последний раздел данной секции это описание пакета. Первая строка содержит кратное описание, последующие строки содержат более подробное описание. Подробное описание, должно иметь определенный формат:
Настройка пакета документации Вместе с библиотекой поставляется документация, чтобы она была в отдельном пакете, добавляем его описание:
rules
Данный файл является аналогом Makefile для сборки пакетов. По умолчанию, он создается в таком виде:
Видно, что это bash скрипт с синтаксисом Makefile. Единственная интересная конструкция здесь это
Т.к. исходники используют систему сборки CMake, то нужно изменить эту запись следующим образом:
Содержимое пакетов
После того, как мы указали в debian/control какие пакеты мы хотим получить, нужно указать какие файлы в какой пакет помещать. Для этого, для каждого названия пакета из файла control, нужно создать в папке debian два файла. Первый должен называться пакет.dirs, а второй пакет.install. Суть файлов в том, что первый указывает, какие папки нужно создать для пакета, а второй, какие файлы включить в пакет.
Посмотрим на их содержимое:
Важный момент, отсутствие начальной дроби в путях и отсутствие дроби в конце пути к папке. Проверив, куда CMake устанавливает файлы библиотеки, можно сформировать такие файлы:
Завершение настройки
Т.к. исходники мои, то никаких дополнительных описаний и ограничений copyright у меня нет, поэтому я удаляю все лишние файлы из каталога debian.
Сборка пакетов
После настройки, сборка пакетов происходит довольно просто, нужно в папке проекта (которая включает подпапку debian) выполнить команду:
Заключение
Если вы дочитали до сюда — значит вы любите читать.
Этот текст является результатом моего опыта внедрения deb пакетов на работе. Опыт показал, что наличие сетевого репозитория (reprepro) и внимательное отслеживание версий, позволяют без проблем обновлять и тестировать различные версии ПО на парке из 30 машин с системами Astra Linux 1.3, 1.4 и Эльбрус ОС.
Debian по-прежнему отказывается использовать HTTPS
APT (advanced packaging tool) — программа для установки, обновления и удаления программных пакетов в операционных системах Debian и основанных на них (Ubuntu, Linux Mint и т. п.). Иногда также используется в дистрибутивах, основанных на Mandrake. Пакеты скачиваются по интернету из репозиториев по незащищённому соединению, без использования протокола TLS и шифрования. Возникает вопрос: почему? Разве HTTPS не обеспечивает лучшую безопасность? Debian считает, что HTTPS — лишняя сущность, поскольку система SecureAPT проверяет контрольную сумму для скачанных файлов и криптографическую gpg-подпись всего пакета.
Один из разработчиков Debian запустил сайт whydoesaptnotusehttps.com («Почему APT не использует HTTPS»), где объясняет официальную позицию.
Как работает SecureAPT
Во-первых, apt сравнивает хэши файлов из пакета. Они публикуются на сайте Debian в файле Release…
…и передаются вместе с пакетом.
Чтобы защитить файл Release от подделки, система SecureAPT добавляет цифровую подпись gpg, которая находится в файле Release.gpg:
Программа apt скачивает файл Release.gpg и проверяет подпись с помощью доверенных публичных ключей, которые хранятся в файле /etc/apt/trusted.gpg. По умолчанию там записан записан публичный ключ архива Debian.
Это последняя линия защиты, поэтому Debian периодически меняет ключи. Новые ключи распространяются с пакетом debian-archive-keyring, а также публикуются на веб-странице.
После публикации нового публичного ключа происходит ещё одна процедура. Секретный ключ, который использовался для генерации открытого ключа, с помощью программы gfshare делится на пять частей и распределяется между пятью авторитетными разработчиками по схеме разделения секрета Шамира. Чтобы восстановить секрет, как минимум трое из пяти разработчиков должны предоставить свои части секрета. Математическое доказательство схемы Шамира публиковалось на Хабре: оно основано на том, что через две точки на плоскости можно провести неограниченное число полиномов степени 2. Чтобы выбрать из них единственный — нужна третья точка. Проще говоря, схема основана на полиномиальной интерполяции.
Итак, в системе SecureAPT секретный ключ разделён на пять частей и надёжно защищён, криптографическая подпись файла Release проверяется общедоступным публичным ключом, а в этом файле хранятся контрольные суммы файлов из пакета. Зачем же использовать HTTS, если всё так защищено?
Зачем использовать HTTP?
Основная задача HTTPS — скрыть трафик от посторонних глаз (провайдер, государственные службы и другие злоумышленники), чтобы третье лицо не смогло:
Разработчик Debian пишет:
HTTPS не обеспечивает значимой конфиденциальности для получения пакетов, поскольку злоумышленник обычно видит, с какими хостами вы связываетесь. Если вы подключитесь к зеркалу дистрибутива, будет совершенно очевидно, что вы загружаете обновления.
Вероятно, этот абзац написан в те времена, когда браузеры и интернет-сервисы не начали поддерживать технологию DNS over TLS и DNS over HTTPS (DoH) для шифрования DNS-трафика. Например, в апреле 2018 года её внедрил один из крупнейших CDN-провайдеров Cloudfalre, а в октябре 2018 года Google Public DNS тоже включил поддержку DNS over TLS.
Таким образом, после соответствующей настройки системы можно эффективно прятать DNS-запросы от постороннего лица, которое прослушивает трафик. Также идёт активная работа над внедрением других технологий, которые скрывают адресата пакетов. То есть в будущем HTTPS всё-таки сможет обеспечить должную конфиденциальность.
Debian приводит ещё один аргумент: даже на зашифрованном соединении «несложно выяснить, какие файлы скачивает пользователь по размеру трафика». Эту «уязвимость» можно использовать даже при анализе трафика через Tor.
Наконец, Debian не видит причин полностью доверять центрам сертификации: существует более 400 CA, которые предлагают сертификаты для любого домена. У многих плохая репутация, а некоторые напрямую контролируются государством. Сложно определить, какому CA можно доверять.
Таким образом, по мнению Debian, самое главное — гарантировать подлинность файлов в пакете, а не защитить само соединение.
Почему бы не внедрить HTTPS поверх существующего механизма SecureAPT? Разработчик считает это сложной инженерной задачей, которая требует безопасного обмена и хранения секретных ключей. Кроме того, внедрение HTTPS подразумевает «введение в заблуждение пользователей относительно уровня безопасности и конфиденциальности» по причинам, описанным выше.
В 2019 году сознательный отказ от HTTPS выглядит весьма экстравагантно, поэтому позиция Debian вызвала оживлённую дискуссию на Hacker News, где комментаторы выдвинули несколько контраргументов.
Что думаете вы, нужно ли шифровать трафик apt? (Опрос ниже).
