> > 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?
That means you'd have to set up a chroot jail for every package you wanted to build (or keep it across a single incarnation of srcpac, but not across multiple srcpacs). That also means that srcpac would *have* to be run as root. One of the nice things about makepkg itself is that it doesn't have to be run as root. srcpac does support the -w feature, which is build but not install. In that way, you could build the package as a non-root user, as long as you first ran srcpac -Sy as root (to update the abs tree to the most recent version). You'd just have to be able to tell srcpac to put the built package somewhere other than /var/cache/pkg. Now that I think about it, I could check to see if the user is non-root and put the built package in the cwd. > 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. I think that we've got one set of tools that do one thing and another set of tools that do something else and we're saying, "gee, it'd be really nice if I could mash these sets of tools together and get something out of it". What we really need is a way to get recent versions of packages in unsupported and build them without putting the whole system at risk. Something similar to abs and srcpac, not necessarily abs and srcpac. I also mentioned this in the bug report, srcpac won't work without a full pacman repo behind it. srcpac uses pacman to resolve dependencies and find updates. Without pacman telling it what to do it'll never notice that your version of xyz is different from the PKGBUILD you have on your system. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
