Skip to content

fix(readme): describe the aarch64 Crypto Extension probe (LAB-4654) #267

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
27b-merge-warden merged 1 commit into from
Oct 28, 2026
Merged

fix(readme): describe the aarch64 Crypto Extension probe (LAB-4654) #267

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions packages/cachekit/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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';
Expand Down
Loading