Dependabot cannot propose `tauri`, and no configuration can change that

[PathGao]

Cargo.lock pins tauri at 2.10.2. 2.11.5 has been published since
2026-07-01. No Dependabot pull request has ever offered it — not #478 in July,
which was unrestricted enough to cross notify 6→8 and zip 2→4, and not #489
or #491 under the current config.

This is not a backlog item. It is a hole in the reporting, it is permanent, and
the two configuration changes that landed today (#484, #490) do not touch it.
I am not asking for an upgrade — I have no benefit case for 2.11.5 and did
not go looking for one. I am reporting that the mechanism we just built cannot
see the framework this app runs on.

Why

Two independent rules multiply.

Dependabot's cargo resolver runs exactly one command. From
dependabot-core/cargo/.../version_resolver.rb: cargo update -p <dep> -vv
against a manifest whose requirement has been loosened to >= <locked>. One
-p, no --precise.

tauri 2.11.5 raises its floor on four siblings that release in lockstep with
it, and all four moves are within the same semver line:

	2.10.2 requires	2.11.5 requires	locked at
tauri-runtime	^2.10.0	^2.11.3	2.10.0
tauri-runtime-wry	^2.10.0	^2.11.4	2.10.0
tauri-utils	^2.8.2	^2.9.3	2.8.2
tauri-macros	^2.5.4	^2.6.3	2.5.4

Cargo cannot hold two 2.x copies of one crate, so those four have to be replaced
in place — and cargo update may not touch a package it was not named. So it
declines, and says so:

Unchanged tauri v2.10.2 (available: v2.11.5)

Reproduced against master's lockfile, naming different sets:

named	result
-p tauri	nothing moves
-p tauri -p tauri-runtime	nothing moves
-p tauri -p tauri-runtime -p tauri-runtime-wry -p tauri-utils -p tauri-macros	tauri → 2.11.5
-p tauri-build (control)	2.6.3, works — its cascade only adds copies on a different line

And the four unblockers are transitive. allowed_updates is unset, so the
default dependency-type: direct applies (job.rb#allowed_update?), and
Dependabot will never propose them on their own either.

One rule means it can only ever name tauri. The other means it can never name
the four crates that would let tauri move. There is no allow: or groups:
entry that resolves this, because the constraint is in how the resolver is
invoked, not in what it is allowed to consider.

How wide the hole is

Narrower than it first looks, and worth stating precisely so this is not read as
a general indictment.

The obvious hypothesis — that every bare-caret requirement like
tauri = { version = "2" } is invisible — is false. serde, regex and
three tauri-plugin-* crates are all declared exactly that way and were all
updated lockfile-only in #489.

The class is lockstep crate families: it bites only where a crate raises its
floor on siblings that version in step with it. Running the resolver emulation
over all 24 direct dependencies, seven are already current and tauri is the
only one that is both behind and unproposable.

That is the uncomfortable part. One dependency out of 24, and it is the one
everything else sits on.

What this does to today's work

#472, #484 and #490 built a mechanism whose whole promise is that drift becomes
visible — a scheduled pull request, a bounded ignore list, a written record of
what is held and why. A dependency that can sit two minors behind and appear in
none of it is a hole in that promise, and nobody would notice it from the
outside: the bot looks like it is working, because for the other 23 it is.

The same shape as the Node 20 deprecation earlier today. That warning was printed
in every release build for months and nobody read it, because nothing ever asked
anyone to decide about it. This is worse in one respect — there is no warning to
miss.

#490 is not the cause. #478 predates it and also omits tauri;
exclude-patterns is npm-only and the ignore entries name only windows and
webview2-com. (Confirmed while checking: tauri 2.11.5 still requires
windows ^0.61 and webview2-com ^0.38, so those two entries stay correct
against the newer core.)

What I think should happen

Not an upgrade — a way to be told. The options I can see, worst to best:

1. Nothing. Remember to check by hand. This is the option that already failed
   once today.
2. A comment next to tauri in Cargo.toml saying the bot cannot see this
   line. Cheap, and about as effective as any comment nobody has a reason to open.
3. A check at release time. build.yml runs when someone is watching and is
   already the place where release-shaped facts surface. A step that compares the
   locked tauri against the index and fails loudly would turn an invisible state
   into a red build at the one moment a human is present.

I would do 3, and I am happy to open it — but it is your call whether a release
should be blockable by an upstream version number, so I would rather ask than
ship it.

If tauri 2.11.5 is ever wanted, it is mechanically clean:
cargo update -p tauri -p tauri-runtime -p tauri-runtime-wry -p tauri-utils -p tauri-macros
resolves in one step (32 packages) and cargo test gives 125/125, identical to
master. That is a compile-and-unit-test result on macOS only — it says nothing
about runtime behaviour, and the Windows-gated code was not built.

Not established

• Dependabot's own job logs. There is no public API for them; everything above is
  reproduction of its documented resolver plus reading dependabot-core, not the
  bot's record of what it decided.
• Whether any runtime behaviour differs on 2.11.5.
• Why chrono appears in chore(deps): bump the cargo group in /src-tauri with 17 updates #478's table. Consistent with moving as a byproduct of
  another bump rather than being proposed on its own, but not proven.

[PathGao]

A benefit case turned up for the npm side of this, from the release that
shipped as 2.7.2. Recording it here rather than opening a PR, because the
version it wants is a floor rather than a bump.

package.json asks for "@tauri-apps/cli": "^2"; package-lock.json
resolves it to 2.9.6. The lockfile is what CI installs, so 2.9.6 is what
build.yml runs.

That matters at line 332, where the AppImage is re-signed after the strip:

npm run tauri signer sign -- "$APPIMAGE"

signer sign did not read the TAURI_SIGNING_* names until CLI 2.10.0:

Added new environment variables for tauri signer sign command, to align
with existing environment variables used in tauri build, tauri bundle
and tauri signer generate: TAURI_SIGNING_PRIVATE_KEY,
TAURI_SIGNING_PRIVATE_KEY_PATH, TAURI_SIGNING_PRIVATE_KEY_PASSWORD. The
old environment variables are deprecated and will be removed in a future
release: TAURI_PRIVATE_KEY, TAURI_PRIVATE_KEY_PATH,
TAURI_PRIVATE_KEY_PASSWORD

So on 2.9.6 the workflow has to spell the same key two ways, and does:

step	variables
tauri build	TAURI_SIGNING_PRIVATE_KEY, TAURI_SIGNING_PRIVATE_KEY_PASSWORD
signer sign (#529)	TAURI_PRIVATE_KEY, TAURI_PRIVATE_KEY_PASSWORD

Both read from the same two repository secrets. The second spelling is not a
mistake — it is the only spelling 2.9.6 answers to — but it is a trap with a
timer on it, because those names are deprecated upstream and are stated to be
going away. When they go, the step stops seeing a key. signer sign without a
key does not fail loudly; it is the -f "$APPIMAGE.sig" check added in #529
that turns it into a build error, which is the only reason it would not ship a
release with a stale signature.

Raising the floor to ^2.10.0 lets both steps use one spelling and removes the
deprecated pair from the workflow entirely.

Why it is not the same problem as the crate

This is the npm ecosystem, not cargo, and none of the mechanics documented
above apply to it: ^2 is satisfiable by any 2.x, and the npm group has
proposed plenty of updates (#477, #487, #491). Dependabot can see this one.

It has not raised it because there is nothing to raise: ^2 is already
satisfied, and Dependabot updates a lockfile entry within its range on its own
schedule. What it will never do is tell us that the resolved 2.9.6 is below the
version a workflow step needs — a requirement expressed in a shell line, not in
a manifest.

So the two halves of "tauri is stuck" have different causes. The crate is
invisible to the tool for the structural reason this issue documents. The CLI
is visible, in range, and pinned low by nothing more than a lockfile nobody had
a reason to look at.

A one-line floor bump was staged locally and dropped rather than opened as a
PR, since #497 asks for the reporting hole rather than upgrades. If a floor is
wanted, it is "@tauri-apps/cli": "^2.10.0" in package.json — enough for the
signing alignment, without asserting a benefit case for anything newer.

[PathGao]

Correcting the last line of my previous comment. I suggested ^2.10.0 as the
floor, "without asserting a benefit case for anything newer." There is one, and
it was already written down — in #529, where this was worked out in detail
before it was summarised here. Linking it rather than restating it, plus the
two parts I left out.

The AppImage half

2.11.4:

Fixed an issue in the AppImage bundler that caused the /.desktop and
.DirIcon files to be absolute symlinks instead of relative symlinks which
caused problems with AppImage installers like AppManager.

This is a different defect from the bundled libwayland-client.so.0 that #498
reported and #499 worked around, and it is in the bundler's own output rather
than in what the runner happens to bring — but it lands in the same artifact
the workflow already unpacks and repacks by hand. Fixing it upstream is
strictly better than not, and it costs nothing beyond the version we would be
raising to anyway.

So the floor worth having is ^2.11.4, not ^2.10.0: 2.10.0 for the signing
alignment, 2.11.4 for this.

Upgrade impact, as tested

Checked before proposing it, in #529:

2.10.0	additive — v2 env names added, TAURI_PRIVATE_KEY kept and deprecated
2.11.0 breaking change	scoped to tauri-bundler library users (NsisSettings, WindowsSettings gained fields). CLI consumers unaffected
2.11.0 new config fields	uninstallerIcon, bundle > windows > minimumWebview2Version — tauri.conf.json sets neither
npm test	passed
real npm run tauri build	succeeded, artifacts where the workflow expects them: macos/Markpad.app.tar.gz, .sig, dmg/Markpad_<ver>_<arch>.dmg

The signing failure itself reproduces cleanly on the version boundary, same v2
env vars in both runs:

$ npx @tauri-apps/cli@2.9.6  signer sign fake.AppImage
       Error Key generation aborted: Unable to find the private key    ← the CI failure
$ npx @tauri-apps/cli@2.11.4 signer sign fake.AppImage
  → fake.AppImage.sig written

What that testing does not cover: it was run on macOS, so only the macOS
artifact line was exercised end to end. Windows *-setup.exe and Linux
*.AppImage naming is unchanged per the changelogs, but neither was built. The
AppImage symlink fix above is therefore taken from the changelog rather than
observed — which is worth saying plainly, since the Linux artifact is the one
it is about.

Why it is filed here and not as a PR

The chain that made any of this matter is not something the project chose:

#498  AppImage ships libwayland-client.so.0 from the runner → host libEGL aborts → blank window
  ↓
#499  the only available fix: unpack, delete the libs, repack
  ↓
      repacked bytes ≠ the bytes `tauri build` signed → the .sig is void
  ↓
      so the artifact must be re-signed → the first `tauri signer sign` in this repo's history
  ↓
#529  and that command sat on the v1 env names until 2.10.0

Every step is forced by the one above it. The lockfile pin was harmless for as
long as nothing called signer sign, which is why it surfaced at 2.7.2 and not
earlier.

That is also the reason this belongs in the reporting hole this issue is about
rather than in a PR: nothing in package.json was ever wrong — ^2 permits
2.11.4 today — and no dependency tool reports "the lockfile resolves below what
a workflow step needs," because that need is expressed in a shell line. The
crate half of this issue is invisible for a structural reason; this half is
invisible for a different one, and neither is a backlog item.