11 ms·

The Arch User Repository hosts whatever people want to upload to it, with basically no proactive vetting whatsoever. In addition, the installation scripts run a

The Arch User Repository hosts whatever people want to upload to it, with basically no proactive vetting whatsoever. In addition, the installation scripts run arbitrary code, a portion of which must run with root privileges. When a package gets orphaned, that means that anybody in the community can take over maintainership of the package. There's a whole lot of trust that has to go on when installing a package from the AUR - and yes, this is a fundamental problem with the security model of Arch Linux, but that's been known for a very long time. Honestly, I'd be surprised if this hasn't happened before with orphaned packages.

dozzie 8y ago
The thing is not that it's a new deficiency or something, it's just that Arch user conveniently ignore this when praising their distribution over e.g. Debian.
- dvfjsdhgfv 8y ago
  Fortunately admins are not unreasonable and don't base their decisions on praises but on actual merits, so most servers run Debian rather than Arch (which is an interesting distro for other usage cases).
  - farresito 8y ago
    Who would want to use a rolling release distribution for a (production) server? Sounds like a pretty terrible choice, to be quite honest.
    - cmiles74 8y ago
      Maybe you could make the case for some cutting edge development or test box, but then again, I'd rather be testing on something that's as close to identical to the production environment as possible. I used Arch on my laptop (primarily used for development) for several years. It mostly worked great and I always had access to the newest whatever with a minimum of hassle. I don't have many complaints, but occasionally after an update something critical would stop working. I'm on Solus now and, so far, it's been pretty great. :-)
    - Foxboron 8y ago
      All of the Arch Linux infrastructure is run on Arch. Works pretty well.
      - JackCh 8y ago
        There is an expectation that projects dogfood their own software, but I really can't think of a rational reason for a production server not affiliated with the Arch project to be running Arch. Rolling release is great for technically competent users to install on their workstations, but why would you ever want a rolling release on a production server?
        Foxboron 8y ago
        You wouldn't. The only reason why we run it is because we know it. I wouldn't have used Arch on any production things personally.
        semi-extrinsic 8y ago
        Well, one thing which I know of several projects doing, is having an Arch server as one of the continuous testing servers. This way you can test against bleeding edge gcc/glibc/whatnot and catch bugs or breaking API changes long before they appear in major distros.
    - walrus01 8y ago
      Nobody that values their job or sleeping well at night. It's basically one level of nuts above and beyond running Debian Sid on all your production servers.
      - hultner 8y ago
        I ran SID in a embedded customer box testing unreleased software, I did run it in KVM from a stable release since I wouldn’t have physical access if something went wrong, glad I did.
