131–137 of 137 posts
Earlier quoted context omitted.
My understanding is some things (e.g. Google Chrome, Google and Microsoft fonts) can't be put in the main Arch Linux repos for copyright reasons.
Chromium and Google's Roboto and Noto fonts are all in the official repos.
Anything proprietary can't simply be copied over and mirrored for copyright reasons.
Earlier quoted context omitted.
No, AUR packages are PKGBUILD files, which are essentially little batch scripts that run inside a fakeroot. IMHO, the danger of a PKGBUILD itself doing something nasty is small--it would be limited to things like recording `uname -a`, listing all your installed packages: the things mentioned in the article. The real danger is that the PKGBUILD is installing some software, which you will later run with full user privi…
The PKBUILD runs in the fakeroot, but AFAIK the .install files (postinstall hooks etc) run on the host system directly, with root permission. Definitely something you will always want to review. (Also, I don't really get the critique of tools like yaourt, since they make it easy to inspect the PKGBUILD and - if present - install files. The tool simplifies downloading, you still need to review yourself!)
But, yeah, they run as root, so they could still do something nasty at install time. Not when you `makepkg` the PKGBUILD, though.
Earlier quoted context omitted.
AUR PKGBUILDs are much more restricted than this, since they're restricted to a fakeroot. Of course, if you're ultimately going to run the program, the binary set up by the PKGBUILD has a lot of control. But the PKGBUILD itself is limited in what it can do (to things like listing your installed packages, getting `uname -a`--the stuff mentioned in the article).
No. Whatever you stick in the install= file will run as root at install time. If you're using an AUR helper/running `makepkg -i`, the PKGBUILD absolutely can run code as root, without waiting for you to interact with the installed program. Installing a package from a PKGBUILD is no more or no less "powerful" to an attacker than `make && sudo make install`.
But, yeah, they run as root, so they can still do damage.
My point was that the danger zone is when you trust the package, rather than when you run the PKGBUILD itself with `makepkg`. Of course `makepkg -i` runs both `makepkg` and `pacman` as root.
This is exactly what we've been preparing for. Don't use yaourt, and read those diffs. I know a lot of people don't do this, but it's important.
Even yaourt defaults to prompting you to read all the packages scripts and displays a red WARNING UNSAFE when the package is unmaintained as this one was. It has options to configure it to do everything automatically, but you have to actively go in and set it so.
Earlier quoted context omitted.
> Though the software is at fault. It created a false sense of security, misleading the users. What else in Arch just feels secure, but in fact is not? AUR never tried to pass false sense of security, it is explicitly declared as not supported everywhere. > And then, if the users around the software generally exhibit a jockey attitude, you get the whole environment built in a similar manner, not a robust one. The sof…
> AUR never tried to pass false sense of security, it is explicitly declared as not supported everywhere. Funny that I only ever hear of this when talking about security aspects, not when discussing available software. In the latter case I always hear how many things are there in AUR, especially comparing to Debian. AUR must have failed miserably in not trying to pass false sense of security.
One argument does not invalidate the other. It is true that tons of software are available in AUR that is not easily available in other distros. It is also true that AUR is not supported.
A similar thing happens with PPAs in Ubuntu or even with Flatpak/Snaps: they brings tons of additional software to the distro, however they're unsupported and can be security nightmares [1].
[1]:Yeah, even when Flatpak/Snaps are properly sandbox (since some apps are not), they can include software to mine cryptocurrencies for example.
Earlier quoted context omitted.
What packages would you like to se inn our repositories?
Imho, especially things that are important solutions to common things on the Archwiki but are AUR, indicated with the AUR superscript there. For example for MTP: https://wiki.archlinux.org/index.php/Media_Transfer_Protocol The one that worked most stable for me was simple-mtpfs, but it's AUR. It happens with other archwiki topics too, I encounter it regularly though can't think of good examples from the top of my hea…
Honestly, MTP is terrible on every OS though. Mac and Windows have it a _lot_ worse for interacting with MTP devices.
Earlier quoted context omitted.
What would you recommend over yaourt?
#!/bin/bash set -e if [ -z "$1" ]; then echo "No package name specified."; exit; fi mkdir -p $1 cd $1 wget -q " https://aur.archlinux.org/cgit/aur.git/snapshot/$1.tar.gz" tar xzf $1.tar.gz cd $1 makepkg -sf read -n 1 -s -p "Press any key to continue..." echo -e "\n" sudo pacman -U --noconfirm --needed $1*pkg.tar.xz