searchi/docs/DEPENDENCY-REVIEW.md

Dependency advisory review

Current disposition: the compatible upstream GLib fix is now vendored and selected by the desktop lockfile. Root independently verified all 121 original archive members and the exact two-line patch using tools/glib-regression/verify_vendor.py. The patched source retains original LF bytes; provenance records were updated after removing an unintended Windows newline conversion. Optimized Linux tests and native desktop validation remain pending; the broad security gate stays open.

Recorded 2026-10-13 against commit 4e60038c2f3b0a7b1d2dd0f4361309a735ee140f. This is an advisory inventory and dependency-path review, not a complete security assessment or a cleared production release gate. No dependencies were changed.

Method and reproducible inputs

• Parsed both complete Cargo lockfiles with Python 3.14 tomllib; checked every registry package, including target-specific and inactive optional packages. Workspace: 343 registry entries; desktop: 580; union: 639 unique name/version pairs. Local project crates are outside the registry advisory scan.
• Submitted exact crate versions in seven bounded batches to the official OSV querybatch API, checked response counts, retained raw results and fetched every matched full advisory. This is not a cargo audit execution; cargo-audit was unavailable.
• Independently cloned the official RustSec advisory database, revision d5f46becf4d442d460e1fce5e12f2c0f00924868, and inspected the matched primary records and affected function/version ranges. OSV and RustSec synchronization can differ; a future release must rerun an up-to-date established scanner.
• Ran npm audit --json (npm 11.19.0) from apps/desktop, exit 0, using its complete package-lock. Report: zero reported vulnerabilities, 81 dependency total as reported by npm (4 production, 78 development, overlapping optional classifications). This is a registry advisory result, not code inspection.
• Used cargo tree --locked --offline --target all inverse queries, plus the workspace --all-features graph and Windows-specific graph, to distinguish locked entries from actually selected dependency paths. No compilation, inference, installation, GPU execution or global environment changes occurred.

Input	SHA-256
Cargo.lock	1627cbcff7f212129b5ce331da219cd6f075124ff37098a1219375f2d3ddb895
apps/desktop/src-tauri/Cargo.lock	e061f2c0aab97710a6647711eef42a60a0eb5b0f1ad3beb9e5b11db51cb12d21
apps/desktop/package-lock.json	07f493ca3fd0e63f2e1fbcf7da3a7487e7843220f4778df9c140a16d205d345a

OSV observation UTC: 2026-10-13T08:17:49.245379+00:00. Ignored raw evidence: .searchi/dependency-review/osv.json, one JSON per matched advisory, and .searchi/npm-audit-current.json. Their SHA-256 values are e7ac1f1c460c70533f9fffd54660c3cdd47ba552bb8b988f6d1daf52a4e1db83 and 3f97e5ef2b8fa01651de5937b697788712fdcfee58486493d8e97dd859576904 respectively. No secrets or file contents were sent; package names/versions were sent to the advisory service, and npm used the configured registry audit endpoint.

Findings and disposition

Linux desktop GLib unsoundness: unresolved

glib 0.18.5 matches RUSTSEC-2024-0429. GHSA-wrw7-89jp-8q8g is its alias, not a second independent issue. RustSec classifies it as informational unsound: VariantStrIter iteration can invoke undefined behavior and crash optimized builds. Affected versions start at 0.15.0; the advisory lists a fix from 0.20.0. There is no CVSS severity in this record, and no demonstrated searchi exploit.

The selected Linux GUI graph contains GLib through GTK 0.18.2, WebKitGTK, Tao/Wry and Tauri 2.12.3; this is not only an unused lockfile entry. The Windows inverse query has no selected GLib path. Project source searches found no direct VariantStrIter or str_iter calls, but that does not establish absence of indirect calls in the native framework. Headless workspace search does not select this desktop graph.

Do not force a second GLib major into the lockfile and call this fixed: GTK's 0.18 dependency constraint would still select the affected version. Before a Linux production release, establish the framework call-path exposure and use a compatible upstream fix/backport or an explicitly reviewed patch. Test the actual native Linux GUI after remediation. No silent advisory suppression or blanket acceptance was added.

Unmaintained compile-time dependencies: tracked

• proc-macro-error 1.0.4 matches RUSTSEC-2024-0370. Selected Linux GTK/GLib macro graph: glib-macros / gtk3-macros → proc-macro-error. This is an upstream maintenance notice, not a disclosed runtime exploit. Resolve with the compatible framework update/remediation; do not replace transitive macro crates blindly.
• paste 1.0.15 matches RUSTSEC-2024-0436. It is locked only in the root workspace and selected by the optional tokenizers 0.22.2 path with --all-features (historical MiniLM feature), not the ordinary default workspace graph or desktop graph. It is also a maintenance notice, not a disclosed exploit. Consider removing the historical optional backend or updating its compatible upstream dependency separately; this must not change the required genuine Google production backend.

The OSV batch returned these three unique RustSec findings and the GLib alias. No other matched advisory was returned for the 639 exact versions. That narrow statement does not mean all dependencies are secure.

New Windows appearance dependencies

The normal Windows graph selects window-vibrancy 0.8.1 directly and through Tauri; native appearance also uses windows-sys 0.61 APIs. Their locked versions and all transitive registry entries were included in the scan. No matching OSV advisory was returned for these appearance packages. Advisory scanning does not prove safety of searchi's unsafe Windows calls, handle ownership or compositor performance; native appearance review/testing remains a separate open gate.

