pacaur - an AUR helper that minimizes user interaction

X-dark · 2012-12-18 10:46:47

If you only want to update your AUR packages and not those from the official repos, "pacaur -Sua" would be the way to go.

Airon90 · 2012-12-28 15:58:01

Hi you all,
I just installled pacaur and I'd just want to know if there is an option in order not to edit PKGBUILD everytime I want to install a package.
Thank you very much!

Spyhawk · 2012-12-29 09:09:58

Yes, there is. See man pacaur.

Airon90 · 2012-12-29 11:29:24

Ok, I have to use --noedit option. Is there a configuration file in order to automatically "add" this option?
Thank you very much!

Spyhawk · 2012-12-29 12:21:54

So you really don't want to read the manual, don't you?

Airon90 · 2012-12-29 12:55:47

I'm sorry but I didn't read the last section. I thought the man ended just before it
Thank you very much!

Spyhawk · 2013-01-10 15:14:18

Today's new release (v3.3.0) does not bring any new feature. Instead, it takes care of a very overlooked issue: security.

As you might know it, malicious code introduced into a PKGBUILD or its install scripts can make serious damage to your install. That is why is it always recommended to look at a PKGBUILD before compiling it with makepkg.

This being said, most AUR helpers available today implement a complete, efficient dependency solver that does all the job for you. There are basically two way of solving dependencies:
- by sourcing the PKGBUILDs (execute its whole content to read all of its content at once) to retrieve the depends and makedepends arrays, or
- by manually parsing the PKGBUILDs (reading little part of it at a time) to retrieve the depends and makedepends arrays.

The first method is obviously much more dangerous, as a malicious sudo command could be executed if sudo has no timed out at the moment the PKGBUILD is executed. The second method is much more secure, but its drawback is that many PKGBUILDs use bashism (such as executing the $CARCH variable to find out what is the current architecture) - PKGBUILDs are bash scripts meant to be executed after all. Those will in most case not being able to be read correctly by a manual parser, and your AUR helper will fail miserably. This is the case of the internal solver of cower, which succeed in most case but doesn't support bashism.

In short:
- sourcing: efficient, but might be dangerous
- manual parsing: secured, but fall short on a number of case

And as you might not know it, most AUR helper available today use the first method, and some do source the PKGBUILDs automatically before asking you to view it. And so were all pacaur 3.x releases until today. What happened is that early release were using the internal dependency of cower, and I implemented a full bash solver to overcome its parsing limitations (this was called "carchmagic" compatibility). After some technical improvement, this solver was turned on by default in pacaur 3.0.0, and the access to cower internal solver was removed in release 3.2.0.

Today, release 3.3.0 reintroduce the usage of cower internal solver as an option you can enable in the config file (secure=true). The usage of the full bash solver (secure=false) is still possible and proposed by default, with some improvement: an automatic check will notify you of a possible malicious sudo code ("sudo" characters that are not in the "depends" array) and prompt you to view the PKGBUILD before sourcing. In addition, many portion of code have been replaced by more secure code.

I'm open to any suggestion and remark concerning the security aspect of pacaur. Also, please report any regression, as always

*I guess the only truly secure way would be to implement a chroot feature, like the one that Arch developers use to compile binary packages, but this is far from the objective of this little project.

Last edited by Spyhawk (2017-12-02 18:15:04)

peets · 2013-01-10 21:46:18

Just updated; pacman-color is expected by default, and I can't turn it off:

$ cat /etc/xdg/pacaur/pacaur.conf 
#!/bin/bash

#
# /etc/xdg/pacaur/pacaur.conf
#

# The following options are commented out with their default values listed.
# If you wish to use different values, uncomment and update the values.
#builddir="${BUILDDIR:-$tmpdir}"       # build directory
#editor="${EDITOR:-vi}"                # PKGBUILD editor
#editpkgbuild=true                     # edit PKGBUILD script
#editinstall=true                      # edit install script
#fallback=true                         # pacman fallback to the AUR
#clean=true                            # clean up after package install
#cleandevel=true                       # clean up devel package
color=false                           # color support via pacman-color
#secure=false                          # enhanced security
$ pacaur -Q
:: The binary pacman-color is not installed.
Check configuration in /etc/xdg/pacaur/pacaur.conf
$

Spyhawk · 2013-01-11 05:37:50

Thanks, fixed in 3.3.1 3.3.2.

This was caused by the powerpill support. I removed it in the meantime, and I'll readd it later.

Last edited by Spyhawk (2013-01-11 05:50:10)

fosskers · 2013-01-11 11:29:49

