Безопасно ли использовать OpenSource продукты от крупных корпораций?

Question

[Ivan]

Существует масса крупных компаний которые выпускают компиляторы, библиотеки для ЯП, IDE и т.д. под открытыми лицензиями, понятное дело код таких продуктов выложен на GitHub, GitLab, но фактически они выпускают скомпилированные под платформу бинарники, как можно проверить, что выложенный код совпадает со скомпилированным бинарником?
Я понимаю, сейчас много кто может сказать: не доверяешь - компилируй. Но, так или иначе, чтобы этим заниматься, нужно время и погружения в определённые стеки, чего бы я хотел избежать.
Есть простые способы проверки соответствия скомпилированного бинарника с такой же версией открытого кода?

Comments

[shurshur]

Некоторые разработчики делают reproducible builds. Это когда специальные усилия потрачены на то, чтобы можно было по инструкции собрать приложение, контрольные суммы которые совпадали бы с таковыми у официальной сборки. Если такое есть и это какой-то востребованный софт - то почти наверняка есть независимые проверяльщики, которые регулярно собирают этот софт и сверяют эти суммы. Такое встречается далеко не всегда и не везде, особенно для всякой мелочи, потому что на это тоже требуются усилия разработчиков.

Но в целом для многих массовых продуктов это не имеет смысла. Специально выкладывать "патченные" бинарники на большую аудиторию - это риск непонятно для чего. Особенно для продуктов с большим количеством конкурентов, рссчитанных на массовую аудиторию: вляпаешься в скандал и получишь отток клиентов, падение инвестиций, недовольство акционеров...

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

Answer 1

[GavriKos]

Есть простые способы проверки соответствия скомпилированного бинарника с такой же версией открытого кода?

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

Comments

[Ivan]

Фактически те кто являются пользователями таких продуктов просто доверяют, что разработчик и вендор не добавляют специй в продукт перед компиляцией и проверить это не представляется возможным, в конечном итоге получается, что по уровню доверия OpenSource от проприетарного ПО особо нечем не отличаются, и там и там просто доверие)
Ну кроме самостоятельной компиляции продуктов, что как по мне скорее всего делается крайне редко, установка у меня по крайней мере осуществляется из репозитория, компилировать и отслеживать версионность как проекта, так и библиотек довольно сложно, особенно если в этом стеке не работаешь.

[GavriKos]

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

[Ivan]

GavriKos, От себя скажу у меня под рукой постоянно довольно много OpenSource решений, разработанных на приличном зоопарке технологий и ЯП, отслеживать версионности, создавать под компиляцию каждого продукта виртуалку, у меня просто нет времени, думал есть какой нибудь цифровой стандарт (сертификат) от тех же площадок типа GitHub который бы гарантировал, что внутри коробки положено тоже самое, что было размещено для всеобщего обозрения.

[shurshur]

Ivan, такого "стандарта" нет. Аудит кода - дорогое удовольствие. Хорошо, если что-то имеет независимый аудит, но это скорее исключение.

А вот в контексте вопроса может быть интересно то, что в некоторых сферах таки софт массово используется не в виде бинарей от вендора, а собирается независимо от него. Так делают в мире Linux (весь дистриб в пакетах собирается разработчиками дистриба), такое есть для Android в проекте f-droid (все приложения принципиально собираются в инфраструктуре самого f-droid из исходников, сборки разработчика не используются). Плюс в Linux это ещё и хоть немного проверенные версии (для stable-релизов, не разных экспериментальных и rolling).

[Ziptar]

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

[Кот Абсолютный]

В генте например, большая часть софта, который opensource - компилируется из исходников и это стандартный путь. Даже для таких монстров как libreoffice. Да, хочешь быстрее - доверяй сборщику и ставь бинарный пакет, не доверяешь - emerge -av packagename :)

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

Answer 2

[alexalexes]

Реинжиниринг кода - это для тех ребят, для которых повторная доверенная сборка компилятора из исходников - стандартное действие.
Так что, нет, никогда не будет проста такая операция.

Answer 3

[Everything_is_bad]

Есть простые способы проверки соответствия скомпилированного бинарника с такой же версией открытого кода?

нет, для простых способов нужно минимум, чтобы процесс был обратимый

Answer 4

[Drno]

насчет надежности опенсорса
https://vk.com/wall-194576836_28348

Answer 5

[Василий Банников]

как можно проверить, что выложенный код совпадает со скомпилированным бинарником?

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

Чтобы компиляция была воспроизводимой - нужно приложить специальные усилия, так как на итоговый бинарник влияет не только исходный код, но и окружение (конкретные версии компилятора и системных библиотек)

Есть простые способы проверки соответствия скомпилированного бинарника с такой же версией открытого кода?

Собрать самостоятельно - это и есть самый простой способ.
Ну и ещё если все пайплайны для сборки описаны в этом же репозитории (github actions или просто дана ссылка на пайплайны), то это +1 очко к уверенности, что для сборки используются те же самые исходники.

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

Answer 6

[pfg21]

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

самым правильным решением исключения вопросов левых внедрений в код на этапе компиляции является собственная компиляция.

Answer 7

[Ivan]

Спасибо всем коллеги за развёрнутые ответы, как я понял, выход для людей которые желают пользоваться разработками под открытыми лицензиями:
1. Проверка соответствия кода и бинарника - это самостоятельная компиляция проверенного комьюнити кода из сетевых хранилищ, обращая внимание на контрольную сумму выложенную вендором полученного в результате компиляции бинарника. Этот вариант предусматривает настройку окружения под стек продукта, включая среду ЯП, скрипты компиляции, внешние зависимости и т.д., такой вариант будет полностью на ответственности того кто компилирует и необходимости контроля и перекомпиляции в случае обнаружения уязвимостей;
2. Реверс-инжиниринг готового бинарника от вендора с целью сопоставления коду размещённому в открытом сетевом хранилище, задача так же не тривиальная и требует ещё большего погружения как в стек, так и в более низкоуровневые технологии;
3. Просто доверять тому или иному вендору открытого ПО, без проверки на соответствие.

Comments

[Adamos]

0. Представить вектор атаки производителя ПО на пользователя. Точнее, понять, что он высосан из пальца - и не маяться всеми дальнейшими пунктами, если ты не Секретный Отдел ЕИВ Канцелярии.

[Ziptar]

Adamos, проблема даже не в производителе ПО может крыться, а в компрометации/взломе внутренних систем производителя ПО. История, увы, знает примеры. Громких не помню, правда.

[Adamos]

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

[Ziptar]

Adamos, всё так. эхъ