Proposed Pamac AUR Update Delay

Contributions
1

After the recent discussion about AUR package safety in Active AUR malicious packages incident (Active AUR malicious packages incident), I’ve put together a small feature that lets users delay AUR updates from appearing in the update scan.

A new setting, “Delay showing AUR updates (days)”, is available in Preferences > Third Party > AUR. When set to a non-zero number of days, any AUR package whose upstream LastModified timestamp is newer than that age is hidden from the normal update scan.

  • Default is 0 or behavior unchanged.
  • The delay only applies to the passive update scan (pamac-checkupdates, tray notifications, the Updates tab).
  • It does not block manual installs, builds, or full upgrades. If you explicitly ask Pamac to build or upgrade a package, it will still do so.

The work is split across the two repositories:

Users accept very real risks when installing software from the AUR. As one forum moderator put it: “…one can explain that the soup is hot, but that does not prevent those hungry from burning their lips.”. This change gives the user a thermometer, an optional delay that lets AUR packages cool down before they appear in the update scan.

One of Manjaro’s defining traits is its measured approach to updates. Unlike Arch’s immediate upstream sync, Manjaro holds repository packages through testing and unstable branches so issues can surface before they reach the stable user base. This feature brings a similar safety margin to the AUR, an optional cooling-off period, that keeps just-published commits off the update scan until they have had time to be reviewed in the wild.

4

A little housekeeping:

Contributions such as this do not belong in Support categories – instead, they should be placed appropriately under Contributions – the topic has been moved accordingly.

The topic has been unlisted (hidden from public view) pending approval by Community leaders.

At that point the topic will either be re-listed, or an opportunity for further discussion may be given with the view to possible improvement. This is standard practice.

In the meantime, I’d suggest the title could be changed, for brevity. :slight_smile:

Thank you for your interest.

Regards.

5

This forum platform does not provide me authorization to revise the title.

Manjaro already provides implicit support for AUR as a concept; pamac (a first party tool) can build, install, and update AUR packages and the Manjaro forums contain an AUR sub-category. I suspect the community feedback would not be resoundingly positive if pamac removed AUR usage.

While it may not provide explicit support, including a mechanism which could help mitigate damage from an AUR package takeover (which seems to be the most common exploit attempt) will further drive Manjaro as the stable and user centric distro. It’s not a guaranteed mitigation but in this specific instance all packages were identified and remedied in a couple days.

6

If you hover the mouse pointer over the thread title, a pencil should appear, or at least it should as you are the topic creator.

If not, suggest the change here and we’ll fix it for you. :wink:

7

Thanks,

Proposed Pamac AUR Update Delay

1 Like
8

When we say support we mean technical support.

The fact the pamac is an AUR helper does not imply that Manjaro provides technical support for anything from the AUR (Arch doesn’t support it either).

A delay would be extremely hit and miss, we can’t predict how long it would take to discover something malicious in the AUR.

Such a delay may help the uneducated avoid updating too early when they’re on stable, but again there’s no way to tell how long that delay should be, especially as each package is different.

it’s likely to cause more problems than it would solve, and it doesn’t solve the real issue which is that people need to learn how to use the AUR.

There’s nothing stopping you or anyone else from delaying an update (nor from learning how to use the AUR properly).

The simple fact is that using the AUR safely requires knowledge and effort. Not just to avoid something malicious, but to also make sure things work.

You need to inspect at least the PKGBUILD and any corresponding scripts and patches, and understand if and when to install or update something. Ideally you’d also keep yourself well-informed and inspect the source code. Avoid pre-compiled binaries (-bins) whenever possible.

Blindly installing or updating things and hoping for the best often works, but it leaves you open to malicious and broken software.

Ultimately if you want to use the AUR then you should learn how to do so.

4 Likes
9

I’m curious what new problems are created with this PR that it creates more problems than it solves? In this most recent AUR takeover a delay of a couple days would have prevented a user for unintentionally, accidentally, or otherwise updating and becoming infected. This does not increase the liability of Manjaro or impact its ability to hide behind the “AUR requires knowledge and effort” stance.

You say Manjaro does not provide technical support for AUR but the Manjaro forums contain a specific sub-category for AUR support. Manjaro provides direct technical support for accessing the AUR and installing from the AUR. While it may not provide support for say bambu-studio within the AUR it does provide all support for accessing and installing said package.

While I’m biased in getting this PR approved, I guess I don’t understand the hesitation to providing a user with a tool that is an optional parameter from an element of danger within a utility which Manjaro has created, maintains, and actively supports.

1 Like
10

To be clear I’m not against the setting, though I think it has limited value. Users learning how to use the AUR properly is the better approach.

