oscam 11888 problem

[Kind regards]

das läuft auf u18lts hier auch nicht mehr ... weder mit ssl3 - noch mit ssl1.1!

eben mal im /tmp mit fresh checkout s3 gestestet

Du musst Regestriert sein, um das angehängte Bild zusehen.

was soll da nicht funktionieren?

 

[Token]

das erstellen ist nicht das problem, aber das binary startet auf U24 + U18 (hier) nicht wg.s sign error!

 

[Kind regards]

startet auch problemlos

Spoiler: siehe hier:

16:46:42 00000000 s  (signing) Signature      = Valid - Binary's signature was successfully verified using the built-in Public Key
16:46:42 00000000 s  (signing) Certificate    = Trusted CA Certificate, valid until 18.10.2026 16:31:35
16:46:42 00000000 s     (main) waiting for local card init
16:46:42 399B4956 h    (webif) webif: decompressed 178327 bytes back into 480728 bytes
16:46:42 399B4956 h    (webif) HTTP Server running. ip=0.0.0.0 port=8888 (no SSL)
16:46:42 00000000 s     (main) init for all local cards done

Unix Starttime: 1760799733
Starttime:      18.10.2025 17:02:13
Build Date:     18.10.2025 16:31:36
Version:        2.25.10-11899@ba95185b
Compiler:       x86_64-linux-gnu-ssl
Box Type:       generic (generic)
PID:            49881
TempDir:        /tmp/.oscam
GBox tmp_dir:   not defined using: /tmp/.oscam
ConfigDir:      /usr/local/etc/
WebifPort:      8888

Signature:      Valid - successfully verified using built-in Public Key
  Signer:       OpenSSL 3.6.0 1 Oct 2025
  SHA256:       3994deac8c2f67d4acde789a4e5e7ef55423ce4d35427d3e58e48c2e3bdf5d3b
Certificate:    Trusted CA Certificate
  Subject:      CN=Private OSCam CA Certificate
  Issuer:       CN=Private OSCam Root CA
  Version:      3
  Serial:       01394c20a0c6edcc87ab240c285a881f3161dc0f
  Fingerprint:  16583c9f6b800f3e22c965b08c2445b5b9b97cae
  Valid from:   18.10.2025 16:31:35
  Valid to:     18.10.2026 16:31:35
  Status:       Valid
  Type:         256 bit ECDSA Key

 

[Token]

hmm, dann baue+teste ich das hier nochmal!
auf jeden Fall erstmal Danke fürs gegentesten!
(wobei, du hast ein Debian14 getestet - wir sprechen hier von Ubuntu!)

 

[Kind regards]

kannst du ja auch im /tmp mal eben gegen checken -->bebaut mit : OpenSSL 3.6.0 1 Oct 2025 (Library: OpenSSL 3.6.0 1 Oct 2025)

cd /tmp
git clone https://github.com/gorgone/s3_releases.git s3

 

[Token]

edit: nee, das geht auch nicht !!! einzigste änderung war s3.590 -> .592

ich mache mal die certs komplett neu!
=> nee, auch das hilft nicht!
17:36:35 00000000 s (signing) Signature = Error: Binary's signature is invalid! Shutting down...
17:36:35 00000000 s (signing) Certificate = Trusted CA Certificate, valid until 18.10.2026 17:31:26

okay, dann baue ich eben ohne Sign erstmal weiter - das müssen sich dann die Profi's anschauen - da bin ich leider raus!

 

[Kind regards]

dann stimmt mit deinem openssl auf der Maschine was nicht , S3 kann man ausschließen, da es hier mit aktuellster Umgebung problemlos läuft
teste gleiches mal auf einem Ubuntu , moment

Spoiler: auch kein Problem

Du musst Regestriert sein, um das angehängte Bild zusehen.

 CONFIG ----->    build/x86_64-linux-gnu-ssl/config.c
 BUILD ------>    oscam.c
 LINK ------->    /tmp/s3/support/binaries/oscam-git11899@ba95185b-Linux-x86_64-webif-dvbapi-ssl-signed.debug
 SIGN ------->    SHA256(64): 05f37f15a26b85451d92d4c61310b387ef582b0ef234424bac497a8693dc130a -> Verified OK <- DIGEST(71)
 STRIP ------>    /tmp/s3/support/binaries/oscam-git11899@ba95185b-Linux-x86_64-webif-dvbapi-ssl-signed
 SIGN ------->    SHA256(64): 63f9a5b48a5b159a0a516efb4f2f86a8ea1049c223cf4e54cafc422bb533c6c9 -> Verified OK <- DIGEST(71)
 REMOVE ----->  /tmp/s3/support/binaries/oscam-git11899@ba95185b-Linux-x86_64-webif-dvbapi-ssl-signed.debug
 TIME -------> [  0 min(s) 3 secs ]

