Linux и побитовая идентичность бинарников

Гугли: воспроизводимые сборки

Ну, NixOS. А ещё в Debian тоже пытались, но я не знаю чем это закончилось.

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

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

Подпись не поможет сделать пустой дифф из непустого.

Так пустой дифф сам по себе никому не интересен. Подпись подтверждает аутентичность и целостность бинарников. Если нужно проверить соотвествие коду, то надо собирать самому - но для проверку «пустого диффа» нужно сделать то же самое.

По-моему, про аутентичность вопрос не стоял.

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

По-моему, про аутентичность вопрос не стоял.

Именно.

Только лишь про неизменность бинарника при неизменности сорцов.

А ещё в Debian тоже пытались, но я не знаю чем это закончилось.

А в чём сложности? Тут ниже пишут, что достаточно подправить пару макросов: __DATE__ и __TIME__.

А в чём сложности?

У Debian? Понятия не имею. Возможно, они справились, но я не следил.

https://www.altlinux.org/%D0%92%D0%BE%D1%81%D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D0%B8%D0%BC%D0%B0%D1%8F_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0

https://wiki.debian.org/ReproducibleBuilds

но я не помню когда и как он был скомпилирован

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

Всякое бывает. На момент его «ввода в эксплуатацию» разумеется всегда известно из чего он собран, а вот логи на этот счёт могут и не вестись, и спустя 5 лет можно и не вспомнить. Да и почему сразу прод? На всяких тестовых окружениях тоже желательно знать что из чего собрано. Да и на локалхосте тоже.

В идеале конечно запускать надо только одновременно с сопутствующим коммитом только что скомпилированных исходников, и где-то документировать «туда-то залита такая-то версия», но по разным причинам не всегда это так, особенно среди чего-то сильно старого или сильно мелкого. Что-то может быть вообще по-быстрому накодено в $HOME на сервере и бинарник там же локально скопирован куда надо, с расчётом «потом всё переделаю по-нормальному».

УМВР

Нужен тулчейн фиксированной версии (у меня это шланг 15.0.1 в данный момент), фиксированные флаги, ремап путей (типа -ffile-prefix-map=/your/build/root/proj/=proj/) и -Werror=date-time

Но мне никогда не приходила в голову мысль собирать таким образом всю ОС, хз какие грабли будут у тебя на пути.