If someone isn’t aware of the setting, or has forgotten about it then they’ll wonder why updates aren’t showing up. In some cases the lack of an update may mean the software breaks. This is likely to generate additional issues here on the forum (and probably additional complaints elsewhere).

There’s a category because people will have problems and they will want to ask for help, it’s best to separate these issues from general support issues.

The community does often help, but there’s no guarantee that anyone will be able to (though that’s not really any different from anything else).

Perhaps a better way of putting it is that there are issues that won’t be addressed by either Arch or Manjaro.

This is Arch’s warning.

Warning AUR packages are user-produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.

There’s too much variation and too little control in the AUR to do anything but say that you’re pretty much on your own.

It’s up to you to decide if you should install or update something from the AUR, to ensure your computer remains secure and to make sure things work.

Manjaro makes it easy (perhaps too easy) for you to use the AUR. Manjaro also provides this community forum, and information via the wiki. The community provides technical support as best they can, including for the AUR when possible.

3 Likes
11

No official support is explicit in the Wiki

Arch User Repository - Manjaro Wiki

Use the AUR at your own risk!

No support will be provided by the Manjaro team for any issues that may arise relating to software installations from the AUR. When Manjaro is updated, AUR packages might stop working. This is not a Manjaro issue

Although Manjaro is very close to Arch Linux and mostly compatible —being based on Arch Linux itself— it is not possible to access their official repositories for use in Manjaro. Instead, Manjaro uses its own repositories in order to ensure that any software packages that are accessible, such as system updates and applications, have been fully tested to be compatible and stable before release. It is still possible to access additional software packages from the Arch User Repository (AUR).

The AUR is managed by the Arch Linux user community itself. Although this repository is unofficial, software packages first placed here can eventually make their way into Arch Linux’s official (community) repository if they become popular enough.

AUR, as a community maintained repository, present potential risks and problems.

Possible risks using AUR packages:

  • Multiple versions of the same packages.
  • Out of date packages.
  • Broken or only partially working packages.
  • Improperly configured packages which download unnecessary dependencies, or do not download necessary dependencies, or both.
  • Malicious packages (although extremely rare).

As such, although much of the software packages provided by the AUR should work, do not expect the installation process to always be quite as straight-forward as when you are using the official Manjaro repositories.

On occasion, it may be necessary to manually identify and install dependencies yourself (such as, after an aborted installation attempt).

Again, there is no guarantee that any installed software will work properly, if at all.

Forum community can provide some support for well-known AUR packages, but AUR contains over 100,000 packages, so there may be no experience for a large proportion of these packages

3 Likes
12

I get it, AUR isn’t supported but here’s a first party tool to use and if you have an issue maybe the forum can help…but don’t tell anyone as this we don’t want people to think we support AUR.

If there is so much angst against AUR, why does pamac support…errr…that’s a bad word…allow building and installing from AUR in a close to one-click manner? Reading through this forum this only logical decision is for a PR to be created removing AUR functions from (lib)pamac.

13

AUR access is disabled by default in pamac, and octopi requires the extra step of installing an AUR helper (such as yay) before it can access the AUR.

Packages from the AUR are unsupported, and yes, people who use Manjaro are expected to assume responsibility. Just because Manjaro is an easier-to-use Arch derivative doesn’t make it any less of an Arch-based distribution, let alone a distribution for people with a blind consumerist attitude as in the event of Microsoft Windows or Apple macOS.

2 Likes
14

You make a fair point, having AUR disabled by default is the right move, and users absolutely must take responsibility for their systems. I’m not looking to turn Manjaro into a hand-holding OS.

My proposal for a delay isn’t about avoiding user responsibility; it’s about adding a security buffer against the very risks the Wiki warns about; specifically, bugs and exploits in the AUR. When Pamac pulls an AUR update immediately, users are effectively acting as the canaries in the coal mine for malicious PKGBUILDs or severely broken updates.

Implementing a delay creates a quarantine period. It gives the broader Arch community time to spot and flag a malicious or broken AUR update before Pamac automatically offers it to Manjaro users. It’s a structural safeguard that fits Manjaro’s philosophy of preferring stability and security over bleeding-edge speed and providing an optional value for this delay ensures the user remains in control of their system.

15

Then wouldn’t it be better to, instead of setting a delay, pop up a warning instead that users should check first whether there are any current reports regarding compromised AUR packages?

In the end, updated AUR packages may either way not work on Manjaro Stable due to the fact that they were created against Arch Stable, which is far more bleeding-edge than Manjaro Stable or even Manjaro Testing.

2 Likes
16

Why does pamac allow skipping review of a PKGBUILD and not treat it like a ToS screen requiring full scroll before install becomes available? Why does pamac allow enabling AUR without any confirmation? If security and stability are pillars of Manjaro, why is pamac allowed to violate that ethos in it’s relation to AUR? Why was AUR support added into pamac in the first place?

