Yay: Sudo password after long build

[tierriminator]

After a build, sudo password is required to install the built package. However if the build takes a long time, one might miss the moment, when one needs to enter the password, resulting in a failed installation. After retrying, even without a clean build, everything gets built again, resulting in the same problem.

[jonathonf]

If the package has been built you can install it with pacman -U ?

You'll get the same issue if you leave a makepkg -sri running, but the answer isn't to start over, it's to install the built package file (pacman -U or makepkg -i).

[tierriminator]

Yes, but shouldn‘t a AUR helper / pacman wrapper hide the usage of pacman itself?
It seems to me, that this can be solved quite easily without the user needing to know the build directory and good knowledge of makepkg and pacman.
The intuitive thing for a user to do after a failed installation is, to retry. And the current implementation really doesn‘t help in this aspect.

[jonathonf]

In my view a helper should augment pacman rather than replace it. A user should know what pacman does and use a helper only as an assistant rather than a replacement - for me the pacaur approach is pretty perfect, with plain pacman commands being passed through, and only AUR-specific functionality being implemented in the helper/wrapper. (This is my personal view and @Jguer should obviously make his tool do what he wants it to. :wink: )

However - starting a build of a package already built shouldn't rebuild from scratch. For example, makepkg will report "package already built - reinstalling" when the package has already been built. From this perspective it's a bug, and one that should now be fixed, therefore :tada:

[Jguer]

When it came to doing the upgrade menu since we have direct access to the ALPM library via C bindings, I prefer using it than parsing command outputs from the terminal, just seems more elegant and normally provides better information (and faster) than parsing a pacman output.
The privileged install operations are the only ones I would prefer to keep passing to pacman .

[eli-schwartz]

This is a really bad idea, as sudo credentials are cached by the TTY and if you walk away from the computer while yay is running, another person can come by, CTRL+C the running program, and gain access to a sudo session.

I know most other popular helpers seem to implement a sudo loop, and I'm not even hugely bothered by that as the user should be allowed to make that decision.
(Although it would be interesting to see an AUR helper that ran as root and dropped permissions except when running pacman -S / -U )

But not providing a configuration option to turn this off, means this AUR helper is now on my naughty list. :disappointed:

...

Not really sure why any of this matters if the package has already been built and is cached in a persistent location.

[Morganamilo]

Yes I agree, It also tends to bug out for me getting stuck in a loop of trying to sudo over and over. This solution also won't work when sudo is configured to require a password every command.

[Jguer]

Fair enough, makes complete sense, adding it as an off by default option

[Tyilo]

Alternatively you can make a wrapper around sudo that never times out, see https://askubuntu.com/a/1114156/41269

[eli-schwartz]

Or, you know, just disable the sudo timeout via /etc/sudoers instead of using dreadful ASKPASS hacks.

[Tyilo]

Or, you know, just disable the sudo timeout via /etc/sudoers instead of using dreadful ASKPASS hacks.

I didn't know you could do this, thank you! (add Defaults passwd_timeout=0 line to sudoers)

[ryukinix]

It's not possible just pre-auth the sudo? I always thought this is very annoying behavior from aur helpers, for "security" reasons they don't allow the helper itself running as root.

[eli-schwartz]

It's not possible just pre-auth the sudo?

Perhaps you missed the fact that this issue is a feature request to add exactly that feature, and it was closed over a year ago because it was successfully implemented?

I always thought this is very annoying behavior from aur helpers, for "security" reasons they don't allow the helper itself running as root.

You are wrong, AUR helpers do not set this -- makepkg, as defined by the developers of Arch Linux itself, defines this "security" reason, and AUR helpers have no choice because they still run makepkg and therefore if the helper runs as root, makepkg will error out.

Do you understand the difference between makepkg and an AUR helper?

[ryukinix]

Do you understand the difference between makepkg and an AUR helper?

Yes.

[YodaEmbedding]

It would be nice if yay didn't completely terminate after a failed sudo attempt; rather, why not prompt the user with a Retry? [Y/n]?

pikaur does this https://github.com/actionless/pikaur/issues/327.

[eli-schwartz]

Don't commands which try to use sudo but fail due to wrong passwords, usually go ahead and completely terminate? I mean, if you don't want that to happen then the usual advice is to get it right at least once during the three chances that sudo gives you by default. Or you can configure the number of chances you get, via the sudoers setting passwd_tries.

