From 822c771842bc37bcbac901f045ea570666d5940b Mon Sep 17 00:00:00 2001 From: Ray Walker Date: Wed, 28 Oct 2026 08:27:24 +0000 Subject: [PATCH] fix(readme): describe the aarch64 Crypto Extension probe cachekit-core 0.7.0 replaced the aarch64 NEON check with a runtime probe for the Armv8 Crypto Extension AES instructions, and the core-ts 0.2.1 binding embeds it. The README still described the cachekit-core 0.6 behaviour (true on every aarch64 build). --- packages/cachekit/README.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/packages/cachekit/README.md b/packages/cachekit/README.md index 466c5921..ff52c22b 100644 --- a/packages/cachekit/README.md +++ b/packages/cachekit/README.md @@ -728,9 +728,10 @@ crypto backend picks its implementation independently, so use it to explain `.secure` latency, not to change behaviour. It initialises the bindings if needed, and returns `null` (unknown) only when the installed binding predates the accessor. The per-architecture semantics are core's — as of -cachekit-core 0.6 a runtime AES-NI probe on x86/x86_64, `true` on every aarch64 -build (a NEON check, not the Crypto Extension), and `false` on Cloudflare -Workers (wasm32 has no AES instructions). +cachekit-core 0.7.0 a runtime AES-NI probe on x86/x86_64, a runtime probe for +the Armv8 Crypto Extension's AES instructions on aarch64 (a Raspberry Pi 4, a +Cortex-A72 without the Crypto Extension, reports `false`), and `false` on +Cloudflare Workers (wasm32 has no AES instructions). ```typescript import { EncryptionManager } from '@cachekit-io/cachekit';