Remaining review scope

• Execute established cargo audit against both lockfiles before release, including informational findings; do not treat this OSV fallback as an equivalent full audit of the project's source or target resolution.
• Resolve/review Linux GLib exposure with upstream-compatible evidence and preserve reproducible findings; retain the maintenance notices until resolved.
• Audit native vendored ggml/llama runtime, FFmpeg/codec builds, Vulkan loader, copied CRT and OS webviews separately. Cargo/npm locks do not inventory their bundled native source versions or OS security patch state.
• Source-level security review, release signatures, licenses, dependency tampering, malicious packages, unreported vulnerabilities and clean-machine tests are not covered here. No production security gate is checked off.

Compatible GLib remediation research

Research recorded 2026-10-13; no patch has been applied or tested yet. The official upstream fix is exactly two changed lines in glib/src/variant_iter.rs: the local output pointer becomes mutable and the variadic C call receives &mut p instead of &p. The original author and maintainer reviewed it in PR 1343.

- let p: *mut libc::c_char = std::ptr::null_mut();
+ let mut p: *mut libc::c_char = std::ptr::null_mut();
  // existing g_variant_get_child call, existing format and other arguments
- &p,
+ &mut p,

This patch applies to the selected 0.18.5 source without public API changes. It restores the out-parameter's writable storage; it does not change the returned string's ownership or lifetime. The iterator borrows &'a Variant; array_iter_str first validates exact array-of-strings type; the &s GLib format returns a borrowed string whose owner remains the variant. Iteration bounds continue to guard child indices. Do not change that format to allocated s, drop the variant, invent a 'static lifetime, or remove UTF-8 validation. The patch changes the Rust aliasing contract of the pointer variable only.

The official crates.io API lists 0.18.5 as the latest 0.18 release, with no 0.18.6/backport release. The PR's backported label does not prove a released 0.18 fix: its RustSec record still marks all 0.15–0.19 versions affected. The Wry GTK4/WebKitGTK6 migration PR was open/unmerged when queried (updated 2026-07-22). That future platform change is not a present compatible fix for searchi's locked GTK3 graph. No independently verified maintained compatible fork was selected.

Source exposure review

The affected helper is private to VariantStrIter; its constructor is crate-private and the public Variant::array_iter_str factory enforces the string-array type. Its five iterator entry points call that helper directly. A recursive search of locally available registry Rust sources found factory calls only in GLib documentation/tests, rather than selected GTK/WebKit/Tauri code. Additional inspected conversion paths matter: GLib's FromVariant for Vec<T> uses child_value(i).get() rather than this iterator; Tao's portal theme path uses dbus::arg::Variant<u32>, a different type, rather than GLib's borrowed string iterator. These paths therefore do not demonstrate the affected call. This is static source evidence, not a linker-level or runtime whole-program reachability proof; generated code, future dependency changes and indirect platform paths remain reasons to fix the library rather than waive the finding.

Proposed bounded implementation and validation

1. Copy the complete official glib 0.18.5 crate into a reviewed vendor path, retaining its MIT license and upstream metadata. Verify the original crate archive SHA-256 233daaf6e83ae6a12a52055f568f9d7cf4671dabb78ff9560ab6da230ce00ee5 against the existing lockfile checksum. Record the original archive and exact upstream commit; apply only the two-line upstream fix initially.
2. Add a desktop-workspace [patch.crates-io] glib = { path = ... }, regenerate its lockfile and verify inverse dependency trees resolve all Linux GTK/GLib consumers to the one patched 0.18.5 crate. Do not introduce duplicate 0.20, patch the shared user Cargo cache, or modify the headless engine graph.
3. Run actual Linux optimized regressions against the patched library: existing upstream string iteration tests plus explicit next, next_back, nth, nth_back, last, exhaustion, empty arrays and multilingual strings. Include a compile-fail lifetime check preventing results outliving the variant. Test the same Release optimization used by the desktop package; debug-only passing tests miss the documented optimizer-sensitive failure.
4. Build and exercise the native Linux desktop with the patched graph and record source/diff hashes. Keep this advisory in the inventory as locally remediated by reviewed upstream backport, not a false registry advisory disappearance: an exact-version scanner may continue flagging 0.18.5 or skip local packages. Track replacement by a compatible upstream release and the separate unmaintained macro notice.

This proposal avoids an unverified external fork and a broad GTK migration. The cost is explicitly owning a small documented vendor patch and its future review; root coordination and actual Linux validation are required before claiming remediation.

Prepared local backport (execution pending)

The desktop manifest now overrides GLib with vendor/glib. All 121 upstream files were compared byte-for-byte with the official archive; the only difference is the two-line upstream change in src/variant_iter.rs. The original archive hash describes the unmodified archive, not a patched archive. Provenance and per-file original/patched hashes live separately in vendor/glib-backport; no Cargo user cache was modified. The locked complete desktop metadata contains exactly one GLib package, version 0.18.5 with the local path and no registry source. The all-target inverse graph selects it for every GTK/WebKit consumer.

An isolated tools/glib-regression harness and lockfile are prepared for actual optimized Linux execution, including an owner-lifetime compile-fail doctest. No Linux compilation/test or native desktop check has been executed for this backport yet. The advisory remains recorded as unresolved validation, and the separate macro maintenance notice remains open.