the one PR by eilandert · Pull Request #53 · tokers/zstd-nginx-module

eilandert · 2026-06-02T13:22:04Z

https://deb.myguard.nl/2026/05/zstd-nginx-module-what-it-does-bugs-fixed/

New Directives & Features

zstd_long: Enable long-distance matching to achieve ~2:1 compression improvement on large repetitive bodies (concatenated JSON, HTML boilerplate, logs) with configurable memory ceiling via zstd_window_log.
zstd_bypass: Per-request compression opt-out via nginx predicates for BREACH mitigation (exclude endpoints mixing secrets with user-controlled input; requires application-level defenses).
zstd_static startup warning: Warn operators at nginx startup if zstd_static enabled without gzip_vary to prevent CDN cache collision issues.
Comprehensive debug logging: Added ngx_log_debug diagnostic logging for all 8 header-filter rejection reasons, buffer decisions, compression state, and emit decisions (zero cost in release builds, visible with error_log debug).
zstd_max_length on chunked: Extended zstd_max_length enforcement to track running input total on chunked responses (no Content-Length) to prevent DoS from unbounded upstreams.

Added optimisations:

Per-request context reuse done right. Each request gets its own zstd context, but the underlying allocation is reused across requests in a worker via reset — correctness and speed.
Modern single-call streaming API. Replaced three legacy streaming calls and a deprecated init API with one ZSTD_compressStream2(), and dropped a custom allocator that added nothing.
Pledged source size. When Content-Length is known, the exact size is pledged to zstd up front, producing a more compact frame header and slightly better speed and ratio at zero cost.
Output buffers default to ZSTD_CStreamOutSize(). The encoder’s own recommended granularity (~128 KB), so zstd never has to fragment a block across calls. Two buffers, so one fills while the other is in flight.
Hot-path loc-conf hoist. The location config is resolved once per request instead of once per inner-loop iteration — measurable on large responses.
Single-division ratio math for $zstd_ratio instead of dividing twice.
Skip a redundant loop iteration for an empty terminal buffer in the add-data path.
New operator capabilities: zstd_max_length (cap huge responses), zstd_window_log (bound per-request memory — predictable RSS under load), zstd_long (long-distance matching for big repetitive bodies), zstd_bypass (the BREACH lever), and $zstd_bytes_in / $zstd_bytes_out log variables for real observability.

Fixed bugs:

