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?
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
===> 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.
I qualify this as upstream problem, so I'd close this PR and reopen it upstream (wherever it is).
Thanks for understanding. I have the same problem about not even knowing what upstream is. The old ps2dev.org went away, and some people seem to run different github repos now, the most likely being https://github.com/pspdev/psptoolchain/
However, there is no clarity IMHO whether this is the new de-facto official place or not, at least I cannot find any mention of ps2dev on there or the wiki they point to: http://www.darkhaven3.com/psp-dev/wiki/index.php/Main_Page
Since this is the most complete/comprehensive, though, let's assume this is upstream.
Please let me know if there is something for me to do, or if I can be helpful in any way.
WWW: http://www.ps2dev.org/ this website was not found.
Maintainer: can you pls check, ist there a other Website?
Otherwise I would suggest to delete the port.
/add @rene (portmgr) because of possible deletion of the port - also because of these security Vulnerabilities and no new version (website down)
(In reply to Jochen Neumeister from comment #9)
I don't understand the suggestion to remove the port without neither having taken into account the discussion above, nor the fact that none of the sources even depend on www.ps2dev.org. If you want me to change the pkg-descr, I can do that. About the security question, please refer to the discussion above.
So, what do you want me to do?
We have a security vulnerability in the port, it was reported in 2015.
https://www.freshports.org/devel/psptoolchain-binutils show me this Info
This website is not accessible for me.
As ports-secteam I have to make sure that ports with security holes are closed as soon as possible.
What can you do as a maintainer? If the project has a new website, for example change this into port. And preferably a patch / update to finally solve the 2015 security problem.
Ports that have a security hole for years that are not closed will be removed from the port-tree.
It would be great if we can solve the problem soon :-)
Thank you for the input. I understand your role as a ports-secteam member, but I want to point out in this specific case, which is a dilemma:
- there are hundreds of ports that have broken urls in the pkg-descr, so I really do not understand why this plays into security; however, sure, I can update this, it isn't sure whether this site will come back to life or not, I have no control over it
- I was asking years ago already what to do, as this is an upstream problem, which include, so could you please provide input on this? To sum it up, this is not a security problem for FreeBSD, as it affects the cross-built psp binaries
- you suggest "patching" it: yes, I can cherry pick the security fixes against binutils, but I'm sure that pkg-audit will not be happy after this, as it does a mere comparison of the binutils version number
Believe me, I also would be very happy if this could be sorted, soon. I want to, but I either get no, or conflicting feedback here.
I hope this makes sense
From what I gather, the upstream is
At least, these sites aren't down/archived and reference each other. There is even some activity in the GitHub repo.
However, the software itself is just a script to build another software from source. I don't really see a point for this port, so I propose to remove it.
(In reply to Gleb Popov from comment #13)
When I worked on the first version of this port I was told that I cannot just port this "script", b/c then it would download things during the build phase, which makes sense. The consensus back then was to basically reproduce the script. This means that upstream's work is in this case not the script as we don't use it, but basically the patches.
So I don't really understand your suggestion to remove this port, where exactly is the problem with the way it was done, as also suggested back then by other ports committers?
(In reply to Tassilo Philipp from comment #14)
Ok, this makes sense. This is a rare case when the port has 2 usptreams: the one is that GitHub repo containing patches and the other is an "upstream of upstream", the binutils project itself. Your port is basically and alternative to the GitHub repo upstream. And after thinking about this a bit, I'd say I like the approach.
However, I still do not see the point of keeping this PR open. Since you are the maintainer you should either fix the port yourself by adding necessary patches or report this issue to the upstream and wait them to fix it. The upstream would either pull the patches from the "upstream of upstream" or even rebase their patches on top on newer binutils.
(In reply to Gleb Popov from comment #15)
I agree, this PR doesn't need to be open, and the fact that it is is basically the dilemma I wrote about in previous comments, and conflicting- or no answers from others that participated in this discussion.
If I understand you correctly, your first suggestion is to fix the port by adding patches, this could mean two things:
- either cherry pick the security patches that were done against binutils 2.22 relating to the mentioned CVEs and integrated them into the port; in that case I'm not sure how pkg-audio would be happy b/c it would still just see v2.22 (or am I missing something)
- or upgrade myself to a newer binutils version (given the amount of patches to get the psp supported, this is a bit more involved)
Your second suggestion is to contact upstream and lobby them to upgrade. It's true that I should probably retry this, probably first, despite previous attempts that went nowhere: Previous experience was that when ps2dev.org went down, I had a hard time even knowing what upstream is, as seemingly unofficial mirrors with different changesets came up. Emails from years ago remained unanswered.
Now there seems to be psp-dev.org which didn't even exist at the time of the last comments on this PR (before you pitched in). The page seems to have been created in september 2020 - thanks for digging that up! Also, the github repo you mention seems to be the de-facto upstream by now. They even did upgrade the binutils version to 2.23, however that version is still vulnerable.
So, I'll check with psp-dev.org, and report back. Thanks for reviving this and bringing this new page to my attention, that I didn't know of.
I mailed the people that run psp-dev.org multiple times now, but zero replies. I'll wait for a bit longer, but I start to seriously consider removing this port and all the other psptoolchain* ports, as they depend on it.
Any progress on this?
Hello, sorry for having not gotten back. I tried to contact what we think upstream is 4 times now, via different addresses I dug up, and zero replies. In my mails I asked if there is any update planned, and also if I can help getting this updated (and if so if there is anyone I can write to if questions come up).
Well, zero replies, not even any reply like "sorry cannot help you". Given that, I'm not even sure that if I would upgrade this myself that my patches would be included anywhere, actually (and I'm not shooting for maintaining a custom and bigger patch set myself).
To be fair, there might be other ways to contact upstream, e.g. via github, that I haven't tried (I don't even have a github account). However, I think I got to the point of being frustrated enough with it that I don't want to deal with it anymore.
So, long story short: I think upstream is unresponsive and the psptoolchain* ports should be removed, and we can finally close this chapter.
I apologize not having gotten to this point, sooner.
If you don't plan to maintain these ports anymore, should I reset the MAINTAINER field to ports@?
Yes please. That said, given that upstream is unresponsive, I'm not sure whether it's better to delete the ports, instead of just dropping me as maintainer.
A commit in branch main references this bug:
Author: Gleb Popov <arrowd@FreeBSD.org>
AuthorDate: 2021-12-11 07:03:47 +0000
Commit: Gleb Popov <arrowd@FreeBSD.org>
CommitDate: 2021-12-11 07:04:51 +0000
devel/psptoolchain*: Reset MAINTAINER as requested.
devel/psptoolchain-binutils/Makefile | 2 +-
devel/psptoolchain-gcc-stage1/Makefile | 2 +-
devel/psptoolchain-gcc-stage2/Makefile | 2 +-
devel/psptoolchain-gdb/Makefile | 2 +-
devel/psptoolchain-newlib/Makefile | 2 +-
devel/psptoolchain-pspsdk-stage1/Makefile | 2 +-
devel/psptoolchain-pspsdk-stage2/Makefile | 2 +-
devel/psptoolchain/Makefile | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
^Triage: Reset Assignee (timeout: 2 years, original (security) report 2015)
It would be a shame to lose these ports, but 7 years on multiple security vulnerabilities in our tree.
Upstream repo's are active , but this port now has no maintainer. (comment 22).
Can someone please mark these ports deprecated with an expiration_date of ~3 months due to outstanding and unresolved security issues. We originally triaged this in 2015.
While here, ping pkubaj who's fixed issues with these ports on other archs, in the event they'd like to update them and has free cycles. Also cc freebsd-ports-bugs to get the word out. If any issue needs it its this one.
Retriage Requested by: concerned freebsd community member
^Triage: Core is on cc, and doesn't need to specifically ack this. (cancel feedback req)
^Triage: I think a vuxml entry is still needed.
I don't think updating to newer binutils is feasible, we would pretty much create our own fork.
What's feasible is backporting https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0102ea8cec5fc509bba6c91df61b7ce23a799d32, https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5a4b0ccc20ba30caef53b01bee2c0aaa5b855339 and https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7e1e19887abd24aeb15066b141cdff5541e0ec8e.
A commit in branch main references this bug:
Author: Rene Ladan <rene@FreeBSD.org>
AuthorDate: 2022-05-07 10:32:12 +0000
Commit: Rene Ladan <rene@FreeBSD.org>
CommitDate: 2022-05-07 10:32:12 +0000
devel/psptoolchain*: mark for expiration on 2022-06-30
These ports are unmaintained and have up to seven years of
accumulated security issues. Deprecate these ports as
suggested in 
devel/psptoolchain-binutils/Makefile | 3 +++
devel/psptoolchain-gcc-stage1/Makefile | 3 +++
devel/psptoolchain-gdb/Makefile | 3 +++
devel/psptoolchain-newlib/Makefile | 3 +++
devel/psptoolchain-pspsdk-stage1/Makefile | 3 +++
devel/psptoolchain/Makefile | 3 +++
6 files changed, 18 insertions(+)
Expired psptoolchain ports removed.