-p/--prompt behaviour breaks ansible

[EvoRowan]

-p on C sudo would replace the entire prompt which ansible relied on for privilege escalation. -p on sudo-rs just appends it within the brackets. With sudo-rs being the default on Ubuntu now, this breaks a lot of ansible scripts.

To Reproduce
$ sudo -p "password:" hostname
[sudo: password:] Password:

Expected behavior
$ sudo -p "password:" hostname
password:

Environment:

• Linux distribution: [Ubuntu 25.10]
• sudo-rs version [0.2.8`]

Additional context
Same behavior happens on 0.2.12 as well

[squell]

Thanks for requesting this. This was a design choice, related issues: #842 and #1242, although this issue is not a duplicate of those.

For our internal discussion it would help to have an example of an ansible script that fails!

[EvoRowan]

Anything that uses become will break, for example:
ansible all -i hosts.yml -m ping --become -K
Just an adhoc command to ping all hosts, but with the --become flag it'll fail

Similarly any task that uses become: true will fail as well

Edit: Just tested with -p "", that works!

[squell]

Related discussion: ansible/ansible#85837, and there's also a fix-in-progress at Ansible: ansible/ansible#86175

Note that regardless of how exactly we would format the string given with --prompt, it will break programs that expect the current sudo prompt (on Linux at least), since we are not hiding the prompt given by PAM(*) (since PAM might be asking for a password, a PIN, ... and we can't control that).

So we can discuss whether the argument given to --prompt fmtstring should be one of these two things:

a. (current) [sudo: {fmtstring}] PAMPrompt:
b. {fmtstring} PAMPrompt:

I.e, so that the default promptvalue is going to be [sudo: authenticate] instead of authenticate. But this will still result in incompatibilities, suppose one would use -p [sudo hash=keykeykey] password: , then with sudo-rs the prompt would become:

[sudo hash=keykeykey] password: Password:

(*) The only exception of course is that if -p "" is given, the whole password prompt is suppressed.

I don't really see a right way forward here except maybe that software should rely less on the exact formatting of the password prompt. We do have plans to modify this in the future (e.g. to mention the hostname by default)

Of course there's also the askpass functionality that we added (and that ogsudo support) that these tools could use for a much more robust password-integration.

Edit: If I read ansible/ansible#85837 correctly, it might be that option b. above might actually pass the ansible code by accident sincce it uses .starts_with. ?