Mistyped password aborts pamac, potentially forcing complete rebuild of AUR packages

Description

Pamac may request authorization before beginning an update, spend a long time compiling one or more AUR packages as the unprivileged user, and then request authorization again before committing the completed packages.

If the user mistypes the password at that final prompt, the first unsuccessful Polkit result is treated as a terminal error. Pamac exits immediately instead of permitting another authentication attempt. Rerunning pamac update can repeat the entire compilation.

I have run into this several times with long builds of mysql. I suspect that while alt-tabbing to check progress I have inadvertently entered characters that then are read by the password prompt - or that I'm simply mistyping a password that includes mixed case, numbers, and symbols. Either way, the very slow build then needs to be repeated unless I want to dive into the Pamac working directories and complete installation manually.

Steps to reproduce

1. Enable AUR support and install or update an AUR package that takes a substantial amount of time to compile.
2. Run pamac update as a normal user.
3. If prompted, complete any initial authorization prompt correctly.
4. When prompted, enter y to apply updates.
5. Allow Pamac to finish compiling the AUR package.
6. At the authorization prompt immediately before installation/commit, enter an incorrect password once.

Actual result

Pamac reports Authentication failed and aborts the transaction immediately. Running the update again may repeat the completed AUR build.

Expected result

Pamac should continue prompting after an incorrect password. It should abort the transaction when the user presses Ctrl-C at the authentication prompt or when Polkit or the daemon reports an internal error.

Cause

pamac-cli starts pkttyagent but otherwise leaves authorization to Transaction.run_async(). The terminal agent completes an authentication request after a rejected password, and libpamac treats the resulting non-authorized response as a failed transaction. The CLI therefore has no opportunity to ask again and cannot preserve the already completed portion of the transaction.

The CLI also installs its own SIGINT handler. At an authentication prompt, Ctrl-C terminates pkttyagent, but the handler does not consider authorization to be a cancellable transaction phase. Pamac can remain active after its terminal agent exits, allowing another registered agent, such as the desktop GUI agent, to handle a subsequent authorization request.

Proposed fix

Have pamac-cli explicitly acquire authorization with Transaction.get_authorization_async() before starting a privileged transaction. Repeat a plain unsuccessful authorization request, but stop when authorization succeeds, the user presses Ctrl-C, or libpamac emits an error with diagnostic details.

While authorization is pending, treat Ctrl-C as cancellation of the entire operation and return status 130. This ensures that losing the terminal agent cannot move the interaction to a GUI agent while the CLI transaction continues.

Security impact

Each attempt is still independently mediated by Polkit. The patch does not validate passwords itself, run builds as root, or bypass policy.

After successful authentication, libpamac retains authorization for this CLI sender until the transaction finishes. This deliberately extends authorization across downloads and unprivileged AUR builds so the completed transaction does not require another authentication interaction before commit. The CLI removes the authorization afterward, and exiting the CLI also closes its daemon connection.

While allowing multiple password entries could increase brute forcing risk, note that this is an interactive session with an already logged in user. They could as easily use sudo or passwd to make authentication attempts. A strict "one try" rule adds nothing here.

Start in pamac-cli around the Transaction.run_async() flow, the proposed Transaction.get_authorization_async() call, pkttyagent handling, and the CLI SIGINT handler. Trace how authorization failures and cancellation reach the transaction, then verify that retries work, Ctrl-C returns status 130, successful authorization covers the transaction, and authorization is removed afterward.