Consolidate Windows FFTW3 sourcing: vendored blob vs. setup script (audit clean, hygiene only)

Start with scripts/setup/setup-fftw.ps1, CMakeLists.txt around lines 140 and 1428, and the committed files under third_party/fftw3/. Review the closed pull request linked to this issue before choosing between removing the vendored files with hash verification or documenting and checking their provenance. Done means one consistent FFTW sourcing path with the selected verification or provenance checks in place.

Summary

The Windows FFTW3 dependency is vendored as a committed binary (third_party/fftw3/) and also obtainable via a download script (scripts/setup/setup-fftw.ps1). The two paths overlap inconsistently, and the committed .dll/.lib entered the tree in a large, unreviewed PR. This issue proposes consolidating onto a single, provenance-verified path. No security problem was found in the current bytes — see the audit below.

Audit result (current bytes are clean ✅)

The committed third_party/fftw3/bin/libfftw3-3.dll was verified byte-for-byte identical to the official upstream fftw-3.3.5-dll64.zip from fftw.org:

• SHA-256: 001a835d2f25ac0661580d67db5622157c28481c06a7f3ef45ad939839bf54a1
• MD5: f24bb2f008f059c8a7de9b71b9f81ad0
• Version: FFTW 3.3.5, MinGW-w64 x86-64 (upstream build, 2016-07-30)

So this is a process / hygiene issue, not a compromised-binary issue.

What's inconsistent today

Two specific oddities:

1. The committed blob is redundant. scripts/setup/setup-fftw.ps1 already downloads the exact same fftw-3.3.5-dll64.zip from fftw.org and generates the .lib via lib.exe. CMake (CMakeLists.txt:140) even points users to that script when the lib is missing.
2. Double is vendored, float is fetched. The single-precision fftw3f.lib/libfftw3f-3.dll is not committed — CMakeLists.txt:1428 tells you to run the script to get it. So the same library's two precisions are sourced two different ways.
3. Provenance. The double-precision blob entered in #79 (a 2,567-line PR, merged with zero reviewers). The bytes happen to be legitimate, but nothing in-tree records that or lets CI re-verify it.

Not a patent issue

For the record: FFTW is not patent-encumbered. It's GPLv2-or-later free software from MIT. The only obligation is GPL copyleft (which applies regardless of how FFTW is obtained), so licensing isn't a reason to prefer vendoring.

Proposed resolution (maintainer's call)

Pick one consolidation path:

• Option A (recommended): drop the committed blob, rely on setup-fftw.ps1. Add a pinned SHA-256 verification step to the script (assert the downloaded zip matches the hash above). This makes Windows consistent with the float path and with Linux/macOS, and removes unauditable binary from going-forward history.
• Option B: keep it vendored, add provenance. Add third_party/fftw3/PROVENANCE.md recording the verified SHA-256 + upstream URL + version, and a CI check that re-verifies the committed bytes against that hash. Choose this if clone-and-go on Windows with no network step is a priority and CI independence from fftw.org uptime matters.

Either is fine. The current state — blob committed and script exists, double vendored and float fetched — is the one combination worth cleaning up.

Suggested follow-on hardening (separate, optional)

A CI guard that fails on newly-introduced binary files (*.dll/.lib/.so/.dylib/.a/.exe) would prevent the #79 class of unreviewed-blob merges in future.

Filed for maintainer review. Audit performed against upstream fftw.org/pub/fftw/fftw-3.3.5-dll64.zip.