Do we want to enable aarch64-linux for cuda package set on hydra?

I think it makes sense with already available GH200 and Digits available in May

I am currently working on fixing cuda-samples. I wanted to bikeshed a bit more about its dependency on the insecure freeimage package. I still think that in general having eval errors for insecure package dependencies is useful. Afaik, the official hydra builders don't build insecure packages, so I am kind of against setting allowInsecure/allowInsecurePredicate/permittedInsecurePackages in release-cuda.nix.

On the other hand, it's kind of silly to treat cuda-samples as insecure just because it depends on freeimage. Most of the code in cuda-samples is for demonstration/validation purposes only, a lot of it doesn't even have proper error checking and shouldn't be used in production anyway. So it is extremely weird to refuse building cuda-samples just because there are some potential buffer overflow exploits or whatever in the library it uses for image reading.

I still think that we should just change freeimage to

freeimage.overrideAttrs (prev: {
  meta = prev.meta // {
    knownVulnerabilities = [ ];
  };
})

specifically only in the cuda-samples derivation.

However, if not shipping "vulnerable" binaries is so important, then we could keep cuda-samples broken, but introduce a separate cuda-samples.passthru.buildCheckOnly derivation that ignores the freeimage "vulnerabilities", but then replaces its installPhase with something along the lines of touch $out. That way, we keep cuda-samples.buildCheckOnly as a useful smoke test, but don't distribute any "potentially vulnerable" binaries. Though, TBH, this sounds like over-engineering and we should just override freeimage.knownVulnerabilities in cuda-samples specifically.

Any thoughts?

In reply to @connorbaker:matrix.org
Does a patched version of freeimage exist, or is it abandoned? If there is a newer version, I’d be interested in whether, as a longer term goal, it’d be possible to update the samples to use it.

It seems there is a fork

https://github.com/danoli3/FreeImage

Readme says:

This GitHub Fork/Patch of FreeImage

• Numerous Sub-Dependancy patches (Security/Bugs/Latest)
• With patches applied from nVidia Devs and OpenSource additions
• CMake Build ability allowing compiling easily for all targets and platforms

I guess, the relevant questions would be:

1. Is it backwards compatible with the older official versions of FreeImage?
2. Is there some sort of consensus around this fork being a good replacement?
3. Which CVEs does this fork fix?
4. Are these fixes verified / documented by whatever authorities published the original CVEs?

by changing SAMPLE_ENABLED := 1 to SAMPLE_ENABLED := 0 here:

https://github.com/NVIDIA/cuda-samples/blob/9c688d7ff78455ed42e345124d1495aad6bf66de/Samples/4_CUDA_Libraries/freeImageInteropNPP/Makefile#L284