eigenes Zertifikat

[haentschman]

Moin...

Zitat:

Warum hat die Kopie die richtige Signatur?

Ich denke inzwischen, daß das Signieren klappt. Aber bei der Dateierstellung irgendetwas schiefläuft. Wenn ich die Datei, mit der Signatur (die Kopie ), in irgendeinen Ordner, auch im Netzwerk (mit installiertem Zertifkat), kopiere, wird das mit Zertifikat in den Eigenschaften angezeigt. Im Original nach dem Kompilieren nicht.

Seht ihr an der Batch was Falsches? Irgend ein Cache der das auslöst?

Code:

echo off

if not exist E:\Projects\Projects_Delphi\xxx\_out\Development_Runtime\xxx.exe exit
if not exist E:\Projects\Projects_Delphi\xxx\_out\app\KTE_Release\Win32 md E:\Projects\Projects_Delphi\xxx\_out\app\xxx_Release\Win32

E:\Projects\Projects_Delphi\xxx\Certificate\Tools\signtool.exe sign /v /s "xxx Certificate Store" /n "xxx Signierung" /fd SHA256 "E:\Projects\Projects_Delphi\xxx\_out\Development_Runtime\xxx.exe" 
E:\Projects\Projects_Delphi\xxx\Certificate\Tools\signtool.exe verify /pa /v "E:\Projects\Projects_Delphi\xxx\_out\Development_Runtime\xxx.exe" 

copy E:\Projects\Projects_Delphi\xxx\_out\Development_Runtime\xxx.exe E:\Projects\Projects_Delphi\xxx\_out\app\KTE_Release\Win32\xxx.exe

PS: xxx_Release\Win32\xxx.exe hat das richtige Zertifikat, _out\Development_Runtime\xxx.exe nicht
...das ist die Frage.

Danke...

[himitsu]

Nee, sieht OK aus.

Wenn die KTE_Release das hat, dann muss die Development_Runtime das natürlich auch haben, dazumal in der ja die Signatur hinzugefügt wurde.

Und egal ob das Zertifikat installiert ist oder nicht, angezeigt muß es dennoch werden, da es ja in der EXE drin stekt.
Das "Installiert" im Zertifikatsspeicher entscheidet nur darüber wie es angezeigt wird, also ob es verifiziert werden kann oder nicht.


Ich denke hier eher daran, dass z.B. der Explorer noch den alten Inhalt anzeigt und nicht aktualisiert wurde.
Ich hab das öfters mal mit der Dateigröße oder dem Änderungsdatum ... da hilft dann nichtmal ein F5 oder Explorer zu+auf ... aber mal kurz den Dateieigenschaftendialog auf und schon stimmte es auch in der Liste wieder, das kappte bisher eigentlich immer.


Aber du weißt doch bestimmt selbst, dass eine Fehlerhandlung nie schaden kann.

Code:

@echo off

:: ExitCode: 0 = OK / 1 = Failure / 2 = Warning

set file=xxx
set outdir=E:\Projects\Projects_Delphi\%file%\_out
set signtool="E:\Projects\Projects_Delphi\%file%\Certificate\Tools\signtool.exe"

if not exist "%outdir%\Development_Runtime\%file%.exe" exit /b 1
if not exist "%outdir%\app\KTE_Release\Win32" (
  md "%outdir%\app\%file%_Release\Win32"
  if errorlevel 1 exit /b 1
)

%signtool% sign /v /s "%file% Certificate Store" /n "%file% Signierung" /fd SHA256 "%outdir%\Development_Runtime\%file%.exe"
if errorlevel 1 exit /b %errorlevel%

%signtool% verify /pa /v "%outdir%\Development_Runtime\%file%.exe"
if errorlevel 1 exit /b %errorlevel%

copy "%outdir%\Development_Runtime\%file%.exe" "%outdir%\app\KTE_Release\Win32\%file%.exe"
if errorlevel 1 exit /b 1

@ : damit auch das echo off nicht angezeigt wird, weil ist ja erst danach aus
set : damit das Ganze bissl übersichtlicher wird
exit 123 und errorlevel : damit man außerhalb auch eine Fehlerprüfung vornehmen kann, z.B. im FinalBuilder/BuildServer/BuildScript oder Dergleichen das Ergebnis auswerten
exit /b statt exit : damit nur dieses Script abgebrochen und nicht gleich ALLEs (das aufrufende Script)

