Hi, i just committed the patch i posted earlier based on OK afresh1@ semarie@; thanks to both of them for checking.
Lloyd wrote on Sat, Jan 11, 2025 at 06:38:54PM +0000: > Ingo Schwarze wrote: >> The problem only occurs when the initialization file starts a background >> process that prints to standard output, which is even more crazy. > The example given was a foreground process. >> Normal output generated by the initialization file occurs before >> the "echo ENV", so it won't prevent security(8) from finding ENV at >> the end of the output. > I disagree with this. Some testing showed that running neofetch with > no command line arguments, it will generate ANSI escape codes to print > colors to the terminal. This sufficiently corrupts the output stream that > security(8) is trying to parse that it does break, and cannot find ENV. That's highly surprising. While ANSI escape codes are certainly crap that shouldn't be permitted to the terminal, one among the things they are not supposed to contain are newline characters - so i don't quite see how they could possibly ruin the splitting into lines that Perl does with "@output = <$fh>". And even if that ANSI crap would contain additional newline characters, that still couldn't screw up the line splitting because it doesn't matter how many lines there are. All the script cares about are the last two lines. Whatever may come before them should not matter. So, i conclude neofetch(1) almost certainly does something even more crazy that you haven't mentioned, in addition to oozing ANSI escapes. > You can validate this is true by adding the --stdout switch to neofetch > so it will print a plain-text summary to the console instead. security(8) > does not misbehave if you do this. I don't sufficiently care about garbage programs like fortune(6) to install neofetch(1) and investigate what it is that it actually does. All the same, thanks for the report and the patch, i did help to make security(8) better! Yours, Ingo
