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.78.0 | verified | 523a96e832e5947a… |
| amd64 | Node.js | nodejs.org | v24.21.0 | verified | fd8e59d5a511510f… |
| arm64 | FerretDB | wekan/FerretDB | v1.78.0 | verified | d8bb85c7ff49fe02… |
| arm64 | Node.js | nodejs.org | v24.21.0 | verified | 6ad1325edbdb5649… |
| armhf | FerretDB | wekan/FerretDB | v1.78.0 | verified | c4df2f4e6fe8fa9a… |
| armhf | Node.js | wekan/node-patches | v24.21.0 | verified | fcd7558bda05a44b… |
| armv6 | FerretDB | wekan/FerretDB | v1.78.0 | verified | eeb962ba8d7b76d7… |
| armv6 | Node.js | wekan/node-patches | v24.21.0 | verified | ea68d25e1eef47cb… |
| armv7 | FerretDB | wekan/FerretDB | v1.78.0 | verified | c4df2f4e6fe8fa9a… |
| armv7 | Node.js | wekan/node-patches | v24.21.0 | verified | 561b357700e2019c… |
| i386 | FerretDB | wekan/FerretDB | v1.78.0 | verified | c855b2f74a7c8b13… |
| i386 | Node.js | wekan/node-patches | v24.21.0 | verified | d3a55c1b0e22c164… |
| mac-arm64 | FerretDB | wekan/FerretDB | v1.78.0 | verified | 34d45b3eee2f322f… |
| mac-arm64 | Node.js | nodejs.org | v24.21.0 | verified | 6239d4cf92d86448… |
| mac-x64 | FerretDB | wekan/FerretDB | v1.78.0 | verified | 1fd4a358aae472d9… |
| mac-x64 | Node.js | nodejs.org | v24.21.0 | verified | 0ae5a24c24bb7d01… |
| ppc64le | FerretDB | wekan/FerretDB | v1.78.0 | verified | ae5e77d7e26ff668… |
| ppc64le | Node.js | nodejs.org | v24.21.0 | verified | 1936fd64623a2f98… |
| riscv64 | FerretDB | wekan/FerretDB | v1.78.0 | verified | c52b5d9b477d8a73… |
| riscv64 | Node.js | unofficial-builds.nodejs.org | v24.21.0 | verified | 5c4e83d46cc1f8ee… |
| s390x | FerretDB | wekan/FerretDB | v1.78.0 | verified | 5f6e44510345e653… |
| s390x | Node.js | nodejs.org | v24.21.0 | verified | 2ef7e2ecbf7a6c2f… |
| win-arm64 | FerretDB | wekan/FerretDB | v1.78.0 | verified | ebd8eb6dac62319d… |
| win-arm64 | Node.js | nodejs.org | v24.21.0 | verified | 8779b1bde1d39f8d… |
| win64 | FerretDB | wekan/FerretDB | v1.78.0 | verified | 39b8bd8b95754497… |
| win64 | Node.js | nodejs.org | v24.21.0 | verified | 158f7685b44de51f… |
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.67 2026-09-10 WeKan ® release
In short: Board export to .zip (with attachments) answered a bare 500 error on every request; the archiver dependency's v8 API change was missed in one of the two places WeKan builds a zip on the server. Issue [#6681] (OIDC redirect-style login loop) is confirmed already fixed and closed.
This release fixes the following bug:
Board export to .zip (with attachments) answered a bare 500 error
`models/server/ExporterZip.js` still called the archiver package the v7 way - `const archiver = require('archiver'); archiver('zip', {...})`. archiver@8 (package.json pins `^8.0.0`) is ESM-only and exports classes - `{ Archiver, ZipArchive, TarArchive, JsonArchive }` - with no callable default, so that call threw `TypeError: archiver is not a function` synchronously, before the `exportZip` route (models/export.js) had written any response header. `safeRoute` (server/apiMiddleware.js) then answered a bare 500 with no board-specific detail - every "export board -> .zip (with attachments)" request, for every board, since archiver was bumped to v8. `server/methods/backup.js` hit the identical break earlier and already fixed it with `import { ZipArchive } from 'archiver'; new ZipArchive({...})`; `ExporterZip.js` was the one call site that was missed. Fixed the same way. `tests/exportZipArchiverApi.test.cjs` pins the correct API shape, that the dead factory call is gone, and scans every server-side source file so a second call site cannot reintroduce the same break unnoticed.and closes the following already-fixed issue:
Confirm [#6681] (OIDC redirect-style login loop) stays fixed
The reporter's `DEBUG=true` server log (getToken/getUserInfo repeating six times in under twenty seconds, each with a fresh access token) is the same signature the fix for [#6681] already targets: `oauth2-login-style: redirect` with `oidc-redirection-enabled: true`, `Template.userFormsLayout.onCreated` re-firing the auto-redirect on the identity provider's bounce-back render before the prior login had finished. That was fixed by commit 89682c251 ("Fix OIDC auto-redirect looping until the provider rate-limits it"), which landed before v11.62 - several releases before this one - so a build the reporter's log shows as v11.60 predates the fix, and the fix has not been touched since. `tests/oidcAutoRedirectLoop.test.cjs` (6 checks) still passes against current source, confirming the one-shot sessionStorage flag still gates the auto-redirect and is still cleared on both login success and failure. No new code change was needed; the issue is closed with a pointer to where it was already fixed, and the reporter is asked to upgrade to v11.62 or newer.Thanks to above GitHub users for their contributions and translators for their translations.