Воспроизводимые сборки

И вновь я всех приветствую! Сегодня я бы хотел рассказать о такой теме как воспроизводимые приложения/сборки. Одним из примеров воспроизводимых сборок является как раз сам телеграмм. Телеграмм является приложением с открытым исходным кодом, но есть ли гарантия, что вы скачиваете с магазина приложений именно его? Да, это и есть воспроизводимые сборки. ❗Воспроизводимые сборки — это набор методов разработки программного обеспечения, которые создают независимо проверяемый путь от исходного кода к бинарному коду. ❓Почему важны воспроизводимые сборки? Воспроизводимые сборки гарантируют, что программное обеспечение, которому вы доверяете, является безопасным и проверяемым. Это достигается путем проверки соответствия загружаемых вами бинарных файлов исходному коду, не подвергавшемся изменениям. Для инструментов, связанных с безопасностью, это означает высокую степень уверенности в том, что ваши данные и коммуникации защищены от скрытых бэкдоров или уязвимостей. 💭Работает это так: Во-первых, система сборки должна быть полностью детерминированной: преобразование заданного исходного кода всегда должно приводить к одному и тому же результату. Например, текущая дата и время не должны записываться, а выходные данные всегда должны записываться в одном и том же порядке. Во-вторых, набор инструментов, используемых для выполнения сборки, и, в более общем смысле, среда сборки должны быть либо зафиксированы, либо предварительно определены. В-третьих, пользователям следует предоставить возможность воссоздать достаточно близкую к исходной среду сборки, выполнить процесс сборки и убедиться, что результат соответствует исходной сборке. ❓Какие проблемы решают воспроизводимые сборки? Хотя любой может проверить исходный код свободного и открытого программного обеспечения на наличие вредоносных уязвимостей, большинство программ распространяется в предварительно скомпилированном виде, что не даёт возможности подтвердить соответствуют ли они друг другу. 💡Цель проекта «Воспроизводимые сборки» — обеспечить проверку отсутствия уязвимостей или бэкдоров в процессе компиляции. Обеспечивая получение идентичных результатов из исходного кода, проект позволяет нескольким сторонним разработчикам прийти к единому мнению о «правильном» результате, выявляя любые отклонения как подозрительные и заслуживающие тщательного изучения. Возможность заметить, если система разработки или сборки была скомпрометирована, предотвращает подобные угрозы или атаки, поскольку любое нарушение безопасности может быть быстро обнаружено. В результате, сотрудников, работающих на передовой, нельзя принудить к использованию уязвимостей или раскрытию информации о своих коллегах. 📣Когда сборку можно воспроизвести? Сборка считается воспроизводимой , если при наличии одного и того же исходного кода, среды сборки и инструкций по сборке любая сторона может побитово воссоздать идентичные копии всех указанных артефактов. Соответствующие атрибуты среды сборки, инструкции по сборке и исходный код, а также ожидаемые воспроизводимые артефакты определяются авторами или распространителями. Артефакты сборки — это части результатов сборки, которые являются желаемым основным выходным результатом. Исходный код обычно представляет собой копию, полученную из системы контроля версий в определенной ревизии, или архив исходного кода. К соответствующим атрибутам среды сборки обычно относятся зависимости и их версии, флаги конфигурации сборки и переменные среды, если они используются системой сборки (например, локаль). Предпочтительнее сократить этот набор атрибутов. К артефактам относятся исполняемые файлы, дистрибутивы или образы файловых систем. Обычно они не включают журналы сборки или аналогичные вспомогательные выходные данные. Воспроизводимость артефактов проверяется побитовым сравнением. Обычно это выполняется с использованием криптографически защищенных хэш-функций.

❓Как пользователи могут узнать, что созданная ими сборка успешно воспроизвела исходную? Самый простой способ — убедиться, что выходные данные сборки всегда идентичны побайтно. Побайтовое сравнение — тривиальная операция, которую можно выполнить во многих различных средах. ⚡Ещё одно преимущество наличия идентичных байтов заключается в возможности использования криптографических контрольных сумм. Такие контрольные суммы очень малы по сравнению с суммами, используемыми в полной сборке. Их легко обменивать даже в условиях очень низкой пропускной способности. Например, это позволяет создавать релизы программного обеспечения как на сервере с хорошим (но ненадежным) подключением, так и на ноутбуке с плохим мобильным соединением. ✅Цифровая подпись может быть создана локально на ноутбуке. Поскольку результаты сборки будут идентичны, подпись будет действительна для файлов, созданных на сервере с хорошим подключением. ✏Проблема со встроенными подписями. Распространяемое программное обеспечение, использующее встроенные криптографические подписи, может создавать проблемы с воспроизведением пользователями идентичных результатов. По определению, они не смогут сгенерировать идентичную подпись. Эту проблему можно решить либо путем включения подписи в процесс сборки, либо путем предоставления инструментов для преобразования распространяемых бинарных файлов в безупречные результаты сборки. Один из способов обработки встроенных криптографических подписей — сделать подпись (необязательным) входным параметром процесса сборки. Если подпись доступна, она просто копируется в нужное место. Это позволяет реализовать следующий рабочий процесс: ✅Первоначальную сборку выполняют разработчики, имеющие доступ к закрытому ключу. ✅Результат сборки записывается во внешний файл. ✅Подпись становится частью выпущенного исходного кода. ✅Распространяемая сборка создана на основе последнего источника. Ещё один пример — использование F-Droid для копирования подписей APK-файлов с помощью apksigcopier. Можно разработать специальный инструмент сравнения, способный сравнивать сборки, в которых отсутствуют подписи. В идеале он также должен уметь генерировать криптографические контрольные суммы, чтобы не требовалось скачивать исходную сборку только для сравнения результатов. Подобный инструмент должен быть очень прост в проверке и понимании. В противном случае трудно доверять тому, что скрипт не игнорирует байты, которые могли бы изменить его поведение. Другой вариант — предоставить инструмент, способный удалять подписи из официальных релизов. Полученный результат затем можно будет сравнивать побайтно с результатами, полученными от пользователя. 😡Недостатком этого метода является то, что для сравнения пользователю необходимо загрузить официальные релизы. Кроме того, сложнее гарантировать, что удаляемые данные не приведут к изменению поведения программного обеспечения. ❓Как пользователи могут убедиться в том, что сборка не была скомпрометирована, обмениваясь сертификатами, подтверждающими, что все они смогли получить одинаковые результаты сборки? В Debian рассматривают возможность разрешить нескольким разработчикам Debian загружать подписи, подтверждающие, что им удалось воспроизвести сборку. Этот вопрос также связан с работой Бена Лори по обеспечению прозрачности бинарных файлов. Идея состоит в создании журнала с возможностью добавления данных, аналогичного системе прозрачности сертификатов, который можно было бы использовать для аутентификации бинарных файлов. ↗Для повышения эффективности воспроизводимых сборок и раннего выявления взломов необходимы дополнительные исследования в этой области. ⚡На этом кончается небольшой экскурс в тему воспроизводимых сборок.