Attributed metadata history

3.5

Highlights Runs on a 256 MB Raspberry Pi The trail update needed ~1.1 GB and was OOM-killed on small boxes, and the sensor needed 153 MB, twice that across a trail reload. Measured in a 221 MB container with no swap, against the full 1.9M-trail set: 3.4 3.5 trail update (peak) 1,144 MB 69 MB sensor (steady) 153 MB 32 MB sensor during a reload 304 MB 58 MB The static trail set is streamed from its cache instead of being held in memory whole: the update peaks at ~255 MB on every machine now, not 1.1 GB. Below 768 MB available (container and systemd limits included), the merge spills to a SQLite file. Same code, byte-identical trails.csv. UPDATE_SERVER downloads stream to disk. The sensor's trail store is file-backed (reclaimable page cache instead of heap); lookups measured the same speed. Hosts with under 1 GB get a capture ring of 10% of RAM instead of 64 MB. Thanks to @gpaterson for the report and the idea (#19641). 32-bit ARM sensor New static ARMv6 build, arm-unknown-linux-musleabihf: one binary for every 32-bit Raspberry Pi, Pi 1 and Zero included, on Raspberry Pi OS, DietPi or Alpine. install.sh picks it automatically, also on a 64-bit kernel with a 32-bit userland. Each release replays a trail through it on an emulated Pi 1 CPU and refuses to publish a binary that does not detect it. Also Basic sensor status on the dashboard (#19627). Windows installer (install.ps1); NetBSD and OpenBSD added to the tested platform matrix. Workflows and shell scripts are linted in CI. Full list in CHANGELOG. Full Changelog: 3.4...3.5

This record contains metadata and attribution only. It does not host, download, unpack, render, or execute malware samples.