vyos-1x.git/debian, branch 1.4.0

T3420: Remove service upnp

2024-05-14T17:37:45+00:00

Remove `service upnp` as it never worked as expected, nft rules do not integrated and custom patches do not seem like a suitable solution for now. Security: UPnP has been historically associated with security risks due to its automatic and potentially unauthenticated nature. UPnP devices might be vulnerable to unauthorized access or exploitation. (cherry picked from commit 7c438caa2c21101cbefc2eec21935ab55af19c46)

T6307: Add dependency procps to build vyos-1x

2024-05-06T15:15:13+00:00

(cherry picked from commit 8041201fccffa96ca05ecd764b6d4b9d103b4c1a)

T6199: add missing build dependency

2024-04-09T15:23:03+00:00

(cherry picked from commit 8e2330fed6480886cbce97cc1b541e54c5394564)

Debian: T6199: add pylint do list of build dependencies

2024-04-06T08:58:33+00:00

(cherry picked from commit 71786307eed6a0ebb42755f24c19dfd46b1b9696)

T6199: drop unused sphinx documentation folder

2024-04-03T19:01:42+00:00

(cherry picked from commit 86b632874288aa5707a94a4f28ca816e543823b9)

ssh: T6192: allow binding to multiple VRF instances

2024-04-02T16:33:59+00:00

Currently VyOS only supports binding a service to one individual VRF. It might become handy to have the services (initially it will be VRF, NTP and SNMP) be bound to multiple VRFs. Changed VRF from leafNode to multi leafNode with defaultValue: default - which is the name of the default VRF. (cherry picked from commit e5af1f0905991103b12302892e6f0070bbb7b770)

Debian: T2267: extend version tag from GIT repo

2024-01-19T19:06:26+00:00

This extends commit 2c3e4696b3e22 ("T2267: Versioning: Update version tag from GIT repo") to also include release tags. (cherry picked from commit 04aa70e3f75169fc592b20acfa6e0b2f37d90a6c)

https: T5886: migrate https certbot to new "pki certificate" CLI tree

2024-01-08T20:11:13+00:00

(cherry picked from commit 9ab6665c80c30bf446d94620fc9d85b052d48072)

pki: T5886: add support for ACME protocol (LetsEncrypt)

2024-01-08T20:11:13+00:00

The "idea" of this PR is to add new CLI nodes under the pki subsystem to activate ACME for any given certificate. vyos@vyos# set pki certificate NAME acme Possible completions: + domain-name Domain Name email Email address to associate with certificate listen-address Local IPv4 addresses to listen on rsa-key-size Size of the RSA key (default: 2048) url Remote URL (default: https://acme-v02.api.letsencrypt.org/directory) Users choose if the CLI based custom certificates are used set pki certificate EXAMPLE acme certificate or if it should be generated via ACME. The ACME server URL defaults to LetsEncrypt but can be changed to their staging API for testing to not get blacklisted. set pki certificate EXAMPLE acme url https://acme-staging-v02.api.letsencrypt.org/directory Certificate retrieval has a certbot --dry-run stage in verify() to see if it can be generated. After successful generation, the certificate is stored in under /config/auth/letsencrypt. Once a certificate is referenced in the CLI (e.g. set interfaces ethernet eth0 eapol certificate EXAMPLE) we call vyos.config.get_config_dict() which will (if with_pki=True is set) blend in the base64 encoded certificate into the JSON data structure normally used when using a certificate set by the CLI. Using this "design" does not need any change to any other code referencing the PKI system, as the base64 encoded certificate is already there. certbot renewal will call the PKI python script to trigger dependency updates. (cherry picked from commit b8db1a9d7baf91b70c1b735e58710f1e2bc9fc7a) # Conflicts: # debian/control

tacacs: T141: Wrap string in double quotes to allow expansion

2023-12-29T20:04:15+00:00

(cherry picked from commit a95ee3fd38f3c1d54ea359088d0eb1a4d4582b6b)