Re: count in vi mode alters prompt

2025-05-15 Thread Mohamed Akram
I’ve opened an issue in the readline repo for this with a patch if there’s 
interest.

https://savannah.gnu.org/support/?111068

I had been using this patch for some months in my own build of bash and it seems
to be working well. More recently I’ve just used the default zsh on a new 
machine
since it doesn’t have this issue, but it would be good to align bash with the 
other
shells in this regard.

Mohamed

> On May 20, 2024, at 5:51 PM, Chet Ramey  wrote:
> 
> On 5/20/24 9:34 AM, Mohamed Akram wrote:
>> Is there a way to disable this feature, at least in vi mode?
> 
> No.
> 
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
> 



Re: SourceAv in xparse_dolparen when trying to compare with rvalue

2025-05-15 Thread Martin D Kealey
On Wed, 14 May 2025, 11:14 Александр Ушаков,  wrote:

> For reference, I believe this qualifies for a CVE because:
>  * It is a reproducible crash (DoS) in a security-sensitive component
> (command interpreter).
>

By this logic, there should be a CVE for gcc because when you give it « int
main (){ *(int*)0 = 42; } » and run the resulting binary, it crashes.

Both gcc and bash rightfully assume that an attacker cannot control their
inputs, the programs they are expected to compile and/or run. If an
attacker can control what bash attempts to parse, you have much worse
security problems than Bash crashing.

That's not to say this isn't a bug in Bash, but it does not degrade system
security, because the only way to exploit it is if your system is already
compromised, so that an attacker can feed input to the shell parser.

As for the specific use of « bash -n » to perform validation on untrusted
input, SIGSEGV will result in a non zero status, which will correctly be
interpreted as a validation failure.

-Martin