There is a myriad of human and technical solutions to this but it requires a lot of context to pick the right combination.
The first question to ask, is how one gets to be an impactful rogue maintainer. We've seen examples of rogue hustling out a real maintainer. But this AUR attack is thru gaining ownership of abandoned ports.
Both of these are somewhat solved by the human process if it can be established. It is a simple trust system that doesn't go far to eliminate deep sleepers, that can happen anytime anywhere, in CIA or KGB or FreeBSD. That sort of shit is still unseen in the open source world. Trust the verified people, the mentors. Trust nobody from outside. New committers are mentored over.
The thing is, a few new committers made a 400 port change over there in a week. I don't have to make analogies for that sort of stupidity.
If it is legit, it is somebody's concentrated AI act. They got funds to make AI refresh stale ports, or they will try to profit on the fact somehow.
That somebody should introduce himself first, and the whole thing should have been controlled.
I see no major problem here. The port ownership and controlling hierarchy can be established without putting load on the main ports guys because in real life nobody comes over and one shots 400 stale possibly highly non-important shit. What mentors need to take into account is hustling out the regular commiters. "Hi I am Zare and I'm taking over John because he went to a hospital" does not cut it. I am a new guy and should be treated as such.
Then we have several technical options, flagging system that goes up if a regular committer changes anything that can yield into different code paths taken in our domain of the build. Bumping up a version in the URL string, removing a dep would be allowed. A deterministic tool would go through this, and an local AI model could compare changes. Another system would be deployed to actually build the port. This system should not be discernable from a random FreeBSD installation, but it should be a snapshottable VM where the orchestration framework simulates keyboard input and scans the video framebuffer. Potential malware in the port build running as root should not be able to detect its being tested ala Volkswagen. As soon as the build finishes the machine is frozen into a snapshot and environment compared to what it should be.
I am going to watch the video but I don't think the situation is bleak because we seemingly have a better trust model going on with ports than AUR?
Btw. I don't imply above tech solutions should be done for every port, but for those that are already flagged as potential vectors, unmaintained niche stuff done by somebody overly zealous to do it, and potentially nags the reviewers for "velocity" and such.
The attitude of individuals like MrBSD are the reason take up is and always has been slow. Lets keep up the positivity and ignore basement dwelling trolls like MrBSD.