Once again I'm totally unsurprised that pikaur would implement a questionable feature like that.

[YodaEmbedding]

It's nice from a usability perspective. yay runs for a reasonably long time and semi-interactively (e.g. selecting packages, editing PKGBUILDS). Reconfiguring these interactively on each run is painful. I can't see anything wrong from a security perspective. At worst, it's not "Unix philosophy"... but that was only ever intended with usability in mind.

Other reasonable alternatives would be a yay --resume option to continue from wherever yay last terminated, but I imagine that's a bit more complicated to implement.

[eli-schwartz]

But, if you're really losing all that work due to sudo failing, then like I just said, you can configure sudo to always give you more chances. So why does any thirdparty consumer, either yay or pikaur, need any such option? It's 100% bloat and does nothing but increase cognitive overload.

I can't see anything wrong from a security perspective.

Did anyone suggest there was something? This comment seems to come completely out of left field.

At worst, it's not "Unix philosophy"... but that was only ever intended with usability in mind.

It strikes me as an unusable, unmaintainable, unpredictable mess to get hundreds of programs to implement automatic state resumption, more dialog boxes/prompts, and fragile error handling (either re-invoke on every non-zero return, or do some hacky parsing of output), rather than learning to use sudo and configuring it once, in a very accurate manner, that applies everywhere.

[YodaEmbedding]

Ah, I see now that there's a sudoers configuration for setting the password prompt timeout:

Defaults passwd_timeout=$MINUTES

[eli-schwartz]

Ah, I see now that there's a sudoers configuration for setting the password prompt timeout:

Yes, I said so above, see https://github.com/Jguer/yay/issues/147#issuecomment-459028296

[Harvie]

It would be nice if yay didn't completely terminate after a failed sudo attempt; rather, why not prompt the user with a Retry? [Y/n]?

Yes! Can you please add this? It would make a lot of sense...

[shaljam]

Or maybe can it ring before prompting for password?

[Harvie]

Or maybe can it ring before prompting for password?

that might help, but is surely not enough by itself... you might be absent, when the ring goes off...

[ts1a]

Or maybe can it ring before prompting for password?

Then it goes back to #1031.

[YodaEmbedding]

There's two clear existing solutions:

• Set Defaults passwd_timeout=$MINUTES in the sudoers file. (See above.)
• yay --sudo-loop. (Slightly insecure, as pointed out by Eli.)

And a more fun one for the ricers out there:

• Build in a tmux pane, then output the last line of that tmux pane to some persistent area of the screen (e.g. polybar). My configuration looks like this:

[module/preview]
type = custom/script
exec = tmux capture-pane -p -t "0:1.1" | tac | egrep -m 1 . | sed -e 's/^[ \t]*//'
interval = 1
label = %output:0:16:...%

[pklapperich]

So for those coming here late and trying to make sense of @eli-schwartz harassing users instead of leaving helpful comments:

Add sudoloop: true to your ~/.config/yay/config.json. A simple way to do this is yay --save --sudoloop

This allows you to start the install, enter your password once, and walk away.

[eli-schwartz]

trying to make sense of @eli-schwartz harassing users instead of leaving helpful comments

Your mother was a hamster and your father smelt of elderberries!

...

Oh wait, by my so-called unhelpful harassing, do you mean when I said this?

Perhaps you missed the fact that this issue is a feature request to add exactly that feature, and it was closed over a year ago because it was successfully implemented?

It is now over two years ago. The feature was implemented within two days of the issue being opened. All the comments in this thread were written after that, by people who don't seem to understand that this is closed because it is implemented.

[addeps3]

If the package has been built you can install it with pacman -U ?

You'll get the same issue if you leave a makepkg -sri running, but the answer isn't to start over, it's to install the built package file (pacman -U or makepkg -i).

The object does not exist in main repo's how would pacman find it?
makepkg is used locally, in the same directory, Im running yay from new terminal, when do you expect me to use makepkg?
Edit: ok, I answered my own question and builds exist in ~/.cache/yay/whatever_app_youre_building

Just run makepkg -i without sudo, and you wont have to rebuild.

And you're welcome for that information (that no one else bothered to provide) =D