> The issue here is, essentially, whether or not (or to what extent) there > should be cvsup access (right along with abs) to the unsupported portion > of the AUR. This, among other things, opens up the possibility for a > user to relatively easily compile and install packages from the AUR > using srcpac. > > The major issues at play here are that srcpac -S must be run as root, so > a malicious PKGBUILD on the AUR could wipe out someone's system. > However, the ability to use srcpac on AUR packages brings a bsd > ports-like easiness to the currently mildly complicated process of > building a package from the AUR.
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. 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"). 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
