0.4.0 adds self-reporting: when the library loses a record, cannot deliver, stops, or refuses a collector’s certificate, it writes a syslog record saying so, into the trail itself. wolfSSL joins the TLS stacks, the store is tested adversarially on every change, and every CI run’s test results and coverage are published with the documentation.
0.3.0 made every loss visible: a record lost anywhere in the pipeline leaves a gap in the sequence number at the collector, and the device’s error handler is told what happened. What the collector could not see was why. An analyst looking at a gap in a controller’s audit trail knew that records were missing, and nothing more; the explanation stayed on the device.
SolidSyslog 0.4.0 closes that distance. When the library meets a failure of its own, it writes a syslog record about it, and that record travels the same path as the application’s: through the store during an outage, numbered in sequence, delivered when the link returns. A collector learns which audit-processing failure occurred, not only that records are missing. Reporting is on by default, and the product can turn it off, or back on, while the device runs.
What the collector sees
A report is an ordinary RFC 5424 record under the facility syslog reserves for the log system’s own messages. Its message ID names the failure, and one structured-data element, under our IANA private enterprise number, carries the component that raised it, the category, the detail, and where a platform call failed, the platform’s own code:
“text [solidsyslog@67478 source="BlockStore" category="STORE_FROZEN" detail="DEVICE_WRITE_FAILED"] “
Every value is an enumerator name or an integer; no record content, path or key material can appear in it. Sixteen kinds of failure are reported, among them records lost at a buffer, store or sender, a storage medium that failed, a stored record that failed verification, a key that was not available, a collector certificate that was refused, a halted logger, and a run of delivery failures beginning and ending. Each is reported once per run of the fault, so a storm does not flood the trail it is describing, and the sequence number tells the collector how many records went. A report bypasses the buffer, so a full buffer never refuses the report of its own loss. The self-reporting page specifies the record for whoever writes the collector rule that consumes it, and states what a stopped device cannot report.
What it means for compliance
IEC 62443-4-2 CR 2.8 lists audit log events among the categories a component records, and CR 2.10 asks that it respond appropriately to audit processing failures. 0.3.0 made the response a product decision; 0.4.0 puts the failure itself in the trail, so the trail accounts for its own gaps at the collector. Under the Cyber Resilience Act, Annex I Part I (2)(l) asks for the recording of relevant internal activity with an opt-out for the user, and the logging function’s own activity is in scope; the reporting switch is that opt-out. The IEC 62443 and CRA pages map each control. The cost is a table of pending events in static RAM, 256 bytes on a 32-bit target, and room in the message cap and the store for the reports themselves.
wolfSSL
wolfSSL is the third TLS stack, alongside OpenSSL and Mbed TLS: the stream and credentials roles, pinned fingerprints, cipher policy, mutual TLS, and both at-rest policies over wolfCrypt. It is tested on Linux and compiled from source into a QEMU Cortex-M image with static memory and no filesystem, the form an embedded integrator meets. The TLS contract is the same on all three stacks, so the choice follows what the device already links. The reference platforms now number fifteen: POSIX, Windows, C11 atomics, OpenSSL, Mbed TLS, wolfSSL, lwIP raw and sockets APIs, FreeRTOS-Plus-TCP, FreeRTOS, CMSIS-RTOS2, VxWorks 6.4, FatFs, FreeRTOS-Plus-FAT and LittleFS.
Proven against the medium
0.3.0 promised that a failing storage medium does not interrupt delivery. 0.4.0 proves it on every change. A new test applies a single media fault at every byte position of the store: a flipped bit, a byte stuck at one or zero, a read that fails at one offset, a truncated block, a block absent at open, a block that fails every operation, a block removed while the device runs, and power lost in the middle of a write. Every case runs under each at-rest policy and each discard policy, and each is judged by the same verdicts: no silent loss, no undetected damage, no write outside the faulted block, no unbounded work, and a store never left wedged. Alongside it, a scenario suite drives the real Core through scripted faults and seeded random walks, with the collector refusing, the medium failing, the key withheld, the queues filling and reporting switched off and on mid-run, and checks a table of invariants after every pass.
Evidence you can read
The documentation site now carries the test report and the coverage of the build that produced it: some twenty thousand tests across nineteen CI lanes, down to each test and how long it took, and line and branch coverage of Core and every pack a Linux host can build, gated at 99 percent. The release bundle carries the same report and coverage for the tagged commit, signed, so a technical file can hold the evidence of what was tested rather than a statement that it was. The release is tested against current upstreams: FreeRTOS V11.3.3, FreeRTOS-Plus-TCP V4.4.2, Mbed TLS 3.6.7, CMSIS 6.4, wolfSSL 5.9.4, FatFs R0.16 and lwIP 2.2.1.
By our own assessment SolidSyslog continues to meet every applicable clause of RFC 5424, 5425, 5426 and 6587; the compliance matrix holds the evidence. No defect is open at this release.
Footprint
On the worked example, the first compliant record is about 7.2 KB of flash and 2.8 KB of RAM. The complete path, with pinned TLS, certificate renewal, mutual TLS, encryption at rest and the device’s own discard policy, is about 23.9 KB of flash and 38.1 KB of RAM, measured on the running target. Against 0.3.0 that is about 1.3 KB more flash and 1.8 KB more RAM, spent on the reports and the room they need in the record. The hardening path states the cost of each stage.
Moving from 0.3.0
This is a 0.x release. The release notes list what to check under Before you upgrade. Both worked examples, CMake and GNU Make, have 0.4.0 releases rebuilt one commit per stage. The release carries a signed offline copy of its documentation, a signed software bill of materials and a signed source-tree hash.
Next
1.0.0 follows in Q4 2026. Any organisation can evaluate SolidSyslog free under the PolyForm Internal Use licence, with no time limit. Start from the product page or contact us about your product.
