chore(desktop): glib <0.20.0 advisory is blocked on a Tauri gtk-rs upgrade

[Abhash-Chakraborty]

Context

The last non-torch Dependabot alert (#73, medium): glib <0.20.0, GHSA-wrw7-89jp-8q8g — unsoundness in the Iterator and DoubleEndedIterator impls for glib::VariantStrIter.

It cannot be fixed with a lockfile change or a Cargo override.

Why

frontend/src-tauri/Cargo.lock resolves glib 0.18.5 through this chain:

tauri 2.11.2
 └─ wry 0.55.1
     └─ webkit2gtk 2.0.2
         └─ gtk 0.18.2
             └─ glib 0.18.5

The gtk-rs 0.18 series is what Tauri 2.x pins on Linux. glib 0.20 requires the gtk-rs 0.20 stack, which means a Tauri-side upgrade — forcing it via [patch] would just fail to build against the 0.18 API surface.

Actual exposure

Low. The advisory is unsoundness in glib::VariantStrIter, which requires calling that iterator directly. find-desktop is a thin shell — Cargo.toml declares only tauri, serde, and serde_json, and no code in src-tauri/ touches glib. The path is also Linux-only; the Windows and macOS desktop builds never pull the gtk stack at all.

So this is a transitive advisory we carry, not a reachable bug in Find.

What to do

Nothing actionable today. This issue exists so the alert isn't mistaken for something that was overlooked.

Revisit when:

• Tauri publishes a release that moves to the gtk-rs 0.20 stack — then bump tauri in frontend/src-tauri/Cargo.toml and confirm glib lands at >= 0.20.0
• Or the advisory is withdrawn / rescored

If the alert becomes noisy in the meantime, dismiss it as tolerable_risk with a link back here — but do not dismiss it as inaccurate, because unlike the pyproject.toml batch cleaned up during the sweep, this one accurately describes the tree.

Verify current state

cd frontend/src-tauri
grep -A2 'name = "glib"' Cargo.lock          # 0.18.5
cargo tree -i glib                            # shows the tauri -> wry -> webkit2gtk -> gtk chain