# kern 1.0.0-rc3 > The full rc2 security scan closed, the installer builds from source, and the runtime stopped leaking. Source: https://kern-lang.eu/releases/1.0.0-rc3 The full rc2 security scan closed, the installer builds from source, and the runtime stopped leaking ## Release notes rc3 closes every finding from the rc2 security scan (H-1 through H-9, M-1 through M-15) and adds three CI gates that did not exist: **AddressSanitizer**, **UndefinedBehaviorSanitizer** and **ThreadSanitizer**. ### The installer builds from source No prebuilt binary: the one-liner clones the release tag, builds the C runtime, verifies the published seed IR, compiles the compiler with the adopter's own clang, and proves the result by compiling and running a program. The trust gates run on the adopter's machine. ### Container host sealed (H-1): seccomp filters compose monotonically, so the host seal now installs on top of the workload seal; the premise "a container host cannot be sealed" was wrong. ### Handle lifetime (H-3/H-5): Channel, Mutex, RwLock and thread-pool handles are now GC objects with trace and destroy hooks; 500,000 channels created and dropped left 163 MB resident and added 2 ms to every collection, now 22 MB flat. ### `chan_select` race (H-4): two selectors woken by one send both returned the same index; one took the value, the other hung for ever. A reservation protocol settles it. ### `pd_anonymize` deleted (M-3): it returned the first byte plus asterisks, not anonymisation; `pseudonymise(key, data)` is the named primitive for a stable, join-preserving surrogate. ### Mutex\ and RwLock\ value slot was unguarded (H-2): the type whose purpose is mutual exclusion provided none for the value it holds, and E0309's own fix-it text recommended the pattern. A second lock guards the value slot now, and ThreadSanitizer over the concurrency pins is the evidence, not a passing test. ### The fuzzer found an out-of-bounds write in the GC collector On its first real run; the harnesses had been running a unit test.