My personal space on the web. Mostly about FOSS and technological autonomy.

cross-posted from: https://lemmy.ml/post/31718711

Always wanted to selfhost your Fediverse instance but were always worried about system administration trauma?

Do you ever have to run around your flat, picking up all the leftover parentheses from yesterday’s party with your hosting coop coworkers?

Then you are probably the right person, check out this post about fearless Bonfire hosting on a Guix System. You’ll learn that taking care of a community is much more manageable when you let computer do the boring work for you.

Set up HTTPS, automatic backups, automatic nightly upgrades and join the awesome Bonfire community without a single worry on losing data from your instance.

  • jim3692@discuss.onlineEnglish
    31·
    2 days ago

    I quickly went through the article, and I have a question: Why not Docker (or Podman) on NixOS?

    NixOS has much larger community (although a bit toxic) and provides native tooling for managing OCI containers through Docker and Podman.

    • fishinthecalculator@lemmy.mlOPEnglish
      6·
      2 days ago

      I find Guix far better on almost every remark, in no particular order:

      • as you said some part of the Nix community is made of techbros (even if Guix attracts some fossbros as well)
      • the way governance is structured in the Nix community is brittle, just see the drama from which all the new Nix forks spawned
      • better documentation. The doc for Nix is scattered, the Guix manual, albeit not perfect, is much more complete
      • the Guile language is far clearer than Nix, also you don’t have to use it only for package recipes, you can build full applications with it
      • the Guix story around trustability of binaries is far better (checkout how Guix boostrapps everything), entires classes of vulnerabilities are prevented by design
      • the Guix UX is far better designed imho, the command line is intuitive and well documented and features are easily composable
      • the community is not diverging, as is the case for Nix flakes
      • Guix as well provides OCI integration, check out the point about enabling gocix
      • jim3692@discuss.onlineEnglish
        2·
        2 days ago

        I don’t have any experience with guix, so I will not express any opinions towards that.

        However, regarding NixOS:

        • Yes, as a person with experience in the Nix language, I can confirm it’s awful
        • The documentation of NixOS is a known issue, and there are currently efforts to improve it
        • Talking about the trustability of binaries, by doing a quick search, I read that Guix builds are reproducible. This is true for NixOS as well. All upstreamed packages must have their version and the hash of the code (or artifact), to allow verification
        • The community of NixOS is opting to maintaining flakes, because:
          • Some applications can simply not be built following the Nix guidelines. Examples are some electron apps (like Falkor) and apps that have weird toolchains (like bubblejail)
          • The reviewing process takes way too long, and PRs for upstreaming are often ignored. This forces a lot of people to just PR a flake.nix to the application, or maintain their own overlays (overlays are like overriding the available packages, while flakes are more like distributing Nix code in general)
          • jim3692@discuss.onlineEnglish
            2·
            2 days ago

            It’s the first time I see the concept of bootstrappability in the context of security.

            Is it really worth the effort?

            There are multiple ways to run a supply chain attack. With bootstrappability, one can be sure that the compiler is trusted, but what about the code that the compiler compiles? There was this recent attack to XZ utils, which shows that more attention is needed on the code being merged and compiled.

            I think that this just creates a false sense of security.

            Contrary to that, I had read about a BSD team (I think FreeBSD) that reviews all the code before each release. This way they have achieved ~5 RCE exploits throughout their entire history.

            • fishinthecalculator@lemmy.mlOPEnglish
              2·
              12 hours ago

              I think it’s worth the effort since it prevents numerous risks at the root, for sure it’s not enough. I agree that bootstrapping wouldn’t necessarily solve the XZ attack, but I think that should be solved by big tech paying FOSS maintainers enough or at all to prevent them from burning out.

              About the BSD experience that looks like a big amount of work but definitely worth it, I’m sure they didn’t ship many packages as Guix ships but I guess the projects have different goals and requirements.

            • unhrpetby@sh.itjust.worksEnglish
              2·
              1 day ago

              There was this recent attack to XZ utils, which shows that more attention is needed on the code being merged and compiled.

              XZ was made possible largely because there was unaudited binary data. One part as test data in the repo, and the other part within the pre-built releases. Bootstrapping everything from source would have required that these binaries had an auditable source, thus allowing public eyes to review the code and likely stopping the attack. Granted, reproducibility almost certainly would have too, unless the malware wasn’t directly present in the code.

              Pulled from here:

              Every unauditable binary also leaves us vulnerable to compiler backdoors as described by Ken Thompson in the 1984 paper Reflections on Trusting Trust and beautifully explained by Carl Dong in his Bitcoin Build System Security talk.

              It is therefore equally important that we continue towards our final goal: A Full Source bootstrap; removing all unauditable binary seeds.

              Sure you might have the code that was input into GCC to create the binary, and sure the code can be absolutely safe, and you can even compile it yourself to see that you arrive at the same bit-for-bit binary as the official release binary. But was GCC safe? Did some other compilation dependency infect the compiled binary? Bootstrapping from an auditable seed can answer this question.