>I actually quite like the idea of control codes in commit messages for internal teams where you can implement rules.
>It could be useful for highlighting risky commits in red or other visual markers.
Yeah... that is really not a good idea. You are not supposed to take this blog post seriously.
Why not just agree on some terminology like CRITICAL/MINOR/SECURITY, which a visual interface can then highlight?
SECURITY: Fix XSS in spline reticulation
If it detects "SECURITY" it adds a red background, etc. Anyone viewing the raw text version of the commit messages will still get the message without having to see a bunch of gibberish.
ANSI control characters include cursor positioning, so in theory you could implement marquee messages. The problem would be introducing delay. I don't recall if you can do that using ANSI. You can emulate it by doing repeated cursor repositioning, but that would be rendered so quickly that the commit message would have to be enormous to include any appreciable delay.
I think the most devious would be to simply move the cursor up one line. This would result in the 'git log' line being overwritten, and hiding the commit from casual scrutiny.
Well, then it fits; many terminal emulators don't support \e[5m as blink anymore. Xterm, URxvt, and Konsole do, but the Linux terminal doesn't (gives it a grey background, not blinking), VTE-based terminals (gnome-terminal, lxterminal, ...) don't (ignored), Emacs term-mode doesn't (treats it as bold).
The "gray background" is really a "bright black" background. The old IBM CGA and successors had a flag for whether to interpret the top bit of the background color as intensity or blink[0]. It looks like Linux used to have it set to blink a few years back[1].
Haha, what a coincidence. Just the other day we discussed string special cases[0][1], to which I contributed ansi escapes. Unicode "fonts" 𝓵𝓲𝓴𝓮 𝖙𝖍𝖎𝖘 seem to work in commit messages as well.
I think this is quite harmful, especially the character movement ansi escapes could be used for nefarious purposes.
Just yesterday I ran across this example: "(っ˘▽˘)っ :cloud: ⊂(◕。◕⊂)" in the Parse SDK repo, which I found especially distracting, and in general, kind of turned me off from the project (even though I know Parse is awesome). I agree that UTF and special-chars should be permissable; I don't agree that if they don't actually communicate something, they should be used anyway. Maybe this cute 'moticon trend is trendy, but for my buck$, I'd rather things just be kept simple. My eyeballs see (っ˘▽˘)っ :cloud: ⊂(◕。◕⊂) as line-noise, mostly, and make me wonder if there are other such typo's to be found in the attached code-base.
We are all gonna die anyway. The mature commiters too, including everybody they love.
And all of their "serious" work will amount to absolutely nothing in just 100 years (that's it if they're lucky: for most their work wont matter at all in 10 or 20 years, their companies shuw down, or bought and dismantled, their startup dreams shattered etc.).
(A lot of them will even regret working so hard and giving importance to the BS they gave importance to after they retire).
Just to put some mature perspective on being playful.
Some Unicode characters can also move the cursor in strange ways. I think most of them only work in GUI programs, though. (See the list of bad strings above)
>Just yesterday I ran across this example: "(っ˘▽˘)っ :cloud: ⊂(◕。◕⊂)" in the Parse SDK repo, which I found especially distracting, and in general, kind of turned me off from the project (even though I know Parse is awesome).
This reasoning turns me off from types who have it.
It's not like they use emoticons everywhere -- and if having one is the big distraction one can complaint about, then their repo is in excellent shape.
I recently had to write some code[0] that handles strings of UTF-8 with ANSI color escapes sprinkled throughout.
A fun exercise is to write a function that overwrites string A with string B, starting at index N. It's hard enough with unicode, but ANSI escapes make it more fun.
> So the basic TL;DR: please don't use really ancient terminal programs that are vulnerable to this stuff.
Disappointing that he would make this statement and then not bother to recommend specific ones to avoid and/or use.
Doesn't work on Xfce either. On a virtual terminal thingy (ctrl-alt-f1) it shows a grey background with white text. I suspect blink is only implemented on the Mac's terminal, not in Linux-land.
I suspect it's really not a terminal issue but something about git. Or does a Terminal that doesn't interpret a command print it in clear text? I just get the string back, the same way I entered it.
It's definitely a terminal thing. The "bug" in git is that it doesn't strip out the control characters or reject the commit if the commit message contains non-text data.
This works for me in OS X's built-in Terminal app, but not iTerm. Both report xterm-256color as $TERM, so I'm not sure what about iTerm is configured differently to prevent it from working there.
"XSS has nothing to do with {my website framework}, it just applies javascript that work anywhere in a compatible browser."
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.
I see your point, and I agree. The OP didn't mention that aspect, but yes, git is darned crappy software, repeating stupid mistakes that are long forgotten elsewhere. Some developers don't seem to be learning from past mistakes.
Why would git strip formatting from my message? If my team wants colorful messages why should git be the one to say we're wrong?
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.
If you need to have this feature, then you should have to opt in (git config for example). But i have very good reasons to say that the default should properly escape the messages before printing them. I would not like it to clone a repo from github and having "git log" let my terminal go crazy. You unterstand, that this issue can have bigger impact than blinking commit messages, right?
Terminal attacks are not new and the solution isn't to expect every individual program to escape terminal escape codes.
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.
So to be clear, the article isn't suggesting that e.g. github will interpret the ANSI escape sequences, but they will be when you `git log` from a command line, right?
We cannot know (in principle) what GitHub does with data streams sent their way, but in the case of the blinking, the target is your terminal. It will interpret and “execute” (by modifying display) any text it is given.
104 comments
[ 4.4 ms ] story [ 54.0 ms ] threadIt could be useful for highlighting risky commits in red or other visual markers.
Would play merry hell with almost every other way of viewing commits though :D
>It could be useful for highlighting risky commits in red or other visual markers.
Yeah... that is really not a good idea. You are not supposed to take this blog post seriously.
Why not just agree on some terminology like CRITICAL/MINOR/SECURITY, which a visual interface can then highlight?
If it detects "SECURITY" it adds a red background, etc. Anyone viewing the raw text version of the commit messages will still get the message without having to see a bunch of gibberish.And you were not supposed to take my comment seriously... I thought I made that obvious with the last sentence but oh well.
Works for OS X apparently.
But you can make your text black with a black background. Or re-order lines, which I suspect to be "fun" for git logs.
[0] http://webpages.charter.net/danrollins/techhelp/0087.HTM
[1] http://sourceforge.net/p/linux-fbdev/mailman/message/7849329...
https://iterm2.com/images.html
Edit: even animated gifs
I think this is quite harmful, especially the character movement ansi escapes could be used for nefarious purposes.
[0] https://news.ycombinator.com/item?id=10035008
[1] https://github.com/minimaxir/big-list-of-naughty-strings/blo...
Like what?
It's all going to depend on the team; it would be a mistake to conflate seriousness with competence.
And all of their "serious" work will amount to absolutely nothing in just 100 years (that's it if they're lucky: for most their work wont matter at all in 10 or 20 years, their companies shuw down, or bought and dismantled, their startup dreams shattered etc.).
(A lot of them will even regret working so hard and giving importance to the BS they gave importance to after they retire).
Just to put some mature perspective on being playful.
This reasoning turns me off from types who have it.
It's not like they use emoticons everywhere -- and if having one is the big distraction one can complaint about, then their repo is in excellent shape.
- Rewrite the commit hash in git log with character movement
Actually I don't know if it's a practical attack in any way, could cause some confusion.
A fun exercise is to write a function that overwrites string A with string B, starting at index N. It's hard enough with unicode, but ANSI escapes make it more fun.
[0]: https://github.com/tillberg/ansi-log (Go logging library with support for ANSI colors and interleaving multiple writers)
Anyway, they default to "linux" for more than a decade.
...Lord, when did I get so old? :/
EDIT: https://en.wikipedia.org/wiki/VT100
https://en.wikipedia.org/wiki/ANSI_escape_code
It's definitely a terminal thing. The "bug" in git is that it doesn't strip out the control characters or reject the commit if the commit message contains non-text data.
Off by default; enable and blink like its 1989.
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.
Let's not go crazy now.
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.
[0]: http://marc.info/?l=bugtraq&m=104612710031920
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.
[1] https://en.wikipedia.org/wiki/ANSI_escape_code