Spyhawk, I actually just started rewriting my Bash parser this afternoon, but $CARCH is ever-present, looming on the horizon. How did you get that figured out?

Spyhawk · 2013-01-11 11:39:00

fosskers> What do you mean exactly? Pacaur originally used cower's internal parser, which showed some limitation over time. That is the reason I developed a full bash parser in parallel, more efficient but also less secure (sourcing PKGBUILDs). The recent release aims at improving security of this full parser.

fosskers · 2013-01-11 12:26:20

Ah, maybe I was getting ahead of myself thinking that you had solved this problem:

[ "$CARCH" = "i686"   ] && depends=('apr-util' 'gtk2' 'libgl' 'libidn' 'libjpeg-turbo' 'mesa' 'nss' 'sdl' 'glu' 'pangox-compat' 'libxml2')

My new parser will handle this line fine, but it's the $CARCH I'm worried about. Where does that come from?

Last edited by fosskers (2013-01-11 12:28:01)

tdy · 2013-01-11 16:15:22

fosskers wrote:

it's the $CARCH I'm worried about. Where does that come from?

sourced from makepkg.conf

fosskers · 2013-01-12 00:14:08

Hot damn, time to parse that!

Spyhawk · 2013-01-22 12:10:29

v.3.4.0 released, with some important changes:
- the config file moved from /etc/xdg/pacaur/pacaur.conf to /etc/xdg/pacaur/config
- "powerpill" support readded. Simply define the $PACMAN env variable and pacaur will use it.
- the prompt now show download and install size of binary dependencies.
- a couple of bugfixes. See the Changelog for details.

Last edited by Spyhawk (2013-01-22 12:11:01)

Spyhawk · 2013-02-25 12:34:59

Hi there,

Pacaur v4.0.0 will be the next release. As the version number implies, there are a number of important changes (see changelog).

For the user, the most prominent features are:

The main interface is now much more similar to pacman output
A new, optional detailed interface that can be enabled with the VerbosePkgLists variable in pacman.conf
A new option in config file to automatically update the sudo timestamp (sudoloop)
Internationalization support

If you would like to translate pacaur in your native language, read the provided instruction and send me a pull request on GitHub.

And if you feel as a guinea pig, be sure to install pacaur-git. Current git version is 3.4.7.74, and all known regressions have been fixed so far. Any comment welcome!
Further work will focus on tracking additional regression, and improving --devel compatibility with the new VCS scheme of the upcoming pacman 4.1.

Also, from this day I will not backport anymore any bugfix to the 3.4.x branch (which is pretty stable, so you are all very lucky )

Last edited by Spyhawk (2013-02-25 13:51:11)

gbj13 · 2013-03-04 17:53:38

After updating pacman today I get the following errior

cower: error while loading shared libraries: libarchive.so.12: cannot open shared object file: No such file or directory

Does anyone know of a fix?

Spyhawk · 2013-03-04 18:16:24

Yes. Libarchive got a soname bump, so cower needs to be recompiled (see comments on the cower aur page).

"pacaur --fixbackend" will do that for you automatically.

drcouzelis · 2013-03-04 20:45:16

Spyhawk wrote:

"pacaur --fixbackend" will do that for you automatically.

Woah. WOAH. And here I went and rebuilt cower manually like a neanderthal.

pacaur is pretty amazing.

markoer · 2013-03-04 21:20:44

@Spyhwak:

1. I can't see support for customizepkg
2. why do you prefer pacman-color for colored output, there is no need for two same binary in path which diffier only but parsing colors. It would be better to implement your own colors in addictional script which will be readed if color var in XDG config is true or false and upon that include script or just ignore it.
3. ability to fetch PKGBUILD in arbitrary location. Cower by itelsf can do this by specifing -t as destination, pacaur uses -m as flag but it's destination is staticaly defined. Impement $3 argument as dst parameter. If $3 is not defined fetch it in current dir and pass info to stdout in both cases, with info user can see if fetching was succesfull or not.

thx for pacaur

Spyhawk · 2013-03-04 22:31:46

drcouzelis> Good that you can handle the neanderthal way, it will save you in many cases. The --fixbackend option is only for lazy people (like me) that think compiling cower manually every 6 or 12 months is too much
Edit: Oh, and "--allanbrokeit" is an unofficial alias for this option

markoer>
1/ Customizepkg support will not be implemented (see the reason here and here).
2/ Because I'm a lazy guy. Color support is coming to pacman. Might be too late for pacman 4.1, but will be in 4.2 almost certainly. Until then, pacaur will rely on pacman-color. But feel free to provide a color script patch in the meantime, that would be warmly welcome!
3/ Is that really necessary? The build directory can be defined in the config file. Beside this, I don't understand the need to build package in various locations. And if you need to download a PKGBUILD in a certain location (which can happen), well.. just use cower. It is already installed on your system

