Readme updated today:

This repository is no longer actively maintained.

The TrueNAS build system previously hosted here has been moved to an internal infrastructure. This transition was necessary to meet new security requirements, including support for Secure Boot and related platform integrity features that require tighter control over the build and signing pipeline.

No further updates, pull requests, or issues will be accepted. Existing content is preserved here for historical reference only.

https://github.com/truenas/scale-build

Wondering if this is just the first step towards doing a minio in the future.

  • Eskuero@lemmy.fromshado.ws
    link
    fedilink
    arrow-up
    12
    ·
    2 days ago

    Self sign doesn’t defeat the purpose, you can add your own keys to your bios that you use to sign your kernel. I do that and have a secure booted Arch Linux installed.

    • TehPers@beehaw.org
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 day ago

      Self sign doesn’t defeat the purpose

      The whole point of signing is that the BIOS can verify that the bootloader is legitimate. For a local Arch install, it doesn’t matter because Arch doesn’t distribute signed bootloaders and the environment is wholly personal. TrueNAS sells products and services though, such as enterprise-level support. It isn’t just something used in home labs. Their customers may require things we do not, and secure boot support appears to be one of them.

      Self-signing to work around the idiotic restrictions Microsoft imposes to get it signed would be one way to do that, but then the software is essentially acting as its own authority that it is legitimate. Customers would realistically rather the bootloader’s signature is valid with the built-in key provided by MS since it means that MS is confirming its validity instead - not exactly a name I would trust, but I’m personally not a TrueNAS enterprise customer either.