О Боже! Что опять придумали эти антилопы?!

 , , ,



Уважаемые, вот здесь какой-то трешак про *.exe в линуксах! Тащите скорее огнетушитель! У меня там все горит уже! Сейчас взлечу как ракета со стула! Опенсорц в опасносте! Кто умеет в английский, о чем там?
Для Ъ:

I'm working again on making reproducible .exe-s. I thought I'd share my process:


End users get a bit-for-bit reproducible .exe, known not to contain trojan and auditable from sources Point releases can reuse the exact same build process and avoid introducing bugs


Generate a source tarball (non reproducibly) Debian Docker as a base, with fixed version + sources.list Dockerfile: install packaged dependencies and MXE(.cc) from a fixed Git revision Dockerfile: compile MXE with SOURCE_DATE_EPOCH + fix-ups Build my project in the container with SOURCE_DATE_EPOCH and check SHA256 Copy-on-release

Result:;a=tree;f=autobuild/dfarc-w32-snapshot Generate a source tarball (non reproducibly)

This is not reproducible due to using non-reproducible tools (gettext, automake tarballs, etc.) but it doesn't matter: only building from source needs to be reproducible, and the source is the tarball.

It would be better if the source tarball were perfectly reproducible, especially for large generated content (./configure, wxGlade-generated GUI source code...), but that can be a second step. Debian Docker as a base

AFAIU the Debian Docker images are made by Debian developers but are in no way official images. That's a pity, and to be 100% safe I should start anew from debootstrap, but Docker is providing a very efficient framework to build images, notably with caching of every build steps, immediate fresh containers, and public images repository.

This means with a single:

sudo -g docker make

you get my project reproducibly built from scratch with nothing to setup at all.

I avoid using a :latest tag, since it will change, and also backports, since they can be updated anytime. Here I'm using stretch:9.4 and no backports.

Using in sources.list makes sure the installed packaged dependencies won't change at next build. For a dot release however (not for a rebuild), they should be updated in case there was a security fix that has an effect on built software (rare, but exists).

Last but not least, APT::Install-Recommends «false»; for better dependency control. MXE is compilation environment to get MingGW (GCC for Windows) and selected dependencies rebuilt unattended with a single make. Doing this manually would be tedious because every other day, upstream breaks MinGW cross-compilation, and debugging an hour-long build process takes ages. Been there, done that.

MXE has a reproducible-boosted binutils with a patch for SOURCE_DATE_EPOCH that avoids getting date-based and/or random build timestamps in the PE (.exe/.dll) files. It's also compiled with --enable-deterministic-archives to avoid timestamp issues in .a files (but no automatic ordering).

I set SOURCE_DATE_EPOCH to the fixed Git commit date and I run MXE's build.

This does not apply to GCC however, so I needed to e.g. patch a __DATE__ in wxWidgets.

In addition, libstdc++.a has a file ordering issue (said ordering surprisingly stays stable between a container and a host build, but varies when using a different computer with the same distros and tools versions). I hence re-archive libstdc++.a manually.

It's worth noting that PE files don't have issues with build paths (and varying BuildID-s - unlike ELF... T_T).

Again, for a dot release, it makes sense to update the MXE Git revision so as to catch security fixes, but at least I have the choice. Build project

With this I can start a fresh Docker container and run the compilation process inside, as a non-privileged user just in case.

I set SOURCE_DATE_EPOCH to the release date at 00:00UTC, or the Git revision date for snapshots.

This rebuild framework is excluded from the source tarball, so the latter stays stable during build tuning. I see it as a post-release tool, hence not part of the release (just like distros packaging).

The generated .exe is statically compiled which helps getting a stable result (only the few needed parts of dependencies get included in the final executable).

Since MXE is not itself reproducible differences may come from MXE itself, which may need fixes as explained above. This is annoying and hopefully will be easier once they ship GCC6. To debug I unzip the different .zip-s, upx -d my .exe-s, and run diffoscope.

I use various tricks (stable ordering, stable timestamping, metadata cleaning) to make the final .zip reproducible as well. Post-processing tools would be an alternative if they were fixed. reprotest

Any process is moot if it can't be tested.

