Files
searchi/docs/DEPENDENCY-REVIEW.md
T

285 lines
17 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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
now pass; native Linux release compilation and packaged startup also passed.
Native graphical interaction and the broad security gate stay 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. The initial inventory changed
no dependencies; the subsequent compatible backport is documented below.
## 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
### Initial Linux desktop GLib finding: subsequently locally remediated
`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
- Keep established `cargo audit` current before subsequent releases, including
informational findings. The completed scan below supersedes the earlier OSV
fallback for current lockfiles; it does not audit project source.
- Maintain the reviewed GLib backport and preserve reproducible findings;
native graphical interaction and the maintenance notices remain open.
- 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
The following records research on 2026-10-13 before applying the patch.
The subsequent implementation and execution evidence follows below.
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.
## Local backport and optimized Linux execution
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.
Actual optimized execution passed in Ubuntu 24.04 WSL on 2026-10-13: all three
unit tests and the owner-lifetime compile-fail doctest passed. The inverse graph
confirmed the selected local GLib 0.18.5 package. The archive verifier again
confirmed all 121 official files and only the exact two-line fix; harness source
and lockfile matched the repository byte-for-byte before execution.
Rust 1.99.0, system GLib 2.80.0; one Cargo build job, no inference or GPU.
After downloading a missing locked dependency, the recorded repeat used
`--release --locked --offline --jobs 1` and passed. The upstream crate emitted
34 compiler warnings; this is not a warning-free Clippy result. Its official
source was not reformatted or otherwise edited to suppress those warnings.
Raw WSL evidence:
`/home/karl/.cache/searchi-validation/glib-optimized-20261013.log`, SHA-256
`98ce2a1580e6b73f58040d6efefdbdcc2dcb5e2cab6f64dc88d8a9424a0031dc`.
This validates the focused iterator regression, not all GLib memory safety or
the patched native desktop. Subsequent native 0.1.4 compilation and packaged
startup passed with this selected local crate; see [Linux package evidence](LINUX-0.1.4.md).
Desktop interaction, broad security review and the
separate macro maintenance notice remain open.
## Current established scanner execution
On 2026-10-13 at 15:52:51 UTC, official `cargo-audit 0.22.2` inspected both
current lockfiles using RustSec database revision
`6aed84668c23d7f535077a9fe918bf1fa0f6a5bc`, containing 1310 advisories.
The workspace scan fetched the database; the desktop scan reused that exact
checkout with `--no-fetch`. Its JSON database commit fields are null in that
mode; the independently read Git revision above identifies the shared checkout.
No advisory ignore list, target filter or yanked-check bypass was used.
The [official Windows artifact](https://github.com/rustsec/rustsec/releases/tag/cargo-audit%2Fv0.22.2)
was verified against GitHub's published digest before extracting/executing:
6192256 bytes, archive SHA-256
`0a7316540862c13d954f648917ceacca593747baed6eec180fafa590be2710ab`.
The tool is kept under ignored `.searchi/tools`; it is not an app dependency or
a globally installed replacement. No inference or GPU operation was involved.
Equivalent commands with that tool available on PATH:
```sh
cargo audit --file Cargo.lock --db .searchi/dependency-review/rustsec-current --json --deny warnings
cargo audit --file apps/desktop/src-tauri/Cargo.lock --db .searchi/dependency-review/rustsec-current --json --deny warnings --no-fetch
```
Both reported zero vulnerability-class findings, but both exited **1** because
warnings were denied. Workspace warning: `paste 1.0.15`, RUSTSEC-2024-0436;
desktop warning: `proc-macro-error 1.0.4`, RUSTSEC-2024-0370. The paths/dispositions
above remain applicable. This is not a fully green strict audit. No speculative
macro/framework migration or silent warning suppression was introduced.
The scanner does not list the local GLib override as the affected registry
package. This omission is not proof of remediation: the independent 121-file
archive comparison, exact upstream patch and optimized iterator tests remain
the evidence for this local backport. Their stored log hash was rechecked and
the original-archive verifier rerun successfully on the current vendor tree.
| Current input/report | SHA-256 |
| --- | --- |
| Workspace lockfile | `f6f995c96bf8554175423edfaccbdf61b88a52a5742c660a4a6346395139eb6e` |
| Desktop lockfile | `12b3522694a2a85c937b59b3d8128b10517b2393f6ceb6c105fb75c28e4d398e` |
| Workspace audit JSON | `7fee9db9cf1dca04b82b915cfff76a3fee0023c7fb419d61b287b46d394ec461` |
| Desktop audit JSON | `b4a039d05ad54be81cd0673af5fe9c281193449bb03cc882fe65843a6437d65c` |
Ignored reports and stderr files live in
`.searchi/dependency-review/cargo-audit-0.22.2-current/`.
Advisory data changes; repeat this established scan before future releases.
Registry scanning does not cover native runtime/codec source, platform webviews,
unreported issues or project-level security, whose gates stay open.