Using srcpac this way is something that a naive user could easily do without understanding the consequences, and we're talking about users who who wouldn't dream of downloading a random tarball off the web and compiling it for fear of security/software quality issues. So I think that we must be careful.
I know I've already given my opinion in the bug report, but I'll reiterate here: I understand that malicious PKGBUILD files can be created, and that in that case, something can go terribly wrong. However, the whole "protecting a user from themselves" goes directly against the Arch philosophy... a user should be competent enough to figure things out for their own.
Yes, but making it easy for someone to get into an unfortunate situation via a common usage pattern is not what Arch is about.
That said, I'm also of the opinion that the AUR should verify PKGBUILDs... when I first heard the idea of the AUR, I thought that it would include some checking (ala namcap) to verify a PKGBUILD. I don't know if namcap is used on an upload or not - but I feel it should be done, and that namcap can be extended to check for certain attacks... yes, this won't cover everything, but pacman should deal with the rest (i.e. the worst someone can do is overwrite some system files... in which case pacman would require a "force").
It becomes very difficult to do this with any degree of guaranteed benefit. Consider that srcpac -S must be run as root. Then consider that any command in the PKGBUILD ends up getting run as root. So if my build() function contains "rm -rf /" then there goes your hard drive.
Supposing, like you say, I have some checks for nasty things in place. So then suppose I ship an additional script in my tarball that cleverly builds the string "rm -rf /" and assembles it and executes it, so it's impossible to check for its existence. Now I call it from the PKGBUILD. It's all too easy.
Does anyone have any ideas on how to make this safer? It wouldn't seem like a good idea in general for packages to be getting built as root in srcpac, so fixing this more generic problem is maybe a good idea. For one, could there be a way to run the whole srcpac makepkg process in a chroot jail?
I don't mean to sound particularly negative here. It's clear that many careful users would benefit greatly from being able to browse a package in unsupported, inspect it carefully themselves, and then just do a "srcpac -S <package>" and have it appear on their system. It's just that we're not there yet on making it safe enough, I don't think.
- P
Anyway, namcap can be extended to check for "allowable" build programs... i.e. cp/rm/install/make/python/perl/etc - in addition, seeing you suggested it, srcpac can be adjusted to spit out the contents of the build() function saying "run this build script?"
it's a bunch of simple fixes to make it "safe for kiddies" - however, I don't think that's a good idea....
_______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
-- Paul Mattal, Computer Scientist [EMAIL PROTECTED]
Information contained in this e-mail transmission is confidential and may be protected by attorney-client or attorney work product privilege. If you are not the intended recipient, please do not distribute or reproduce this transmission. If you have received this e-mail transmission in error, please call 617-621-3100 x102.
Elysium Digital, L.L.C. http://www.elys.com
_______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
