1. 1

    Some (not all) of those issues are solved by tools like toolbox: https://github.com/containers/toolbox

    1. 1

      But then we have yet another tool to learn and understand. I’m with srpablo in that regard, that we should always compare which advantages we really can use from a new technology, which downsides it brings along and then evaluate whether the benefits for our use case (which in most cases is only a subset of the benefits the tool advertises) are really higher than new abstraction layer + new tool to learn + downsides of the tool.

      btw I recommend the article linked by srpablo.

    1. 2

      They give the impression that stringing a bunch of config files together is all you need to become operational. Get a server, follow the HOWTO and you’re good.

      If the reader needs that HOWTO, they will probably not be aware of how to set up backup and restore themselves. The server is now a ticking time bomb. And that’s just the basic operational concern.

      Or the reader doesn’t need the HOWTO, and the article is just mildly interesting. Great, they use YAML to generate systemd units that run podman, that forwards environment variables to a container.

      1. 4

        The only thing needed to backup the Matrix homeserver state is to save the content of the PostgreSQL database. The steps to do that are in the project README. They are written with updates in mind but apply equally.

        How is the server a time bomb? We took great care to make sure everything auto-updates regularly so that you are not running software with know issues or vulnerabilities.

        Disclaimer: Co-author.

        1. 3

          I didn’t think it was supposed to be a bulletproof how to set up your server guide, more “here’s how you might use CoreOS”. Which is why I liked it, I’ve not seen many good motivating introductions to CoreOS.

          1. 4

            I agree with jaffachchief here, this article is one of those use case examples. Trying to find “reasons” to use CoreOS is challenging, this gives you a happy path to get something working.

            Sometimes posts like this are just enough to be able to drop your other app in and see it work.

        1. 11

          As Tavis says himself: https://twitter.com/taviso/status/1288244033710481408:

          Yes, there are reasonable non-security reasons you might want it, I’m only opposed to the security arguments.

          Reproducible builds do not add much from a security perspective because to validate them, you have to do the entire work yourself and trusts the inputs.

          They are however useful from a development, debugging, deployment and distribution perspective (as mentioned already several times in the comments) and he does not deny that.

          1. 4

            Reproducible builds do not add much from a security perspective because to validate them, you have to do the entire work yourself and trusts the inputs.

            Nope, you can have multiple builders within the community who reproduce the build and sign off on it being identical. There’s a level of trust between “trust the vendor and their infrastructure entirely” and “build everything yourself”, and it is precisely this level that I have seen promoted by the reproducible builds people. :-)

            1. 2

              F-Droid does this automatically. If upstream provides an APK, and F-Droid can exactly reproduce that APK, then F-Droid will distribute the one it built with the original’s signature applied in addition to F-Droid’s signature.

            2. 2

              And yet.

              Such builds don’t prevent your source code from being malicious. They do make it harder for a compromised toolchain to go undetected by random users. They also help users verify the source they see is the source that built.

              If you build the same artifact twice and get different results, you learn nothing. Build it twice and get the same result, you know the toolchain did the same things both times, and that’s comforting.

              1. 1

                Reproducible builds do not add much from a security perspective because to validate them, you have to do the entire work yourself and trusts the inputs.

                Which isn’t what they are writing though? Tavis claims the following:

                Now if the vendor is compromised or becomes malicious, they can’t give the user any compromised binaries without also providing the source code. […] Regardless, even if we ignore these practicalities, the problem with this solution is that the vendor that was only trusted once still provides the source code for the system you’re using. They can still provide malicious source code to the builders for them to build and sign.

                So this is largely from only one perspective, and that is proprietary vendors where the pristine source is only gotten from the the vendor publishing the binaries themselves. This hold for proprietary vendors, but doesn’t for Open-Source distributions as pointed out earlier in this comment section.

              1. 5

                See also this (older) article on Auto-squashing Git Commits.