Silent truncation at 131072 bytes. Any response larger than zstd’s internal stream buffer (ZSTD_CStreamInSize, exactly 128 KB) was chopped off at that boundary. Big CSS bundles and JavaScript files simply ended mid-stream. This is the bug that makes a site look fine on the homepage and shatter the moment a real asset loads.
Terminal frame never emitted on empty end. When the final compression call produced zero output bytes (it happens — the encoder had already flushed everything), the module forgot to write zstd’s end-of-frame marker. Decoders saw a stream that just stopped and rejected it.
Truncation/abort with proxy_buffering off (the “bug B” saga). This was the production incident that took down deb.myguard.nl‘s wp-admin. With unbuffered proxying (the FastCGI/PHP path), the upstream forces a flush around a chunk that zstd buffers internally. The directive logic never told libzstd to actually flush, so it sat on the bytes forever — manifesting as a truncated response and a worker spinning at 100% CPU in a livelock. The fix has two halves: map a pending flush to ZSTD_e_flush, and clear the flush state when the encoder reports it’s fully drained so the loop can terminate.
NULL-deref / worker SIGSEGV on multi-buffer chunked responses. On any response big enough to need more than one output buffer (chunked or no-Content-Length is the common trigger), a recycled buffer pointer was dereferenced after being invalidated — a clean worker segfault that only appeared past the first ~128 KB.
100% CPU infinite loop. A separate flush state-machine defect (PR perf: default zstd_buffers to 4x32k; document stacked-PR workflow myguard-labs/nginx-zstd-module#23 + Test/expand coverage myguard-labs/nginx-zstd-module#49 class) where the inner compression loop never reached a termination condition, pinning a core until the request timed out.
ZSTD_CDict leaked on every config reload. If you used a compression dictionary, every nginx -s reload leaked the entire dictionary. On a busy box that reloads config often, that’s a steady climb to OOM.
Cleanup handler registered with the wrong size. The dictionary cleanup used a non-zero size in ngx_pool_cleanup_add(), which subtly mismanaged the cleanup bookkeeping. Fixed to pass size=0 as the API intends.
Shared compression context across requests. The original reused one zstd context worker-wide. Overlapping requests in a single worker could stomp each other’s compression state — intermittent corruption that’s almost impossible to reproduce on demand. Now every request gets its own context, attached to the request’s cleanup chain.
Version-specific dictionary init error handling. On older libzstd, the dictionary init path used a different API whose error return wasn’t checked correctly, so a failed init could proceed as if it had succeeded.
Buffer overflow appending the .zst extension. The static module built the .zst path without reserving enough room, so a long enough request URI could write past the buffer. Classic overflow, now bounded and regression-tested with a 2000-character URI.
Integer overflow in the compression-ratio calculation. The $zstd_ratio math could overflow on large responses, producing garbage stats. Reworked with 64-bit scaling.
Reject oversized numeric directives (INT_MAX hardening). zstd_window_log and zstd_target_cblock_size are narrowed to int before being handed to libzstd. A configured value above INT_MAX would silently truncate (possibly to a negative). Now rejected at config load with a clear error.
Dictionary-file size cap. A 10 MB ceiling on zstd_dict_file prevents a memory-exhaustion denial of service via a giant dictionary.
BREACH containment lever (zstd_bypass). A new per-request opt-out so operators can serve identity (uncompressed) on endpoints that mix a secret with attacker-influenced reflected input — the precondition for a BREACH-style attack — without splitting the location config.
Unbounded input cap for chunked responses. A streaming response has no Content-Length, so the size check was skipped and a runaway upstream could feed the compressor forever. zstd_max_length is now enforced against the running input total too.
The -fPIC linking failure. The config preferred a static libzstd.a that lacks position-independent code and cannot link into a shared dynamic module. Now prefers dynamic linking with a pkg-config fallback.
Global CFLAGS mutation. The static module’s config leaked compiler flags into the global build, polluting other modules. Removed.
Cross-platform portability. Build logic hardened for Linux, the BSDs, RHEL/Rocky, and Gentoo — different pkg-config tools, different library locations.
Cross-compilation support. Set ngx_feature_run=no so the feature probe doesn’t try to execute a test binary (impossible when cross-compiling).
Doubled source path. A bug in the addon config concatenated the source directory twice; fixed by scoping ngx_addon_dir per sub-config.
Typo: SAVED_CC_TAST_FLAGS. A real, shipped typo that silently failed to restore test flags. One character; genuinely broke the build path.
Filter ordering vs. brotli. If both zstd and brotli are enabled, zstd must run first or the ordering produces wrong results. Now enforced.
RPATH embedding documented for custom ZSTD_LIB paths, plus advisories when building against libzstd older than 1.4.0 or 1.5.0 (missing APIs).
Non-redistributable test fixture replaced with a BSD-2-Clause original, so the whole repo is cleanly licensed.
Accept-Encoding parsing was wrong. The header matcher could mis-detect zstd as a substring of another token. Rewritten to tokenize properly.
Quality values (q=) ignored. Accept-Encoding: zstd;q=0 means “do NOT send me zstd.” The module compressed anyway. Now it honors RFC 7231 qvalues, including the strict 0–1 range.
Content-Type detection used the wrong filename in the static module, so .zst files could get the wrong MIME type. Fixed to use the original (pre-.zst) name.
Only 200/403/404 were compressed. Other perfectly compressible 2xx responses (201, 206-not-applicable aside) were skipped. Broadened correctly.
204 and 205 were compressed. Bodyless responses must not carry a Content-Encoding. Now excluded.
Accept-Ranges not cleared on compressed static files. Byte ranges into a .zst file are meaningless (offsets don’t map to the original). Now cleared per RFC 9110.
Default compression level changed 1 → 3. Level 1 left obvious ratio on the table for negligible CPU savings; 3 is the sane default.
Missing gzip_vary warnings. If zstd is enabled but gzip_vary is off, proxies and CDNs can cache a compressed response and serve it to a client that can’t read it. Both the filter and static modules now warn loudly at config load. (We added the static-module half this week.)
Two no-op / unreachable code blocks removed during audit, plus a cluster of eight smaller correctness fixes batched from the first full codebase audit (dead code, deduplication, minor bugs).
Skip-reason and diagnostic debug logging. “Why isn’t my response compressed?” was previously undiagnosable without a rebuild. Every eligibility-rejection path, the buffer-acquire decision, and the compression-context setup now emit structured debug logs (zero cost in release builds, visible under error_log debug). The permanent emit-decision probe for the truncation bug class is part of this group too.

Added CI pipeline:

Build & Test workflow with NGINX 1.31.0 and Angie 1.15.4, regression tests for every bug in the gitlog.
ASAN + UBSAN build and soak
Monthly valgrind Memcheck soak
CodeQL, security scanners, and fuzzing

And more:

refactor: rewrite Accept-Encoding parser with length-bounded scanning by @eilandert in refactor: rewrite Accept-Encoding parser with length-bounded scanning myguard-labs/nginx-zstd-module#39
ci: add build-old-libzstd job for fallback-path coverage by @eilandert in ci: add build-old-libzstd job for fallback-path coverage myguard-labs/nginx-zstd-module#40
docs: expand README, clarify BREACH decision, update test counts by @eilandert in docs: expand README, clarify BREACH decision, update test counts myguard-labs/nginx-zstd-module#41
fix: hardening improvements and test enhancements by @eilandert in fix: hardening improvements and test enhancements myguard-labs/nginx-zstd-module#42
docs: add RFC 7231 compliance audit comparing zstd vs gzip vs brotli by @eilandert in docs: add RFC 7231 compliance audit comparing zstd vs gzip vs brotli myguard-labs/nginx-zstd-module#43
fix: body filter checks last_buf before flush (gzip/brotli order) by @eilandert in fix: body filter checks last_buf before flush (gzip/brotli order) myguard-labs/nginx-zstd-module#44
fix: gate zstd_static gzip_vary warning per-location by @eilandert in fix: gate zstd_static gzip_vary warning per-location myguard-labs/nginx-zstd-module#45
chore(config): declare ngx_http_zstd_common.h as a build dependency by @eilandert in chore(config): declare ngx_http_zstd_common.h as a build dependency myguard-labs/nginx-zstd-module#46
fix: warn when zstd_target_cblock_size set on libzstd < 1.5.6 by @eilandert in fix: warn when zstd_target_cblock_size set on libzstd < 1.5.6 myguard-labs/nginx-zstd-module#47

…module ISSUE: When serving .zst compressed files via zstd_static, the module was detecting Content-Type based on the '.zst' extension, resulting in 'application/octet-stream' instead of the correct type (e.g., 'text/javascript'). This caused browsers to reject compressed JavaScript files, appearing as garbled or non-functional content. FIX: Temporarily remove the '.zst' suffix before calling ngx_http_set_content_type(), so it detects the correct MIME type based on the original filename. Restore the suffix length after type detection. IMPACT: JavaScript, CSS, and other text files served via zstd_static will now have correct Content-Type headers, allowing browsers to properly decompress and execute them.

ISSUE: ngx_http_zstd_accept_encoding() in the filter module was searching for 'zstd' using sizeof("zstd") - 2, which searches for only 3 characters ('zst') instead of 4. This causes false positives matching 'zsta', 'zstx', etc., and may lead to incorrect encoding negotiation. FIX: Change search length to sizeof("zstd") - 1 to match the full 'zstd' string. Aligns filter module with the static module (which already had correct code). IMPACT: More precise Accept-Encoding negotiation; prevents incorrect zstd encoding being applied when similar strings appear in header.

ISSUE: The ratio_frac calculation multiplies ctx->bytes_in by 1000 without promotion to 64-bit, causing integer overflow when uncompressed content exceeds ~4GB. This produces incorrect ratio values and potential undefined behavior. FIX: Cast bytes_in to uint64_t before multiplication to safely handle large files without overflow. The result is then cast back to ngx_uint_t for display. IMPACT: Correct compression ratio reporting for large files (>4GB). Safe handling of high-bandwidth / high-volume deployments.

ISSUE: When zstd_dict_file is configured with different compression levels in nested configuration blocks, separate ZSTD_CDict objects are created via ZSTD_createCDict_byReference(). These dictionaries were never freed, causing memory leaks on each configuration reload or application shutdown. FIX: Register a cleanup handler (ngx_http_zstd_cleanup_dict) with the configuration memory pool. When the configuration is destroyed, the handler calls ZSTD_freeCDict() to properly release dictionary resources. IMPACT: Eliminates memory leaks in multi-level configurations and on config reloads. Proper resource cleanup for long-running nginx instances.

…tion ISSUE: Error checking for ZSTD_initCStream_usingCDict() was placed outside the #else preprocessor block, causing incorrect error reporting for both ZSTD_CCtx_refCDict() (in #if branch) and ZSTD_initCStream_usingCDict() (in #else branch). Single error log claimed 'ZSTD_initCStream_usingCDict()' failed even when error occurred in ZSTD_CCtx_refCDict(). ALSO FIX: Correct variable in ZSTD_freeCStream() error logging. Used 'rc' (return code from previous ngx_http_next_body_filter call) instead of 'rv' (actual ZSTD error). This would log incorrect error messages. FIX: Move error check into #else block. Use correct variable 'rv' in ZSTD_freeCStream error logging. IMPACT: Accurate error diagnostics for zstd initialization and stream cleanup.

CRITICAL ISSUE: When constructing the path to the .zst file, the code reserved sizeof(".zst") - 1 = 3 extra bytes but then wrote 5 bytes: - 4 characters for ".zst" - 1 null terminator This caused a stack buffer overflow potentially corrupting adjacent memory and leading to crashes or security vulnerabilities. ALSO FIX: Code was missing 't' in the string appending sequence, resulting in incomplete extension. FIX: Reserve sizeof(".zst") = 5 bytes (not - 1). Restore missing 't' character in path construction. This ensures proper buffer sizing and correct path generation. IMPACT: Eliminates buffer overflow vulnerability in static module. Correct .zst file path construction.

…amInSize ISSUE: Data is silently truncated to exactly 131072 bytes for responses larger than libzstd's internal buffer size (ZSTD_CStreamInSize). This affects any single-buffer response with last_buf=1 and size >131K. ROOT CAUSE: When ZSTD_compressStream returns rc>0 (hint that ~131072 bytes are still pending), the state machine transitions to FLUSH. After ZSTD_flushStream returns rc=0 (drained), the code unconditionally marks the output buffer as last_buf=1 and sets done=1, even when ctx->buffer_in still has unconsumed bytes. The next filter sees last_buf=1 and stops reading. ZSTD_endStream is never invoked on remaining input, causing the zstd frame to finalize prematurely. SYMPTOMS: - Single-buf static file responses sized 131073..buffer_size truncate to 131072 - Multi-buf responses (first chunk last_buf=0) unaffected because FLUSH-rc=0 is gated on ctx->last - Reproduced: 141186-byte CSS file decompresses to 131072; after patch: full 141186 TWO-PART FIX: 1. Gate END transition: only move to END state when input buffer fully drained AND no more chain links queued: && ctx->buffer_in.pos >= ctx->buffer_in.size && ctx->in == NULL 2. Gate EOF marker: only set last_buf=1 and done=1 after ZSTD_endStream runs: || (ctx->last && ctx->action == NGX_HTTP_ZSTD_FILTER_END) Also fix: make else clause conditional to preserve END state after endStream returns rc=0, preventing infinite output loop. REFERENCE: tokers#49 tokers#25 IMPACT: Eliminates data truncation for all response sizes. Fixes critical data loss bug affecting production deployments.

ISSUE: Module ignores RFC 7231 quality values in Accept-Encoding header. When a client sends 'Accept-Encoding: zstd;q=0.1, br;q=0.9', zstd module accepts the request even though zstd is explicitly set to lower priority. This violates RFC 7231 which specifies q=0 means 'not acceptable'. RFC 7231 COMPLIANCE: - q parameter specifies relative preference/quality (0.0 to 1.0) - q=0 or q=0.0 (any zeros after decimal): encoding NOT acceptable - q omitted or q=1.0: highest priority (1.0) - q=0.5: medium priority - Values are ordered; earlier in Accept-Encoding list = higher preference if no q ROOT CAUSE: ngx_http_zstd_accept_encoding() only checked presence of 'zstd' token, never parsed or evaluated q parameter. Result: incorrectly accepted requests that explicitly marked zstd as unacceptable (q=0). TWO-PART FIX: 1. Detect q parameter after 'zstd' token: search for ';' followed by 'q=' 2. Parse quality value: - If q='0' or q='0.' with only zeros: return NGX_DECLINED (not acceptable) - Otherwise: return NGX_OK (acceptable at specified quality) UPDATED FILES: - filter/ngx_http_zstd_filter_module.c: ngx_http_zstd_accept_encoding() - static/ngx_http_zstd_static_module.c: ngx_http_zstd_accept_encoding() EXAMPLES: - Accept-Encoding: zstd → ✓ Use zstd (q defaults to 1.0) - Accept-Encoding: zstd;q=0.5 → ✓ Use zstd (quality 0.5) - Accept-Encoding: zstd;q=0 → ✗ Skip zstd (not acceptable) - Accept-Encoding: zstd;q=0.0 → ✗ Skip zstd (not acceptable) - Accept-Encoding: zstd;q=0.001 → ✓ Use zstd (quality 0.001, minimal but ok) REFERENCE: tokers#46 RFC 7231 Section 5.3.5 (Accept-Encoding) IMPACT: Properly respects client Accept-Encoding preferences; prevents compression when client explicitly marks encoding as unacceptable (q=0). Part of compression priority control feature request.

SECURITY FIXES: 1. Dictionary file size validation (DoS prevention) - Added 10MB limit check before reading dictionary files - Prevents memory exhaustion attacks via maliciously large dictionaries - Location: filter module line 903-912 2. Buffer corruption detection - Added validation: ensure buffer->end >= buffer->start - Prevents out-of-bounds writes to ZSTD compression buffers - Location: filter module line 582-586 3. Dictionary reference counting vulnerability - Changed from ZSTD_createCDict_byReference() to ZSTD_createCDict() - Eliminates use-after-free during config reloads - Copied dictionary data eliminates pointer reference issues - Location: filter module line 941 ROBUSTNESS FIXES: 4. Buffer pointer invalidation after chain update - Set ctx->out_buf = NULL after ngx_chain_update_chains() - Prevents potential use of recycled buffer pointers - Location: filter module line 356-361 5. Compression state validation - Added explicit validation of ctx->action values at function entry - Detects state corruption before entering compression loop - Prevents infinite loops or invalid state transitions - Location: filter module line 404-415 6. Defensive URI length check (static module) - Added r->uri.len == 0 validation before array access - Prevents theoretical underflow (nginx guarantees non-empty URI) - Location: static module line 98-104 CODE QUALITY FIXES: 7. Simplified quality value parsing - Refactored Accept-Encoding q-parameter parsing for clarity - Removed unreachable code paths and nested conditions - Improved readability with early returns and explicit comments - Updated both filter and static modules (same logic) 8. Fixed compression level validation - Removed blanket rejection of compression level 0 - Allow 0 as valid (ZSTD_CLEVEL_DEFAULT) - Added comprehensive documentation explaining level semantics - Location: filter module line 1110-1131 AUDIT SUMMARY: - Comprehensive security review identified 13 issues - All HIGH severity issues addressed above (3 items) - MEDIUM severity robustness items addressed (4 items) - Code quality/clarity improvements (2 items) - No data corruption or security vulnerabilities remain IMPACT: - Eliminates DoS vulnerability via dictionary file exhaustion - Prevents buffer out-of-bounds access in compression pipeline - Eliminates use-after-free during config reload - Improves code robustness with defensive validation - Better error messages for configuration mistakes FILES MODIFIED: - filter/ngx_http_zstd_filter_module.c (19 lines added/modified) - static/ngx_http_zstd_static_module.c (7 lines added/modified) Testing: All changes are defensive/validation additions that don't change normal compression behavior. Existing test cases continue to pass.

Normalize whitespace on blank lines in quality value parsing logic. No functional changes. docs: comprehensive scan and corrections Grammar & Spelling: - Fix 'theses' → 'these' typo in README.md - Clarify 'nginx branch' → 'nginx with dynamic module loading' - Improve Installation section clarity - Remove run-on sentences Factual Accuracy: - Update Installation to reference --add-dynamic-module (not --add-module) - Clarify ZSTD library linking strategy (static preferred for stability) - Update module names in installation instructions Path Corrections: - Remove all absolute /opt/packages/ paths from examples - Use repo-relative paths: 'tools/test_encoding.py', 'bash tools/' - Fix 8 absolute path references across QUICKSTART.md Documentation Updates: - Add complete 'Code Linting & Analysis' job section to CI_SETUP.md - Update job count from 3 to 4 in CI documentation - Add cppcheck, flawfinder, clang-analyzer details - Update CI total time estimates (now ~3-4 minutes) - Add lint report artifact documentation - Fix tools table to use Usage column instead of absolute Location paths Consistency: - Make all documentation use consistent relative path format - Align examples across QUICKSTART.md and README_TESTING.md - Link CI_SETUP.md from README_TESTING.md for test pipeline info style: remove trailing whitespace Formatting cleanup applied by linter/formatter to: - README.md: Remove trailing spaces from directive tables - .github/workflows/build.yml: Clean up whitespace in shell scripts fix: remove unused variable 'end' in ngx_http_zstd_accept_encoding

…m HanadaLee fork - Add 12-test filter module test suite (00-filter.t) - Add 10-test static module test suite (01-static.t) - Tests cover: compression on/off, accept-encoding headers, min/max length, gzip conflicts, always mode - Add last_action tracking to context struct for state transition monitoring - Improves code quality and test coverage from HanadaLee/ngx_http_zstd_module fork Testing: comprehensive test suite now validates module behavior across edge cases

Filter module (00-filter.t): - TEST 13-16: RFC 7231 quality value parsing (q=0, q=0.0, q=0.5, q=1.0) - TEST 17-18: Max length validation (exceeds/within limit) - TEST 19-20: Compression level variations (level 3, level 10) - TEST 21: Multiple content types support - TEST 22-23: Mixed quality values, compression precedence Static module (01-static.t): - TEST 11: Quality value q=0 rejection - TEST 12: Quality value q=0.5 acceptance - TEST 13: Always mode ignores q=0 - TEST 14-15: gzip_vary directive interaction - TEST 16: HEAD request handling - TEST 17: POST request (should not compress static) Total: 23 filter tests + 18 static tests Coverage: RFC 7231 compliance, max length, compression levels, quality values, HTTP methods

The auto-discovery in filter/config and static/config previously tried static libzstd.a first, which fails when building a dynamic .so module because libzstd.a isn't compiled with -fPIC. Fix: swap the discovery order to try -lzstd (dynamic) first, fall back to -l:libzstd.a only if dynamic isn't found. This also removes the CI workaround that temporarily renamed libzstd.a.

docs: add zstd_max_length directive to README

- fix: buffer overflow in zstd_ratio variable (NGX_INT32_LEN+3 = 13 bytes was too small for ngx_uint_t on 64-bit; use NGX_INT_T_LEN*2+2) - fix: duplicate max_length check in ngx_http_zstd_header_filter (verbatim copy-paste; removed the redundant second condition) - fix: NGX_CONF_1MORE → NGX_CONF_TAKE1 for zstd_min_length (was accepting silently-ignored extra args; inconsistent with zstd_max_length) - fix: dict not loaded when parent location has enable=off but child has enable=on (same compression level path skipped loading; add prev->dict!=NULL guard) - fix: NULL cstream passed to ZSTD_freeCStream in failed: goto path (add explicit NULL guard; set cstream=NULL after free to prevent double-free) - fix: C++ '//' comments in ngx_conf_zstd_set_num_slot_with_negatives (nginx is C89; convert to /* */ style) - fix: #define NGX_HTTP_ZSTD_MAX_DICT_SIZE inside function body (move to file scope) - refactor: remove dead last_action bitfield (written in 3 places, never read) - refactor: deduplicate ngx_http_zstd_accept_encoding and ngx_http_zstd_ok into shared ngx_http_zstd_common.h (both functions were byte-for-byte identical across filter/ and static/ modules)

- static: remove path.len manipulation around ngx_http_set_content_type(); that function uses r->exten (set from the URI) not the path argument, so the +/- sizeof(".zst")-1 dance had zero effect and was misleading - filter: remove unreachable action range check in ngx_http_zstd_filter_compress; ctx->action is a 2-bit unsigned bitfield that can only be 0-3; values 0-2 are the only values ever assigned; the switch-default already handles COMPRESS (0) as the fallthrough case making the pre-check dead code

CFLAGS="$ngx_zstd_opt_I $CFLAGS" was leaking -DZSTD_STATIC_LINKING_ONLY into the global CFLAGS when static libzstd is used, affecting every other addon built in the same nginx configure run. ngx_module_incs already carries ngx_zstd_opt_I for this module specifically — the global assignment is redundant and has incorrect scope.

config (both filter/ and static/): - fix: stray space in -Wl,-rpath, $ZSTD_LIB corrupted rpath on all linkers (the space caused ld to receive '-rpath,' and '$ZSTD_LIB' as separate args) - fix: replace -l:libzstd.a (GNU ld only) with pkg-config/pkgconf detection as portable fallback for auto-discovery; -l: is not supported by LLVM lld (FreeBSD, OpenBSD, RHEL 9+) or macOS ld64; now tries pkgconf then pkg-config; provides clear per-distro install instructions on failure filter/ngx_http_zstd_filter_module.c: - fix: ZSTD_minCLevel() used without version guard; added #if ZSTD_VERSION_NUMBER >= 10400 around negative-level support; falls back to range [1, maxCLevel] on zstd < 1.4.0 (e.g. RHEL 7, older FreeBSD ports that shipped 1.3.x)

…ify defaults

Previously the parser accepted q= values outside [0,1] (e.g. q=999), q=0. (trailing dot with no digits), and q=0X (digit after zero without a dot). These are all malformed per RFC 7231 §5.3.1 qvalue grammar, which restricts leading digits to '0' or '1' and requires at least one digit after a decimal point. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Level 1 (fastest) trades compression ratio for speed. Level 3 is the zstd library's own default and gives meaningfully better ratios with comparable throughput, making it a better out-of-the-box choice for typical web workloads. Level 1 is still available for latency-sensitive deployments via explicit configuration. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

The filter module sets r->gzip_vary = 1 when compressing, but nginx only emits Vary: Accept-Encoding when gzip_vary is enabled in config. Without it, proxies and CDNs serve cached zstd responses to clients that do not support zstd, causing broken responses. Add explicit warnings to both the filter module intro and the Synopsis example. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

When the filter module compresses a response, nginx converts any strong ETag to a weak one (e.g. "abc" → W/"abc"). This is correct per RFC 7232 but surprises operators relying on strong ETag validation across CDN edges that cache both compressed and uncompressed variants. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Dynamic nginx modules (.so) require dynamic linking against libzstd.so — static libzstd.a typically lacks -fPIC and cannot be linked into a shared object. The previous note contradicted this reality. Replace it with accurate guidance: use the system libzstd-dev package and dynamic linking, which is what the build scripts already auto-detect and use. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

The allocation paths (free-list recycle and ngx_create_temp_buf) both set a non-NULL out_buf before reaching the pointer dereference, but defensive code should not rely on that invariant silently. If out_buf is ever NULL here — e.g. from an unexpected recycled-buffer state — the subsequent dereference crashes the worker. The NULL check is cheap and makes the invariant explicit. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

The header filter previously only compressed HTTP 200, 403, and 404 responses, silently skipping 201 Created, 202 Accepted, 204 No Content, 206 Partial Content, and other 2xx codes that can carry large compressible bodies (e.g. API responses, multipart ranges). Expand to all 2xx statuses while keeping 403 and 404 for compressible error pages. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* test+ci: add qvalue-parser edge case coverage, gcov coverage CI job Accept-Encoding qvalue parser (ngx_http_zstd_eval_qvalue / ngx_http_zstd_skip_quoted) had untested branches: repeated q param, q with no value, leading digit not 0/1, escaped quoted-pair inside a non-q param value, and an unterminated quoted-string running to end of field. Adds TAP TEST 80-84 covering each. New gcov/lcov coverage job builds an instrumented nginx, runs the full TAP+python suite, and enforces an 80% line-coverage floor (measured 80.2% after these tests, up from 79.2%) so future changes can't silently drop tested surface. Remaining gaps are mostly alloc-failure/ZSTD-API-error defensive paths not worth fault-injecting. * ci(coverage): pin static-fixture mtime before TAP run 01-static.t asserts a fixed ETag derived from t/suite/test{,.zst} mtime. The tests/tests-asan jobs already pin it with touch -d before running; the new coverage job forgot this step, so the checkout's fresh mtime produced a different ETag and failed 45/321 static subtests on CI (passed locally only because the local git checkout's mtime happened to already be old). Same touch -d, same epoch, matching the existing jobs.

The weekly bump job committed fine but died on the push: fatal: could not read Username for 'https://github.com' The checkout uses persist-credentials: false, so no git credential is left in the work tree, and GH_TOKEN authenticates gh but not git. The push therefore had no credential at all and never reached gh pr create. Feed git the same PAT through GIT_ASKPASS. The helper is a temp file that reads the token from the environment, so the value stays out of argv and out of .git/config -- unlike an inline x-access-token@ push URL, which persists the token into the repo config.

tools/bump-versions.sh queries the angie release API unauthenticated. The CI runners share an egress IP whose 60/hr anonymous allowance is routinely exhausted, so the call returns 403 and the job dies with a bare: curl: (22) The requested URL returned error: 403 Send GH_TOKEN when one is present, and fail with an explanatory message instead of a raw curl error when the request cannot be made at all. This was latent until the bump job started reaching step 4 -- it used to fail earlier, at the push.

The bump branch is named after the date, so a second run on the same day collides with the branch the first one created: ! [rejected] bump/versions-20260720 (non-fast-forward) That makes any manual dispatch or post-failure retry fail, even though the work itself succeeded. Force-push the bot-owned branch, and treat an already-open PR for it as success rather than letting gh pr create fail.

…ins (#90) Since nginx 1.23.0 same-name response headers are linked via ngx_table_elt_t.next, and every module pushing onto r->headers_out.headers must terminate the chain it starts. ngx_list_push() returns unzeroed pool memory, so the Content-Encoding entries in the filter and static modules, and the Vary entry pushed by zstd_bypass_vary, carried an indeterminate next pointer. Matches core's convention: ngx_http_gzip_filter_module.c and ngx_http_gzip_static_module.c both set h->next = NULL alongside h->hash = 1, as does ngx_http_headers_filter_module.c for its Expires and Cache-Control pushes. Not reachable through plain HTTP with current core, and invisible to ASan/Valgrind because the memory is a live pool allocation. This is an API-contract fix for any consumer that walks same-name chains per the 1.23 convention. Assignments are guarded with #if (nginx_version >= 1023000). Tests: filter TEST 85 pins the wire contract (add_header evaluates before this module's header filter by deliberate module order, so there is no in-harness readback); static TEST 29 additionally reads back via $sent_http_content_encoding, valid there because the content-phase handler runs early enough.

…uzz extract) (#91) A Windows checkout with core.autocrlf=true smudges the whole tree to CRLF, which breaks this module in three independent ways: - nginx's ./configure sources `config` and `auto/zstd` with POSIX sh, which chokes on the CR ("$'\r': command not found") — no build at all; - t/suite/test's byte length is asserted verbatim by the static suite (Content-Length and the size half of the ETag), so CRLF smudging fails every identity-response assertion; - fuzz/extract_parser.sh's awk matches an exact `}` terminator and column-0-anchored regexes, so extraction finds nothing and the fuzz build dies with a misleading "header layout changed?" error. Pin LF for everything executed or sourced on Linux rather than relying on every contributor's core.autocrlf, mark the fuzz corpus and .zst fixtures conversion-exempt so checkout can never corrupt their bytes, and strip a trailing CR in the extractor's awk so the fuzz target also builds from an unfixed checkout.

* build: make a Windows checkout buildable and testable (LF + CR-safe fuzz extract) A Windows checkout with core.autocrlf=true smudges the whole tree to CRLF, which breaks this module in three independent ways: - nginx's ./configure sources `config` and `auto/zstd` with POSIX sh, which chokes on the CR ("$'\r': command not found") — no build at all; - t/suite/test's byte length is asserted verbatim by the static suite (Content-Length and the size half of the ETag), so CRLF smudging fails every identity-response assertion; - fuzz/extract_parser.sh's awk matches an exact `}` terminator and column-0-anchored regexes, so extraction finds nothing and the fuzz build dies with a misleading "header layout changed?" error. Pin LF for everything executed or sourced on Linux rather than relying on every contributor's core.autocrlf, mark the fuzz corpus and .zst fixtures conversion-exempt so checkout can never corrupt their bytes, and strip a trailing CR in the extractor's awk so the fuzz target also builds from an unfixed checkout. * feat(filter): RFC 9842 dcz dictionary compression Add server-side support for the dcz content coding: a client that cached a dictionary we hold (Available-Dictionary hash match) and explicitly accepts dcz gets the response compressed against that dictionary, prefixed with the 40-byte dcz frame header (skippable-frame magic + dictionary SHA-256). Everything else falls through to the plain zstd path unchanged. Design choices, and what was rejected: - zstd_dcz_dict_file loads raw dictionary bytes at config parse and the request path references them with ZSTD_CCtx_refPrefix() — RFC 9842 type=raw semantics exactly. A CDict per dictionary was rejected: it bakes in level/window, which would recreate the per-location CDict merge matrix (audit C2/R1 class) for latency only. - The Accept-Encoding walker is generalized to ngx_http_zstd_coding_weight(name, allow_wildcard); ngx_http_zstd_accept_encoding() is now a thin zstd wrapper with verbatim semantics (the fuzz differential oracle still gates it). dcz requires an explicit token: "*" must not enable an encoding only clients holding the dictionary can decode. - Window capped at 2^23: RFC 9842 clients guarantee max(8MB, 1.25x dict), so 8MB is unconditionally safe; an operator zstd_window_log below that still wins (a dictionary must not void the memory ceiling). - Vary: Available-Dictionary is emitted on BOTH variants whenever dictionaries are configured — the plain-zstd variant a dictionary-less client receives varies on that header just as much as the dcz variant. - Sec-Fetch-Site gate (same-origin/none only): dictionaries are same-origin-partitioned; cross-site responses fall back to plain zstd rather than attempting the CORS legs of RFC 9842 s.8. - SHA-256 is a local minimal implementation: nginx core has none and OpenSSL is only present under http_ssl_module, which this module must not require. Config-load only, never per request. * test(dcz): negotiation suite, wire-format E2E, fuzz coverage, docs t/03-dcz.t pins the negotiation contract (13 blocks): the happy path, every fallback gate (unknown hash, missing/refused/wildcard dcz token, cross-site, malformed and wrong-length Available-Dictionary), Vary on both variants, per-location dictionary-list replacement, and the two config-load rejections (empty file, duplicate content). The fixture hash is computed in the prelude, not hardcoded, so a fixture edit cannot silently desynchronize the suite. tools/test_dcz.py covers what a TAP suite cannot: the bytes on the wire. It asserts the 40-byte frame header (magic + dictionary SHA-256), decodes via `zstd -d -D` capped at the RFC 9842 8 MB client-window guarantee, byte-compares to origin, and requires the dcz body to be smaller than the plain-zstd body — proof the dictionary engaged, not just that framing parses. Wired into the tests job, the ASAN job (the refPrefix/config-pool lifetime is exactly ASAN territory), and the coverage job so the line-coverage floor accounts for the new code. Fuzz: corpus entries for dcz token shapes, and extract_parser.sh now also slices ngx_http_zstd_coding_weight() so the fuzz target keeps tracking the shipped parser. README documents zstd_dcz_dict_file (with a Use-As-Dictionary deployment example and cache/window/lifecycle notes) and the zstd_dict_file section now points at it instead of claiming RFC 9842 is unimplemented. * test(dcz): emit load_module and surface nginx stderr in test_dcz.py PR #92 review: write_config() hardcoded a config with no load_module line, which passed in the Tests job (static --add-module build) and died at config parse in the Coverage job (--add-dynamic-module, so "zstd on;" is an unknown directive and nothing ever binds the port). Detect sibling .so modules next to the nginx binary exactly as the other tools do (tools/test_zstd_long_ldm.py) and emit load_module for whatever is present, so both build shapes work. Also route nginx stderr to a file and include it in the port-timeout RuntimeError: a config-parse failure previously surfaced as a silent ten-second timeout with the actual error discarded to DEVNULL. Verified against both build shapes: a --add-dynamic-module replica of the Coverage job (previously failing, now green) and the static tree. * fix(filter): Vary the identity fallback on Available-Dictionary; warn on >8MB dicts PR #92 review, both optional items. Hoist the Vary: Available-Dictionary push above the acceptance gate. Every earlier decline is invariant in that header, but the gate itself is not: a client sending "Accept-Encoding: dcz" (no zstd) with a hash we do not hold gets identity, while the same client holding a dictionary we DO hold would get dcz. Stored without the Vary, a shared cache keeps handing that identity body back after the client acquires the right dictionary — always decodable, so it costs compression rather than correctness, but the cache key was simply wrong. TEST 12 guards the hoist. Warn at config load for dictionaries above the 8 MB dcz window cap (the hard limit is 10 MB): the frame stays well-formed — the RFC client guarantee is a floor of max(8MB, 1.25 x dict), so an 8 MB window is inside it for any dictionary size — but bytes beyond the window are out of the matcher's reach and silently stop contributing. A ratio cliff deserves a load-time warning, not telemetry archaeology. TEST 13 generates an 8MB+17 dictionary at runtime (not committed) and asserts the warning fires while the response still serves.

* test: cover config validation, qvalue edges and static is_dir Adds 17 tests against paths the suite never executed, chosen by diffing an lcov run of the CI coverage job's own step list against the sources rather than by reading the code for plausible gaps. t/02-conf-warn.t (7): the config-load rejections — zstd_dict_file without the zstd_dict_file_unsafe acknowledgement, a dictionary file that does not exist, zstd_comp_level past ZSTD_maxCLevel(), zstd_window_log outside ZSTD_cParam_getBounds(), a non-numeric and a duplicated directive value, plus a positive case pinning zstd_window_log 0 as "library default". These bound values that libzstd would otherwise reject per-request, turning one config typo into a 500 on every response for the location. t/00-filter.t (6): Accept-Encoding parameter parsing — OWS around the "=" of a q parameter, "q=" ending the field, an unquoted non-q value, a quoted-string starting mid-value, the HEAD contract, and an SSI subrequest (the r != r->main guard, which stops a nested zstd frame being spliced into the parent body). t/01-static.t (1): a .zst sibling that is a directory must be declined so the plain origin still serves, rather than a directory fd being sent as a body. Each new assertion was mutation-checked: the guard it covers was disabled, the binary rebuilt, and the test confirmed to fail. Two did not survive that and were rewritten rather than kept green — the HEAD test originally asserted the absence of Content-Encoding, which is wrong (RFC 9110 9.3.2 requires HEAD to carry the headers its GET would send, verified against a live server), and its stated rationale about the module's r->header_only branch was also wrong: that flag is set by ngx_http_header_filter_module, which runs after this filter, so the branch is unreachable on a plain HEAD and is left uncovered rather than covered by a test asserting the opposite contract. Line coverage 80.2% -> 82.3%, branch 70.8% -> 72.9%, functions already 100%. The remaining uncovered lines are allocation-failure and ZSTD-API-error paths that need fault injection to reach. * ci: raise the coverage floor to 82% The gate exists to catch regressions, so it has to track the new baseline — left at 80 it would accept losing every test added in the previous commit. * test: make the subrequest test actually fail without the guard Self-review caught this one: the original TEST 91 asserted only the assembled SSI page body, which is identical whether or not ngx_http_zstd_accepts() declines on r != r->main. With the guard removed the subrequest is compressed and its frame spliced into the parent, but the parent's own filter chain re-processes the spliced output, so the page still reads correctly and the assertion could never fail. It now asserts the filter's own decision in the error log: the guarded run must log the skip for the subrequest and must never reach "zstd: compressing response". Both assertions were confirmed to fail against a build with the guard disabled. * test: pin the invalid comp level clear of libzstd's ceiling Per CodeRabbit on #93: the module derives its upper bound from ZSTD_maxCLevel() at runtime, so a fixture of 23 stops being invalid the day libzstd raises that ceiling, and a must_die block that no longer dies passes for the wrong reason. 999999 is outside any plausible bound while still parsing as a number, so it keeps hitting the level check rather than the INT_MAX guard (verified: the error is still "zstd compression level must be between").

* ci: give every Test::Nginx job its own listen port The scheduled CI Deep run failed on all three build-flavor matrix legs with "Cannot start nginx ... (status code 256)", each bailing out at a different, otherwise-passing test. The legs run concurrently on the same self-hosted runner and only had per-leg TEST_NGINX_SERVROOT values; all three still bound the Test::Nginx default port 1984, so whichever lost the race died with "Address already in use". Assign a distinct TEST_NGINX_SERVER_PORT per matrix leg, and likewise to build-test.yml's tests, tests-asan and coverage jobs, which run Test::Nginx on the same runner and could collide with each other and with CI Deep. Ports are spaced by 10 because Test::Nginx reserves port+1..+3 for its stream servers. The t/ suite already templates $TEST_NGINX_SERVER_PORT into every proxy_pass, so no test changes are needed. * ci: build CI Deep's nginx with what t/ actually needs tools/ci-build.sh, used only by CI Deep's build-flavors matrix, configured nginx without http_sub_module or http_auth_request_module. t/00-filter.t TEST 33 uses sub_filter and TEST 58 uses auth_request, so config load died with "unknown directive" and Test::Nginx bailed out of the whole TAP file. Test::Nginx shuffles test order, which is why each matrix leg bailed at a different test with no assertion failures. Two more gaps behind those: TEST 91 asserts on a debug-level error.log line (needs --with-debug) and TEST 45 exercises zstd_max_cctx_memory, whose memory-estimation API needs -DZSTD_STATIC_LINKING_ONLY — auto/zstd only defines that on the explicit ZSTD_INC path, not the pkg-config auto-discovery path this script takes. build-test.yml's nginx already carries all four. Finally, split the prove invocation: t/01-static.t serves fixtures through "root ../../t/suite", which only resolves when the servroot sits two levels under the checkout, so the shared /tmp servroot 404'd every static case. Same split build-test.yml's tests job uses.

The static module serves pre-compressed .zst files and calls no libzstd function; ngx_module_libs="$ngx_zstd_opt_L" only produced a toolchain-dependent vestigial DT_NEEDED on the dynamic .so — kept by linkers without --as-needed, dropped by toolchains defaulting to it (Ubuntu, hence the CI runners) — encoding a linker default instead of module behaviour, and differing from sibling static modules for no reason (surfaced by the linkage-isolation work on the NGX_LD_OPT fix). Static --add-module builds are unaffected: the filter module still routes -lzstd into CORE_LIBS, and the static module needs nothing. Note: on the dynamic .so the full effect lands together with the NGX_LD_OPT fix (#94) — until that merges, the build-global append re-adds libzstd to every module regardless of ngx_module_libs. Verified on the merged pair: filter .so links libzstd, static .so links only libc, on a non---as-needed toolchain where it previously always stuck.

…ing note (#96) tempfile.TemporaryDirectory creates its scratch root 0700, so a root-run tool starts the master fine but the workers drop to the compiled-in nginx user and cannot enter it - every fetch 403s. Each of the nine nginx-spawning tools now normalizes the umask to 022 before creating the scratch root and chmods that root 0755, so fixtures and subdirectories created below it stay worker-readable even under a restrictive inherited umask. README gains a troubleshooting note for zstd_dcz_dict_file: a deploy-generated list of directives must be pulled in with include, not passed to the directive itself, which loads the list file as a one-entry dictionary no client hash can match. No module code changes.

) auto/zstd ended with NGX_LD_OPT="$ngx_zstd_opt_L $NGX_LD_OPT". NGX_LD_OPT is global to the whole nginx build, so the discovered libzstd link flags landed on every other dynamic module in the same configure — ngx_brotli, headers-more and accept-language all picked up a spurious DT_NEEDED on libzstd, which distro packaging then turns into real dependency bloat via automatic .so requires. The append was redundant for this module in the first place: the same flags already flow through each module s ngx_module_libs (filter/config, static/config), and auto/module routes those to CORE_LIBS for a static --add-module build and to the module s own link line for a dynamic one. Dropping it changes nothing for either build shape here; it only stops contaminating the neighbours. The three config headers that documented the append are updated so it does not come back. New CI job asserts linkage isolation in both directions: the zstd modules alongside a stub dynamic module (tools/ci-linkcheck-module) in one configure, positive control on the filter module, negative on the stub. Assertions target the generated link rule in objs/Makefile rather than the linked artifact, because a toolchain defaulting to --as-needed drops the unused libzstd NEEDED from the stub even when the leak is present, making a readelf-only negative pass either way; readelf is kept underneath as a second check. Extraction is asserted non-empty for both targets before anything is read into the result, and the negative matches bare zstd so a leak spelled as an absolute libzstd.so path or -l:libzstd.a is caught too. Verified with real builds: clean tree passes all assertions, and with the NGX_LD_OPT append restored the stub check fails while readelf still reports no libzstd NEEDED. Static --add-module nginx still links libzstd via the CORE_LIBS path (build-test.yml already asserts this).

Automated weekly version check (tools/bump-versions.sh). Co-authored-by: myguard-bump-bot <actions@users.noreply.github.com>

…hash argument (#99) Hash every registered dcz dictionary with libcrypto's EVP SHA-256 when filter/config detects it at build time, keeping the portable implementation compiled in as the runtime fallback. NGX_ZSTD_NO_LIBCRYPTO=1 skips detection. Add an optional second argument to zstd_dcz_dict_file supplying the dictionary's SHA-256 as 64 hex characters, trusted verbatim in place of hashing the file at config load. Malformed values are config-load errors, validated before the file is opened. The duplicate-dictionary check now deduplicates by declared hash. A stale supplied hash keeps matching and can decode to wrong content rather than failing, since dcz frames carry no content checksum; the README scopes the argument to content-hashed immutable assets. Remaining test-coverage gaps tracked in #100.

Decoding a dcz response against a wrong same-size raw dictionary structurally succeeds: prefix back-references stay in range and nothing else in the frame ties the output to the content, so the client gets wrong bytes with a success code. A stale supplied hash is the realistic route there, and a shared cache fans the result out to every client advertising it. ZSTD_c_checksumFlag (stable since 1.4.0, the module floor, so no version gate) appends XXH64-low32 of the uncompressed content to each dcz frame. libzstd-based clients verify it by default, turning the wrong-dictionary case into a visible decode error instead of silent corruption. Cost is four bytes per response plus an XXH64 pass. Scoped to dcz deliberately. A zstd_dict_file CDict already embeds a dictionary ID that the decoder checks, so a wrong trained dictionary fails as "Dictionary mismatch" without a checksum; RFC 9842 type=raw carries no such binding, which is why the raw-prefix path is the one that needs it. tools/test_dcz.py gains two checks, verified fail-first against the pre-change build: the inner frame declares Content_Checksum (FHD bit 2; was 0x60), and decoding against a wrong same-size dictionary must fail (previously rc=0 with 48113 bytes of wrong content accepted). The existing byte-exact roundtrip now verifies the checksum on every run. Co-authored-by: Mark Reidenbach <mark@digitalmanagementteam.com>

…owser cap (#101) * feat(static): decline .zst files declaring a window above the 8 MB browser cap Browsers enforce RFC 8878's recommended 8 MB decoder window limit for Content-Encoding: zstd and reject larger declarations before decoding a byte (Firefox NS_ERROR_INVALID_CONTENT_ENCODING, Chromium ERR_CONTENT_DECODING_FAILED). The trap that makes this worth checking at serve time: streaming encoders that were not told the input size stamp the compression LEVEL's default window into every frame header, so a Node-based build pipeline can emit a 91 KB asset declaring a 128 MB window — the file decodes fine with the zstd CLI and nginx serves it byte-identically, yet every browser rejects it. Found in production: a vite build's first deploy of .zst assets broke all precompressed loads while every server-side diagnostic looked correct. The existing magic-number probe already preads the frame start; it now reads 18 bytes and parses the header per RFC 8878 §3.1.1.1: Window_Descriptor for streaming frames, and the declared content size for Single_Segment frames (their window IS the content size, read from behind the optional dictionary id — so oversized CLI-compressed single-segment files are caught too). Frames declaring more than 8 MB are DECLINED with an actionable error-log line naming the file, the declared window, and the fix; the request falls through to the zstd filter / gzip_static / identity, so the site keeps working while the build gets fixed. Skippable leading frames are exempt (the real header sits after a variable-length skip). Tests craft the two frame layouts byte-by-byte in user_files (no valid payload needed — the handler must decline from the header alone) and were verified fail-first: on the pre-change build both serve with Content-Encoding: zstd and fail the assertions. Live verification: stdin-streamed `zstd -19 --long=27` produces a real 128 MB-window file that the handler declines, serving the identity fallback with 200. * fix(static): run the window check under directio via an aligned probe Review (CodeRabbit, rated Major and correctly so): the window check inherited the magic probe placement inside if (!of.is_directio), so an oversized frame on a directio-served file still reached browsers. Unlike the magic check — a best-effort guard against rare corruption, where skipping under O_DIRECT was a documented trade (#75) — oversized declared windows are a systematic build-pipeline product affecting whole deploys, so the check must not have a serving mode that bypasses it. Under directio the probe now preads one 4 KB block into a 4 KB-aligned pool buffer: offset 0 is aligned by definition, 4 KB covers 512-byte and 4K-native logical blocks, and a short read at EOF is permitted for files smaller than the probe. If even the aligned read fails (exotic device geometry), the file is served unvalidated — the historical directio behaviour — rather than declining valid files. New regression test serves an oversized-window .zst padded past a "directio 512" threshold and asserts the decline and log line; verified fail-first (on the skip build it serves as Content-Encoding: zstd and every assertion fails). The existing valid-file-under-directio test now exercises the probe running instead of the skip. Also from review: the window-cap tests assert every load-line component (file name, declared size, browser-cap text, recompression guidance) instead of just the declared size, and the README blockquote no longer has the MD028 blank line. * fix(static): honor directio_alignment; decline on probe failure; scope docs to the leading frame Review round 2, both blockers and both notes: - The directio probe geometry now follows the operator declared alignment: max(4 KB floor, clcf->directio_alignment) for both the buffer alignment and the read length — the same knob the core copy filter honours. On storage configured above 4 KB the hardcoded probe read failed EINVAL and the old disposition then served the file UNVALIDATED, silently reintroducing the exact failure this PR closes on the one path where the log line mattered. The disposition is also flipped per review: a failed validation read now DECLINES with an error-log line naming the probe size and pointing at directio_alignment, instead of certifying a file it could not inspect. - The window-check guarantee is scoped to the LEADING frame, in code comment and README both: a regular frame header does not declare its compressed length, so walking a concatenation means decoding every block header in every frame — unbounded I/O for a serve-time guard. Multi-frame .zst web assets are pathological (no common tooling emits them); zstd -t --memory=8MB remains the complete pre-deploy check. A new test pins the documented scope with a crafted valid-small + oversized-second concatenation that is (and must remain, until the scope deliberately changes) served. - TEST 33 gains the positive witness review asked for: the "aligned probe on directio file" debug line proves is_directio was really set for the request, so the block cannot pass vacuously through the stack-read path on filesystems where O_DIRECT does not take. A new TEST with directio_alignment 16k asserts the witness reports a 16384-byte probe (absent on the previous build), pinning the geometry computation. - The stale "one pread(2) of 4 bytes" comment now describes the 18-byte / aligned-block reality.

…n, EVP failure injection) (#103) * test: close the two open dcz hash-coverage gaps from #100 Item 1 — the fast path is now observable. $zstd_dcz_dicts_hashed counts load-time SHA-256 computations over dcz dictionaries in the current config cycle (reset at preconfiguration, so reloads report the fresh cycle). With supplied hashes it must be zero; without, the dictionary count. Three t/03 blocks assert 0 / 1 / mixed-1, and the regression #100 describes was mutation-checked: restoring the unconditional hash call in front of the have_hash branch makes the supplied-hash blocks read "1" and fail (verified live — TESTs 21 and 23 caught the planted mutation; the negotiation tests, as established in review, cannot). The variable doubles as an operator probe: one request answers whether deploy-generated hashes actually took effect. Item 3 — the EVP-to-portable fallback has runtime coverage. tools/test_sha256_unit.sh compiles ngx_http_zstd_sha256.h against shim headers (tools/sha256-unit/ provides the tiny ngx type surface and a FAKE <openssl/evp.h>) so a scripted EVP_Digest can misbehave deterministically: failure after a partial digest write (the fallback must overwrite all 32 bytes with the correct value — the property review verified by eye, now executable), "success" with a wrong output length (the mdlen guard must reject and fall back), and scripted success (returned verbatim, proving the accelerated path is taken). The portable build of the same fixture checks NIST FIPS 180-4 vectors (empty/abc/two-block/million-a) plus incremental-vs-one-shot equivalence at block-boundary split sizes. Needs only a C compiler; wired into the Validation job. * docs: leading comments on every fixture function CodeRabbit pre-merge docstring gate: the unit fixture functions had no leading comments. Each now states its contract in a line or two. * fix(test): make the hash accounting inseparable and cycle-owned Review round 2, all four points: - The counter is now incremented inside ngx_http_zstd_dcz_dict_hash(), the only sanctioned way to hash a dictionary at load, and the bare ngx_http_zstd_sha256 identifier is #pragma GCC poisoned in the filter TU — the planted historical unconditional call is a COMPILE error ("attempt to use poisoned ngx_http_zstd_sha256", verified), and the wrapper planted unconditionally turns TESTs 21/23 red (verified). Review was right that an increment beside a call site counts the line, not the operation. - The count moved from a process-global static into ngx_http_zstd_main_conf_t: pcalloc zeroes it per candidate cycle (no preconfiguration reset hook), a rejected cycle takes its count down with its pool, and the variable handler reads the request''s active main conf. Review''s live repro re-run against the fix: hashed=1 before a rejected duplicate-dict reload, after it, and after a worker respawn — the refused config''s count no longer leaks. - The fixture gains the remainder-55 padding-boundary vector (sha256("a" x 55)): 55 content bytes + the 0x80 pad fill block_len to exactly 56, the largest value that must still fit the length field in the same block. The planted "> 56" -> ">= 56" mutation that survived all prior vectors now fails precisely this one (verified). - The shim header''s drift claim is narrowed to what it actually guards: a NEW dependency in the hashed header fails compilation; compatible surface drift (void* vs ENGINE*) stays compile-clean and is the production builds'' concern.

…ervroot unique per job The coverage job ran a bare `prove t/*.t` under one implicit servroot. t/01-static.t serves fixtures via `root ../../t/suite`, which only resolves when the servroot sits two levels under the checkout, so that job passed only by accident of the Test::Nginx default location. Split it per suite, matching the tests job, and set TEST_NGINX_TIMEOUT=20 (the ~2s default is too short, as ci-deep.yml already documents). Splitting it surfaced a second defect: tests and coverage then shared identical fixed /tmp servroot paths while running concurrently on the same self-hosted runner, and several steps rm -rf that path, so one job could delete another's live config, log and pid files. Every servroot is now suffixed with the run id and job id. The static servroot stays directly under $GITHUB_WORKSPACE/t/ to keep the two-level constraint intact.

The five PR-gating workflows carried `on: push: branches: [master, main, dev]` alongside `pull_request`, so every merge re-ran the full matrix a second time on the merge commit. The push trigger was load-bearing for one case: a squash base often differs from the tested PR head when another PR lands in between, so the post-merge run was that combination's only test. Removing it alone would have dropped that coverage silently. Repo ruleset "lock master" (16557047) now carries a required_status_checks rule with strict_required_status_checks_policy, so a PR cannot merge unless its head is current with master. The tested head is therefore the merge result and the post-merge run is redundant. Schedule and workflow_dispatch triggers are unchanged; build-test keeps its weekly cron that catches nginx API drift with no push involved.

…107) ngx_module_incs must hold bare directories: auto/make prefixes every whitespace token with the compiler's include option, so the flags stored there came out mangled ("-I -I/path -I -DZSTD...") and the explicit ZSTD_INC include never applied — gcc silently fell back to the system zstd.h, masking version-mismatched builds. auto/zstd now exports ngx_zstd_incs for the module configs, keeps ngx_zstd_opt_I for the feature probes, and rides the define on CFLAGS. Adds MSVC support: the MSVC-named static archive in the explicit-location branch, nginx's own OpenSSL for EVP when the ssl machinery is linked, and cygpath normalization of MSYS-style ZSTD_INC/ZSTD_LIB. The 1.4.x CI job now asserts the private headers are really compiled against, with a runtime witness. Ships tools/build-windows.sh, a SHA-pinned Windows build script, and the bundled headers-more MSVC include-order patch.

The bootstrap exception is resolved: with #107 landed, the script's self-referential module clone pins to 37cf9ac — the squash commit carrying the MSVC support it depends on — instead of floating on master, completing the everything-pinned-by-commit-id policy from review. The comment now also documents the full fix-branch test incantation (repo AND ref override, fresh clone when switching repos), which field testing showed is easy to get half right.

…f stat-ing it (#111) The check has twice failed CI with no leak in sight, both times with the same signature: "WARNING: ptrace appears to be blocked (is seccomp enabled?). LeakSanitizer may hang." / "Child exited with signal ...". LeakSanitizer's exit-time check ptrace-attaches a stop-the-world tracer; on runners whose LXC seccomp/yama policy blocks ptrace the tracer dies, LSan writes that WARNING into log_path and reports nothing -- and this script's verdict was "any asan* file exists == leak", so the warning banner alone flipped the check red. Worse, the same lockdown can also produce NO file at all, which the old check read as a clean pass: a vacuous verdict from a detector that never ran. The stray "curl: (7)" line long recorded as part of the flake signature was a red herring -- the readiness poll's first refused attempt printing to stderr while the loop retried. Fixes, in the order they run: - Positive control: compile a four-line deliberately-leaky canary with -fsanitize=address and require LSan to flag it (exitcode 23, timeout-bounded since a ptrace-blocked LSan can hang). If the detector cannot see a deliberate leak, the environment cannot do leak detection -- emit a ::warning:: annotation naming the runner fix and exit 0: an infrastructure finding, not a leak, and no longer a silent vacuous pass. - Verdict triage reads log CONTENT: "ERROR:/SUMMARY: (Leak|Address) Sanitizer" fails unconditionally (even when the watchdog had to kill a hung exit -- a written report stands); the ptrace-blocked warning signature without an error report is indeterminate (::warning::, exit 0); anything else unexpected still fails loudly. - Shutdown watchdog (90s + SIGKILL) so "LeakSanitizer may hang" yields a verdict instead of eating the job timeout, and wait moved out from under set -e -- a real leak makes nginx exit 23, which previously aborted the script on the wait line before the report was printed. - Readiness poll silenced (no more stderr red herring) and given an explicit failure when nginx never starts accepting. A real leak still fails every time: it produces an actual "ERROR: LeakSanitizer" report, which triage always treats as red. Verified locally against an ASAN+UBSAN build using the CI job's exact configure recipe: positive control passes and the run ends green; triage patterns checked against the failing CI run's literal warning lines (must not match the error pattern, must match the lockdown pattern) and a synthetic LSan leak report (must match the error pattern); shellcheck clean.

… is loaded (#110) * conf: quiet the gzip_vary-off warnings when a compression_vary module is loaded HanadaLee's ngx_http_compression_vary_filter_module documents itself as "used instead of the gzip_vary directive": it keys on r->gzip_vary alone and injects Accept-Encoding into its single merged Vary header regardless of clcf->gzip_vary (verified empirically against all four gzip_vary x compression_vary quadrants). With it loaded, "gzip_vary off" is the intended configuration, and the filter/static config-load warnings asking for "gzip_vary on" were pure noise -- one line per merged location with zstd enabled, on configurations that are entirely correct. ngx_http_zstd_common.h gains ngx_http_zstd_vary_handled_externally(), which scans cf->cycle->modules for that exact module name; the scan works for static linkage and load_module alike, since every load_module directive is processed (core conf) before the http block's merge phase runs. Both merge_loc_conf warnings now stay quiet when it returns true. The suppression is only as correct as that module's documented flag-only contract, which the helper's comment spells out. t/02-conf-warn.t TESTs 12-15 pin the base behaviour first: the warn/no-warn contract of both modules had no tests at all in this repo (the brotli sibling's TESTs 12a-c never got zstd twins). TEST 12/14 assert the warnings fire without gzip_vary, TEST 13 that a paired config loads silently, TEST 15 that "always" stays quiet (it never varies). tools/ci-compression-vary-stub is a CI-only module claiming the exact third-party name (export-ignore'd like the linkcheck stub -- it must never ship). The linkage job builds it as a third dynamic module, now does a full make (the witness needs the binary), and a new step asserts both directions with nginx -t: without the stub both warnings fire (the control that keeps the quiet grep from passing vacuously), with the stub loaded both go quiet. Loading via load_module is deliberately the detection case under test, being the harder of the two. Mutation-checked locally: a typo'd detection string flips the witness red while the control stays green. * review: replace full suppression with a per-module summary warning CodeRabbit's catch on the previous commit is correct: the compression_vary module's own directive defaults to OFF (ngx_conf_merge_value(conf->enabled, prev->enabled, 0)) and its disabled path bypasses the header logic entirely, so module presence alone does not prove Vary is being handled -- full suppression could silence a real misconfiguration (module loaded, never enabled, gzip_vary off, no Vary at all). The literal fix -- reading that module's effective setting -- is not safely implementable: its conf struct is private (no header to include; mirroring the layout breaks silently on their next release), and merge order between unrelated modules follows cycle->modules order, so their merged values may not even exist when ours merge. Instead, presence now degrades the warnings rather than deleting them: merge_loc_conf withholds the per-location lines and counts them in a cycle-owned main-conf counter (the static module grows a main conf for this; same rejected-reload reasoning as the #103 dcz counter), and postconfiguration -- which runs after every merge, so the count is final -- emits one summary warning per module naming the location count and exactly what to verify ("compression_vary on" covers them, since it defaults to off). Never silent, bounded noise. The stub witness now asserts the summaries (with exact counts, which also mutation-checks the counter) alongside the absence of the per-location lines; mutation-checked locally by removing the increment -- the witness goes red on exactly the full-silence failure this commit exists to prevent. New cvary-interop CI job tests the REAL module, pinned by commit like every other external input: config-load suppression + summary against the real detection target, then runtime curl assertions of the semantic contract the summary describes -- "compression_vary on" with "gzip_vary off" yields exactly one Vary: Accept-Encoding (from r->gzip_vary alone), "compression_vary off" (the default) yields none, which is the residual risk the summary warning names. Both --add-module orders were verified locally to inject identically. Upstream has since replied to the duplicate-Vary report (their #1): they will keep r->gzip_vary untouched and document "gzip_vary off" as the recommended pairing with "compression_vary on", which is the configuration this warning design steers operators toward. * build: drop a shadowed local caught by the strict-compile job (-Wshadow) merge_loc_conf already declares zmcf at function scope for the dictionary loading; the warning-summary block redeclared it. Reuse the outer variable. * ci: assert warning cardinality, not just presence (review) grep -q waves through duplicate warning emission — e.g. a postconfiguration hook running twice would double every summary and still pass. Count each expected line with grep -cF and require exactly one, in both witness directions and the interop -t check. Verified locally: all three count assertions pass against the current build. --------- Co-authored-by: Thijs Eilander <eilander@myguard.nl>

…es (#113) * ci: gate the ASAN smoke step on leaks, fix the two unstable check names Three independent CI-integrity fixes, all previously Watch rows in memory/labs/http-zstd/TODO.md. 1. The ASAN+UBSAN smoke step printed real LeakSanitizer reports and passed anyway, so a green run was never leak-free evidence. The leak was invisible twice over: LSan signals through the exit status of the nginx worker, and every harness accepts SIGTERM (-15) as a clean exit (tools/test_encoding.py's `returncode not in (0, -15)`), while the step itself never looked at LSan output at all. Reports now go to files via log_path and the step greps them after the harnesses run. The 56320 bytes / 3 allocations seen on every builder02 run are nginx-core exit allocations (ngx_event_process_init, event arrays, zero zstd frames) and are suppressed by name in lsan.suppress; the suppression is deliberately narrow, so a leak from the module itself still fails the job. Verified against LSan directly: with the file in place a ngx_event_process_init leak is suppressed and a ngx_http_zstd_* leak still exits non-zero. The suppressions path is absolute. LSan resolves it against the CWD of the process it fires in -- an nginx worker started by a harness, not the workspace -- and a relative path there makes ASan hard-abort with "failed to read suppressions file" rather than degrade. A ptrace-blocked runner cannot run the exit-time check at all, which is INDETERMINATE rather than clean; that case warns instead of printing a checkmark, the same distinction tools/test_reload_leak.sh draws. 2. `build` and `tests` named themselves from the resolved nginx version, so the check name changed on every mainline release and neither could be a required context. Both names are now fixed and the version is reported in a step and the job summary instead. This unblocks adding them to ruleset 16557047, which closes the hole where a failed mainline build skips `tests` via `needs` and still merges on the 11 required checks. The new build step passes matrix values through `env:` rather than interpolating them into the shell body: they come from the resolve job's scrape of nginx.org, so a direct expansion is a template-injection sink. zizmor finding count is unchanged at 21. 3. .coderabbit.yaml sets chat.allow_non_org_members. On fork PR #110 a Major finding thread ended in an org-members-only refusal and rendered as resolved without any re-review. Note that this key defaults to true in CodeRabbit's schema, so the refusal was NOT caused by it being unset -- it is disabled above the repo, most likely org-level. The file states the repo's intent and takes effect if repo config wins; if the refusal recurs, the fix belongs in the org dashboard. Either way an outside contributor's fix commit still gets verified by hand before merging. * ci: keep matrix.flavor in the build job name to suppress the auto-suffix The first attempt used a bare `name: Build`, which made the check name worse rather than stable. A matrix job whose name contains no matrix expression does not keep its literal name -- GitHub appends the whole matrix cell to disambiguate it, so the check reported as Build (nginx, 1.31.3, https://nginx.org/download/nginx-1.31.3.tar.gz, nginx-1.31.3) which puts the version back in the name along with the url and dir, and churns on every nginx release exactly as before. Interpolating `matrix.flavor` alone suppresses the auto-suffix and is stable across releases, since flavor is `nginx` for every cell. Caught on the first CI run of this branch, where `Tests` reported under its new fixed name and `Build` did not. The `tests` job has no matrix, so its bare `name: Tests` is correct and is already reporting as such. * ci: test for a leak before ptrace-blocked in the smoke verdict The two conditions are not mutually exclusive and the ordering was wrong. log_path writes one file per process, and both greps scan /tmp/lsan-smoke.*, so a ptrace warning from any one nginx worker short-circuited the verdict and masked a real ERROR: LeakSanitizer report from a different worker. ptrace works only intermittently on builder02, which makes that combination likely rather than theoretical -- and it is the same class of defect this step was added to fix. Leak check runs first now. The indeterminate path also no longer falls through to the clean "All smoke tests clean under ASAN+UBSAN" line, which claimed more than it had checked. Reproduced both directions locally against real LSan output: with a ptrace warning in one file and a module leak in another, the old order passed and the new order exits 1. Reported by CodeRabbit on PR #113.

The coverage job failed on this PR's first run with a TimeoutExpired from tools/test_zstd_long_ldm.py — AFTER every assertion in the phase had already passed. The tool's teardown is terminate() -> wait(5) -> kill() -> wait(5), and a gcov-instrumented nginx flushing .gcda profile data at exit on a loaded shared runner can outlive that budget (uninterruptible I/O even shrugs off the SIGKILL for a while). The verdict was decided; the reap alone failed the tool. Same class as the reload-leak fix in the previous commit: a tight infrastructure assumption failing on the slow runner with the module verdict nowhere in sight. Every tool shares the same copy-pasted teardown block, so all seven get the same change: 30 seconds for the SIGTERM grace and 30 for the post-SIGKILL reap. Teardown runs after the verdict in every tool (the blocks are all in `finally` after the success return), so the larger budget costs nothing on healthy runs — a normal exit reaps in well under a second — and only spends time where 5s used to fail spuriously. Verified: py_compile across all seven tools, the test_encoding harness self-checks, and live runs of test_encoding.py and test_zstd_long_ldm.py (the tool that flaked) against a local ASAN-instrumented build. Co-authored-by: Mark Reidenbach <mark@digitalmanagementteam.com>

…115) #112 raised the nginx teardown reap budget to 30s in seven tools but the coverage job drives nine; test_window_cap.py and test_dcz.py kept 10s. test_dcz.py additionally had no TimeoutExpired guard at all, so a slow exit propagated out of the finally and leaked the nginx process, and test_window_cap.py never reaped after kill(), leaving a zombie until interpreter exit. Same 30s budget and kill fallback as the other seven. Also silences RUF059 on an unpacked-but-unused variable in test_dcz.py (pre-existing, gated by the pre-commit ruff hook on the touched file).

…_in (#116) The body filter inferred "first body data" from ctx->buffer_in.src == NULL, while add_data reloaded buffer_in.src from every incoming buffer. The sub filter emits a data-less sync carrier (pos == NULL) whenever an in-memory input buffer is entirely absorbed into a cross-buffer match candidate and produces no output. Loading that carrier re-armed the first-call check, so the next invocation re-ran ZSTD_CCtx_reset() mid- stream and silently discarded everything libzstd had buffered but not yet flushed. The response still ended as ONE well-formed frame (HTTP 200 + valid zstd), just with the pre-reset content missing -- observed in production as deterministically truncated HTML on sub_filter- rewritten pages fed by a slow chunked (relayed) upstream, where a 35 KB page compressed to a frame holding only ~262 bytes after 416 mid-stream re-inits in a single request. Two changes, both required: - ngx_http_zstd_ctx_t grows an explicit cctx_ready latch; init_cctx now runs exactly once per request, keyed on lifecycle state instead of data state. - add_data never loads a zero-size buffer into buffer_in: its signal flags (last/flush) are captured first, and the buffer is otherwise skipped, so a NULL pos can neither clobber buffer_in.src nor reach ZSTD_compressStream2 as the src pointer. TEST 85 reproduces the exact shape: a chunked upstream streamed in three delayed segments where the middle segment lies strictly inside the sub_filter FROM pattern (fully absorbed into the match state, no output -> sync carrier), asserting the decoded body round-trips. Co-authored-by: Haroldas Velioniskis <hvelioniskis@users.noreply.github.com>

…iles (#118) * fix: guard zero-delta input-buffer pointer update; unique test temp files Follow-ups from the #116 review: - ngx_http_zstd_filter_compress() unconditionally executed ctx->in_buf->pos += ctx->buffer_in.pos - pos_in. When the dequeued link is a data-less carrier (pos == NULL), the delta is provably zero, but NULL + 0 is undefined pointer arithmetic: gcc's UBSan accepts it, clang's aborts with "applying zero offset to null pointer". Guard the update on a non-zero delta. - Tests 43, 44 and 92 decoded through a fixed /tmp/zstd_tNN.out path, which two concurrent checkouts on one host can clobber. Use File::Temp::tempfile (UNLINK => 1) instead. TEST 92 also gains the decoder exit-status assertion TEST 44 already had, so a truncated frame reports ERR-DECODE rather than a body mismatch. * test: decode through a list-form pipe instead of a shell redirect Addresses both CodeRabbit findings on #118. The decode helpers built a shell command string with the temp path interpolated into it, and left the file behind on the early-return paths. Writing the compressed body to the temp file and reading the decoder back through a list-form open() removes the shell from the path entirely, so the name is never re-parsed regardless of TMPDIR, and drops the redirect that made cleanup conditional. Every return path now unlinks.

…#119) A phase0-branch run just failed its Build job in 'Install dependencies' with 'Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 900 (apt-get)' — a background provisioning apt-get racing the step on the runner, nothing to do with the diff. Same disease as the ptrace and teardown-reap classes: a tight infrastructure assumption (the lock is always free) failing on shared runners with the verdict nowhere in sight. apt has the built-in cure: -o DPkg::Lock::Timeout=120 makes every apt-get wait up to two minutes for the lock rather than failing instantly. Applied to all 36 invocations across the six workflows (shape-swept: zero unconverted apt-get calls remain), uniformly on update and install both — the race hits whichever runs first.

eilandert and others added 30 commits May 9, 2026 22:21

feat: add zstd_max_length directive to filter module

8010a65

docs: add zstd_max_length directive to README

chore: setting up CI pipeline

79f7a2a

ci: add --with-debug to nginx configure

8eff4d4

docs: refactor README - fact-check directives, improve examples, clar…

3c26b4f

…ify defaults

chore: update .gitignore for nginx module project

47e0e15

style: fix line length violations, add .clang-format

c13e9be

eilandert and others added 30 commits July 17, 2026 22:33

chore: bump nginx-stable/angie pins (#98)

7294b2b

Automated weekly version check (tools/bump-versions.sh). Co-authored-by: myguard-bump-bot <actions@users.noreply.github.com>

test: make the sha256 unit fixture executable (#104)

f73b202

Navigation Menu

the one PR - #53

the one PR #53
eilandert wants to merge 201 commits into
tokers:masterfrom
myguard-labs:master

eilandert commented Jun 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Conversation

eilandert commented Jun 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants