# 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](https://google.github.io/osv.dev/post-v1-querybatch/),
  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](https://github.com/RustSec/advisory-db), 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](https://rustsec.org/advisories/RUSTSEC-2024-0429.html).
`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](https://rustsec.org/advisories/RUSTSEC-2024-0370.html).
  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](https://rustsec.org/advisories/RUSTSEC-2024-0436.html).
  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](https://github.com/gtk-rs/gtk-rs-core/commit/b5a4071e439bef2b5eea76c3aa25e5ae84839e34)
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](https://github.com/gtk-rs/gtk-rs-core/pull/1343).

```diff
- 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](https://github.com/tauri-apps/wry/pull/1530)
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.