fix: AUR Workflow Improvement

[JustinBacher]

Current Behavior

Comtrya currently uses yay/paru to handle all package installations on Arch-based distributions, including both official repository and AUR packages. This approach presents a couple issues: if multiple manifests contain package installs, the package manager is called for each manifest, Ya/Paru prompt for sudo authentication each time if the user is not a Sudoer.

Technical Context

Terminal-based sudo authentication is clunky due to sudo auto printing directly to stderr on /dev/tty (unavoidable as it's built into sudo which is built into the AUR helpers)

Both yay/paru explicitly warn against running them as root_(sudo), as it can cause problems since they use fakeroot to limit security flaws

While AUR helpers can handle both AUR and Offical Repo packages, using them for all package installations introduces unnecessary complexity and security implications.

Proposed solutions

1. Consolidated Package Installation

• Merge all package installations into a single event to minimize authentication prompts.
• Multiple sudo prompts still occur if both yay and paru are specified

2. Custom implementation with aurutils

• Implement a custom solution using aurutils with a dedicated user group and minimal required permissions. I got this idea from this reddit post.

3. Ditch AUR for its potential security risks / unstable packages

• Remove AUR support and only install from the official Arch repository using pacman
  • While the AUR is a primary reason some users choose Arch, Comtrya's automation removes the user's ability to act as the ultimate security measure.
  • Using Paru and Yay manually (non automated as intended) are likely better than anything Comtrya will do since the user really needs to review and approve before package installation.

Keep current implementaion but use something like ratatui to ensure /dev/tty is printed in it's own pseudo window under regular program output

• Would make the program more complex without solving the core issues of multiple auth / security risks.
  • If user is a Sudoer then only one prompt is made.

Rationale

While developing concurrent manifest execution #556, I found that password prompts would get mixed in with other program output. This caused Comtrya to freeze, waiting for user input, while also making it difficult to see it was waiting.
I tried using tools like polkit to circumvent this, but Yay and Paru still show their prompts since they both use sudo, atop the other issues above.

For example, consider setting up a new dev environment with the nightly version of Neovim. The AUR is the only source for this package, without AUR support either Comtrya installs the stable release or you install from the AUR manually.

Goal

The change finally implemented should push to align with Comtrya's core automation principle. The current behavior of multiple sudo prompts contradicts the non-interactive design goal. Running AUR helpers as root (while maybe possible) introduces permission issues and deviates from intended usage patterns.

Discussion Points

• Are there alternative approaches I haven't considered?
• What are the security implications of each solution?
• Should Comtrya handle mixed official/AUR package installations?
  • Or only official packages? (breaking change)

[JustinBacher]

After writing this up, I thought of 2 other solutions that I think are actually better than what are in my post.

Self elevation

Just have Comtrya automatically sudo itself when running apply and then run

sudo -u "$SUDO_USER" paru -S …
# or
sudo -u "$SUDO_USER" yay -S …

can’t believe I didn’t think of that this whole time. smh

Plugin system

What if Comtrya's core package management stuck with just pacman in this case, but instead, add plugin support to the base application?

This way users get a stable, trusted solution with reproducible results by default, but users who want more can extend it with plugins.

Then support the AUR through a plugin. Not only would that make the distinction between where the package is coming from more clear; it would also solve requests for other package managers like pip, cargo, or luarocks like asked in #311; Or actions that are not planned such as #545 (not to say that isn't planned, just an example)

Thoughts?

[JustinBacher]

Just saw a plugin system was mentioned in #257 as well. This would be a great candidate for a plugin in my mind. Great way of isolating blame from Comtrya if someone installs a malicious package from the AUR using Comtrya as well.

I wouldn't mind implementing it if that's the way it goes.