- mateuszf 8y ago
  AUR repository isn't supported by the core tools and packages. To use it one has to install external scripts. So it's by no means part of the system.
  - mar77i 8y ago
    Urm, you need git, you need build tools... and pacman. That's it. But oh yeah, because I do these things by hand and check whether the source urls point to the place I'd actually like to install (and other code doesn't download external sources, eg. in the PKGBUILD or external scripts like *.install files), I'm suddenly an exception. I just noticed that the blue used on the Archlinux logo is actually quite consistent with Rick's hair color. https://i.imgur.com/kkE25w2.jpg https://i.imgur.com/kkE25w2.jpg Fits me. I don't give a damn.
    - Foxboron 8y ago
      I'll assure you Rick has a blue-grayish color while the Arch logo is Navy Blue.
  - dozzie 8y ago
    Which, as I said, very conveniently is glossed over by Arch users.
    - JackCh 8y ago
      That's a problem with Arch users, not with Arch. It's unfortunately common that fanboys undermine the reputation of reasonable software.
      - dozzie 8y ago
        Oh yes, it is a problem with the users, not the software itself, but you don't get to separate the two in the case of an OS or distribution.
        JackCh 8y ago
Latty 8y ago
> this is a fundamental problem with the security model of Arch Linux And with every other OS that isn't locked down so the user can't run arbitrary stuff. The AUR is just the arch equivalent of downloading a `.exe` installer and running it. Yes, clearly there are security concerns there, but they aren't specific to Arch. If you want a level of trust, then don't build AUR packages and install things using the package manager (AUR packages aren't supported by it) which have trusted maintainers and are signed.
tomn 8y ago
> this is a fundamental problem with the security model of Arch Linux, but that's been known for a very long time It's exactly the same problem that every other distro has when users compile or install unvetted community packages. The only way to make unvetted community repositories safe is to have users look at the sources before building or installing. Arch encourages users to do that -- AUR helpers and binary repositories are discouraged, and the source package format is simple enough that an average user could probably spot something like this.
LukeShu 8y ago
> yes, this is a fundamental problem with the security model of Arch Linux No, it's not. AUR is not Arch, and is not "supported" by Arch. It's a fundamental problem with the security model running code from randos on the internet. If someone published a git repo on GitHub that installed malware when you ran git clone git://github.com/user/repo . && ./configure && make && sudo make install you wouldn't be saying that "this is a fundamental problem with the security model of git." From the AUR homepage, in big text: > AUR packages are user produced content. Any use of the provided files is at your own risk.
- xiii1408 8y ago
  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).
  - LukeShu 8y ago
    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`.
    - xiii1408 8y ago
      The install hooks are chrooted inside the pacman install directory. 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.
- cakes 8y ago
  I understand your point but the problem is that the title is "Arch Linux AUR Repository Found to Contain Malware" (and not, for example: "AUR Repository Found to Contain Malware"). I would argue that the implication (I guess reputation-wise if that matters) starts with the "Arch Linux" part. It's easy to jump on Arch because of this regardless of the fact that the AUR is not supported. At a cursory glance plenty of people (though incorrect) will equate this to "Arch Linux contains malware"

dozzie 8y ago

The thing is not that it's a new deficiency or something, it's just that Arch user conveniently ignore this when praising their distribution over e.g. Debian.

dvfjsdhgfv 8y ago
Fortunately admins are not unreasonable and don't base their decisions on praises but on actual merits, so most servers run Debian rather than Arch (which is an interesting distro for other usage cases).
- farresito 8y ago
  Who would want to use a rolling release distribution for a (production) server? Sounds like a pretty terrible choice, to be quite honest.
  - cmiles74 8y ago
    Maybe you could make the case for some cutting edge development or test box, but then again, I'd rather be testing on something that's as close to identical to the production environment as possible. I used Arch on my laptop (primarily used for development) for several years. It mostly worked great and I always had access to the newest whatever with a minimum of hassle. I don't have many complaints, but occasionally after an update something critical would stop working. I'm on Solus now and, so far, it's been pretty great. :-)
  - Foxboron 8y ago
    All of the Arch Linux infrastructure is run on Arch. Works pretty well.
    - JackCh 8y ago
      There is an expectation that projects dogfood their own software, but I really can't think of a rational reason for a production server not affiliated with the Arch project to be running Arch. Rolling release is great for technically competent users to install on their workstations, but why would you ever want a rolling release on a production server?
      - Foxboron 8y ago
        You wouldn't. The only reason why we run it is because we know it. I wouldn't have used Arch on any production things personally.
      - semi-extrinsic 8y ago
        Well, one thing which I know of several projects doing, is having an Arch server as one of the continuous testing servers. This way you can test against bleeding edge gcc/glibc/whatnot and catch bugs or breaking API changes long before they appear in major distros.
  - walrus01 8y ago
    Nobody that values their job or sleeping well at night. It's basically one level of nuts above and beyond running Debian Sid on all your production servers.
    - hultner 8y ago
      I ran SID in a embedded customer box testing unreleased software, I did run it in KVM from a stable release since I wouldn’t have physical access if something went wrong, glad I did.
mateuszf 8y ago
AUR repository isn't supported by the core tools and packages. To use it one has to install external scripts. So it's by no means part of the system.
- mar77i 8y ago
  Urm, you need git, you need build tools... and pacman. That's it. But oh yeah, because I do these things by hand and check whether the source urls point to the place I'd actually like to install (and other code doesn't download external sources, eg. in the PKGBUILD or external scripts like *.install files), I'm suddenly an exception. I just noticed that the blue used on the Archlinux logo is actually quite consistent with Rick's hair color. https://i.imgur.com/kkE25w2.jpg https://i.imgur.com/kkE25w2.jpg Fits me. I don't give a damn.
  - Foxboron 8y ago
    I'll assure you Rick has a blue-grayish color while the Arch logo is Navy Blue.
- dozzie 8y ago
  Which, as I said, very conveniently is glossed over by Arch users.
  - JackCh 8y ago
    That's a problem with Arch users, not with Arch. It's unfortunately common that fanboys undermine the reputation of reasonable software.
    - dozzie 8y ago
      Oh yes, it is a problem with the users, not the software itself, but you don't get to separate the two in the case of an OS or distribution.
      - JackCh 8y ago

Latty 8y ago

> this is a fundamental problem with the security model of Arch Linux And with every other OS that isn't locked down so the user can't run arbitrary stuff. The AUR is just the arch equivalent of downloading a `.exe` installer and running it. Yes, clearly there are security concerns there, but they aren't specific to Arch. If you want a level of trust, then don't build AUR packages and install things using the package manager (AUR packages aren't supported by it) which have trusted maintainers and are signed.

tomn 8y ago

> this is a fundamental problem with the security model of Arch Linux, but that's been known for a very long time It's exactly the same problem that every other distro has when users compile or install unvetted community packages. The only way to make unvetted community repositories safe is to have users look at the sources before building or installing. Arch encourages users to do that -- AUR helpers and binary repositories are discouraged, and the source package format is simple enough that an average user could probably spot something like this.

LukeShu 8y ago

> yes, this is a fundamental problem with the security model of Arch Linux No, it's not. AUR is not Arch, and is not "supported" by Arch. It's a fundamental problem with the security model running code from randos on the internet. If someone published a git repo on GitHub that installed malware when you ran git clone git://github.com/user/repo . && ./configure && make && sudo make install you wouldn't be saying that "this is a fundamental problem with the security model of git." From the AUR homepage, in big text: > AUR packages are user produced content. Any use of the provided files is at your own risk.

xiii1408 8y ago
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).
- LukeShu 8y ago
  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`.
  - xiii1408 8y ago
    The install hooks are chrooted inside the pacman install directory. 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.
cakes 8y ago
I understand your point but the problem is that the title is "Arch Linux AUR Repository Found to Contain Malware" (and not, for example: "AUR Repository Found to Contain Malware"). I would argue that the implication (I guess reputation-wise if that matters) starts with the "Arch Linux" part. It's easy to jump on Arch because of this regardless of the fact that the AUR is not supported. At a cursory glance plenty of people (though incorrect) will equate this to "Arch Linux contains malware"