thanks four you effort.

I think no one complains about SBo and Slackware. This should be clear, to avoid drifting in unwanted directions with this thread.
the build not as root, and in my and possible from other cases, do not write & test new build scripts as root, is more a general question thing.
There are different opinions, thats ok, and there is no reason why not both can be satisfied, and no one should be forced to do certain tasks as root if he/she does not want to.

I can't seem to find it right now, but there's a great article by security guru Bruce Schneier about trust in computing. In a nutshell, we all have different levels of trust in our life. When I call a plumber because my bathtub has a problem, I'll let him into my appartment because I don't expect him to murder us (even if the odd serial killer has been a plumber). All folks in our life have respective trust levels. My girlfriend has my credit card code and I have hers, and we don't expect each other to empty the other's bank account and flee to South America (though similar things have been know to happen). I trust my climbing partner with my life (and so does he), even though accidents have been know to happen. You get the idea. And I'll happily continue to use SBo (and sbopkg), even though the odd package has been known to spam the system. I'll just avoid to test new scripts on production servers.

The good folks at SBO may not be perfect, but judging from the mailing list, I'm sure they work very hard to do their best.

4 members found this post helpful.

Well... It wouldn't be the case if sudo was used in place of su, there's a "session timeout", and you only have to enter the password once.

I'm not really into sudo for my day to day, handwritten commands (I'd rather use su and be interactive as root), but for "safe scripts" that requires elevation just for one thing or two, and generally for automations, sudo can be very useful.

Cheers.

Garry.

The password prompt allows me to check the build log and the contents of /tmp/SBo/package-xxxxxx before running makepkg.

Cheers

You are welcome, for my tiny contribution.

fakeroot is actually smarter than that (and a lot smarter than my script!). You can chmod a file to be owned by any user or group. Of course the ownership would not really change but all utils running under the fakeroot environment will act as it they did. this means you can tar up a package with a variety of ownership, e.g.:

In summary you would be better off checking for the presence of fakeroot and optionally using that. My script can only change ownership to root, nothing else. Handy for 95% of cases but not good enough for every case. This is why my script has the possibility to disable conversion to root. In those 5% of cases I switch the option off and use fakeroot instead.

1 members found this post helpful.

