Waiting for T3595 to clear up before I can test this on rolling release.

I cannot replicate this bug in a clean install of 1.4-rolling-202105291042.

vyos@vyos# set interfaces dummy dum0 address 192.168.201.1/24
[edit]
vyos@vyos# commit
[edit]

Either there's something in your config meddling with the interface creation or (most likely) this bug was solved in the main branch since then.

Here are some kernel features we need to consider:

1. Disable kexec. The user should never need to swap the kernel.
2. Restrict access to /proc/kallsyms for regular users, which makes sense since we're using a custom kernel.
3. Set hidepid to prevent regular users from seeing process IDs. Might be too intrusive.
4. Harden BPF JIT. Might interfere with XDP. Testing necessary.
5. Set kernel lockdown mode. Disables kexec and unprivileged BGP commands. Again, might interfere with XDP.

An easy start would be adding

export DEB_BUILD_MAINT_OPTIONS = hardening=+all
export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed -Wl,-z,-defs

to debian/rules to harden our C programs (which is currently only VyShim and XDP). hardening=+all passes PIE and bindnow linker options to GCC.

This is possibly a problem on curl's end but funnily enough, there's a similar problem with the native implementation over T3563. Once that's solved, this bug will be rendered moot.

install-image now calls a routine that queries the size of the remote file and aborts if there isn't enough space to download the image.

commit-archive now uses Paramiko for SSH connections instead of curl and directly reads ~/.ssh/known_hosts if it exists.

This is a consequence of using an old Paramiko version. I just sent a PR upping the version of cryptography and Paramiko.

New file transfer script parses the port field in the URL.

That's a good point. I just might do that.

Update: It turns out the md5sum.txt files are put there by Debian's Live Build. Checksums are added on lb binary_checksums step of the build, which defaults to MD5 if no variable is provided to tell it otherwise. As Daniil suggested, we can put a second checksum step with SHA256 variable to produce both checksums, then check for sha256sum.txt files on new images. This way, old update scripts can still find an md5sum.txt in images.

Turns out vyatta-remote-copy.pl has been broken for a while. It fails to exchange encryption keys when it tries to establish an SSH connection (for SFTP or SCP), possibly because of the old libssh it relies on.