Binaries in these bundles
Each bundle carries a Node.js, a FerretDB and the MongoDB Database Tools. Which source has a given CPU varies from release to release - nodejs.org builds some architectures, unofficial-builds others, and the wekan/node-patches build the ones neither of them does - and not every source publishes a checksum. This is what went into this release, and which downloads were checked against a published SHA256.
| Bundle | Binary | From | Version | Checked | SHA256 |
|---|---|---|---|---|---|
| amd64 | FerretDB | wekan/FerretDB | v1.66.0 | verified | 1ad06f66f40811ce… |
| amd64 | Node.js | nodejs.org | v24.20.0 | verified | 2f2c0da162318f0d… |
| arm64 | FerretDB | wekan/FerretDB | v1.66.0 | verified | d46e712d1cbacc5a… |
| arm64 | Node.js | nodejs.org | v24.20.0 | verified | 5f4ddab610c1ab20… |
| armhf | FerretDB | wekan/FerretDB | v1.66.0 | verified | 981c0d36cfc518ff… |
| armhf | Node.js | wekan/node-patches | v24.20.0 | verified | b8ed7065d44f0afe… |
| armv6 | FerretDB | wekan/FerretDB | v1.66.0 | verified | 0c324a06fc5af400… |
| armv6 | Node.js | wekan/node-patches | v24.20.0 | verified | d5cefa6f8cc4acb1… |
| armv7 | FerretDB | wekan/FerretDB | v1.66.0 | verified | 981c0d36cfc518ff… |
| armv7 | Node.js | wekan/node-patches | v24.20.0 | verified | c04c81e539347f39… |
| i386 | FerretDB | wekan/FerretDB | v1.66.0 | verified | 4f8dc04310608f27… |
| i386 | Node.js | wekan/node-patches | v24.20.0 | verified | bb44927307460dcf… |
| mac-arm64 | FerretDB | wekan/FerretDB | v1.66.0 | verified | b57f4c1a3811fa73… |
| mac-arm64 | Node.js | nodejs.org | v24.20.0 | verified | b7bf7707070b950b… |
| mac-x64 | FerretDB | wekan/FerretDB | v1.66.0 | verified | fffc0c0824f2019f… |
| mac-x64 | Node.js | nodejs.org | v24.20.0 | verified | 26fc30891004603d… |
| ppc64le | FerretDB | wekan/FerretDB | v1.66.0 | verified | bc0623f4c84593c2… |
| ppc64le | Node.js | nodejs.org | v24.20.0 | verified | 341307dcee20d883… |
| riscv64 | FerretDB | wekan/FerretDB | v1.66.0 | verified | a4ad264602c2f188… |
| riscv64 | Node.js | unofficial-builds.nodejs.org | v24.20.0 | verified | a149c5bf85f98ff1… |
| s390x | FerretDB | wekan/FerretDB | v1.66.0 | verified | 0109c0c09234c5ff… |
| s390x | Node.js | nodejs.org | v24.20.0 | verified | ca381121cb5a8d38… |
| win-arm64 | FerretDB | wekan/FerretDB | v1.66.0 | verified | 63d88a9546753709… |
| win-arm64 | Node.js | nodejs.org | v24.20.0 | verified | 31c6799744de8a54… |
| win64 | FerretDB | wekan/FerretDB | v1.66.0 | verified | 4a3db57c76179ad5… |
| win64 | Node.js | nodejs.org | v24.20.0 | verified | 6cac9ffbca8f6a47… |
A row saying no checksum published is not a failed check - it is a source that publishes nothing to check against. Those are the ones worth fixing at the source.
v11.42 2026-09-01 WeKan ® release
In short: Persistent sessions now remain valid with FerretDB when login tokens are matched through nested arrays. Cross-database conformance protects the corrected logical OR behavior on every available backend.
| Platform | Binary | From | Version | SHA256 |
|---|---|---|---|---|
| amd64 | Node.js | nodejs.org | v24.19.0 | 14b342e71204f811bde6153be8e04b62aef63c236fef92b55f9c83154b409647 |
| amd64 | FerretDB | wekan/FerretDB | v1.53.0 | eae1f0a8f73bfc979738bfff7284d40fd1bc55de2cc56514721fc155c3624f7d |
| arm64 | Node.js | nodejs.org | v24.19.0 | 01443c1e1a29e531ccad5a46fefa6df490d2189c49f7955904aecdbb0fe86fdc |
| arm64 | FerretDB | wekan/FerretDB | v1.53.0 | bdc50caee3ac28495b42d2130b94a042a9dd6d3a38f732cac02b648f36c891da |
| mac-arm64 | Node.js | nodejs.org | v24.19.0 | 3f1cf157479c1480352083105e13faf9d008ede98e7e157746b6df940d197b94 |
| mac-arm64 | FerretDB | wekan/FerretDB | v1.53.0 | cb14ffe93e285903e5a8a9c1821687ddb5b8a979a11c584bf4af534b272c6d3e |
| mac-x64 | Node.js | nodejs.org | v24.19.0 | d35e95230f46f6f0751df497c56622c6735e05d5e1fb1630996a005b9d328fe4 |
| mac-x64 | FerretDB | wekan/FerretDB | v1.53.0 | d97dfa9afa60aa05f25384327de82efe7b71d958ed24c1f66618284294a65cd3 |
This release fixes the following bug:
Persistent login-token lookup works through nested arrays. Thanks to jeremy-arsia and xet7.
FerretDB's SQLite query optimization translated a logical OR into SQL when every branch appeared safe, but its direct dotted JSON accessor could not follow a path through the `loginTokens` array. It discarded the matching user before the Mongo-compatible filter ran, so HttpOnly cookie refresh returned `invalid_cookie` and logged the user out shortly after login. Logical OR filters with dotted paths now remain in the authoritative Go matcher, while safe scalar OR queries keep their optimized SQL path. Positive collection coverage reproduces the nested-token lookup and a negative builder test prevents the unsafe pushdown.and improves developer tooling:
Every available database verifies logical OR matching through dotted arrays. Thanks to jeremy-arsia and xet7.
The shared FerretDB conformance catalogue now reproduces the nested-array query from FerretDB issue 17 instead of testing dotted paths and logical OR only in isolation. The current arm64 run built FerretDB from commit `a7c9441b` and ran all 103 cases on SQLite, PostgreSQL, MySQL and MariaDB. Every backend answered every case identically with no errors. SAP HANA remains the script's explicit opt-in backend and has no arm64 image, so it could not run on this machine.Thanks to above GitHub users for their contributions and translators for their translations.