All of these are rhetorical questions but now you’ve unintentionally moved the goal post into my favor by bringing the stability element in where delayed AUR updates are more likely to improve stability of an AUR user.

17

Well, I never use the pamac GUI — I don’t even have it installed anymore — but when used from the command line, pamac does give you the option to edit the PKGBUILD and any other build-time configuration files.

Because pamac aims to be a one-stop package manager for everything — the repos, the AUR, Snaps, FlatPaks, and the kitchen sink.

Don’t look at me, I wasn’t even here yet when pamac was developed, and personally I only ever use it to access the AUR — from the command line, of course. :man_shrugging:

I also feel — and I’m not the only one within the community — that pamac is an attempt to reinvent the wheel, and especially so with regards to repo packages, because after all, pacman works just fine.

But then again, @philm runs a commercial business, and commercial activity requires customers, regardless of what kind of customers they are. As such, Manjaro has been attempting to attract as many users — read: potential customers — as it could get, among other things by misrepresenting itself as a distribution suitable for absolute beginners and gamers, which couldn’t be farther from the truth. And pamac fits into that strategy, even though it’s got loads of bugs and other issues.

At the moment, @philm is still in full control over Manjaro, and he’s not exactly known for communicating much to the rest of the team. Efforts are underway to split off the development of the distribution into a non-profit organization, whereby the commercial aspect of Manjaro will become the downstream of the distribution itself. But we’re not quite there yet, and thus, for now, the chain of command still stands as it is.

:man_shrugging:

My own strategy — which I think is the best one — is to only update my AUR packages when there is a Stable Update for the repo stuff. And sometimes, an AUR package may need a rebuild after a Stable update due to the Stable Update bringing along new versions of shared libraries which break the AUR package in question.

2 Likes
18

Manjaro is uniquely positioned to capture marketshare as it provides the best compromised experience. As a new user of approximately a year on desktop it provided the most pros against the least cons in a table. I appreciate your response with background context but at this time I’m exiting this conversation. While a different demographic, at time of writing this proposal has an 81% upvote rating on reddit where its community users vs the seemingly 95% down vote here from community leaders and staff members. Not saying there is anything there but there definitely isn’t nothing in that metric disparity.

I spent way to much energy debating supported vs unsupported with community staff members that I’ll leave the PR’s open and they’ll either get merged or won’t get merged. In the mean time I have a patched pamac providing me the functionality I want and if others don’t get that benefit well they can patch it themselves too.

3 Likes
19

There’s a reason why those people are on Reddit and not here, you know? They don’t particularly like us over there, and in all fairness, that has more to do with them and their egos than with us or with Manjaro.

That said, while I provided the alternative approach — in the form of a warning — above as a counter-argument, I do sincerely appreciate the work you’ve put into this, and your willingness to contribute to the development of the distribution. :folded_hands:

2 Likes
20

I don’t remember when any ‘issue’ occurred for me personally that would have been helped by an AUR delay.

I remember paru failing to build for a month because we were behind Arch, but that’s just a failed AUR build that I just excluded from updates for the month - it didn’t break anything.

As for the ‘reddit’ comment - that’s fascinating. There’s a similar vibe over at CachyOS where the Arch users are constantly outnumbered by the Windows Gamer users… and developers are mostly nowhere to be seen.

My take is that I want to see all available updates and decide when I install them - I updated my AUR packages yesterday, taking a while to read through the PKGBUILDS a little more thoroughly than I used to do.

4 Likes
21

Good questions.

pamac was designed not only as one package manager to rule them all, but also to make it easy for newbies without them having to learn anything.

I think that design philosophy is flawed at best, and similar lack of foresight has caused some easily avoided bugs (such as DDOSing the AUR).

This is why I stick to pacman and yay, and occaisonally making my own PKGBUILDS. I only have pamac installed because I installed it to check an issue mentioned on the forum and I forgot to uninstall it again (I might leave it for now).

Back when I first started using Arch, I often used to forget to update the AUR until something broke. I never quite managed to get out of that habit.

Checking everything, especially the code (I usually like to have a quick look, especially when installing for the first time), can be quite a lot of work. So I usually only update when something breaks or if I find an update with new features, etc, that I want. I never update them all in one go, only one at a time.

It’s worked for well over a decade, but I wouldn’t say it’s best practice.

Occasionally there’ll be a version incompatibility caused by being behind Arch, mostly something like somefile.so.8 doesn’t exist. This can happen if the PKGBUILD doesn’t require a specific version of a dependency with such a file and the number has changed (or the filename/path has changed in some other manner), so it builds and installs but fails during runtime.

2 Likes