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"

Reply via email to