Repository navigation
decision(deps): SixLabors.ImageSharp 4 requires a build-time licence key — decide before upgrading #190
Description
SixLabors.ImageSharp is pinned at 3.1.12 and Blurhash.ImageSharp at 3.0.0 in
src/Directory.Packages.props. They were held back in #187 because ImageSharp 4 cannot be built
without a licence key.
What actually happens
SixLabors.ImageSharp.targets(28,5): error : No Six Labors license found.
Set $(SixLaborsLicenseKey), set $(SixLaborsLicenseFile), or add a 'sixlabors.lic' file
to the project/workspace.
Please obtain a license from https://sixlabors.com/pricing/
🔴 This is an ERROR in Release and only a WARNING in Debug. That asymmetry is the trap: a
local dotnet build src/ looks fine, and the failure appears in the Worker image, whose
Dockerfile builds -c Release. It is also why the Docker jobs are the only place CI catches it —
they needs: build-and-test, so they are skipped on any run that is already red.
The licence did not change; the enforcement did
Both 3.1.12 and 4.1.2 ship the same Six Labors Split License 1.0. What 4.x adds is a
build/SixLabors.ImageSharp.targets that enforces a key at build time — 3.1.12 ships only a
.props with no such check. So this is not a new licence to evaluate so much as a key to
provision.
The two packages move together
Blurhash.ImageSharp 4.1.1 takes a hard dependency on SixLabors.ImageSharp 4.1.1, where
3.0.0 only floors at >= 2.0.0. Upgrading either forces the other, so they are held as a pair.
What adopting v4 would require
- A key from https://sixlabors.com/pricing/ — determine whether this project qualifies for a
free/OSS tier under AGPL-3.0, or whether it is a paid licence $(SixLaborsLicenseKey)(or asixlabors.lic) reaching two places, not one: the CI job,
and the Workerdocker build— the latter needs it as a build secret, and ⛔ a build arg
would bake the key into image history
Options
- Stay on 3.x (current state). No key, no credential in the build. Accepts that 3.x will
eventually stop receiving fixes. - Provision a key and thread it through CI and the Docker build.
- Replace ImageSharp. Largest change — it backs the proxy generators, the EXIF path and
blurhash generation.
No action is required for v1.0; this is recorded so the holdback is a decision rather than drift.
Context: #187.
Activity
chore(deps): Bump 27 NuGet packages, and split analyzers into their o…
bitbiter-dev commentedon Oct 9, 2026
This reverses the recommendation above
Found while investigating why Dependabot PRs #200 and #201 were failing. Holding at ImageSharp 3.1.12 is no longer the safe default — it is now the option that ships known high-severity vulnerabilities and does not build.
Every build in the repo currently fails
src/Directory.Build.propscombines:So any moderate-or-higher advisory, in any package, direct or transitive, is a hard build error.
SixLabors.ImageSharp3.1.12 now carries five:10 build errors — 5 advisories × 2 projects (
Anichron.Worker,Anichron.Worker.Tests.Unit). Reproduced locally onmaster's package set.There is no 3.x fix
>= 2.0.0, <= 4.1.1>= 2.0.0, <= 4.1.1>= 2.1.0, <= 4.1.1>= 1.0.0-beta0001, <= 4.1.1>= 2.0.0, <= 4.1.1Queried from the GitHub advisory API. Every one is patched only in 4.1.2 — the exact upgrade this issue parked over the licence key. #202 already proposes it.
NuGet's audit is best-effort: with no reachable advisory feed it silently skips and the build passes. Measured both ways on the same tree —
--no-restoreagainst assets from a networked restore → 10 errors (the advisory data is baked intoproject.assets.json)CI always has the feed, so CI always fails. "It builds on my machine" may only mean the feed was unreachable.
What this does to the four options
docker buildas a secret, never a build arg.NuGetAuditLeveltohigh— silences the two moderates, leaves all three highs failing. Does not unblock.NoWarnthe five advisory codes — unblocks the build while explicitly accepting three high-severity CVEs. If this is the answer it needs an ADR, not a line in a props file.📌 Nothing here has been changed. No audit setting touched, no package version moved — the choice between 2 and 4 is a security decision, not a build fix.
Knock-on
15905bf, 646/646 tests green before the advisory landed) but cannot be pushed — the pre-commit build hook hitsNU1903.bitbiter-dev commentedon Oct 10, 2026
Resolved by #203: ImageSharp 4.1.2 + Blurhash.ImageSharp 4.1.1 under the Six Labors community licence. The key is supplied locally via a gitignored root
sixlabors.lic, in CI and for Dependabot via theSIXLABORS_LICENSE_KEYsecret, and to the Worker image via a BuildKit secret mount. The Worker Release image build in CI confirms it validates.