[WIP] Track upstream-owned glib 0.18.5 RustSec exception

[Claude]

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

---

This section details on the original issue you should resolve

<issue_title>[Security] Track upstream-owned glib 0.18.5 RustSec exception</issue_title>
<issue_description>## Role

• 직무 / O0: v0.1.4 release-readiness stabilization
• 업무 / O1: Rust desktop dependency security closure
• 과업 / O2~O3: keep the remaining upstream-owned glib 0.18.5 RustSec exception narrow and removable
• 작업 / O4~O7: owner-chain verification, upstream watch, lockfile refresh, audit exception removal

Current evidence

RUSTSEC-2024-0429 for glib 0.18.5 remains after the compatible Tauri lockfile refresh. Current owner chain is the Tauri/wry/webkit2gtk/gtk GTK3 stack, not BandScope application code.

The branch stepwise/rust-alert-owner-chain-v2 adds repo-controlled guardrails so the exception is allowed only when every glib 0.18.5 owner is reachable from tauri and belongs to the documented GTK/WebKit stack. The same change removes the retired rand 0.7.3 and fxhash exceptions.

Acceptance criteria

• apps/desktop/src-tauri/.cargo/audit.toml contains only the narrow RUSTSEC-2024-0429 glib 0.18.5 exception for this advisory.
• scripts/checks/verify_supply_chain.py rejects unowned, mixed-owner, or unexpected Tauri-reachable glib 0.18.5 owners.
• A future compatible Tauri/wry/webkit2gtk/gtk update is tested with cargo update --manifest-path apps/desktop/src-tauri/Cargo.toml.
• When the chain drops or patches glib <0.20.0, remove the audit exception and close this issue with lockfile and gate evidence.

Security Notes

• Untrusted inputs: no new runtime input path is introduced; this is dependency metadata and lockfile policy enforcement.
• Trust boundary: the remaining vulnerable package is externally owned by the desktop framework stack, so the repo enforces a narrow owner-chain allowlist instead of broad suppression.
• Safe failure: policy checks fail closed if glib versions are non-numeric, below patched range, unowned, or owned by unexpected packages.
• Logging/privacy: no runtime user data is logged or exported by this tracking work.
• Test points: python3 scripts/checks/verify_supply_chain.py and uv run --project services/analysis-engine pytest services/analysis-engine/tests/test_supply_chain_policy.py -q.

Blocked-by: upstream Tauri/wry/webkit2gtk/gtk stack moving off vulnerable glib 0.18.5 or patching to glib >=0.20.0.</issue_description>

• Closes [Security] Track upstream-owned glib 0.18.5 RustSec exception #196

Comments on the Issue (you are @claude[agent] in this section)

@seonghobae Refresh check from develop a328295:\n\n- Created fresh branch fix/glib-upstream-refresh from origin/develop.\n- Ran `cargo update --manifest-path apps/desktop/src-tauri/Cargo.toml --verbose --dry-run`: 0 packages lockable to newer compatible versions; only generic-array/toml/toml_datetime/toml_edit reported behind latest and unchanged by current constraints.\n- Ran `cargo tree --manifest-path apps/desktop/src-tauri/Cargo.toml --target all -i glib@0.18.5`: `glib 0.18.5` is still reached through the Tauri 2.11.0 / wry 0.55.0 / webkit2gtk 2.0.2 / gtk 0.18.2 GTK3 stack.\n- Ran `cargo audit` from `apps/desktop/src-tauri`: configured audit completed successfully with the existing narrow exceptions.\n\nNo maintained compatible update path is available yet; this remains blocked on the upstream Tauri/wry/webkit2gtk/gtk chain moving off or patching `glib 0.18.5`. @seonghobae Linked to new canonical follow-through program #203. Keep this issue open as the active upstream-owned glib/RUSTSEC tracker. Latest refresh still shows no compatible Tauri/wry/webkit2gtk/gtk update path, so this remains a blocker issue only for removing the narrow audit exception, not for unrelated repo-owned warning/design/security slices. @seonghobae Refresh check from `origin/develop` `38f2b5b08d3ec89cc0535576c4d59faa51d9bac9` on 2026-06-15:

• Created fresh worktree branch refresh/issue-196-glib-upstream from origin/develop.
• Ran cargo update --manifest-path apps/desktop/src-tauri/Cargo.toml --verbose --dry-run: compatible updates are now available, including wry 0.55.0 -> 0.55.1, tao 0.35.0 -> 0.35.3, muda 0.19.1 -> 0.19.2, and related transitive patch updates.
• Applied that refresh locally and ran cargo tree --manifest-path apps/desktop/src-tauri/Cargo.toml --target all -i glib@0.18.5: glib 0.18.5 is still reached through the Tauri GTK/WebKit stack, now tauri 2.11.2 / wry 0.55.1 / webkit2gtk 2.0.2 / gtk 0.18.2.
• Ran python3 scripts/checks/verify_supply_chain.py: passed.
• Ran cargo audit from apps/desktop/src-tauri: the online yanked-package registry lookup timed out repeatedly, so I re-ran cargo audit --no-fetch --stale against the local advisory database; it completed successfully with the current narrow repo-controlled exceptions.

Conclusion: a compatible lockfile refresh exists but does not remove or patch the vulnerable glib 0.18.5 owner chain. This issue remains blocked on the upstream Tauri/wry/webkit2gtk/gtk chain moving off glib 0.18.x or patching to glib >=0.20.0; the audit exception should stay narrow and removable rather than being closed now.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[seonghobae]

Closing as superseded by #327, which merged the same glib exception follow-through with the newer compatible lockfile refresh plus aligned dependency-policy evidence and regression tests. This draft only carries an older Cargo.lock-only refresh and should not be merged because it can regress the refreshed Tauri/muda evidence.