You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Artifact
Result
libfftw3-3.dll
✅ Byte-identical to official fftw.org binary
fftw3.h
✅ Identical after CRLF→LF normalization
libfftw3-3.def
✅ Identical export set (1017/1017 symbols), CRLF-only diff
fftw3.lib / fftw3.exp
⚠️ No upstream equivalent — derived MSVC import stubs (no executable code)
The committed blob is redundant.scripts/setup/setup-fftw.ps1 already downloads the exact samefftw-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.
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.
Provenance. The double-precision blob entered in Add spectral noise reduction (NR2) with FFTW3 integration #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.
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.
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/.libentered 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.dllwas verified byte-for-byte identical to the official upstreamfftw-3.3.5-dll64.zipfrom fftw.org:libfftw3-3.dllfftw3.hlibfftw3-3.deffftw3.lib/fftw3.exp001a835d2f25ac0661580d67db5622157c28481c06a7f3ef45ad939839bf54a1f24bb2f008f059c8a7de9b71b9f81ad0So this is a process / hygiene issue, not a compromised-binary issue.
What's inconsistent today
third_party/fftw3/vendored DLL + locally-generated.liblibfftw3-devvia apt (.github/docker/Dockerfile)/opt/homebrew/lib)Two specific oddities:
scripts/setup/setup-fftw.ps1already downloads the exact samefftw-3.3.5-dll64.zipfrom fftw.org and generates the.libvialib.exe. CMake (CMakeLists.txt:140) even points users to that script when the lib is missing.fftw3f.lib/libfftw3f-3.dllis not committed —CMakeLists.txt:1428tells you to run the script to get it. So the same library's two precisions are sourced two different ways.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:
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.third_party/fftw3/PROVENANCE.mdrecording 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.