You are right, we all have to have trust in other persons in many ways in our life, I totally get that. Trust is fine (though I guess that you don't just trust your climbing partner, but also have made sure that he knows the necessary safety protocols and procedures, since he is part of your safety system), but, as you say, accidents can and will happen. Acknowledging that and saying "hey, it is totally possible that we may have made a mistake, so please always make sure that you have all safeguards in place when working with our scripts, here is how you do it ..." increases trust in someone a 1000% more than saying "hey, if you don't trust us go away".

3 members found this post helpful.

Aha. Yes, thanks, I hadn't appreciated the subtlety of running everything in a single fakeroot invocation... which means that, for slackrepo, it all Just Works already!

(Specifically, when slackrepo is not EUID 0, each SlackBuild is invoked by fakeroot, and $PATH is set so your script is found instead of /sbin/makepkg, and every decent SlackBuild specifies makepkg -c n, so it's copacetic)

(Yes, this is one of those packages that needs a bit more QA)

Much as I would like to promote my own work, I don't think you need my script at all. If a Slackbuild is running under fakeroot then (the original) makepkg will be as well and in turn tar, so everything should just work. I think my script is entirely redundant to your use case.

Well I just have to post a response. It's been a long time and I am a Slackware user, still a Newbie and I can't find another distro I like to even give it much of a try although I will confess I do have an old laptop, Gateway 500 MB ram, 40 Gb HD which has Blag on it and that was purely to start looking at systemd utilities.

However, my history with distro is quite one sided. I first pulled out a disk at the back of a magazine with Red Hat 5.2 and tried to install it on an old 486 I cobbled together. It took a while and finally it worked but I really had to monkey around with it. A couple of weeks later I found Slackware, downloaded the disks and installed without any issues. Since that time I have never really looked back. I did take a look at Debian about 7 years ago and I also took a look at Ubuntu about the same time however I was just never really interested.

In the past year, I have tried a number of distros, Fedora, Ubuntu, Debian, CentOS, etc. My first point of contention was with Ubuntu. When I install a new distro and find myself having to spending 15 minutes or so trying to figure out where the command line is, I am immediately put off. I think it was ubuntu LTE 14.01. It's all icons. It looks like a Google or yahoo login page to me. The second point of contention was seeing icons for corporate logos,.. a big no no for myself. When an operating system loads I am not interested in advertising, similarly when a browser loads I am not interested in advertising but thats just me, which explains why I still use Lynx as browser. The third point of contention is that these sysetms load GUI's automatically and I don't recall being given the option to not load them, although I'm sure that could be arranged. I found the same problems with Fedora. I've yet to properly vet Debian and CentOS and I'm thinking of loading much older versions on non networked laptops. I'm currently very interested in the new Debian Fork without systemd.

I installed Blag on an old laptop and I did not have to configure very much of anything. It's strictly for learning purposes and so far I like it, which means Fedora should be a shoe in but it was so slow I could barely get it to work. Fedora 21 that is.

I understand everyone has their preferences and that's great. I still consider myself as someone with a lot of learning to do, but I've been learning since the early 80's. I like the consistency principle. I still have an old Macintosh 605 Quadra in the basement which I used for programming when at school from 1994. It still works, 4Mb of ram and 60 Mb hardrive. I still have all my assembly, c, pascal and Fortran programs on there. I still have the NCSA Mosaic web browser on there. That machine, despite it being risc architecture, is still very much compatible, UI wise, to the current apple pc's which have of course changed architectures. I love that machine. Its not an nix machine but it works great. It has a modem and I would dial in to my university account and write programs, hand in assignments etc and our accounts were of course on a unix mainframe. I had proprietary Symantec Lightspeed Think Pascal and C (for Macintosh), and university gave us versions for assembly and fortran(for Macintosh), but the mainframe for Lisp and others and I always liked the mainframe experience which is now the home pc experience. A girlfriend of mine who switched out of computer science told me, stick to unix, the future of all computing will be based on it. That was in the 80's she said that. I have since learned that lesson the hard way.


I use Slackware for its simplicity and for the learning curve based on old principles. Its first appeal to me was that I could write c programs without having to purchase proprietary software. I just wanted to practice those skills. I do however like the direction that Ubuntu is taking in terms of their pad and phone direction but if their OS is going to look like groups of touchy icons and corporate logo-ing, then I will not venture that way. I will stick to Slackware and hope they keep the system V init scripts. Slackware has always been there for me which seems to support the ideas of computing, the science of it, at the heart. I'm sure there other distros out there, but like anything else time is an enduring personal investment.

1 members found this post helpful.

I tip my hat to you, sir. Well said.

/usr/share versus /usr/local/share. In fact the entire /usr hierarchy can be replicated under /usr/local. For configuration files you also have /usr/local/etc. However that last one might be trickier in that I wouldn't be at all surprised to find software that will not look there and has /etc hard coded. So it could be a problem if you installed a different version of a software that is already installed and managed by dpkg under /usr and you need the configuration to remain distinct for your locally compiled version under /usr/local.

http://www.pathname.com/fhs/pub/fhs-...LOCALHIERARCHY

1 members found this post helpful.

Sure you have to have some level of trust but you don't have to give extra trust when it is unneeded. I have left plumber working in my house with me not present. But I did hide and lock away some valuables. And I certainly didn't first take out all my savings from the bank and scatter the notes around my apartment before I let him in.

Yes, you have to give trust but that trust does not (and should not) be absolute, in every single case. You can give as much as is needed and there is nothing wrong with taking precautions.

I also have no doubt they "do their best" but nobody is perfect.

This one Niki?

https://www.schneier.com/news/archiv...ier_on_tr.html

1 members found this post helpful.

It doesn't seem that Bruce says anything that invalidates any of TobiSGD's points. Quite the opposite in fact,

Not requiring the user to build packages as root, helps to facilitate trust because it is an extra layer of security during the building and packaging process, to help prevent mistakes.

I know I feel safer trusting those who do not require me to utilise riskier methods.

1 members found this post helpful.

You people are slowly converting me I feel exactly that way about systemd...

However, it is worth quoting the whole of SBo FAQ 11 (which is what started this discussion):

So "don't bother whining" only applies to "security issues"/"malicious activity", and this sentence comes immediately after another sentence that actually tells you one way of running the damn thing as a user. This is a long, long way from requiring SBo users to use riskier methods. In my opinion, ivandi's selective quoting of SBo FAQ 11 in post#83 is highly misleading and unfair. I hope this restores everybody's trust in SBo.

[Footnote: it is worth reminding everyone that the "security issues"/"malicious activity" problem is de minimis, because sooner or later you are going to install the built package as root. Cockups, however, are a different matter, and I have already gone beyond mere agreement on that point with actual code that people can use. If your favourite tool or workflow doesn't do what you want, you need to "be the change that you want to see in the world".]

3 members found this post helpful.