https://gitlab.synchro.net/main/sbbs/-/commit/acd48ef0dee5cff429293734
Modified Files:
src/sbbs3/js_cryptcert.cpp js_cryptcon.cpp js_cryptkeyset.cpp ssl.c ssl.h
Log Message:
ssl: report why cryptlib initialization failed

A CryptContext/CryptCert/CryptKeyset constructor whose do_cryptInit()
call failed threw a bare "do_cryptInit failure", naming neither the
cryptlib status nor the step that produced it. The detail did exist -- do_cryptInit() logs it -- but the lprintf it logs through is the one
declared in sbbs.h, i.e. main.cpp's, which returns 0 when startup is
NULL. Under jsexec nothing is printed at all, so the reason was gone.
The windows-x86 jsexec-testsuite job failed all three exec/tests/crypt
tests this way and left nothing to diagnose it with: https://gitlab.synchro.net/main/sbbs/-/jobs/1728391

Record the reason where it is discovered and hand it back through a new get_cryptInit_error(), which the three constructors append to the
exception. The JS error reporter is per-context and already routed
correctly, so the reason now arrives even where the C log line does not.

Return immediately when cryptInit() itself fails. Falling through to cryptGetAttribute() replaced the real status with CRYPT_ERROR_NOTINITED;
and had that call instead succeeded, the version and patch checks could
have gone on to set cryptlib_initialized on top of a failed init.

cryptfail becomes const char*: it now holds a literal on some paths and
a heap string on others, is written only under crypt_init_once, and is
never freed. Its log line drops the status code it would otherwise
print twice, and no longer reports "cryptInit() returned 0" for a
version or patch-set mismatch, where cryptInit() had in fact succeeded.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net