Open gekoke opened 5 months ago
Thanks for the bug report. Fixed in 0.8.6
Hmm I wonder if there is a larger issue here - it feels like the line of text in the buffer is getting interpreted by emacs/async etc in some way - I wonder if it is possible to get command execution via an untrusted buffer through this issue? Whilst the current fix stops async prompting for a password, I fear async may be invoking emacs
with a command that is derived from text of the current line.
I agree - though I'm not proficient enough in Elisp to understand what's going on, I don't feel like the proposed fix of setting (async-prompt-for-password nil)
and calling (ignore async-prompt-for-password)
is enough to solve the problem in the general case. I don't think this kind of interpreting of the buffer contents should really be possible in the first place.
I couldn't find any code from the emacs-async package that interprets the result buffer as code. It looks like there is a simple regexp that checks if the output of a command matches the tramp-password-prompt-regexp
variable.
Of course this is a superficial check, if someone can reproduce potential vulnerabilities I'll check them more thoroughly.
ah ok - thanks - yep I agree, the input string is not actually interpreted in anyway - just matched against - so there doesn't appear to be any risk here of command injection etc. Thanks for clarifying this for me and your work on blamer @Artawower.
When hovering a line that is part of a commit and includes the word
password
(not sure of the exact heuristic), I receive a password prompt.This only happens when
blamer-enable-async-execution-p
is set tot
.Can replicate by having a committed line with the following contents: