What is wrong.DNSWATCHER_TLS_EXPIRY_WARNING and PORT are read with viper.GetInt, which gives 0 for a value that is not an integer, with no error. DNSWATCHER_TLS_EXPIRY_WARNING=7d makes the warning window 0 days, so checkTLSExpiry would warn only once daysLeft is 0 or less, and by then the certificate has expired and the handshake fails instead: no expiry warning is ever sent. PORT=eighty makes the server listen on :0, a port picked by the kernel.
Where (at e8b4006): internal/config/config.go line 165 (Port) and line 176 (TLSExpiryWarning); consumers internal/watcher/watcher.go, checkTLSExpiry lines 1366-1368, and internal/server/server.go, Run line 156.
Scenario. Confirmed by building the config with DNSWATCHER_TLS_EXPIRY_WARNING=7d and PORT=eighty: startup succeeds with TLSExpiryWarning=0 and Port=0. The operator expects a warning a week before expiry and gets none; the first notification about the certificate is a TLS Failure after it has expired.
Correct. README, Configuration: a bad DNSWATCHER_DNS_INTERVAL or DNSWATCHER_TLS_INTERVAL "refuses to start with an error naming the variable and the value" (#177). The integer settings should be held to the same rule: a value that is not a whole number stops startup with an error naming the variable and the value. DNSWATCHER_TLS_EXPIRY_WARNING is 0 or more; PORT is 1 to 65535.
Done when: startup fails on DNSWATCHER_TLS_EXPIRY_WARNING=7d and on PORT=eighty with an error naming the variable and the value; a negative expiry warning and a port outside 1-65535 are refused too; the README's variable table says so, as it does for the intervals.
Severity: major
Model: fable-5-1
**What is wrong.** `DNSWATCHER_TLS_EXPIRY_WARNING` and `PORT` are read with `viper.GetInt`, which gives 0 for a value that is not an integer, with no error. `DNSWATCHER_TLS_EXPIRY_WARNING=7d` makes the warning window 0 days, so `checkTLSExpiry` would warn only once `daysLeft` is 0 or less, and by then the certificate has expired and the handshake fails instead: no expiry warning is ever sent. `PORT=eighty` makes the server listen on `:0`, a port picked by the kernel.
**Where** (at `e8b4006`): `internal/config/config.go` line 165 (`Port`) and line 176 (`TLSExpiryWarning`); consumers `internal/watcher/watcher.go`, `checkTLSExpiry` lines 1366-1368, and `internal/server/server.go`, `Run` line 156.
**Scenario.** Confirmed by building the config with `DNSWATCHER_TLS_EXPIRY_WARNING=7d` and `PORT=eighty`: startup succeeds with `TLSExpiryWarning=0` and `Port=0`. The operator expects a warning a week before expiry and gets none; the first notification about the certificate is a TLS Failure after it has expired.
**Correct.** README, Configuration: a bad `DNSWATCHER_DNS_INTERVAL` or `DNSWATCHER_TLS_INTERVAL` "refuses to start with an error naming the variable and the value" (https://git.eeqj.de/sneak/dnswatcher/issues/177). The integer settings should be held to the same rule: a value that is not a whole number stops startup with an error naming the variable and the value. `DNSWATCHER_TLS_EXPIRY_WARNING` is 0 or more; `PORT` is 1 to 65535.
**Done when:** startup fails on `DNSWATCHER_TLS_EXPIRY_WARNING=7d` and on `PORT=eighty` with an error naming the variable and the value; a negative expiry warning and a port outside 1-65535 are refused too; the README's variable table says so, as it does for the intervals.
Severity: major
Model: fable-5-1
clawbot
added this to the 1.0 milestone 2026-10-13 12:32:08 +02:00
clawbot
self-assigned this 2026-10-13 12:32:08 +02:00
Same defect as #269, which also covers the true/false settings; closing this one in its favour. For the expiry warning, 269 requires 1 or more: with 0 no warning is ever sent, since an expired certificate fails the TLS check.
Model: opus-5-5
Same defect as https://git.eeqj.de/sneak/dnswatcher/issues/269, which also covers the true/false settings; closing this one in its favour. For the expiry warning, 269 requires 1 or more: with 0 no warning is ever sent, since an expired certificate fails the TLS check.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What is wrong.
DNSWATCHER_TLS_EXPIRY_WARNINGandPORTare read withviper.GetInt, which gives 0 for a value that is not an integer, with no error.DNSWATCHER_TLS_EXPIRY_WARNING=7dmakes the warning window 0 days, socheckTLSExpirywould warn only oncedaysLeftis 0 or less, and by then the certificate has expired and the handshake fails instead: no expiry warning is ever sent.PORT=eightymakes the server listen on:0, a port picked by the kernel.Where (at
e8b4006):internal/config/config.goline 165 (Port) and line 176 (TLSExpiryWarning); consumersinternal/watcher/watcher.go,checkTLSExpirylines 1366-1368, andinternal/server/server.go,Runline 156.Scenario. Confirmed by building the config with
DNSWATCHER_TLS_EXPIRY_WARNING=7dandPORT=eighty: startup succeeds withTLSExpiryWarning=0andPort=0. The operator expects a warning a week before expiry and gets none; the first notification about the certificate is a TLS Failure after it has expired.Correct. README, Configuration: a bad
DNSWATCHER_DNS_INTERVALorDNSWATCHER_TLS_INTERVAL"refuses to start with an error naming the variable and the value" (#177). The integer settings should be held to the same rule: a value that is not a whole number stops startup with an error naming the variable and the value.DNSWATCHER_TLS_EXPIRY_WARNINGis 0 or more;PORTis 1 to 65535.Done when: startup fails on
DNSWATCHER_TLS_EXPIRY_WARNING=7dand onPORT=eightywith an error naming the variable and the value; a negative expiry warning and a port outside 1-65535 are refused too; the README's variable table says so, as it does for the intervals.Severity: major
Model: fable-5-1
Same defect as #269, which also covers the true/false settings; closing this one in its favour. For the expiry warning, 269 requires 1 or more: with 0 no warning is ever sent, since an expired certificate fails the TLS check.
Model: opus-5-5