pyinstaller und reproduzierbarkeit von exe files

[momo_1212]

Hi
ich generiere mit Pyinstaller ein Exe file in windows.
Mein projekt hat immer mehr User.
Jetzt wollte ich meine Projekt etwas sicherer gestalten. Ich habe pyinstaller auf den selben Code auf 2 Rechner laufen lassen und habe festgestellt, dass der EXE file was raus kommt nicht jedes mal gleich ist. Das heisst ein binary comparison der 2 EXE files zeigt unterschiede.
Das ist doch ganz schon gefährlich. Oder?
Gibt es da ein Trick?

[sparrow]

Kannst du kurz erklären, wie genau Pyinstaller funktioniert? Also nicht, dass es eine .exe macht, sondern wie es dafür vorgeht?

[__blackjack__]

@momo_1212: Per se ist das nicht gefährlich. Man kann halt nicht so einfach nachvollziehen ob eine EXE aus einem gegebenen Satz an Eingabedaten erstellt wurde.

[noisefloor]

Hallo,

das fehlt noch Kontext... ist die Python-Version auf beiden Rechner _exakt_ gleich und aus der gleichen Stelle installiert? Hat pyinstaller _exakt_ die gleiche Version? AFAIK fließt in pyinstaller ja alles mögliche ein, weil das am Ende ein selbstextrahierendes Archiv ist. Keine Ahnung, OS-seitig noch was rein fließt und die Build Version von Windows auch noch da mit rein spielt.

Unabhängig davon sehe ich auch nicht, was daran "gefährlich" sein soll. Potentiell gefährlich sind nur zwei Sachen: dein Code und was pyinstaller noch in die EXE packt. Auf ersteres hast du vollen Einfluss, auf letzteres nicht.

BTW: exakt den gleiche Thread gibt es bei python-forum.io: https://python-forum.io/thread-46136.html. Scheinbar ist das Vertrauen in die Qualität der Antworten in den einem oder anderen Forum nicht hoch genug, deswegen "Gürtel + Hosenträger"`?

Gruß, noisefloor

[__blackjack__]

Wegen Archiv: Nicht nur die Dateiinhalte müssen gleich sein, sondern auch die Metadaten wie die Zeitstempel müssen gleich sein. Das stellt sich dann eventuell auch die Frage ob auf beiden Rechnern das gleiche OS verwendet wird, beziehungsweise Dateisysteme, denn nicht alle haben die gleiche Auflösung was beispielsweise Zeitstempel angeht.

[DeaD_EyE]

Ich hab mich schon gewundert. Habe meinen Beitrag gesucht und dann ist mir aufgefallen, dass ich das im anderen Forum gepostet habe.

Reproduzierbarkeit ist nicht einfach zu erreichen, da es vom Compiler, vom Host, von eingesetzten Bibliotheken, (und noch mehr) abhängt.
Es kann z.B. passieren, dass zwei softwaremäßig identische Hosts Unterschiede beim Kompilieren erzeugen.

Jedenfalls bietet Pyinstaller diese Option, aber das bedeutet nicht, dass zwei unterschiedliche Hosts mit Pyinstaller die gleiche Exe erzeugen.





Ich hoffe, dass sich Windows in den nächsten 10 Jahren von selbst erledigt. Neuster Scheiß: Man muss sich bei Windows 11 mit seinem Account anmelden, um Notepad nutzen zu können.
Microsoft arbeitet hart daran, Privatkunden zu verlieren und das Witzige ist, dass sich MS auch nicht auf die Privatkunden konzentriert und jetzt laufen die Unternehmen weg.

PS: Pyinstallier kompiliert nichts, packt aber eine kompilierte Python-Version mit dem Code. Kannst ja mal testen, ob auf zwei Unterschiedlichen Hosts die gleiche EXE erzeugt wird, wenn du die gleiche Python-Version für Pyinstaller verwendest. Musst natürlich diesen SEED-Trick machen, damit der Pseudo-Zufallsgenerator einen definierten Anfangswert hat, der immer gleich ist. Aufrufe von random enden dann immer in der gleichen Sequenz == reproduzierbar.

Beim Spiel Doom wollte man, dass Zufälle immer gleich sind. Anstatt einen Seed-Wert zu setzen, nutzt das Spiel eine Tabelle mit int, um einen Pseudo-Zufallsgenerator zu implementieren. Es sieht zufällig aus, aber wenn man eine Demo abspielt, sind die "Zufälle" immer gleich. D.h. es ist deterministisch und reproduzierbar.

[momo_1212]

Hi Leute
vielen Dank. Ja ich habe auf 2 Foren gepostet weil das Thema plötzlich gebrannt hat bei.
Es geht um folgendes Problem:
Unser Student hat ein EXE generiert. Es wurde 3 Wochen getestet. Wir wussen nicht mehr basiernd auf welchem GIT commit diese Exe generiert wurde. Dann habe ich versucht neu zu builden. Ein binärer vergleich war nicht möglich.
Hier kam dann die Antowrt von DeaD_EyE:
https://python-forum.io/thread-46136.html

Ich habe dann bischen weiter gelesen:
ich glaube das Oberthema ist "reproducable builds" https://reproducible-builds.org/
Ganz schon grosses thema:
https://www.youtube.com/watch?v=wRHi8Ui5vWA

Von hier habe ich mitgenommen:
https://pyinstaller.org/en/stable/advan ... ible-build
PYTHONHASHSEED=1 kam ich schon recht weit. Jetzt muss ich noch mit Datum hinbekommen.
Danke

[__blackjack__]

@momo_1212: Mit einem festen Hash-Seed macht man Programme aber unsicherer. Und ich sehe auch nicht wie Du damit jetzt im Nachhinein herausfinden kannst welcher GIT-Stand in der Vergangenheit mal in eine EXE verpackt wurde.

Ich würde da einfach den GIT-Hash beim verpacken in die EXE mit in das Programm stecken, zum Beispiel zur Versionsnummer oder als Versionsnummer. In die Metadaten der EXE und/oder abfragbar vom Programm.

Ansonsten kennt GIT Tags um so etwas wie Releases — auch Alpha- oder Betaversionen — zu markieren.

[Sirius3]

@momo_1212: die Lösung ist, dass man in seinen build-Prozess den git-Commit einbindet, z.B. in der pyproject.toml Datei als:

Code: Alles auswählen

[tool.setuptools_scm]
write_to = "package/_version.py"
version_scheme = "post-release"

Im Zweifel kann man dann die exe entpacken und diese Datei importieren, oder man hat in seinem Script gleich einen passendes Argument:

Code: Alles auswählen

import argparse
from package._version import __version__

parser = argparse.ArgumentParser(prog='PROG')
parser.add_argument('--version', action='version', version=f'%(prog)s {__version__}')

[DeaD_EyE]

Ich hab jetzt herausgefunden, dass PYTHONHASHSEED nicht random beeinflusst. Also der Seed-Wert von Random scheint unabhängig zu sein. Aber unsicher ist es trotzdem, da durch den Hashseed vieles vorhersagbar ist. Man kann eine erstellte PyInstaller EXE zur Not wieder auseinander nehmen.

https://github.com/extremecoders-re/pyinstxtractor

Beim nächsten Mal einfach eine Versionsnummer hinzufügen. Dann muss man nicht lange suchen.