vyos-1x.git/src, branch fix/T8955-http-api-verify-tls

http-api-client: T8955: leave warning handling to the caller

2026-10-04T09:46:17+00:00

Address the round-2 adversarial-review finding: warnings.catch_warnings() mutates the process-global filter list for the duration of the block (still the case on Python 3.13), so scoping suppression inside the library was not actually isolated. - http_api_client no longer touches warning filters at all. The _suppress_insecure_warning helper is removed and post() calls session.post directly again. The unused warnings, contextmanager and urllib3 imports are dropped. The class docstring now states that callers disabling verification own InsecureRequestWarning handling. The OSError wrapping and verify_tls validation are unchanged. - config_sync ignores InsecureRequestWarning in its __main__ block only, before opmode.run(). That one-shot op-mode process deliberately connects without verification (verify_tls=False) until T9396. Importing the module adds no filter. 🤖 Generated by [robots](https://vyos.io)

http-api-client: T8955: harden verify_tls handling

2026-10-04T09:29:31+00:00

Address the adversarial-review findings on the TLS verification change: - Finding 1: validate ApiClientConfig.verify_tls in __post_init__. Only a bool or a non-empty CA bundle path is accepted; anything else (including "", None and ints) raises ValueError. requests treats "" as falsy and would silently disable verification. Strings are never coerced: "false" is a path, so callers must pass a real bool. - Finding 2: stop calling urllib3.disable_warnings() process-wide from ApiClient.__init__. InsecureRequestWarning is now ignored only around the request itself, via warnings.catch_warnings(), and only when verify_tls is False. post() is the only request path in the client. - Finding 3: wrap OSError (raised by requests' cert_verify for a missing CA bundle path) in ApiTransportError. The handler sits after the RequestException handlers, since those subclass OSError. - Finding 4: config-sync hard-codes verify_tls = False instead of reading an unmapped 'verify_tls' key from the runtime config, whose leaf values are strings. Mapping a CLI option to a bool or CA path is T9396. 🤖 Generated by [robots](https://vyos.io)

http-api-client: T8955: enable TLS verification by default

2026-10-04T09:13:18+00:00

ApiClientConfig.verify_tls defaulted to False and ApiClient unconditionally silenced urllib3's InsecureRequestWarning, so TLS peer verification was off by default. The sole consumer, src/op_mode/config_sync.py, builds the client without passing verify_tls and therefore connected to a *remote* secondary VyOS node over HTTPS without verifying the certificate -- a MITM exposure on the channel that carries the API key and the full configuration. - ApiClientConfig.verify_tls now defaults to True and accepts bool | str; a string is forwarded to requests as a CA bundle path (verify=). - InsecureRequestWarning is suppressed only when verification is explicitly disabled (verify_tls is False), not when a CA path or True is set. - config_sync reads an optional verify_tls from the secondary runtime settings, defaulting to False to preserve current behaviour for self-signed secondaries. The insecurity is now explicit at the call site instead of hidden in the library default. Exposing a CA certificate (PKI reference) and peer fingerprint pinning under service config-sync secondary is follow-up T9396. 🤖 Generated by [robots](https://vyos.io)

policy: T9379: prefix-list duplicate check in linear time

2026-10-01T16:06:45+00:00

verify() looked up each prefix-list rule in a list of the rules seen so far, which is quadratic in the size of the list and runs on every policy commit. verify() alone, run from the source on a workstation, took 41.8 s for a 40,000-rule list; on a 1.5.1 VM the check cost 0.08 s at 2,000 rules. Keep a set of the rules' sorted items instead. Every value under a prefix-list rule is a single leaf, so the key is hashable, and two keys are equal exactly when the rule dicts are: the same rules are flagged, with the same message. The workstation benchmark took 0.11 s.

Merge pull request #5515 from ordex/T9364-openvpn-dco-mtu

2026-09-30T18:13:23+00:00

T9364: openvpn: default the MTU to 1420 when DCO is enabled

Merge pull request #5483 from yzguy/wwan-modem-by-port-ownership

2026-09-30T04:18:19+00:00

wwan: T7487: identify modem by port ownership, not interface number

openvpn: T9364: default the MTU to 1420 when DCO is enabled

2026-09-29T21:33:24+00:00

The ovpn Kernel module does no MSS clamping, so with a 1500 bytes MTU full sized packets get fragmented on the underlay. Add an "mtu" node, rendered as "tun-mtu". With "offload dco" it defaults to 1420, unless a raw tun-mtu/link-mtu/udp-mtu option is present. Reject "mtu" together with such an option, below 100, and below 1280 when IPv6 runs inside the tunnel.

Merge pull request #5491 from omnom62/T8989-hotfix-oidc_aud_validation

2026-09-29T19:07:04+00:00

http-api: T8989: Hotfix to enforce audience validation if OIDC is configured

openvpn: T9363: multiply the site-to-site keepalive timeout

2026-09-29T18:40:44+00:00

"failure-count" counts missed intervals, so the timeout it describes is interval * failure-count. Server mode renders and verifies it that way; site-to-site passed the bare count to "ping-restart", where it lands as seconds - 60s instead of 600s with the defaults. Render the product. That puts a timeout past the 86400 "ping-restart" accepts within reach, so verify() rejects it and the 5-to-6 migration clamps configurations already beyond it. This changes behaviour on upgrade: site-to-site tunnels now tolerate a longer silence, 600 seconds instead of 60 with the defaults.

Merge pull request #5397 from jeleel-muibi/t8999-openvpn-shared-secret-errors

2026-09-29T18:39:27+00:00

openvpn: T8999: improve shared-secret reference errors