Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
enable --preview by default #8
Since this fork seems to be better maintained than the upstream packer, you might be interested in the following.
Packer/apacman currently source PKGBUILDs before the user has a chance to view it, unless the --preview option is passed on. This is an important security flaw in the original design that can be fixed by enabling the --preview option by default or making it mandatory.
On the longer term, you might want to rework PKGBUILD parsing to enhance apacman usability while still ensuring security.
While I agree sourcing unverified PKGBUILDs is a potential problem, parsing the contents manually runs the risk of dealing with a never-ending stream malformed edge cases.
Regarding a mandatory preview, hand-holding users is not a good practice. Flags can be set in the
I don't mean to sound elitist but ArchLinux is not a distro for novices. The lack of a review process is why the AUR is not officially supported by ArchLinux, which is a shame because its the distro's greatest asset IMO. A reminder of the official policy regarding AUR packages:
I'd also like to add that
Finally I was tempted to mark this as wontfix but instead, I'll call for a vote on
I understand this and fully agree with this statement, but this issue goes well beyond "spoon feeding" users imho. This security flaw simply defeats the purpose of reviewing PKGBUILD by the user, and in the current state, not using --preview is the very same as never checking PKGBUILD.
Note I'm glad someone finally stepped over to maintain the good old packer, but I wouldn't recommend apacman as a good helper alternative as long as this isn't fixed.
So you have your own very prominent AUR helper
I made some progress towards this issue in apacman v1.5 (344849b). These changes are enabled with
I'd appreciate if you would look over what I have so far - I'm sure it will break for a number of special package types: split PKGBUILDs, conditional arrays, etc. Ultimately will need to either account for all conceivable edge cases or use a dedicated parser.
Pacaur is kinda irrelevant here. I'm more interested in signaling a security issue that isn't well known by packer/apacman userbase.
The new option is a good step, and yes it will likely break with all kind of bashism. You might want to check yaourt code too, since it does some tricks to avoid sourcing PKGBUILD directly with more or less success.
The way I solved this issue in pacaur is by using the AUR RPC interface instead of sourcing for dependency information. Unfortunately, implementing the same in apacman would probably means throwing away a big part of the code and starting from scratch, especially for better split packages support.