Statt BEFEHL mit anschließendem IF ginge z.B. auch COPY source dest || exit 1 , also wenn beim Ersten der ErrorLevel > 0, dann das Zweite ausführen.
https://ss64.com/nt/syntax-conditional.html

Code:

deine.cmd
if errorlevel 1 echo Fehler %errorlevel% & pause

[haentschman]

Danke...

Morgen habe ich Zeit mich damit zu beschäftigen.

[himitsu]

Na dann viel Spaß.

PS: noch was bezüglich dem @
Alles unsichtbar, abgesehn von den 3 großen Aufgaben, so als Status-/Fortschtittsanzeige,
alternativ geht aber auch ECHO oder TITLE.

Und :: ist ein unsichtbarer Kommentar, ähnlich einem @REM, wobei das Unsichtbar mir da nie so wichtig ist ... es ist im Code einfach übersichtlich/auffällig und kein REM-Wort stört den Text)

Code:

:: ExitCode: 0 = OK / 1 = Failure / 2 = Warning

@set file=xxx
@set outdir=E:\Projects\Projects_Delphi\%file%\_out
@set signtool="E:\Projects\Projects_Delphi\%file%\Certificate\Tools\signtool.exe"

@if not exist "%outdir%\Development_Runtime\%file%.exe" exit /b 1
@if not exist "%outdir%\app\KTE_Release\Win32" (
  md "%outdir%\app\%file%_Release\Win32"
  if errorlevel 1 exit /b 1
)

%signtool% sign /v /s "%file% Certificate Store" /n "%file% Signierung" /fd SHA256 "%outdir%\Development_Runtime\%file%.exe"
@if errorlevel 1 exit /b %errorlevel%

%signtool% verify /pa /v "%outdir%\Development_Runtime\%file%.exe"
@if errorlevel 1 exit /b %errorlevel%

copy "%outdir%\Development_Runtime\%file%.exe" "%outdir%\app\KTE_Release\Win32\%file%.exe"
@if errorlevel 1 exit /b 1

[haentschman]

Moin...

Zitat:

Na dann viel Spaß.

...der ironische Unterton ist mir nicht entgangen.

[haentschman]

Moin...

Neuigkeiten:
1. Wenn ich die BAT nach dem kopilieren manuell ausführe, ist alles so wie es sein soll. Alle Dateien haben das Zertifikat.
2. Wenn ich die BAT als Postbuild Event ausführen lasse, habe ich die Konstellation wie im Eingangspost.
...es sieht danach aus, daß die IDE nach dem PostBuild Event die Datei nochmal überschreibt. Das paßt zu "die Kopie hat das Zertifikat, das original nicht".
...oder das PostBuild Event ist eigentlich ein PreBuild Event.

Jetzt fällt mir nichts mehr ein...

[himitsu]

Das PostBuild ist ja gerade für sowas da.

Nett ist, dass ich demächts auch sowas machen wollte,
also das blöde Eurekalog aus Delphi rauswerfen, weil es beim Debuggen absolut nervt.
Und dann im PostBuild manuell Eurekalog-Infos nur "anhängen" und wenn ich schon dabei bin auch endlich mal die schon lange überfällige Signierung hinzufügen.

Wenn man Eurekalog das selbst machen lässt, dann pfuscht der an den DCC-Setings rum und macht die Delphi-Debuginfos kaputt (denkt wohl seine Debuginfos sind besser und man braucht die Anderen nicht, was der Debugger aber anders sieht)
und dann natürlich ÜBERALL die schwachsinnigsten Hooks, in denen ich ständig lande und nicht mehr raus finde.


Da wirst wohl mal mit SysInternals nachsehn müssen, ob die Datei wirklich anschließend nochmal verändert wird, bzw. wer das macht, was ja eigentlich nicht passieren sollte.
Oder ganz böse: im PostBuild eine EXE starten, welche die Datei öffnet (Sharing: ohne Schreibrechte für Andere) und geöffnet lässt und dann schauen wo Delphi knallt.

Hängt vielleicht noch ein Addon im Delphi?
Via OpenToolsAPI im PostBuild ... k.A. in welcher Reihenfolge die ausgeführt werden.




