Skip to content

decision(deps): SixLabors.ImageSharp 4 requires a build-time licence key — decide before upgrading #190

Closed
Closed
decision(deps): SixLabors.ImageSharp 4 requires a build-time licence key — decide before upgrading#190
Labels
dependenciesPull requests that update a dependency fileneeds-triageMaintainer needs to evaluate this issuequestionFurther information is requested

Description

@bitbiter-dev
bitbiter-dev
opened on Sep 27, 2026

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 a sixlabors.lic) reaching two places, not one: the CI job,
    and the Worker docker build — the latter needs it as a build secret, and ⛔ a build arg
    would bake the key into image history

Options

  1. Stay on 3.x (current state). No key, no credential in the build. Accepts that 3.x will
    eventually stop receiving fixes.
  2. Provision a key and thread it through CI and the Docker build.
  3. 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

  1. bitbiter-dev
    added
    questionFurther information is requested
    dependenciesPull requests that update a dependency file
    on Sep 27, 2026
  2. bitbiter-dev
    added a commit that references this issue on Sep 27, 2026

    chore(deps): Bump 27 NuGet packages, and split analyzers into their o…

    4fbb980
  3. bitbiter-dev
    added
    needs-triageMaintainer needs to evaluate this issue
    on Sep 28, 2026

  4. bitbiter-dev commented on Oct 9, 2026

    @bitbiter-dev
    bitbiter-dev
    on Oct 9, 2026
    OwnerAuthor

    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.props combines:

    NuGetAudit          = true
NuGetAuditLevel     = moderate
NuGetAuditMode      = all
TreatWarningsAsErrors = true

    So any moderate-or-higher advisory, in any package, direct or transitive, is a hard build error. SixLabors.ImageSharp 3.1.12 now carries five:

    NU1903  high      GHSA-j3p4-wp97-rph4
NU1903  high      GHSA-j9gm-c75j-xc9q
NU1903  high      GHSA-jjfr-hcj7-qf5w
NU1902  moderate  GHSA-gwg2-r3hj-4w44
NU1902  moderate  GHSA-wmxv-xphr-5c9g

    10 build errors — 5 advisories × 2 projects (Anichron.Worker, Anichron.Worker.Tests.Unit). Reproduced locally on master's package set.

    There is no 3.x fix

    Advisory Severity Vulnerable range First patched
    GHSA-j3p4-wp97-rph4 high >= 2.0.0, <= 4.1.1 4.1.2
    GHSA-j9gm-c75j-xc9q high >= 2.0.0, <= 4.1.1 4.1.2
    GHSA-jjfr-hcj7-qf5w high >= 2.1.0, <= 4.1.1 4.1.2
    GHSA-gwg2-r3hj-4w44 moderate >= 1.0.0-beta0001, <= 4.1.1 4.1.2
    GHSA-wmxv-xphr-5c9g moderate >= 2.0.0, <= 4.1.1 4.1.2

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

    ⚠️ A local green build is not evidence this is fixed

    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 —

    • restore with advisory data available → 10 errors
    • restore with the feed unreachable → 0 errors, build succeeds
    • --no-restore against assets from a networked restore → 10 errors (the advisory data is baked into project.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

    1. Stay on 3.x — was the recommendation. Now means three known high-severity CVEs and a repo that cannot build. No longer viable without also changing the audit settings.
    2. Licence 4.1.2 — the only option that removes the vulnerability. Cost unchanged: a key threaded into CI and the Worker docker build as a secret, never a build arg.
    3. Lower NuGetAuditLevel to high — silences the two moderates, leaves all three highs failing. Does not unblock.
    4. NoWarn the 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

  5. bitbiter-dev commented on Oct 10, 2026

    @bitbiter-dev
    bitbiter-dev
    on Oct 10, 2026
    OwnerAuthor

    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 the SIXLABORS_LICENSE_KEY secret, and to the Worker image via a BuildKit secret mount. The Worker Release image build in CI confirms it validates.

  6. bitbiter-dev
    closed this as completedon Oct 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    dependenciesPull requests that update a dependency fileneeds-triageMaintainer needs to evaluate this issuequestionFurther information is requested

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions