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.

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.

v10.82 2026-08-11 WeKan ® release

In short: a CRITICAL SECURITY ISSUE, WhereBleed: eight Admin Panel
handlers took a query selector from the client and checked only its type, so a
$where in one made the database run the caller's JavaScript - a repeatable
denial of service, reachable by a per-tenant admin. The detector for it was
already in the codebase and wired into one publication; the eight siblings never
called it, and now share the one copy. Then the snap, where two permanent
markers meant an instance that had failed on an older revision never retried on
the fixed one, so the MongoDB 4.2 reader added for it never ran.
Notifications grew an unbounded array inside the user document that SQLite
was rewriting on every addition, which is the slow login and the pinned CPU.
Clicking an open card closes it again, and a focused Admin Panel checkbox is
no longer drawn as a diamond. It also adds the first new feature in this
release: checklists and card feature groups fold away, on the opened card
and on the minicard, asked for since 2018. Below that: a typed two-digit year
refused rather than stored as the year 26, the Helm chart index listing only
charts that can be installed, and a way to remove the Templates containers made
for accounts that never used them. And two developer-facing fixes: the
database-conformance stage no longer opens a debug port nothing in it uses - one
taken by an unrelated FerretDB made every backend report a database problem that
was not one - and two more snap give-up paths that deleted the directory their
own stage filter names. The binaries below are v10.81's: nothing here rebuilds
them.

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.

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.

v10.81 2026-08-11 WeKan ® release

In short: the release pipeline, and two bugs that stopped WeKan starting at
all. FerretDB advertises its own listen address as the member list of a
one-node replica set, so the MongoDB driver threw away the host in MONGO_URL
and dialled 0.0.0.0:27017 instead - a fresh docker compose up could not
reach its database, and every FerretDB compose file now says
directConnection=true. All Boards on a phone could not be scrolled to its
last boards, its Table view could not be scrolled at all, single rows of board
icons were drawn several times their proper height, and the icons sat too close
together - four separate causes, one of them a calc(100dvh - 48px) in
layouts.css that guessed at a header height which is measured at runtime
precisely because it is never one number. On the release side: the Mac x64
bundle has never once been built, because its runner label was retired by
GitHub and a retired label queues forever instead of failing - and cancelling
that queue is what silently skipped the charts, ucs and nextcloud
jobs. The armv6 bundle was being assembled in a soft-float ARMv5 userland
that its own hard-float Node.js cannot start in, and every Launchpad snap
was ended by an optional MongoDB-migration part that stages a path it does not
build outside amd64 and arm64. Below that: a report of the WeKan releases the
Helm chart index is missing, and the duplicate entries found in it. The
binaries below are v10.80's: nothing here rebuilds them.

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.

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.

v10.80 2026-08-10 WeKan ® release

In short: the Admin Panel, in the two panes v10.79 had just changed.
Version is one table again rather than five: five tables sized their columns
independently, so the values started at a different x in every category. The
categories are rows inside one table now - bold, spanning both columns - over
two equal 50% columns. Problems / Filesystem integrity drew a blank page:
the one piece of its wiring that was missing was a template helper, and Blaze
reads an undefined helper as false rather than complaining. The binaries below
are v10.79's: nothing here rebuilds them.

This release reorganises the Admin Panel:

Admin Panel / Settings - the Version pane, and how it lays itself out.

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.

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.

v10.79 2026-08-10 WeKan ® release

In short: two new platforms and the snap jobs. WeKan now builds a
win-arm64 bundle - Windows on ARM - which needed no new work anywhere else,
because nodejs.org, FerretDB and the MongoDB tools all publish that
architecture already and nothing here had asked for it. armv6 - Raspberry
Pi 1 and Zero - was the opposite: nobody publishes a Node.js for it any more,
so wekan/node-patches gained an armv6 target, and FerretDB and the MongoDB
tools gained GOARM=6 ones beside their armhf builds. It ships as a bundle zip
and no snap, because the Snap Store has no armv6 architecture at all; the
Docker image is wired for it too, but stays gated until a base image
publishes linux/arm/v6 — Debian has no ARMv6 port, and a request for one
silently resolves to soft-float armel rather than failing. (armv5
and armel still cannot be added at all: V8's accepted --arm-arch list stops at
armv6, so there is no Node.js to build.) On the snap
side, one thing had been quietly failing for months: armhf asked Caddy for
a linux_armhf archive that has never existed - Caddy is built by Go and its
assets carry Go's architecture names -
and riscv64, ppc64el and s390x each built a perfectly good snap that
the Snap Store then refused while processing it, with an error about its own
duplicate check; the upload is retried now, and the message no longer blames
credentials. Beside that, the amd64 bundle had never recorded where its
Node.js and FerretDB came from - not because the directory was wrong, which was
last release's fix, but because the scripts themselves were never found, and the
|| true meant for release notes swallowed the error every run. Below that, the
CPU platforms of the image and of the snap now have a page each, and the
FerretDB v1 page lists every architecture its binary is built for. The binaries
in the table below are v10.78's: nothing here rebuilds them.

This release adds the following new features:

Windows on ARM - a bundle whose every binary was already published.

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.

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.

v10.78 2026-08-09 WeKan ® release

