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

Afaik, the official hydra builders don't build insecure packages, so I am kind of against setting

Yeah but honestly I see no reason for that

I still think that we should just change freeimage to

That would be lies though?

Message deleted by NixOS Moderation Bot

o_0

On a related note, can somebody tell me:

1. Should I prefer linking to libglvnd instead of libGL?
2. Is it bad if I end up having both libGL and libglvnd in the same closure?
3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?

~~On a related note, can somebody tell me:

1. Should I prefer linking to libglvnd instead of libGL?
2. Is it bad if I end up having both libGL and libglvnd in the same closure?
3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?~~

On a related note, can somebody tell me:

1. Should I prefer linking to libglvnd instead of libGL?
2. Is it bad if I end up having both libGL and libglvnd in the same closure?
3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?

Edit: nvm, I am blind. libGL is an alias for libglvnd

~~On a related note, can somebody tell me:~~

1. Should I prefer linking to libglvnd instead of libGL?
2. Is it bad if I end up having both libGL and libglvnd in the same closure?
3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?

Edit: nvm, I am blind. libGL is an alias for libglvnd

~On a related note, can somebody tell me:~

1. Should I prefer linking to libglvnd instead of libGL?
2. Is it bad if I end up having both libGL and libglvnd in the same closure?
3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?

Edit: nvm, I am blind. libGL is an alias for libglvnd

On a related note, can somebody tell me:

1. Should I prefer linking to libglvnd instead of libGL?
2. Is it bad if I end up having both libGL and libglvnd in the same closure?
3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?

Edit: nvm, I am blind. libGL is an alias for libglvnd

On a related note, can somebody tell me:

1. Should I prefer linking to libglvnd instead of libGL?
2. Is it bad if I end up having both libGL and libglvnd in the same closure?
3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?

Edit: nvm, I am blind. libGL is an alias for libglvnd

Edit: nvm, I am blind. libGL is an alias for libglvnd

On a related note, can somebody tell me:

1. Should I prefer linking to libglvnd instead of libGL?
2. Is it bad if I end up having both libGL and libglvnd in the same closure?
3. It seems that libglvnd doesn't provide libGLU or libglut. Is there an equivalent vender-neutral dispatch mechanism for those libraries?

Edit: nvm, I must be blind and/or sleep deprived. libGL is an alias for libglvnd

Edit: nvm, I must be blind and/or sleep deprived. libGL is an alias for libglvnd

Btw, it seems that there is a mismatch in CUDA vs GCC version compatibility after all. In particular, for me

cudaPackages_11_2.backendStdenv.cc.version == "12.4.0"

and with that compiler, a couple of the samples in cuda-samples are failing to compile due to errors inside cuda_cccl headers. Here is a forum post discussing this exact error.

I wasn't able to find precise compatibility matrices for CUDA 12.1, but according to this stackoverflow answer, CUDA 12.1 supports GCC versions up to 12.2 which is lower than the current 12.4.0.

Minor versions don't work in pkgs/development/cuda-modules/nvcc-compatibilities.nix, but setting gccMaxMajorVersion = "11" for "12.1" I was able to successfully build the problematic samples that fail with GCC 12.4.0. So it looks like CUDA 12.1 doesn't fully support GCC 12.4 after all.

Thoughts?