Bracketed paste mode turned off by mc

[nerijus]

With bash-4.4/readline-7.0 if I put "set enable-bracketed-paste on" in ~/.inputrc, pasting a string with EOLs does not execute it. But with mc there is one problem. If I launch mc, press Ctrl-O and paste, it gets executed. But if I paste again, it does not. Or if I launch mc, press Ctrl-O, press Enter and then paste - it does not paste EOLs too.

[nerijus]

Created a new ticket by request. The old ticket is #3229.

[egmont]

(I'm removing the first three paragraphs of your post, since it's utterly irrelevant, and hence might distract us from the actual problem. It does not matter at all where the text was copied from. The remaining last paragraph on its own is a valid bugreport: if you paste a text which ends in a newline, bracketed paste mode is disregarded.)

[egmont]

Bumping the priority to "critical". Devs, please relax on it if you disagree.

Bracketed paste mode, and especially bash supporting it, aims to protect against a certain kind of security problem, namely when the contents of the clipboard unexpectedly differs from what the user believes it is. See e.g. ​https://bugzilla.gnome.org/show_bug.cgi?id=697571 and also follow the links from there for a couple of examples.

Someone having bash-4.4 with bracketed paste mode enabled would expect to be protected against this kind of attack, and might carelessly copy-paste data from untrusted sources expecting bash to provide sufficient protection.

This expectation is broken by mc, leaving the user in a false sense of security and potentially becoming a victim of such an attack.

[zaytsev]

Well, for me the priority has no relation whatsoever to whether I'd be able to find time to look into it, and if this is the problem I'll look into first whenever I happen to get any spare time :/ My current strategy whenever I get a block of time is to either invest it into issues that are likely to cause a complete meltdown if left unattended for much longer, or issues small & simple enough such that I could actually handle them within this block of time :/

I'm afraid that you're the only one capable and interested in addressing this problem for now anyways...

[egmont]

I didn't mean to urge you or anyone else. Alas, I myself probably won't have any time to look at it any time soon either. But I wanted to note that (in my opinion) this bug is significantly more severe than most other bugs we have here.

[For what it's worth: mc trac's priority levels are truly badly chosen/named. The default is called "major" which name suggests it's more important than the average, the one below is "minor", there's no neutral choice. The default should be a neutrally sounding "normal", with "minor" being below it and "major" being above it. Currently there's no level between the default and "critical". I couldn't express that this bug is more severe than the typical bugs, although probably not yet critical.

Some bugtrackers even distinguish between priority and severity, although I find that a bit of overkill and don't see too much practical use for that. With that model, this bug would be of severity: high or critical, and priority: whatever.]

[zaytsev]

There are severities on Trac, we just don't use them. If you can tell me what should I rename current "blocker / critical / major / minor / trivial" into that Andrew would agree with, I will do it.

[andrew_b]

Ticket #4003 has been marked as a duplicate of this ticket.