java-topology/whitepaper/outreach/shotcut.md

Shotcut — CWE-407 Disclosure Brief (shotcut-0001)

2026-04-13 · Patch available — awaiting upstream merge

Finding

An O(N²) linear scan in PlaylistProxyModel at src/docks/playlistdock.cpp. The m_hashes member uses std::vector<std::string> with std::find() for membership checks inside filterAcceptsRow(), which fires for every row in the playlist model. With N playlist clips, filtering costs O(N²).

The Defect

shotcut-0001 (PATCHED — MEDIUM): src/docks/playlistdock.cpp

std::vector<std::string> m_hashes;
// In filterAcceptsRow():
return std::find(m_hashes.begin(), m_hashes.end(), hash) != m_hashes.end();
// O(N) per row × N rows = O(N²)

Additionally, hashes() performs sort + dedup via std::set copy on every access instead of maintaining uniqueness at insert time.

Complexity Proof

At N=1,000 playlist clips:

• Defective: 1,000 × 1,000/2 = 500,000 string comparisons per filter pass
• Fixed: 1,000 × O(1) hash lookups = 1,000 probes
• 500× op reduction per filter pass

Impact

Shotcut serves a large community of video editors. Playlist filtering fires on every model update (clip add, remove, reorder) and when switching filter modes (duplicates, used/unused). Large projects with hundreds of clips trigger visible UI lag during these operations.

The Fix

Replace std::vector<std::string> m_hashes with std::unordered_set<std::string>. Use insert() instead of push_back(), count() instead of std::find(). The dedup step in hashes() becomes unnecessary since the set is inherently unique.

Patch

Fix available: defects/shotcut/patch/shotcut-0001-playlist-hashes-linear-find.patch

500× op reduction at N=1,000 clips.

What We Ask

1. Confirm receipt and assign a GitHub issue reference (mltframework/shotcut).
2. Assess severity — fires on every playlist filter update.
3. Coordinate a disclosure date — targeting 90 days from first contact.
4. We will credit the Shotcut team in the public disclosure.

Contact: see cover email. This brief is confidential until coordinated disclosure.