И вновь я всех приветствую! Сегодня я бы хотел рассказать о такой теме как воспроизводимые приложения/сборки. 

Одним из примеров воспроизводимых сборок является телеграмм. Телеграмм является приложением с открытым исходным кодом, но есть ли гарантия, что вы скачиваете с магазина приложений именно его? Да, это и есть воспроизводимые сборки.

Воспроизводимые сборки — это набор методов разработки программного обеспечения, которые создают независимо проверяемый путь от исходного кода к бинарному коду.

❓Почему важны воспроизводимые сборки?

Воспроизводимые сборки гарантируют, что программное обеспечение, которому вы доверяете, является безопасным и проверяемым. Это достигается путем проверки соответствия загружаемых вами бинарных файлов исходному коду, не подвергавшемся изменениям. Для инструментов, связанных с безопасностью, это означает высокую степень уверенности в том, что ваши данные и коммуникации защищены от скрытых бэкдоров или уязвимостей.

Работает это так:

Во-первых, система сборки должна быть полностью детерминированной: преобразование заданного исходного кода всегда должно приводить к одному и тому же результату. Например, текущая дата и время не должны записываться, а выходные данные всегда должны записываться в одном и том же порядке.

Во-вторых, набор инструментов, используемых для выполнения сборки, и, в более общем смысле, среда сборки должны быть либо зафиксированы, либо предварительно определены.

В-третьих, пользователям следует предоставить возможность воссоздать достаточно близкую к исходной среду сборки, выполнить процесс сборки и убедиться, что результат соответствует исходной сборке.

❓Какие проблемы решают воспроизводимые сборки?

Хотя любой может проверить исходный код свободного и открытого программного обеспечения на наличие вредоносных уязвимостей, большинство программ распространяется в предварительно скомпилированном виде, что не даёт возможности подтвердить соответствуют ли они друг другу.

Цель проекта «Воспроизводимые сборки» — обеспечить проверку отсутствия уязвимостей или бэкдоров в процессе компиляции. Обеспечивая получение идентичных результатов из исходного кода, проект позволяет нескольким сторонним разработчикам прийти к единому мнению о «правильном» результате, выявляя любые отклонения как подозрительные и заслуживающие тщательного изучения.

Возможность заметить, если система разработки или сборки была скомпрометирована, предотвращает подобные угрозы или атаки, поскольку любое нарушение безопасности может быть быстро обнаружено. В результате, сотрудников, работающих на передовой, нельзя принудить к использованию уязвимостей или раскрытию информации о своих коллегах.

Когда сборку можно воспроизвести?

Сборка считается воспроизводимой , если при наличии одного и того же исходного кода, среды сборки и инструкций по сборке любая сторона может побитово воссоздать идентичные копии всех указанных артефактов.

Соответствующие атрибуты среды сборки, инструкции по сборке и исходный код, а также ожидаемые воспроизводимые артефакты определяются авторами или распространителями. Артефакты сборки — это части результатов сборки, которые являются желаемым основным выходным результатом.

Исходный код обычно представляет собой копию, полученную из системы контроля версий в определенной ревизии, или архив исходного кода.

К соответствующим атрибутам среды сборки обычно относятся зависимости и их версии, флаги конфигурации сборки и переменные среды, если они используются системой сборки (например, локаль). Предпочтительнее сократить этот набор атрибутов.

К артефактам относятся исполняемые файлы, дистрибутивы или образы файловых систем. Обычно они не включают журналы сборки или аналогичные вспомогательные выходные данные.

Воспроизводимость артефактов проверяется побитовым сравнением. Обычно это выполняется с использованием криптографически защищенных хэш-функций.

❓Как пользователи могут узнать, что созданная ими сборка успешно воспроизвела исходную?

Самый простой способ — убедиться, что выходные данные сборки всегда идентичны побайтно. Побайтовое сравнение — тривиальная операция, которую можно выполнить во многих различных средах.

Ещё одно преимущество наличия идентичных байтов заключается в возможности использования криптографических контрольных сумм. Такие контрольные суммы очень малы по сравнению с суммами, используемыми в полной сборке. Их легко обменивать даже в условиях очень низкой пропускной способности.

Например, это позволяет создавать релизы программного обеспечения как на сервере с хорошим (но ненадежным) подключением, так и на ноутбуке с плохим мобильным соединением. 

Цифровая подпись может быть создана локально на ноутбуке. Поскольку результаты сборки будут идентичны, подпись будет действительна для файлов, созданных на сервере с хорошим подключением.

✏️Проблема со встроенными подписями.

Распространяемое программное обеспечение, использующее встроенные криптографические подписи, может создавать проблемы с воспроизведением пользователями идентичных результатов. По определению, они не смогут сгенерировать идентичную подпись. Эту проблему можно решить либо путем включения подписи в процесс сборки, либо путем предоставления инструментов для преобразования распространяемых бинарных файлов в безупречные результаты сборки.

Один из способов обработки встроенных криптографических подписей — сделать подпись (необязательным) входным параметром процесса сборки. Если подпись доступна, она просто копируется в нужное место.

Это позволяет реализовать следующий рабочий процесс:

Первоначальную сборку выполняют разработчики, имеющие доступ к закрытому ключу.

Результат сборки записывается во внешний файл.

Подпись становится частью выпущенного исходного кода.

Распространяемая сборка создана на основе последнего источника.

Ещё один пример — использование F-Droid для копирования подписей APK-файлов с помощью apksigcopier.

Можно разработать специальный инструмент сравнения, способный сравнивать сборки, в которых отсутствуют подписи. В идеале он также должен уметь генерировать криптографические контрольные суммы, чтобы не требовалось скачивать исходную сборку только для сравнения результатов.

Подобный инструмент должен быть очень прост в проверке и понимании. В противном случае трудно доверять тому, что скрипт не игнорирует байты, которые могли бы изменить его поведение.

Другой вариант — предоставить инструмент, способный удалять подписи из официальных релизов. Полученный результат затем можно будет сравнивать побайтно с результатами, полученными от пользователя.

Недостатком этого метода является то, что для сравнения пользователю необходимо загрузить официальные релизы. Кроме того, сложнее гарантировать, что удаляемые данные не приведут к изменению поведения программного обеспечения.

❓Как пользователи могут убедиться в том, что сборка не была скомпрометирована, обмениваясь сертификатами, подтверждающими, что все они смогли получить одинаковые результаты сборки?

В Debian рассматривают возможность разрешить нескольким разработчикам Debian загружать подписи, подтверждающие, что им удалось воспроизвести сборку.

Этот вопрос также связан с работой Бена Лори по обеспечению прозрачности бинарных файлов. Идея состоит в создании журнала с возможностью добавления данных, аналогичного системе прозрачности сертификатов, который можно было бы использовать для аутентификации бинарных файлов.

Для повышения эффективности воспроизводимых сборок и раннего выявления взломов необходимы дополнительные исследования в этой области.

⚡️На этом кончается небольшой экскурс в тему воспроизводимых сборок.