VyOS 1.3 based on Debian 10 Buster
Fri, Jan 27
Backport PR https://github.com/vyos/vyos-cloud-init/pull/60
Fix for 1.4: https://github.com/vyos/vyos-cloud-init/pull/59
It must be backported to 1.3 now.
Wed, Jan 25
Sun, Jan 15
Wed, Jan 11
Tue, Jan 10
Mon, Jan 9
Thu, Jan 5
Tue, Jan 3
Backport PR: https://github.com/vyos/vyos-cloud-init/pull/57
Dec 27 2022
Dec 26 2022
For 1.4 resolved in the https://github.com/vyos/vyos-cloud-init/commit/d385e3655e9eed77397136f5e27325a93719332d
Waiting several days for tests before doing a backport.
Dec 25 2022
Dec 13 2022
Dec 10 2022
Dec 9 2022
PR with fix is here: https://github.com/vyos/vyatta-cfg-firewall/pull/35
Dec 6 2022
Dec 1 2022
Nov 30 2022
Nov 28 2022
Nov 25 2022
@marc_s Would you be able to open a PR against 1.3 ?
Nov 23 2022
Nov 22 2022
@trae32566 My apologies for the inconveniences. You are right. The criteria for triggering this action shall be narrowed down further.
It would be necessary to issue the warning if and only if such colliding peers also specify the exact same remote endpoint addresses (with empty endpoints also being accounted as to be the same).
In other words, we need to identify incoming peers and apply the rule only to them, not the outgoing ones which already have specific remote endpoint addresses statically defined.
This breaks a perfectly valid use case which I utilize regularly: using IPv4 + IPv6 peers with the same public key. Why would I want to create multiple keys for the exact same devices going over IPv4 and IPv6? If you want to include a warning, fine, but don't limit functionality based on someone's interpretation of how something will be used. I understand where this came from, but any time you limit functionality, you limit your users. As Donald Knuth once said:
Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.
Nov 17 2022
@marc_s thanks for testing !
Nov 16 2022
Nov 14 2022
Nov 10 2022
Nov 8 2022
TLDR; confirmed fixed for 1.3, please backport.