The version we use was proven not to actually have this issue.

PR: https://github.com/vyos/vyos-build/pull/1237

PR: https://github.com/vyos/vyos-build/pull/1232

I believe we should better get rid of the default password in the live image and use some auto-login mechanism instead so that if people want to SSH into a system booted from a live CD, they need to set up a user with their own password, rather than create more default credentials.

PR, for the record: https://github.com/vyos/vyos-build/pull/1190

After the patch:

PR: https://github.com/vyos/vyos-build/pull/1190

The original patch had issues and had to be reverted (https://vyos.dev/T8472). Now we need to find a better solution.

ddclient still doesn't list Route53 among supported services (https://github.com/ddclient/ddclient#supported-services).

This is an old task. These days all logs go to journald first, and rsyslog takes it from journald, so webproxy logs are available there.

This was blocked by the fact that Teleport changed its license to a modified Apache 2.0 that didn't allow unlimited distribution and limited usage to organizations below 100 employees and certain revenue thresholds.

The last remaining component (WAN load balancing) is already gone in 1.5 so this task is complete as stated. Replacing the config backend is a separate story.

We discussed this among maintainers and the conclusion is to close this as 'wont fix'.

We discussed this with maintainers and the support and sales teams and there doesn't seem to be any demand for this from other users, so there's no point in working on it ourselves.

We discussed this among maintainers and our conclusion is that having it as a built-in feature isn't a good idea. There are fundamental performance issues with a userspace daemon, and the feature is very niche (relevant for users of certain VPN providers but that's about it).

We discussed this among maintainers and our conclusion is that it's not really a good idea. The protocol is fundamentally insecure, the implementation doesn't seem actively maintained, and most devices that VyOS is expected to run on have serial or KVM consoles, or even OOB interfaces like IPMI (while many Mikrotik boxes don't have anything, so mactelnet is the only way to restore access after a configuration mistake, short of a factory reset).

We discussed this long-standing request among maintainers and came to the conclusion that it's probably not a good idea. Commit-triggered archival is always superior since it will never miss any revisions.

We discussed this among maintainers and came to the conclusion that there's no reason to implement this, since SSL VPN protocols are meant for user connections and using them for router-to-router connections is a wrong solution.

Cloud-init provides that functionality so the task is done as stated. Any specific platforms or installation methods should get their own tasks with a properly defined scope.

1. Host keys are migrated as they should be.
2. Known hosts are now migrated after https://github.com/vyos/vyos-1x/pull/4678 (T5455).
3. Users' authorized keys are stored in the config by design and out-of-config keys are not supported (T110).

In retrospect, I don't think this root task structure was correct, since it was a parent of tasks of very different nature, and arguably https://vyos.dev/T741 could be the parent.