I suppose the right one would be CC-BY-SA-4.0 as README is rather documentation, than source code, but it has also Apache-2.0 markings in the beginning.

          > fyi @henrirosten

This is definitely better than no check at all, but notice that there is a tool already that checks the project's compliance for REUSE. pkgs.reuse is also available in nixpkgs. Although, manually running reuse lint for Ghaf project indicates a large number of issues, which we should resolve first if we would start using pkgs.reuse instead of the scripts in this PR.

Maybe we'll start with @mikatammi's scritps and possibly gradually move to reuse lint compliance later?

For reference, issues currently reported by reuse lint:

ghaf$ nix-shell -p reuse --run "reuse lint"
reuse.project - WARNING - Could not resolve SPDX License Identifier of LICENSES/LICENSE.Apache-2.0, resolving to LICENSE.Apache-2. Make sure the license is in the license list found at <https://spdx.org/licenses/> or that it starts with 'LicenseRef-', and that it has a file extension.
reuse.project - WARNING - Could not resolve SPDX License Identifier of LICENSES/LICENSE.CC-BY-SA-4.0, resolving to LICENSE.CC-BY-SA-4. Make sure the license is in the license list found at <https://spdx.org/licenses/> or that it starts with 'LicenseRef-', and that it has a file extension.
reuse._util - ERROR - Could not parse 'Apache-2.0" && exit 1)'
reuse.project - ERROR - 'scripts/spdx_nix_checker/check_file' holds an SPDX expression that cannot be parsed, skipping the file
# BAD LICENSES

'LICENSE.Apache-2' found in:
* LICENSES/LICENSE.Apache-2.0

'LICENSE.CC-BY-SA-4' found in:
* LICENSES/LICENSE.CC-BY-SA-4.0


# MISSING LICENSES

'Apache-2.0' found in:
* CONTRIBUTING.md
* README.md
* docs/doc.nix
* flake.nix
* hydrajobs.nix
* microvmConfigurations/netvm/default.nix
* modules/development/authentication.nix
* modules/development/intel-nuc-getty.nix
* modules/development/nix.nix
* modules/development/packages.nix
* modules/development/ssh.nix
* modules/graphics/weston.nix
* modules/hardware/nvidia-jetson-orin.nix
* modules/host/default.nix
* modules/host/microvm.nix
* modules/host/networking.nix
* targets/common-debug.nix
* targets/common-release.nix
* targets/common.nix
* targets/default.nix
* targets/intel-nuc.nix
* targets/nvidia-jetson-orin-flash-script.nix
* targets/nvidia-jetson-orin.nix
* targets/vm.nix

'CC-BY-SA-4.0' found in:
* CONTRIBUTING.md
* README.md
* docs/README.md
* docs/src/appendices/contributing_general.md
* docs/src/appendices/glossary.md
* docs/src/architecture/adr/minimal-host.md
* docs/src/architecture/adr.md
* docs/src/architecture/architecture.md
* docs/src/build_config/build_configurations.md
* docs/src/build_config/cross_compilation.md
* docs/src/build_config/passthrough/nvidia_agx_pt_uart.md
* docs/src/build_config/passthrough/passthrough.md
* docs/src/build_config/reference_implementations.md
* docs/src/index.md
* docs/src/research/passthrough/ethernet.md
* docs/src/research/research.md
* docs/src/scs/basics.md
* docs/src/scs/patching-automation.md
* docs/src/scs/pki.md
* docs/src/scs/sbom.md
* docs/src/scs/scs.md
* docs/src/scs/slsa-framework.md
* docs/src/technologies/technologies.md


# UNUSED LICENSES

The following licenses are not used:
* LICENSE.Apache-2
* LICENSE.CC-BY-SA-4


# MISSING COPYRIGHT AND LICENSING INFORMATION

The following files have no copyright and licensing information:
* .git-blame-ignore-revs
* .github/workflows/doc.yml
* .gitignore
* docs/book.toml
* docs/src/SUMMARY.md
* docs/src/architecture/adr/template.md
* docs/src/img/autopatching.drawio.png
* docs/src/img/ca_implementation.drawio.png
* docs/src/img/overview.png
* docs/src/img/threat_processing.drawio.png
* docs/src/img/threat_processing_1serv.drawio.png
* docs/src/img/threat_processing_2serv.drawio.png
* docs/src/research/passthrough/imx8qm-mek_conn-guest.dts
* docs/src/research/passthrough/imx8qm-mek_conn-host.dts
* docs/style_guide.md
* flake.lock
* scripts/spdx_nix_checker/check_file

