I won't try to address everything you've said, but here's some thoughts that came to mind as I read this:
It's been acknowledged that this is doing something that an install script really shouldn't be doing; while there's no written policy (maybe, I haven't looked again) there's definitely at least a social convention that generally gets followed. Sometimes things slip through the cracks. I would propose that a more effective solution would have been an e-mail to -ports@ or hopping on IRC to get someone to commit the patch that was sitting there and, in a calmer tone, expressing that you think this issue is more urgent than it had been treated up to that point. I was personally put off by your initial post here, and thus less likely to follow through with it as a result as a ports committer. The other point that I'd like to bring up is that ports is delegated ports-secteam@ purview, so this was misguided anyways as secteam should be more of a last resort for ports-specific issues. Thanks, Kyle Evans On Fri, Apr 9, 2021 at 4:22 AM Stefan Blachmann <sblachm...@gmail.com> wrote: > > The deeper-lying problem is the almost complete lack of policy what is > allowed and not for installer scripts. > And the complete lack of policy what to do in case of violations, no > matter whether intentional or not. > > Other appstores (the pkg system is de facto an appstore) have policies > that are being enforced to protect their customers, for example by > (temporarily) taking down apps that behave dubiously. > > When in lack of agreed-upon rules/policies/laws the "police" does not > dare to do anything, in fear to hurt anybody's feelings, isn't it then > an useless placebo police? > > The issue has been reported and said to be fixed more than three > months ago, and the problem still is there like if nothing had be > done. > > If you are not able to understand that advocators and users get angry > rightfully and want to have the deeper-lying issues addressed and > solved, which have led to such problems, then this might be a > complacency issue. > And from another perspective, it might be seen as an entitlement > mentality if developers expect users to fix their bugs, and even > provide them with ready-to-use patches. > > I apologize if I hurt feelings by getting angered over this. > But seeing quite some people having tried to get the issue solved in a > quiet, polite manner without achieving any effective progress, > indicated to me that this approach would not be fruitful. > Sometimes it is necessary to raise the voice, even at the risk of > making oneself unpopular. > > I would be happy if this incident would lead to a discussion and > setting up rules/policies that in future can prevent such things > happen and persist unsolved. > > On 4/8/21, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > > On Thu, Apr 08, 2021 at 04:50:17AM +0200, Stefan Blachmann wrote: > >> The answers I got from both "Security Officers" surprised me so much > >> that I had to let that settle a bit to understand the implications. > >> > >> > >> Looking at the FreeBSD Porters' Handbook > >> [https://docs.freebsd.org/en_US.ISO8859-1/books/porters-handbook/pkg-install.html], > >> it describes the purpose of the package pre- and postinstallation > >> scripts as to "set up the package so that it is as ready to use as > >> possible". > >> > >> It explicitly names only a few actions that are forbidden for them to > >> do: "...must not be abused to start services, stop services, or run > >> any other commands that will modify the currently running system." > >> > >> Anything else is apparently deemed “allowed”. > >> Spying out the machine and its configuration, sending that data to an > >> external entity – perfectly OK. Not a problem at all. > >> > >> This has been proved by the handling of this last BSDstats security > >> incident, where the FreeBSD “pkg” utility is being abused to run > >> spyware without the users’ pre-knowledge and without his content. > >> > >> This abuse is apparently being considered acceptable by both FreeBSD > >> and HardenedBSD security officers. > >> Instead of taking action, you "security officers" tell the FreeBSD > >> users that it is their own guilt that they got “pwnd”. > >> Just because they trustingly installed software from the package repo > >> hosted by FreeBSD, without religiously-carefully auditing every and > >> each packages' pre- and postinstallation script before actual install, > >> using the “pkg -I” option. > >> > >> Indeed, I felt very surprised that the “Security Officer” of “Hardened > >> BSD” chimed in, only to publicly demonstrate his lack of competence to > >> recognize obvious security problems. > >> Like two fish caught with a single hook! > > > > 1. Ad hominem much? I understand the underlying problem very well. > > 2. Your hostility is incredibly annoying. > > 3. You attribute malice where there is none. > > 4. This is volunteer work, where volunteers have everyones well-being > > in mind. > > 5. Threatening to go to journalists accomplishes... what? What makes > > you think journalists are NOT paying attention to this list? What > > makes you think journalists care about you? > > 6. I really, really, really, really, really hate the "Karen" meme. But > > it fits incredibly well here. > > 7. Where can I review your patches that fix the problem? > > 8. Entitlement mentality much? > > > > Sure, the bsdstats package shouldn't submit just on "pkg install." > > Instead of fixing the problem, you went the hostile route. > > > > I'm sure you won't learn anything from this, but I hope you do. To me, > > it reinforces how random people feel entitled to force their will on > > others. > > > > Thanks, > > > > -- > > Shawn Webb > > Cofounder / Security Engineer > > HardenedBSD > > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org" _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"