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

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

2026-09-29T13:41:40+00:00

modem_index() in python/vyos/utils/wwan.py derived the ModemManager modem index straight from the interface name (wwan0 -> 0). The kernel-assigned WWAN interface number and ModemManager's own modem index are two independently enumerated values and are not guaranteed to match - on a box with more than one modem, they can enumerate in different orders, so modem index 0 does not necessarily own wwan0. Every function in this module funnels through modem_index() (start_modem_manager, modem_disconnect, modem_connect, and both admin-disconnect marker helpers), and is_wwan_connected() in vyos.utils.network had its own separate copy of the same assumption - so a single reversed enumeration order silently commands the wrong physical modem for every one of them. modem_index() now lists every modem ModemManager currently knows about and returns whichever one actually has ifname in its own port list, instead of assuming the correspondence. A modem that has not shown up on the bus yet looks the same as one that will never exist, so this waits up to the same modem_wait_timeout budget start_modem_manager() already gives a modem to become dialable, then returns None if nothing claimed the interface. is_wwan_connected() now calls the same resolver instead of keeping its own copy of the old assumption. None is a real, expected return now, not just a theoretical one - the three callers that previously assumed modem_index() always produced *a* string (right or wrong) are updated: start_modem_manager() bails out early (matching the tolerance its own caller's w.exists() check already has for hardware that isn't detected yet), modem_disconnect() and modem_connect() treat it as nothing to disconnect / a failed dial, matching each function's own existing return contract. show_wwan.py's modem_info() raises a clear, specific error instead, which its own top-level exception handler already reports cleanly. set_admin_disconnected()/clear_admin_disconnected() only ever used modem_index() to validate the interface name looks like a WWAN interface in the first place, so they're unaffected.

Merge pull request #5499 from c-po/wwan-improvements

2026-09-29T04:42:46+00:00

wwan: T9350: possible dead interface after boot, disconnect does not stick

Merge pull request #5503 from c-po/T9354

2026-09-28T19:18:12+00:00

op-mode: T9354: replace "reset connection" with "reconnect interface"

pki: T9323: give elliptic curve keys their own constructor

2026-09-27T18:02:14+00:00

create_private_key() took one "size" for every key type, but the number means entirely different things per type: for RSA and DSA it is a modulus size, for EC it selects a curve. CodeQL is not path sensitive across the key_type comparison, so it follows the 256 an EC caller passes into the RSA and DSA branches that caller can never reach, and reports pki.py as generating 256 bit RSA and DSA keys. Build elliptic curve keys in create_ec_private_key() instead and route the op mode generator and the OpenVPN smoketest there, so no curve size ever enters the function that also builds RSA and DSA keys. create_private_key() now refuses a key type it does not build rather than returning None, so a caller cannot drift back into the old shape unnoticed.

Merge pull request #5398 from ruben-herold/T9205-firewall-ruff-cleanup

2026-09-26T20:06:34+00:00

firewall: T9205: fix ruff findings in conf_mode/op_mode firewall.py

op-mode: T9354: run interface reconnect detached from calling session

2026-09-25T19:02:00+00:00

A reconnect is usually issued via the very interface being reconnected. Once the link drops, the calling session dies and the reconnect was killed by SIGHUP - or by SIGPIPE on the next write to the dead terminal - before the interface could be dialed again, leaving the system unreachable. The reconnect now runs in a transient systemd unit and survives the loss of the session. Progress is logged to the journal. PPPoE and SSTP restart the ppp service in a single operation instead of stopping and starting it, so there is no window in which an interrupted command leaves the link down. WWAN still disconnects the modem before dialing again.

firewall: T9205: also catch UnicodeDecodeError from cmdl() output

2026-09-25T18:53:02+00:00

cmdl() decodes subprocess output as utf-8 and can raise UnicodeDecodeError (not an OSError subclass) if that fails, in addition to OSError on command failure. Catch both, closing a gap left by the exact-exception narrowing in the previous commit.