In short: the AppImage workflow. It built both AppImages, started them,
waited for WeKan to answer on port 8080, uploaded them as artifacts - and then
attached nothing to the release, because the job that does the attaching never
checks the repository out and its two gh calls were the only ones in the file
without --repo. Fixed, and the matrix grows from two architectures to
four: i686 and armhf are the other two an AppImage runtime exists for.
The Flatpak workflow had the same one-line bug and a second beside it - it
was attaching the ostree repository along with the bundles - and it stays at two
architectures, because a flatpak needs a published runtime and only x86_64 and
aarch64 have one. Beside that, the Docker images now carry full SLSA
provenance at every one of the four sites that pushes one, and a test pins
that every bundled binary - FerretDB, the MongoDB Database Tools, Node.js -
is still fetched as the NEWEST one everywhere it is fetched, which is what makes
those projects' security fixes arrive without a commit here - and the table
below is that working: FerretDB v1.48.0 replaces v10.77's v1.45.0 on every
platform, with no change in this repository, because latest now resolves to
it. That is the release carrying go1.25.11 and x/sys v0.46.0, which answers
the Go advisories a Quay scan reported against the v10.77 image. Node.js stays
v24.19.0, the newest 24.x. The rest of this release is the same theme - what a
build REPORTS versus what it did. The armhf snap failed three times on a
package name that has not existed since Ubuntu 24.04 renamed it, while the
message blamed a transient build-farm reset; three snaps that BUILT were
reported FAILED by the step that saves their logs; and the provenance table
printed every row twice, left amd64 out entirely, and gave six platforms the
version "latest".

This release adds the following new features:

AppImage - which CPUs get one.

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 fork 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.

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.

v10.77 2026-08-09 WeKan ® release

In short: the snap side, which had three problems that looked like one.
The helper that put a build on channels released ONE snap, ONE revision, to
THREE channels - and a revision number is per architecture, so it could only
ever
be right for one of them. The page documenting the CPU platforms listed five
architectures and omitted armhf, which has been built all along. And the two
architectures that are release bundles but NOT snaps - i386 and armv7 -
were nowhere, so "missing" and "cannot be there" looked identical. The binaries
below are v10.76's: nothing here rebuilds them.

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 fork 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.

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.

v10.76 2026-08-09 WeKan ® release

In short: three round-trip counts that were linear in the input, and are not
any more. The bulk label endpoint asked the database twice per card - a
thousand sequential round-trips at its 500-card cap - global search resolved
each named user with its own lookup before the search could start, and
FerretDB skipped every top-level $or when building a WHERE clause, so the
board-list query narrowed nothing in SQL and filtered every row in Go. None of
them was a wrong answer; each was the right question asked one document at a
time. The binaries below are v10.75's: nothing here rebuilds them.

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 fork 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.

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.

v10.75 2026-08-09 WeKan ® release

In short: two things the full test run turned up, one in WeKan and one in
the scripts that run it. A linked-card cache that could not see a card
added after the first time a subscription asked, and the build script parity
guard that was the one red suite - right twice over, because build.bat really
was missing the two entries and the guard really could not tell a shell function
from a script. The binaries below are v10.74's: nothing here rebuilds them.

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 fork 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.

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.

v10.74 2026-08-09 WeKan ® release

In short: four security reports from Alpastx, all of them the same
mistake in four places - a rule that exists, is correct, and is not asked.
PathBleed let an avatar's owner write the on-disk path of their own avatar
and have board export read that file back out, because the guard attachments
have was never copied to avatars. RevokeBleed left a revoked organization,
team or domain share working in the board publication, because that
publication had its own copy of the visibility query and the copy ignored
isActive. ParentBleed let a card on one board name a parent on a private
one and had the publication deliver that private card to everybody, because
nothing checked who may see the parent's board. CommentBleed let any board
member delete anyone's comment over REST, because the object-level rule lived in
a collection hook that cannot see an HTTP caller. Each fix puts the rule in ONE
place that both callers use, and each comes with a plain-node suite that pins
the attack and the negatives. Auditing for more of the same found five more
cursors leaking cross-board content the way ParentBleed did, three more
hand-written copies of the visibility query, and a comment reaction anybody
on the board could put in somebody else's name.

The features under them are two answers to "and then what": canary tokens,
which record WHO tried a permission override and from WHERE without telling them
they were seen, and a daily filesystem integrity check that asks whether
every stored file is still the file WeKan stored - name, date, md5, sha256,
sha512 and an ed25519 signature - and warns when one changed with no record
saying why. Below that: dependency updates, the two bugs Admin Panel / Problems
was itself reporting, and the security tests, which now say WHICH published
vulnerability they guard so a new guard can check the whole Hall of Fame list
against them - 33 of 58 covered, the other 25 recorded gaps with reasons.
The binaries below are v10.73's: nothing here rebuilds them.

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 fork 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.

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.

v10.73 2026-08-08 WeKan ® release

In short: a GitHub CodeQL finding fixed after v10.72 was tagged -
PatternBleed, a string replacement that replaced a hyphen with itself, so an
escape that looked like one was not there - and a guard that catches the whole
class in WeKan's own test run rather than days later in a web interface. The
binaries below are v10.72's: nothing here rebuilds them.