Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update request: freeimage unstable-2021-11-01 → unstable-2023-05-20 #298114

Closed
1 task done
kjeremy opened this issue Mar 22, 2024 · 5 comments · Fixed by #369766
Closed
1 task done

Update request: freeimage unstable-2021-11-01 → unstable-2023-05-20 #298114

kjeremy opened this issue Mar 22, 2024 · 5 comments · Fixed by #369766
Labels
9.needs: package (update) This needs a package to be updated

Comments

@kjeremy
Copy link
Contributor

kjeremy commented Mar 22, 2024

  • Package name: freeimage
  • Latest released version: unstable-2023-05-20 (r1909)
  • Current version on the unstable channel: 2021-11-01
  • Current version on the stable/release channel: 2021-11-01

Notify maintainers

@viric
@L-as


Note for maintainers: Please tag this issue in your PR.


Add a 👍 reaction to issues you find important.

@kjeremy kjeremy added the 9.needs: package (update) This needs a package to be updated label Mar 22, 2024
@eclairevoyant
Copy link
Contributor

#290949 (comment)
I don't think we're going to see much effort to update this, if anything, patching/updating anything that depends on it and removing it is more realistic

@L-as
Copy link
Member

L-as commented Mar 26, 2024

freeimage is probably full of many more security holes that are yet to be found, agree with above, but updating it probably isn't too hard if upstream hasn't changed much

@risicle
Copy link
Contributor

risicle commented Jul 14, 2024

Our position is that freeimage is unmaintainable.

The upstream updates since the version in nixpkgs are basically updates of the bundled libs, which we make made serious efforts to de-vendor and replace with nixpkgs-versions anyway, so probably wouldn't make any difference to the resulting package.

The vulnerabilities listed in knownVulnerabilities are largely in freeimage code and I don't see any signs of them having been addressed or even acknowledged by upstream.

From what I can tell, there is no way of providing any package that depends on freeimage in a secure way. Packages that depend on freeimage need to have their upstreams made aware of this so they can stop using it.

@tengkuizdihar
Copy link
Contributor

Just want to chime in with this repo https://github.com/danoli3/FreeImage, claiming that it has fixed all of the security issues.

@L-as
Copy link
Member

L-as commented Oct 22, 2024

We could add a new package under a new name and deprecate the old one. I don't want people using this by accident, since it has different trust assumptions (do you trust this author? I won't make that choice for people).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
9.needs: package (update) This needs a package to be updated
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants