java-topology/defects/gimp/SCAN-MOAD-0002-0005.md
russell@unturf.com 89de6df1d4 gimp/inkscape: 2 new CWE-407 defects + all 5 MOADs scanned
gimp-0003: xcf_save_layer_props layer_sets O(L×S×I) MEDIUM 166.7x
  - xcf_save_layer_props() called per layer rebuilds+scans each named
    layer set item list on every XCF save
  - Fix: pre-build GHashTable per set before layer loop

inkscape-0004: LayerManager::_rebuild() std::find O(L²×D) HIGH 166.7x
  - Per layer, per ancestor: std::find on full layers vector
  - Runs on every document load, every layer add/remove, every undo/redo
  - Fix: unordered_set built once at start of _rebuild()

MOADs 0002/0003/0004/0005: CLEAN for both GIMP and Inkscape.
All 3/4 unit tests PASS respectively.
2026-03-31 20:55:50 -04:00

1.2 KiB
Raw Blame History

GIMP — MOADs 00020005 Scan Results

Scan date: 2026-03-31

MOAD-0002 (Intertangle): CLEAN

Gimp is a large struct but subsystems access it via clean interfaces. plug_in_manager, image_manager, display_manager are separate objects connected by pointer. No evidence of independent subsystems coupling through shared mutable state in a way that breaks subsystem isolation.

MOAD-0003 (Leaked Context): CLEAN

No GPrivate, g_private_get/set, or thread_local usage found in app/ for request-scoped identity. GIMP is predominantly single-threaded in its core logic. Thread pool in xcf-save.c uses per-job data structs, not thread-local state.

MOAD-0004 (CWE-312 Logged Secret): CLEAN

Network auth credentials: file-open.c and file-save.c log only mount failure messages, not credentials. PDF password handling in plug-ins/common/file-pdf-load.c is interactive UI only — password never reaches a log/debug call.

MOAD-0005 (Thundering Herd): CLEAN

Thread pool in xcf-save.c uses GAsyncQueue for result delivery (producer/consumer pattern, no shared cache). GIMP's main UI thread manages all image metadata; no concurrent cache get+null+insert pattern found.