If you mean using Incus on Flatcar, there is a PR for adding Incus as systemd-sysext extension.

Flatcar inside Incus is a bit more difficult: for Flatcar being a container one can import https://stable.release.flatcar-linux.net/amd64-usr/current/f... and for it being a VM I don't know if the regular image works. A major hurdle is that one has to tweak the way VMs/containers are configured because normally Ubuntu's cloud-init is used but in Flatcar only coreos-cloudinit or Ignition is supported and there are differences in the way the user-data has to be set up and the contents as well. But in the end Incus would be one more "cloud" platform to support and one could make the Incus integration as nice as with other platforms where Flatcar runs on (OpenStack, VMware, etc.).

Incus on Flatcar is what I mean. This seems to be the PR you're talking about[1]. I'll keep an eye on it, thanks!

[1]: https://github.com/flatcar/scripts/pull/1655

With static binaries that is not needed (and you can use OS=_any in the extension release file to mark them compatible).

If you want to repackage distro binaries without recompilation, you can have a look here: https://github.com/flatcar/sysext-bakery/pull/74 There are two tools, one can bundle the needed libs in a separate folder, and the other one works more like Flatpak and uses a full chroot. Since you already know what files are needed at runtime I think you could try the first approach, otherwise the second might be easier.

This might not be complete because this statement "More patches that seem (even in retrospect) to be fine follow." lacks some more backing facts. There were more patches before the SSH backdoor, e.g.: "Lasse Collin has already landed four of Jia Tan’s patches, marked by “Thanks to Jia Tan”" and the other stuff before and after the 5.4 release. So far I didn't see someone make a list of all patches and gather various opinions on whether the changes could be maliciously leveraged.

I get that there is a reason not to trust those Patches, but I would guess they don't contain anything malicious. This early part of the attack seems to only focus on installing Jia Tan as the maintainer, and they probably didn't want anything there that could tip Lasse Collin off that this "Jia" might be up to something.

Yes, exactly. I did look at many of them, and they are innocuous. This is all aimed at setting up Jia as a trusted contributor.

In https://archive.softwareheritage.org/browse/revision/e446ab7... one can open the patches and then click the "Changes" sub-tab. Stuff like this looks like a perf improvement but who knows if a tricky bug is introduced that was aimed to be exploited https://archive.softwareheritage.org/browse/revision/e446ab7... There are more patches to be vetted unless one would give up and say that 5.2 should be used as last "known-good".

When socat is around a simple server can also be constructed with it:

        tee /tmp/server > /dev/null <<'EOF'
        #!/bin/bash
        set -euo pipefail
        SERVE="$1"
        TYPE="$2"
        read -a WORDS
        if [ "${#WORDS[@]}" != 3 ] || [ "${WORDS[0]}" != "GET" ]; then
          echo -ne "HTTP/1.1 400 Bad request\r\n\r\n"; exit 0
        fi
        # Subfolders are not supported for security reasons as this avoids having to deal with ../../ attacks
        FILE="${SERVE}/$(basename -- "${WORDS[1]}")"
        if [ -d "${FILE}" ] || [ ! -e "${FILE}" ]; then
          echo -ne "HTTP/1.1 404 Not found\r\n\r\n" ; exit 0
        fi
        echo -ne "HTTP/1.1 200 OK\r\n"
        echo -ne "Content-Type: ${TYPE};\r\n"
        LEN=$(stat -L --printf='%s\n' "${FILE}")
        echo -ne "Content-Length: ${LEN}\r\n"
        echo -ne "\r\n"
        cat "${FILE}"
        EOF
        chmod +x /tmp/server
        # switch from "text/plain" to "application/octet-stream" for file downloads
        socat TCP-LISTEN:8000,reuseaddr,fork SYSTEM:'/tmp/server /tmp/ text-plain'

# test: curl -v http://localhost:8000/server

There are other such tiny web server tricks out there too, but his GitHub README says:

  A purely bash web server, no socat, netcat, etc...

I really think we should have means of spawning wasm components from wasm components. How the runtime runs them should be up to the runtime - it could be directly backed by kernel primitives but it could also be in a browser. Leaking posix things into wasm… is something I'd rather never want to see. Let's come up with something better as wasm did aim for from the start.

To spot more common problems I recommend:

  alias shellcheck='shellcheck -o all -e SC2292 -e SC2250'

SC2292: Prefer [[ ]] over [ ] for tests in Bash/Ksh.

* https://www.shellcheck.net/wiki/SC2292

SC2250: Prefer putting braces around variable references (${my_var}) even when not strictly required.

* https://www.shellcheck.net/wiki/SC2250

Opportunistic interjection that unnecessary ${} is the most bothersome style choice in any language I know of:

- It obscures actual uses of modifiers, particularly ${foo-} when set -u is in effect,

- It's obvious when a name runs into subsequent text, even if one has somehow avoided syntax highlighting,

- And expansions followed by identifier chars don't actually occur in practice. Cases where the quotes cannot be moved to surround the variable are often interpolation of an argument to echo, whose behaviour is such a mess not even portable between bash and dash that shellcheck ought to be demanding printf at all times instead!

Related pet peeve: always writing variables as $UPPER_CASE in shell scripts.

Useful: $UPPER_CASE for exported variables ("super globals"), $lower_case for anything else. Can also use $lower_case for function locals and $UPPER_CASE for exported and script global variables (stylistic preference; both are reasonable).

Not useful or reasonable: $ALWAYS_UPPER_CASE_NO_MATTER_WHAT.

I suppose people started doing it because they saw $EXPORTED_VARIABLE and thought "oh, I need to always upper case it", not realizing what that meant. And then after that more copy-copy of this "style".

For regular Linux users you can do:

  sudo touch /etc/udisks2/tcrypt.conf
  sudo systemctl restart udisks2

and then any veracrypt volumes can be used in Nautilus or GNOME Disks similar to LUKS volumes.

Why would one want to use VeraCrypt volumes over regular LUKS?

Cross platform support is a good reason.

Does this finally have UEFI by default?

The next logical step would be to only support wasm programs ;)