> 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.
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.
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 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.
"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.
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.
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.
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.
Anyone know if an issue has been opened (or any relevant discussion on the dev list) on stripping escape sequences? It does seem like it could be harmful.
This is a really entertaining writing style: technical enlightenment through demonstration via humorous examples. For the lazy (and additional humorous demonstration), I wish he'd provided an example gif showing it in action (i.e., Github, terminal, Sourcetree, etc...).
(The terminal would be the only place it would display correctly it seems, but it would be nice to see the chaos it may or may not cause in Github and other tools.)
Finding someone who can write very technically while also being funny and charismatic is pretty rare (We computer types aren't always the biggest hits at parties). I also really appreciate his "last time on" opening paragraphs... it gives some context to the blog post and where's coming from in his headspace. Neat.
There are no gendered pronouns in her blog post.[1]
At first, I was surprised to find I falsely assumed she was male in spite of evidence to the contrary, and was going to thank you for making me more aware of my own oversight. Upon review, however, I made the correct assumption that it was non-gendered. I'll forego the inciting comment, and corresponding cultural political flamewar over my use of a singular default male pronoun. If you down-voted me, please understand that doing so is alienating and a disservice to conversations. We should not punish commenters for failing to conform to our own personal cultural norms. This is consistent with the spirit of your comment; engineers need not conform to external expectations of a masculine identity.
[1] Her handles at the bottom are neither pronouns, nor in the blog post, and were inconsequential to me given my present lack of motive for reaching out to the author.
I didn't downvote you. (Downvotes are heavily rate-limited, at a guess, from very unscientific observation, I think I only get ten a day, so I save them for the really annoying comments.)
I'm not sure why you think he/his pronouns are nongendered. The nongendered pronouns in English are they/them.
You're continuing to controversialize and divert from the original conversation. That said...
> I think I only get ten [downvotes] a day, so I save them for the really annoying comments.
10 downvotes a day? Please reconsider your behavior. You are almost certainly unnecessarily alienating commenters, and in this case, misguidedly so.
> I'm not sure why you think he/his pronouns are nongendered.
When I said "it was non-gendered," I was referring to the blog post, which meant your original comment, "The author uses female pronouns," is factually incorrect.
> The nongendered pronouns in English are they/them.
I'm aware, and intimated as much: "I'll forego [discussing] my use of a singular default male pronoun". Yes, they/them is non-gendered, but it is also plural, making it grammatically historically incorrect. However, despite the informality of my comment, given the extreme propensity of the "generic he" to be controversialized, especially in technology and the internet, and the movement away from it during my lifetime, I'll placate to avoid the negative insinuations.
Educating yourself on the context of the matter would go a long way to ameliorate your sanctimonious attitude, and hopefully disincline you to feel the need to controversialize, divert and detract from conversations in the future.
Yes. I'm aware. I was trying to be as terse as possible on the diverting topic. It's disputed whether past singular they was considered grammatically correct at the time, despite the source. Of course, then you have to define what it means to be "considered grammatically correct" and who decides that and now you're entering a whole subjective can of worms that turns into circular logic, leading back to the realization that language is largely cultural and expressive, not technical, unfortunately. All of these are reasons why there's not much room for a logical argument here, and only an appeal to emotion, bandwagoning, and some historical bad actors making the "generic he" untenable.
Still, the OC was factually incorrect and this entire topic is diverting and as you've now contributed to with your sanctimonious desire to prove me wrong, controversialized and alienating here on HN.
they/them are non-gendered by the older (grammatical) meaning of "gender".
he/his and they/them both have well-established non-gender-specific meanings in the more recent (social) meaning of "gender" (prior to that fairly recent linguistic evolution, words had gender and people had sex -- while its useful to have a term for the distinct feature of people referred to by "gender" as distinct from "sex", its a very different thing than grammatical "gender", and grammatical gender doesn't have a 1:1 mapping to linguistic constructs whose semantics refer to social gender), though he/his also has a gender-specific meaning (and there is considerable potential for ambiguity between the gender-neutral and gender-specific senses of he/his.)
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.
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.
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.
>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.
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)
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.
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.
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].
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.
Who remembers when most of the blogs syndicating discussions about RSS all started blinking at once, when somebody posted an item whose title was "What happens when you put a <blink> tag into the title?"
If you can insert the ESC character, u001B, it's easy. (Though note that it appears as the two characters ^[ in the blog post, so your code should start ESC[5m with only one bracket.)
Unfortunately Sublime wasn't happy with me trying to type it through the Mac Unicode Hex input, but I was able to copy-paste it in, and I was also able to enter it directly in other programs, like GitHub desktop.
[0] https://github.com/thiderman/doge