Open DN-debug opened 2 years ago
Hi @DN-debug . In theory we could have both authentication back-ends and just have a configuration property to choose which one to use. I'm not familiar with doas, but I'm going to have a look as soon as I can.
First of all Happy New Year! :tada:
Sounds like a good plan. I have relied heavily on 'doas' in most of my personal systems, so if you need any help related to doas, I could be of some help.
Thanks for considering!
I am also going to dump in some of the output details along with the image here for future reference:
Image showing the error:
Log file: upgrade_20211231_1640960364.log
@DN-debug , I'm going to add it to the backlog for analysis. I need some time with this tool to check if the integration would be smooth. Thanks for sharing the logs.
Happy new year !
Describe the bug: Hi Vini, it's more of an interactivity constraint. rather than a bug. Bauh relies on sudo for identity privilege, which is hard-coded to use sudo. The functionality would supposedly break on systems where it will encounter doas/opendoas and the password interactivity to delegate the access would break.
I have tested it with that. I am average with python and not as good as you, not even close, so I can't suggest the exact changes to be made, but I am also looking into it for personal interests as Peux Gnome uses doas. You'd know where exactly I am pointing to just by looking at the below limitations.
Limitations: doas doesn't have the typical:
It only works with -LnsC arguments. ASKPASS can be utilized but using external script.
I am not sure how pamac utilizes the identity privilege/ user delegation but it works with both doas and sudo.
Query: Is it possible to implement Bauh in a way to recognize both sudo and doas depending upon the environment? Any thoughts.