Last edited by Spyhawk (2013-03-04 22:35:44)

Spyhawk · 2013-03-08 15:30:57

Pacaur v4.0.0 is now live. Enable the detailed interface with the VerbosePkgLists option in pacman.conf. As always, regression/bug reports are warmly welcome :]
New included languages are French (by spider-mario), German (by BigBoot) and Japanese (by fosskers). Thanks to them!

Supplantr · 2013-03-09 03:26:48

pacaur -k seems to be not working, producing this error:

expac: invalid option -- '>'
:: aur  ::                       ->  
:: aur  chromium-pepper-flash-stable    ->  
:: aur  11.6.602.171-2           ->  
:: aur  ->                                  ->  
:: aur  11.6.602.171-3           ->

Upgrading the package via pacaur -Syu worked fine.

Sirsurthur · 2013-03-09 08:38:41

Spyhawk : pacaur v4.0.0 is great ! In the french translation, they are some blanks in double like here : "Poursuivre[blank][blank]l'installation? [O/n]"

[EDIT] : in french translation, line 780 (pacaur:780), there is a missing blank before msgstr "[missing blank]il n'y a rien à faire"

Last edited by Sirsurthur (2013-03-09 10:23:35)

Spyhawk · 2013-03-09 11:02:14

Thanks to both of you. The broken -k option and the double space issue in French language should be fixed in 4.0.1 (that one was due to non breaking space characters that are encoded on 2 bits in UTF-8 - I replaced them with normal space characters). I also fixed a third bug (possible reinstall check false positive issue when dealing with conflicting packages).

Sirsurthur> I read your edited message a bit too late, but I'll fix that missing space in the soon-to-be-released 4.0.2 release

Last edited by Spyhawk (2013-03-09 11:09:32)

Arch Linux

#301 2012-12-18 10:46:47

Re: pacaur - an AUR helper that minimizes user interaction

#302 2012-12-28 15:58:01

Re: pacaur - an AUR helper that minimizes user interaction

#303 2012-12-29 09:09:58

Re: pacaur - an AUR helper that minimizes user interaction

#304 2012-12-29 11:29:24

Re: pacaur - an AUR helper that minimizes user interaction

#305 2012-12-29 12:21:54

Re: pacaur - an AUR helper that minimizes user interaction

#306 2012-12-29 12:55:47

Re: pacaur - an AUR helper that minimizes user interaction

#307 2013-01-10 15:14:18

Re: pacaur - an AUR helper that minimizes user interaction

#308 2013-01-10 21:46:18

Re: pacaur - an AUR helper that minimizes user interaction

#309 2013-01-11 05:37:50

Re: pacaur - an AUR helper that minimizes user interaction

#310 2013-01-11 11:29:49

Re: pacaur - an AUR helper that minimizes user interaction

#311 2013-01-11 11:39:00

Re: pacaur - an AUR helper that minimizes user interaction

#312 2013-01-11 12:26:20

Re: pacaur - an AUR helper that minimizes user interaction

#313 2013-01-11 16:15:22

Re: pacaur - an AUR helper that minimizes user interaction

#314 2013-01-12 00:14:08

Re: pacaur - an AUR helper that minimizes user interaction

#315 2013-01-22 12:10:29

Re: pacaur - an AUR helper that minimizes user interaction

#316 2013-02-25 12:34:59

Re: pacaur - an AUR helper that minimizes user interaction

#317 2013-03-04 17:53:38

Re: pacaur - an AUR helper that minimizes user interaction

#318 2013-03-04 18:16:24

Re: pacaur - an AUR helper that minimizes user interaction

#319 2013-03-04 20:45:16

Re: pacaur - an AUR helper that minimizes user interaction

#320 2013-03-04 21:20:44

Re: pacaur - an AUR helper that minimizes user interaction

#321 2013-03-04 22:31:46

Re: pacaur - an AUR helper that minimizes user interaction

#322 2013-03-08 15:30:57

Re: pacaur - an AUR helper that minimizes user interaction

#323 2013-03-09 03:26:48

Re: pacaur - an AUR helper that minimizes user interaction

#324 2013-03-09 08:38:41

Re: pacaur - an AUR helper that minimizes user interaction

#325 2013-03-09 11:02:14

Re: pacaur - an AUR helper that minimizes user interaction

Board footer