Actually it has something to do with git. Git should strip or escape the user input before displaying. XSS and SQL Injections are the same kind of issue -> do not trust the user input and escape the input before interaction with it happens.
Actually it has something to do with git. Git should strip or escape the user input before displaying. XSS and SQL Injections are the same kind of issue -> do not trust the user input and escape the input before interaction with it happens.
Git commit messages are used for lots of different things, but at the end of the day it's just another piece of data included in a hash in a content-addressable file system.
If you're doing something with that tool where including formatting like this would be considered a vulnerability, it's on you to take care of that. It's exactly the same with any other bug or exploit in your codebase: it's not git's fault that you committed it.
The ideal solution is to sanitize all data before displaying it
on your terminal, however without a custom terminal application
or data filter, you can't guarantee that every tool you use on
the command-line is going to strip escape sequences. The
responsibility should rest on the actual terminal emulator; any
features that allow file or command-line access should be
disabled by default and more attention should be paid to new
features that implement any use of escape sequences. [0]
Are you cloning untrusted repositories to your computer and running git log blindly?I mean, it would be super nice for your terminal emulator to just automagically filter out escape sequences when you, the user, do not want them and to allow them for programs that you do. a whitelist would work but would be super annoying to actually verify as so many programs output things from so many different inputs. it seems like programs themselves should decide if they need to output arbitrary data and, in cases where they don't, like git, they can filter it.
Let's not go crazy now.