LINUX.ORG.RU
решено Форум — Development  

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

 , ,


0

1

Эту тему затрагивали в своих обсуждениях: te111011010, Stil, toyo-chi, Napilnik, Deleted, hateyoufeel, EXL.

Можно ли собрать ядро с софтом без «лишней» информации, чтобы каждый раз сборки были бинарно идентичны, при одинаковых конфигах? Например, чтобы в бинари не писался timestamp и т.п.

Кто-то пробовал такой дистриб создать? Какой для этого используется компилятор?

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

annulen ★★★★★
()

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

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

annulen ★★★★★
()
Ответ на: комментарий от annulen

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

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

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

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

upcFrost ★★★★★
()
Ответ на: комментарий от upcFrost

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

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

firkax ★★★★★
()

УМВР

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

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

Stil ★★★★★
()
Development