** Description changed: + [ Impact ] + + In Jammy 22.04, when nano is run with both --autoindent (-i) and + --breaklonglines (-b) enabled, pressing Enter can silently delete non-blank + characters to the left of the cursor. This deletion is a silent data corruption + that cannot be undone. + + For example, if nano is opened with -i and -b into this file: + + line 1 + line 2 + + When the cursor is placed here and Enter is pressed: + + | + V + line 1 + line 2 + + You'll get this: + + (empty) + ne 1 + line 2 + + Because this is a data corruption bug in a widely used tool, it is worth + patching. The upload fixes the bug with a one-line patch that was accepted + upstream (Savannah #63407, released in nano 7.1). This fix is already in Noble, + Resolute, and Stonking so there is no divergence being introduced. + + [ Test Plan ] + + To reproduce the bug in Jammy: + 1. Run this script: + ``` + printf 'two words\n second line\n' > words + nano -i -b +,3 words + ``` + 2. Press enter once. + + Buggy behavior: The first two characters in the first line disappear. Fixed + behavior: The line splits correctly with no characters lost. + + Testing should focus on not just the case where the bug occurs, but also cases + with different indentation levels on the first and second line to ensure that + the patch did not alter existing behavior. Different types of whitespace and + undo should also be tested. + + A smoke test should be done on normal nano editing as well. + + [ Where problems could occur ] + + The patch is a one line-change that modifies the behavior of an 'allblanks' + flag by making it check if the preceding characters are actually whitespace. + This only triggers when --autoindent and --breaklonglines is active, and the + next line's indentation exactly equals the cursor column. This code path occurs + in the do_enter function which runs whenever Enter is pressed, so if a + regression occurred that affected the greater function it would be highly + visible during normal editing, but otherwise it would only be visible within the + right situation. Regressions could look like auto-indenting failing to occur or + incorrect content being copied to the next line. + + [ Other Info ] + + Original report: https://savannah.gnu.org/bugs/?63407 + Launchpad bug: https://bugs.launchpad.net/ubuntu/+source/nano/+bug/1998592 + PPA: ppa:varranvar/fix1998592 + + [ Original Description ] + Reproduction recipe: - printf "two words\n second line\n" >words + printf "two words\n second line\n" >words - nano --ignore --auto --break +,2 words + nano --ignore --auto --break +,2 words - Then press Enter. See how "t" from the first word has *disappeared*. - This is wrong. And what is worse: M-U does not bring the eaten letter + Then press Enter. See how "t" from the first word has *disappeared*. + This is wrong. And what is worse: M-U does not bring the eaten letter back. - Attached patch has been applied upstream to fix the issue. Please + Attached patch has been applied upstream to fix the issue. Please consider applying it to nano-6.2 in Jammy (22.04), and maybe also to nano-4.8 in Focal (20.04).
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1998592 Title: in specific situations, nano can eat characters To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nano/+bug/1998592/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