19:29:47 00000000 s  (signing) Signature      = Valid - Binary's signature was successfully verified using the built-in Public Key
19:29:47 00000000 s  (signing) Certificate    = Trusted CA Certificate, valid until 18.10.2026 19:29:20
19:29:47 00000000 s     (main) waiting for local card init

auch auf 18er Ubuntu no Problem

Spoiler: siehe hier:

Starttime:      18.10.2025 19:43:54
Build Date:     18.10.2025 19:43:29
Version:        2.25.10-11899@ba95185b
Compiler:       x86_64-linux-gnu-ssl
Box Type:       generic (generic)
PID:            11740
TempDir:        /tmp/.oscam
GBox tmp_dir:   not defined using: /tmp/.oscam
ConfigDir:      /usr/local/etc/
WebifPort:      8888

Signature:      Valid - successfully verified using built-in Public Key
  Signer:       OpenSSL 1.1.1 11 Sep 2018
  SHA256:       26c4471a583edfcc0525113613dd0b26efcd0422b555babcdd030a56bdcb0a54
Certificate:    Trusted CA Certificate
  Subject:      CN=Private OSCam CA Certificate
  Issuer:       CN=Private OSCam Root CA
  Version:      3
  Serial:       0d602080c7186f82f0d407c334257317c88bfe04
  Fingerprint:  154ddeb83e8d9f2fca9f54170154134ede9198f2
  Valid from:   18.10.2025 19:43:28
  Valid to:     18.10.2026 19:43:28
  Status:       Valid
  Type:         256 bit ECDSA Key

 

[WXbet]

Ich gebe auch mal meinen Senf dazu. Die Signaturprüfung beim Start von oscam reagiert (technisch bedingt) unter Umständen allergisch auf nicht konkrete Pfadangaben beim Aufruf von oscam.
Wenn man im Pfad des Binaries steht und einfach nur z.B. oscam -V aufruft, schlät die Prüfung mitunter fehl. Am Besten ruft man oscam immer mit kompletter Pfandangabe auf, also z.B. /usr/bin/oscam -V.

Warum ist das so?
Beim Start von oscam wird der main-Funktion als Parameter immer der Name, unter dem das Programm aufgerufen wurde, übergeben, also der Pfad oder Name der ausführbaren Datei selbst (das ist C Standard). Das Betriebssystem entscheidet, welchen genauen String es in den Parameter einträgt — das kann also ein relativer oder absoluter Pfad sein, je nachdem, wie du oscam startest. Da oscam, welches in den Speicher geladen und ausgeführt wird, sich sozusagen nochmal selbst einer Signaturprüfung unterzieht, muss es das Binary aus dem Parameter auch finden können. Das ist ohne konkrete Pfadangabe mitunter schlicht nicht möglich.

 

[Kind regards]

dann nur zu Info:
habe bei meine Tests (Debian & Ubuntu) mit einem frisch ausgechektem S3 gebaut und die gebauten *.bins dann auch direkt in /tmp/s3/binaries/ gestartet
dann hatte ich wohl nur Glück

Spoiler: und noch mehr Glück: auch Alex-Bin startet auch ohne Probleme

Du musst Regestriert sein, um das angehängte Bild zusehen.

 

[Token]

u18,upx4,11899 läuft nun auch wieder mit sign!
ich denke, das wird dann mit u24 auch wieder funktionieren! => edit: macht es nun auch!
=> also saß das Problem hier auch letztendlich vor der Tastatur!
=> dann braucht @Alex keine "Kopfstände" mehr machen ... alles nur falscher/blinder Alarm!
sry Guy's

 

[Kind regards]

=> also saß das Problem hier auch letztendlich vor der Tastatur!

ich habe doch gern für dich alle Möglichkeiten durchgetestet

 

[Token]

@Kind regards
ich wollte ja nur, das du nicht aus der übung kommst!