https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8501 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8502 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8503
You have any patches to cleanup this port?
Not yet, I've unfortunately not had any time to look into this, yet. Too much going on, currently, sorry... Also, not sure if the importance needs to be set to "affects many people", as I doubt that. This port of binutils is only used for the psptoolchain, there are no other dependencies on it. I don't think a lot of people are actually using this. But, bigger question: Given that this port is actually port of an existing patchset against gnu binutils 2.22, adding PSP support, it's a bit of an undertaking to switch to a newer binutils version, b/c the source-patchset didn't, yet. Not sure how to handle this best - fork from the sources and maintain an own, newer version of binutils, or actually just add patches to fix those vulnerabilities? Input welcome.
I think it would be best and safest (for the future) to just link to the binutils port if possible. Given the maintainer seems not very active, feel free to try a port if time permits.
assigning to ports-secteam
I am not sure, but ===> Registering installation for psptoolchain-binutils-2.22_1 Installing psptoolchain-binutils-2.22_1... ===> Cleaning for psptoolchain-binutils-2.22_1 sudo pkg audit 0 problem(s) in the installed packages found. is it fixed?
(In reply to w.schwarzenfeld from comment #5) Unsure, but I don't think so. I'm still not sure how to best handle this. Ideally this would use binutils > 2.24, but upstream stays on 2.22, as their patches are for that version (the psptoolchain is basically a patchset itself, which are merely ported here). Also, given this is for building PSP binaries, this is not a security risk to FreeBSD. Maybe that's why pkg audit doesn't show any problems? The best way, IMHO is for me maybe to port their stuff to a newer binutils version, then share this work upstream. Thoughts?