vyos-1x.git/python, 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)

T9365: add wrappers for reference tree path from config/partial path

2026-10-01T16:54:29+00:00

Merge pull request #5493 from jestabro/trim-reftree-caches

2026-10-01T16:46:46+00:00

T9341: Fix consistency of legacy templates, xml_ref cache, and reference tree

wwan: T9326: always pre-negotiate the attach-time PDN type before connect

2026-09-30T06:30:41+00:00

modem_connect() only ran the --3gpp-set-initial-eps-bearer-settings pre-step (added by T9326) when the requested ip-type included IPv6, gated on options.partition('ip-type=')[2].partition(',')[0] in ('ipv6', 'ipv4v6'). A bare 'ipv4' request skipped it entirely. Confirmed live (same MC7455/Google Fi setup as T9326's original report) that the underlying ip-version-mismatch rejection isn't IPv6-specific: with the attach committed to ip-type=ipv6, a bare ip-type=ipv4 --simple-connect fails outright with the same QMI CallEndReason, not just the ipv4v6 case's silent single-family drop. A WWAN interface whose configured address family changes (e.g. dropping dhcpv6 down to dhcp-only) can hit exactly this, and won't self-heal on retry since nothing about a failed connect touches the attach-committed PDN type - vyos-netlinkd's reconcile loop would back off and retry the identical failing request forever. Removed the gate entirely: the pre-step already fails silently and falls through unchanged on a modem/network that doesn't need it, so there's no reason to skip it for any particular family.

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

wwan: T7487: catch malformed mmcli JSON, not just OSError

2026-09-30T04:13:50+00:00

mmcli can return empty or non-JSON output while ModemManager is still starting (T6604), and json.loads() raising on that is a ValueError, not an OSError - it was propagating straight out of _modem_owning_port() uncaught. Under wait=True that reaches wait_for()'s callback and aborts the poll loop instead of retrying, exactly the startup race this module exists to ride out. Co-authored-by: Christian Breunig

ethtool: T9353: fix BASEX mode(s) support in check_speed_duplex()

2026-09-29T19:30:47+00:00

Bugfix which allows for BaseX link modes reported by ethtool to be correctly validated, so config can be commited.

wwan: T7487: move json/wait_for imports into their only callers

2026-09-29T19:21:15+00:00

Requested by c-po: json.loads and wait_for were only used by _modem_owning_port() and modem_index()'s wait branch respectively, so importing them at module level cost every other caller of this module an import it does not need.