reprotest helps by running 2 successive compilations with varying factors (build path, file system ordering, etc.), and check that we get the exact same binary. As a trade-off, I don't run it on the full build environment, just on the project itself. I plugged reprotest to the Docker container by running a sshd on the fly. I have another Makefile target to run reprotest in my host system where I also installed MXE, so I can compare results and sometimes find differences (e.g. due to using a different filesystem). In addition this is faster for debugging since changing anything in the early Dockerfile steps means a full 1h rebuild. Copy-on-release

At release time I make a copy of the directory that contains all the self-contained build scripts and the Dockerfile, and rename it after the new release version. I'll continue improving upon the reproducible build system in the 'snapshot' directory, but the versioned directory will stay as-is and can be used in the future to get the same bit-for-bit identical .exe anytime.

This is the technique I used in my Android Rebuilds project. Other platforms

For now I don't control the build process for other platforms: distros have their own autobuilders, so does F-Droid. Their problem :P

I have plans to make reproducible GNU/Linux AppImage-based builds in the future though. I should be able to use a finer-grained, per-dependency process rather than the huge MXE-based chunk I currently do.

I hope this helps other projects provide reproducible binaries directly! Comments/suggestions welcome.


Я вообще не понял, что это такое человек делает?

«DFARC: Алгоритм типичной унификации воспроизводимых экзешников и избыточности»?

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

Ну что гну делают последние годы? Дрочат вприсядку.

dk- ()

Windows builds ... MingGW

Шизя, плиз.

qula ()

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

amd_amd ()
Ответ на: комментарий от dk-

Ну что гну делают последние годы? Дрочат вприсядку.

Это, похоже, какая-то локальная хрень для игры GNU FreeDink, смысл которой поймет только тот, кому интересно. Насколько я понимаю, вопрос в сборке exe-шника для Windows. :)

Zubok ★★★★★ ()
Последнее исправление: Zubok (всего исправлений: 1)
Ответ на: комментарий от Zubok

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

shimshimshim ()

Я по русски то столько ниасилю...

burato ()

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

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

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

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

Кто то озаботился этим для шиндовс? Чудны дела твои, господи...

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

На более старом симбиане - еще как глотала. Видел 1-2 программки, которые были выполнены именно в виде файлика с расширением .exe.

hunter-12 ()
Ответ на: комментарий от amd_amd

при этом сама симбиан ехе естественно не глотала

как бы .sis(x) это пакеты, в которых exe, dll и прочие файлы программы. То что файлы symbian не совместимы с файлами windows это да.

необходимо было положить специальный файлик в определенное место

Заменить имеющийся. Он может и отсутствовал на диске C, но был на RO диске Z.
не знаю, что там в N73, а в symbian 9.4 самому положить файлик было нельзя, по этому файлы программы (RomPatcher) подсовывались антивирусу и через него восстанавливались. После чего в установленной программе патчем системы отключалась проверка сертификатов

SR_team ★★ ()
Последнее исправление: SR_team (всего исправлений: 1)
Ответ на: комментарий от SR_team

по этому файлы программы (RomPatcher) подсовывались антивирусу и через него восстанавливались

Нет, не так. Качался антивирь, который содержал в карантине три (если правильно помню) вируса, которые восстанавливались. А потом в RomPatcher'е включались патчи. Были еще патчи c2z и e2z, которые позволяли при загрузке системы чекать еще и память телефона и флешку на предмет папок с такой же структурой, как на диске Z. Что позволяло провернуть

необходимо было положить специальный файлик в определенное место

ozz_is_here ()

Что не так? Возможность воспроизводить сборку с результатом бит в бит - это серьёзная и востребованная тема.

Quasar ★★★★★ ()

О чём тред? Уже не первое десятилетие можно сделать mono HelloWorld.exe. Равно как и echo -e '#!/bin/sh\necho 'Hello world!' > helloworld.exe && chmod +x ./helloworld.exe && ./helloworld.exe.

bodqhrohro_promo ()
Ответ на: комментарий от ozz_is_here

Качался антивирь, который содержал в карантине три (если правильно помню) вируса

Все правильно. Антивирус ставился на флешку, потом через ПК в карантин подсовывались 3 файла. И не вирусы это, а RomPatcher.

SR_team ★★ ()

Загуглил бы MXE, чтоли.

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

yurikoles ★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)