PS: Im PreBuild hättest du ja noch die alte EXE (oder noch Keine), weil ist ja davor.

Ins PreBuild war ich schon drauf und dran irgendwann mal eine Prüfung einzubauen:
Läuft EXE noch, dann benenden. (vergesse ich manchmal, wenn ich die ohne Debugger starte, bzw. wenn sie beim Beenden im Hintergrund noch hängt)

[haentschman]

Hallöle...

Zitat:

SysInternals

...auf die einfachen Sachen kommt man nicht.

Zitat:

Hängt vielleicht noch ein Addon im Delphi?

Die üblichen Verdächtigen...MadExcept, CnPack

Info:
Nach Deaktivieren des MadExcept ist die EXE mit dem Zertifikat versehen. Das kann man beliebig oft wiederholen. Wahrscheinlich wird die EXE nach dem PostBuild vom MadExcept noch/erst gepatcht.
Eine Mail an Matthias ist raus... Schaun wir, was er sagt.

[himitsu]

Aber dann sollte doch dennoch das Zertifikat drin sein, weil wenn, dann darf/kann MadExcept die bestehende Datei doch nur ändern/erweitern,
auch wenn das Zertifikat dann vielleicht "ungültig" ist, weil die Datei verändert wurde.

Stimmt, also das gleiche Problem, was ich mit Eurekalog oft hab,
dort wird ja auch anschließend noch aus der MAP-Datei eine detailiertere Debuginfo erstellt und in die EXE eingefügt.

[himitsu]

Zitat:

Wahrscheinlich wird die EXE nach dem PostBuild vom MadExcept noch/erst gepatcht.

Drum will ich ja den ECC anschließend manuell aufrufen, also im PostBuild.
Und das Designtime-Package von denen aus'm Delphi rauswerfen.

Denn aktuell kann ich mit FinalBuilder kompilierte Dateien nicht richtig debuggen
und muß einige/alle nochmals im Delphi kompilieren, weil sich diese Dateien unterscheiden (Dateigröße und eben dass der Debugger keine Haltepunkte mehr findet)
Scheinbar arbeiten die Wenigsten mit Eurekalog und exzessiv mit Packages oder es benutzt wirklich fast niemand den Debugger ... k.A. warum sonst so Wenige damit Probleme haben.

Im Delphi hängt sich Erekalog rein und macht sein Ding beim Kompilieren.
Und im FinalBuilder ruft der FB den ECC statt dem DCC auf.
Der ECC pfuscht dann noch bissl an den Compiler-Settings rum, startet den DCC und modifiziert anschließend die EXE.

Das will ich gern auf MSBUILD umstellen, welches statt der DPR direkt die DPROJ mit den "selben" Optionen und inkl. PostBuild ausführt, so dass "hoffentlich" im Delphi und FB die selben Dateien entstehen.
Wenn erst DCC ausgeführt wird und der ECC nur noch seine DebugInfos "anhängt", ohne die EXE und Compileroptionen zu verpfuschen.

MSBUILD xyz.dproj
* DCCxxx
* PostBuild
** PE-Flags ändern/prüfen (wegen Netzlaufwerken)
** ECC, WasEigenes oder MadExcept
** SignTool

Weil aktuell nutzt der FB seine eigenen Projekoptionen und Delphi nutzt die aus der DPROJ ... alles Doppelt, auch wenn bei den wichtigsten Projekten die Optionen "eigentlich" gleich sind, kommt dennoch was ganz Unterschiedliches bei raus.


Wobei ich den Eurekalog eher mal gern rauswerfen werde/würde, da wir effektiv eh nur den Stacktrace und Fehlerdialog benutzen und die Masse der meisten Hooks eher nervt, als hilft.
Und dann mach ich das selbst.
* VCL-Fehlerdialog ersetzen (unten den Stack mit anhängen)
* an Exception meine eigenen zwei/drei StackTrace-Frunktionen registrieren Exception.StackTrace
** StackStrace erstellen mit der WinAPI StackWalk
** die Delphi-DebugInfos in Windows-DebugInfos übersetzen (map2dbg.exe oder tds2pdb.exe)
** am schönsten wäre es, wenn ich noch rausbekomm, wie ich die PDB von der Einzeldatei in die EXE verschiebe ... sind beides PE-Dateien und die Debuginfo hängt als Section drin