It would have been a car with a funny walk ...

I agree that the advice from SBo , and possible others, to run slackbuilds as root is very properly problematic and needs to be rethought.
but with a look at FAQ 11, I have heavily doubts that this happens.

using fakeroot the package developer would have noticed the /usr/share/zarfy problem on his machine

I also do not like to run sbopkg, because it builds as root.
this is not good, it is wrong, it should only install as root and build as user using fakeroot.

I often wonder about Slackware people, arguing security , knowing their system, .. and then run buildscripts as root
and its not that I mean do not trust, I mean that problems happen, bugs exist, things can go wrong..., therefore it is conceptionally a very bad thing to run build scripts as root.

did you contact the maintainer or at least post at the SBo mailing lists about the problems you had?

These are problems that hit every distribution at some point. I have yet to see a distribution that does not install kernel sources into /usr/src, with /usr/src owned by root, so that you have to built a kernel as root, unless you change the ownerships manually, though building a kernel as root is strongly discouraged by kernel developers.

You're absolutely right. Running slackbuilds as root on your live systems isn't the best idea. However, there are mitigation approaches:

One is having a VM set aside for building your packages whose filesystem gets reset after each build, and I suspect folks like Eric who build a lot of stuff will probably do something like that.


Alternatively, but a little more work, I run my buildscripts as 'build'. I only use the slackbuilds as a reference when writing them. I have a wrapper around 'makepkg' I named 'buildpkg': it does all the man-page handling, stripping of binaries, and other bits that are common to most slackbuilds, and then runs makepkg. Instead of running 'makepkg' my buildscript calls 'buildpkg' which raises its own permissions via sudo.

"But, what about things that need special permissions/actions that only root can do?" I hear you ask. Well, I comment them out of the makefiles and I defer them to the doinst.sh that gets run at install time, but very few packages need anything like this; most just build as is.

it is also known that it is not good to focus on one special exception, or may there be 2, and generalize/apply therefore problematic behaviour to all components i a system.

and no, most distributions do not require you to be root for building packages, in fact they point to the fact that you should not be root for building packages.

You can build a kernel as a non-root user even with /usr/src owned by root and readonly. The make O= option is there for that and it's what I do. Just make sure you install pristine src (make mrproper'd) and keep it that way. I wish all distro would start doing this (slackware included).

Nope. Didn't have time to follow the entire bug reporting process.

And this
doesn't encourage users to report bugs anyway.


Cheers

So you have enough time to post in this thread your complaints about the quality of the SlackBuilds that you use, but not enough to help volunteers enhance that quality? Why don't you just make all the work yourself then?

I fail to see why.

Cheers

Because it basically says: We don't make mistakes. Never!

No, it just says: we carefully checked that there will be no security issues triggered by SlackBuild's execution.

Of course a wrongdoing of the SlackBuild stays possible, but I've never heard of such a case for a SlackBuild provided by http://slackbuilds.org, and the user is allowed to check the SlackBuild before running it.

Then something can go wrong and a security issue appear after installation of the package.

But then, the user is not prevented to make a last check, just examining the package's content (including possibly nasty doinst.sh) before installing it.

What about the users that use Slackbuilds (possibly with sbopkg), but aren't able (possibly because they don't know about scripting and the pitfalls) to spot those mistakes that possibly shoot down your whole system. When this happens (and we all are human, so this is a when, not an if) do you tell them "Hey, you should have checked that!"?
The question is: When it is possible to build packages as unprivileged user, why build as root and why downplaying the potential consequences with statements like the one quoted above?

When you build a package with a Slackbuild script from SBo, the package is built in /tmp/SBo and the final package is stored in /tmp. There is no risk until you install the package, which requires root privileges. Having root privileges when building the package is necessary for some Slackbuilds e.g ffmpeg

oh, come on man!

Fixed that for you.