The following files have no licensing information:
* .github/workflows/fmt-check.yml
* scripts/spdx_nix_checker/check_all


# SUMMARY

* Bad licenses: LICENSE.Apache-2, LICENSE.CC-BY-SA-4
* Deprecated licenses:
* Licenses without file extension:
* Missing licenses: Apache-2.0, CC-BY-SA-4.0
* Unused licenses: LICENSE.Apache-2, LICENSE.CC-BY-SA-4
* Used licenses: Apache-2.0, CC-BY-SA-4.0
* Read errors: 0
* Files with copyright information: 47 / 64
* Files with license information: 45 / 64

Unfortunately, your project is not compliant with version 3.0 of the REUSE Specification :-(

Originally posted by @henrirosten in #79 (comment)

x86_64-generic as an example.

$ nix flake new --template github:tiiuae/ghaf#target-x86_64-generic ~/test-ghaf-downstream
wrote: /home/vilvo/test-ghaf-downstream/flake.nix

[vilvo@carrie:~]$ cd test-ghaf-downstream/

[vilvo@carrie:~/test-ghaf-downstream]$ nix flake show
warning: creating lock file '/home/vilvo/test-ghaf-downstream/flake.lock'
path:/home/vilvo/test-ghaf-downstream?lastModified=1712815534&narHash=sha256-2mIRO3JZxIvS4cBpLzQDpDxVZIaGKlfOvEYs37Yka70%3D
error:
       … in the left operand of the update (//) operator

         at «string»:56:13:

           55|             # This is shadowed in the next //
           56|             // sourceInfo
             |             ^
           57|             // {

       … from call site

         at «string»:47:21:

           46|
           47|           outputs = flake.outputs (inputs // { self = result; });
             |                     ^
           48|

       error: function 'outputs' called with unexpected argument 'nixos-hardware'

       at /nix/store/bwf2bjngr2nyp28nx33fqnnl87ammiz4-source/flake.nix:41:13:

           40|
           41|   outputs = {
             |             ^
           42|     self,

[vilvo@carrie:~/test-ghaf-downstream]$

Affected guides - https://tiiuae.github.io/ghaf/ref_impl/ghaf-based-project.html

    Is this really the minimal we want? This is minimal for a generic headless device, I envisaged us creating minimal-minimal.nix, or barely-enough-to-boot.nix profiles, which we could contribute back.

Originally posted by @brianmcgillion in #41 (review)

There are some open questions and possibly overlapping design proposals on how we integrate modules involving kernel patches and device tree configurations into Ghaf.

In the current main branch the kernel and device tree are configured in the hardware module. More precisely the hardware device tree is set here (line42). Kernel patches and configurations are set in the same file (lines19-38).

The device tree is hashed and copied to /dtbs/ in the boot configuration*.

*Explain this process in more detail, possibly commenting the source code as well.

We are in the process of integrating a module that enables bpmp virtualization on the host. The module includes kernel patches, kernel overlays and kernel configurations as well as device tree configurations and it is specific to the Nvidia Jetson Orin AGX target (or any possible future targets in that family).

I'd like to propose design clarifications, documentation and possibly some refactoring as related to the above context.

Kernel patches

It is my understanding that we have two different proposals as to how we handle modules that involve kernel patches.

1. We create an overlay which applies a kernel patch as well as kernel configuration (as a nix expression) on top of the requested kernel package (line 10) in nixpkgs. Then we extend the kernel with this overlay in our build*.

*How do we handle build-specific configurations such as this? Where do we configure them and how do we make sure different configuration options don't clash?

2. We create a module.

Explain the reasoning behind modules and how they fit our use case?

We should evaluate these approaches, write them out and document a clean way to integrate and test kernel patch modules in Ghaf. Another question is, are this approaches overlapping or complimentary?

Kernel configurations

We propose that all kernel configurations are defined in the nix file that defines the module or the overlay.

Example:

kernel.override {
  kernelPatches = [
    # ...
  ];

  extraConfig = ''
    CONFIG_PCI_DEBUG=y
  '';
}

Device tree configurations

In current main branch some device tree configurations are added from a .dtb file in a target specific hardware module in modules/hardware.

How do we make this modular? Explore device tree overlays.

Modules for different targets

In the current main branch, target specific modules are mixed with common modules. This makes reading the repository somewhat challenging. Maybe we could move to something that separates architecture specific configurations more clearly.

ghaf/modules/
  target/
    nvidia-jetson-orin/
      bpmp-virt/            # Possibly a git submodule (separate repo)?
      ...
    generic-x86/
      ...
  common/
    module.nix
    ...

Open questions

1. How to integrate a module?
2. How to integrate a module involving kernel patches and/or configurations?
   2.1 Do we use modules or overlays (in Nix context)?
3. How to integrate a module that involves device tree configurations?
4. How to separate target specific modules?

Related

• A PR that uses an overlay to patch the kernel.
• Bpmp-virt patch.

          VM specific development modules I’d rather break to VM specific based on categories eventually. It would reduce VM/host size in development mode (think tools useful in GUIVM).

Originally posted by @vilvo in #107 (comment)

Currently the way of adding a new application to GHAF is not clear. (at least I have not found any instructions and rules). What the app should be on GHAF: module, package or smth else.
As an example I took a look at the GALA app. The GALA app already added to the GHAF. Is the way it was added right/suitable for all?

❯ nix flake show
warning: Git tree '/home/brian/projects/code/github.com/tiiuae/ghaf' is dirty
git+file:///home/brian/projects/code/github.com/tiiuae/ghaf
├───formatter
│ ├───aarch64-linux: package 'alejandra-3.0.0'
│ └───x86_64-linux: package 'alejandra-3.0.0'
├───hydraJobs
│ ├───intel-nuc-debug
│ │ └───x86_64-linux: derivation 'nixos-disk-image'
│ └───nvidia-jetson-orin-debug
│ └───aarch64-linux: derivation 'nixos-disk-image'
├───nixosConfigurations
│ ├───imx8qm-mek-debug: NixOS configuration
│ ├───imx8qm-mek-release: NixOS configuration
│ ├───intel-nuc-debug: NixOS configuration
│ ├───intel-nuc-release: NixOS configuration
│ ├───netvm-imx8qm-mek-debug: NixOS configuration
│ ├───netvm-imx8qm-mek-release: NixOS configuration
│ ├───netvm-intel-nuc-debug: NixOS configuration
│ ├───netvm-intel-nuc-release: NixOS configuration
│ ├───netvm-nvidia-jetson-orin-debug: NixOS configuration
│ ├───netvm-nvidia-jetson-orin-release: NixOS configuration
│ ├───netvm-vm-debug: NixOS configuration
│ ├───netvm-vm-release: NixOS configuration
│ ├───nvidia-jetson-orin-debug: NixOS configuration
│ ├───nvidia-jetson-orin-debug-from-x86_64: NixOS configuration
│ ├───nvidia-jetson-orin-release: NixOS configuration
│ ├───nvidia-jetson-orin-release-from-x86_64: NixOS configuration
│ ├───vm-debug: NixOS configuration
│ └───vm-release: NixOS configuration
└───packages
├───aarch64-linux
│ ├───doc: package 'ghaf-doc'
error: The option boot.loader.grub.enable' has conflicting definition values: - In /nix/store/lzv828iaf3p4kjhdsj1vgfn4n510a94x-source/nxp/common/modules.nix': true
- In `/nix/store/5592s3m0cf14nmqm2g14f6mz6plqb9f7-source/nixos/modules/system/boot/loader/systemd-boot/systemd-boot.nix': false
(use '--show-trace' to show detailed location information)

This is caused by the modules/host/minimal.nix declaring systemd boot, while the imx8 is declaring grub.

https://nixos.org/manual/nix/unstable/language/import-from-derivation

This causes slow evaluation times as packages have to be realised along the way. It can also constitute final images being built numerous times making e.g. nix flake check and nix-fast-build take inordinate amounts of time and in part is leading to the OOM that is encountered when running these on standard hardware.

Currently, nix flake check only succeeds in the following situation nix flake check --allow-import-from-derivation as flakes generally disallow IFD in their evaluation.

In the page https://tiiuae.github.io/ghaf/scs/scs.html
in the second paragraph under the illustration, there is a link

• Link text: software bill of materials (SBOM)
• Link URL: https://fossa.com/blog/software-bill-of-materials-formats-use-cases-tools/

Now that we have a dedicated Software Bill of Materials page in Ghaf GitHub pages, we should be pointing to it
-> Replace link URL with: https://tiiuae.github.io/ghaf/scs/sbom.html

Note: in https://tiiuae.github.io/ghaf/scs/sbom.html there is a link also to Fossa page so no information is lost.

Change in flake.nix the description value from this
description = "Ghaf - Documentation and implementation for TII SSRC Secure Technologies Ghaf Framework";
to this
description = "Ghaf Framework: Documentation and implementation for TII SSRC Secure Technologies";

The microvm component is used for running virtual machines inside Ghaf environment. It builds a kernel for virtual machines and filesystems. Filesystems contains NixOS components and additional needed by microvm during runtime (startup scripts, etc.).

Microvm's feature is that it contains hard-coded kernel and package set definitions: kernel configuration and VM's NixOS packages set. There is no way to define a custom packages configuration.
It means that we are unable to define a VM with our own kernel version, configuration, and applied patches. We also cannot change the default package set. I solved this issue in the PR#94, source.

After getting more familiar with Nix/NixOS mechanisms, I have a proposal of solving the problem other way.

Solution

The microvm component is added additional options:

• microvm.vm.kernel: VM kernel package
• microvm.vm.packages: VM NixOS packages to be included in the build

Example

microvm.vm.kernel = pkgs.linuxPackages_5_4.callPackage ./memsharevm-kernel.nix {};
microvm.vm.packages = pkgs.linuxPackages_5_4.extend (_: _: {
kernel = microvm.vm.kernel;
});

Sample kernel configuration: memsharevm-kernel.nix

I think that such change should be easily accepted by microvm's author. I already contacted him regarding other change.

On this page https://tiiuae.github.io/ghaf/architecture/adr.html, there is a link to a template in the archived repository. Could you please update it?

@vilvo Please check if this information is still needed, then move template.md to the ghaf repository and update the link.

PR #167 introduced Ghaf dependency to git revision. After that change, every new revision in Ghaf repository requires a re-build even if the pushed change does not impact any (other) relevant inputs for the build target. This causes unnecessary rebuilds and sub-optimal caching.

This is especially bad for Ghaf, where we are building debug images with the size of each image roughly at 8GB. Since we are now building around 12 targets on each new revision and caching the build results, it means each new change (any change!) generates roughly 100GB of cached images that are largely unnecessary. Since hydra builds all commits merged to main, I assume this generates a lot of problems for remote caches.

We need to think if the trade-off of having the git revision conveniently available on the running system is worth the cost of slowing down the builds and filling our local and remote binary caches with all of these nixos images.

If the ghaf revision must be available in the image, we should think of alternative ways of mapping the running image to the ghaf git revision without introducing the dependency.

          Address host NAT in the minimal host documentation

Originally posted by @vilvo in #93 (comment)

On building Ghaf lenovo-x1-carbon-gen11-debug we see occasional build failures:

error: builder for '/nix/store/dyw71dxaaxvgyl3mnl5xc54ryqf5kxay-nixos-disk-image.drv' failed with exit code 1;
       last 10 log lines:
       > copying path '/nix/store/3z537aq6rbvfrl59bgfm6ls22z2dyy8z-chromium-120.0.6099.71-sandbox' to 'local'...
       > copying path '/nix/store/bblyj5b3ii8n6v4ra0nb37cmi3lf8rz9-coreutils-9.3' to 'local'...
       > copying path '/nix/store/rpzk0h1d11ciarcjkv1zzgsa1iz8zmv8-libidn-1.41' to 'local'...
       > error: hash mismatch importing path '/nix/store/3z537aq6rbvfrl59bgfm6ls22z2dyy8z-chromium-120.0.6099.71-sandbox';
       >          specified: sha256:01bffjgrkk0saf32pjrgpcx893dksp2mqcbpy8bfn6wrinndd2gs
       >          got:       sha256:1wi876fpb69cv2n8vkzr04mv2p5hbc543mpdci7a2lvk3ghnsr2c

More examples are available from the ~'past month' lenovo-x1-carbon-gen11-debug build failures in github action pre-merge builds one can search from: https://github.com/tiiuae/ghaf/actions/workflows/build.yml?query=is%3Afailure.

The issue seems to relate to chromium build (hence only lenovo-x1-carbon-gen11-debug is impacted from the set of targets currently built in pre-merge build workflow). Having many substituters configured seems to increase the likelihood of a build hitting this issue. For instance, github actions pre-merge builds configure the following binary caches: https://github.com/tiiuae/ghaf/blob/main/.github/workflows/build.yml#L146-L147.

As a workaround @brianmcgillion temporarily disabled the lenovo-x1-carbon-gen11-debug target from the pre-merge build workflow with PR: #441.

We would like to re-enable the lenovo-x1-carbon-gen11-debug in the pre-merge build action, but this issue needs to be resolved first.

• Nvidia Jetson host uses special patched version of Qemu.
• The patch is applied as an overlay here
• Patch is created for Qemu 8.0.5 and doesn't apply cleanly to 8.1.3 and should be updated.

          I tested the installer and there are some rough edges, for example I was staring away from laptop while it was installing, then it rebooted, and I wasn't fast enough to disconnect the USB-drive. So the system somehow strangely booted up into ghaf desktop but still something was mounted from USB-drive.

But I'm fine with merging this now and improving things later.

Originally posted by @mikatammi in #249 (comment)

In the page https://tiiuae.github.io/ghaf/build_configurations.html
There is a sentence "The canonical URL for the upstream git repository is: https://github.com/NixOS."

Currently the "https://github.com/NixOS" is not clickable, i.e. does not work as a link.

@jenninikko

          I would propose to keep common target headless and have graphics enabler separately.

Originally posted by @unbel13ver in #77 (comment)

          Note for the future: Also the resulting image was 26 gigabytes, so adding (zstd) compression even to the image embedded, would save many gigabytes

Originally posted by @mikatammi in #249 (comment)

Here https://tiiuae.github.io/ghaf/about/overview.html#reference-implementation we have a link to our old repository.

Is it still actual? Can it be replaced with this one https://github.com/tiiuae/ghaf#build-instructions?

          `allow_unsafe_interrupts` enables threat vector via MSI (message signaled interrupts). This is possible with PCI devices if there's access to device configuration space. See https://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf - pages 6-7. 

I'll add this note to acknowledge the threat from within the netvm and make a ghaf issue out of this to document it - at least until we have iommu group interrupt remapping support or other documented VMM mitigations. It may be that there's other mitigations these days that I'm not aware of. If that turns out to be the case, let's document those and close the issue after the fact.

Originally posted by @vilvo in #93 (comment)

          This whole `features.md` file needs status update based on the the current progress.

Originally posted by @vilvo in #121 (comment)

Check the entire file and others solution names.

Maybe add this link https://docs.nitrokey.com/hsm/ as well.

Ghaf flake evaluation against nixos-unstable fails after commit c7cc82b which was merged in PR #550.

Repro steps

• Pin Ghaf flake to nixos-unstable:

❯ git diff flake.nix
diff --git a/flake.nix b/flake.nix
index 1d1d736..eee65e2 100644
--- a/flake.nix
+++ b/flake.nix
@@ -25,7 +25,7 @@
   };
 
   inputs = {
-    nixpkgs.url = "github:NixOS/nixpkgs/nixos-23.11";
+    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
 
     #
     # Flake and repo structuring configurations

• Update flake lock

❯ nix flake lock --update-input nixpkgs

• Observe the evaluation fails with error: infinite recursion encountered:

❯ nix eval --raw .#packages.x86_64-linux.lenovo-x1-carbon-gen11-debug -v
         ...
         at /nix/store/450afzqlzzgw6wnyc3dwysf3i5yxyqkr-source/lib/customisation.nix:80:32:

           79|       newDrv = derivation (drv.drvAttrs // (f drv));
           80|     in flip (extendDerivation (seq drv.drvPath true)) newDrv (
             |                                ^
           81|       { meta = drv.meta or {};

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: infinite recursion encountered
      ...

• Evaluation passes if c7cc82b is removed:

❯ git revert c7cc82b1e2360cd94cdf55a23ff1b3a896f7dff0
[main 554965f] Revert "Add USB network card kernel patch"
 2 files changed, 26 deletions(-)
 delete mode 100644 modules/common/hardware/usb-network-kernel-patch.nix

❯ nix eval --raw .#packages.x86_64-linux.lenovo-x1-carbon-gen11-debug
...
/nix/store/w0yanw2x2m1nh62awapzzlnf35pjv6ir-ghaf-host-disko-images

On this page https://tiiuae.github.io/ghaf/build_config/build_configurations.html:
If you want to try and check the details, see the build-configurations repository.

Since this repository is now archived, how can we try and verify it now?

Will this instruction be enough? https://github.com/tiiuae/ghaf#build-instructions

          TODO: address how the host allocates dedicated filesystems for guest VMs.

Originally posted by @vilvo in #96 (comment)

In https://tiiuae.github.io/ghaf/scs/sbom.html#sbom-tooling-in-ghaf paragraph there is text

Initially, sbomnix will support CycloneDX SBOM specification, due to the availability of other open source tools that also support CycloneDX. Support for other SBOM formats to sbomnix might be added in later versions.

Because SPDX specification support has been added to sbomnix, the paragraph should say

sbomnix supports CycloneDX and SPDX SBOM specifications.

nix flake check runs out of memory even after #372.

Following reproduction steps were run on x86_64-linux with 16-cores and 32GB memory (no remote builder is configured):

Git HEAD:

$ git log -1 --pretty=oneline
8f8f6538807f8afd9f08dc6a162c5f407f69bc5b (HEAD -> main, origin/main, origin/HEAD) Fix reuse compliance

Run nix flake check to repro OOM:

$ nix flake check
checking flake output 'checks'Killed

Verify from journactl that it's killed due to OOM:

$ journalctl | tail -n500 | grep -i "Out of memory"
Dec 01 09:35:07 duamix kernel: Out of memory: Killed process 1808882 (nix) total-vm:27647872kB, anon-rss:27439060kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:53844kB oom_score_adj:0

Added a 'go' package to my ghaf repo "ghaf/modules/development/packages.nix". and ran Ghaf with “nix run .#packages.x86_64-linux.vm-debug“. Then tried to install Kopia in Ghaf's terminal with "go install github.com/kopia/kopia@latest", but the reserved disk space ran out with few of its last parts. Looked like there was < 1GB space on the Ghaf's reserved disk originally and about 700MB got installed of Kopia when the space ran out. Is there some configuration that is limiting this to only 1GBish? What could be done?

Running Ghaf on Ubuntu 22.04.2 LTS (GNU/Linux 5.15.90.1-microsoft-standard-WSL2 x86_64).

          SSID / password we could also refactor like authentication.nix - would also support .gitignore for developer local secrets until we develop proper way to support these.

Originally posted by @vilvo in #107 (comment)

          > Today I had a routing problem in Ghaf, because my default internet router subnet is 192.168.101.0/24.

[ghaf@net-vm:~]$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         net-vm          0.0.0.0         UG    1025   0        0 wlp0s4f0
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 ethint0
192.168.101.0   0.0.0.0         255.255.255.0   U     0      0        0 ethint0
192.168.101.0   0.0.0.0         255.255.255.0   U     1025   0        0 wlp0s4f0
net-vm          0.0.0.0         255.255.255.255 UH    1025   0        0 wlp0s4f0

The problem was that the net-vm was not able to ping my laptop because the default route in that case was through ethint0 and not to wlp0s4f0.

The solution in my case was simple, change the subnet in my Internet router to 192.168.110.0. But, many user could have a similar problem if their Internet routers subnet are 192.168.100.0 or 192.168.101.0. I think that the subnet managed by the net-vm should be one less popular, such as 192.168.170.0/

@jpruiz84 This is good suggestion. However, I left the change of the ghaf subnet ip addresses now out of this PR because it can cause some confusion in development and breaks in testing (when they have relied on IP addresses when the internal host name queries did not work). Now that the internal host name queries work, let's give people in development and testing time to adopt the change. Then the IP address range can be changed to something less likely to conflict.

Originally posted by @vilvo in #427 (comment)

When checking the ghaf flake with nix flake check --all-systems I get the following:

ghaf git:(main) nix flake check --all-systems
error:
       … while checking flake output 'hydraJobs'

         at «none»:0: (source not available)

       … while checking the Hydra jobset 'hydraJobs'

         at «none»:0: (source not available)

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: cannot build '/nix/store/qlzv68cp8ks2plr60wqwzhrg5bwvl8gs-waypipe-ssh.dr
v' during evaluation because the option 'allow-import-from-derivation' is disabled

Background: In Nix, the act of "importing from a derivation" allows for the dynamic generation of Nix expressions during the build process. By default, the allow-import-from-derivation option is disabled because IFD can have potential complications when used with Hydra, Nix's CI server.

Maybe we could also add the flake check into Github Actions CI maybe as part of #293

https://tiiuae.github.io/ghaf/build_config/reference_implementations.html
the authentication module link is broken