Blinking Commits
blog.annharter.com git commit -F <(curl https://raw.githubusercontent.com/thiderman/doge/master/doge/static/doge.txt) # [0]
git commit --allow-empty -F <(curl https://raw.githubusercontent.com/thiderman/doge/master/doge/static/doge.txt)
Funny timing, with the recent "Terminal escape sequence XSS" post on oss-security in mind: http://www.openwall.com/lists/oss-security/2015/08/11/8
> 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.
Regrettably (?), you can't use this to implement marquee.
But you can make your text black with a black background. Or re-order lines, which I suspect to be "fun" for git logs.
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.
iTerm2 supports images in the terminal. May as well take this as far as it will go.
https://iterm2.com/images.html
Edit: even animated gifs
Ranger utilizes this well on (not just on iterm) http://ranger.nongnu.org/ - a VIM-style terminal-based file explorer via w3m.
Unfortunately only with iTerm2 it seems able to play animated gif.
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.
Would play merry hell with almost every other way of viewing commits though :D
>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?
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.SECURITY: Fix XSS in spline reticulation> You are not supposed to take this blog post seriously.
And you were not supposed to take my comment seriously... I thought I made that obvious with the last sentence but oh well.
Has nothing to do with git, or committing, it just applies VT100 control codes that work anywhere in a compatible terminal.
"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.
Are you cloning untrusted repositories to your computer and running git log blindly?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]no?
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.
Automagically? The terminal emulator's job is to parse and interpret those sequences.
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.
> git is darned crappy software
Let's not go crazy now.
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?
Correct, this is an ANSI escape code[1] interpreted by terminals, not XSS.
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.
To insert a literal character (like the Escape entered in this post) in Emacs, use C-q.
Of course, you can also use other escape codes to make your commits colored (e.g. [92m for green), underlined ([4m), etc.
Or change the terminal title. ^[]0;title^G
Or for screen and tmux:
^[ktitle^[\
So, 1990's Geocities commits are now a thing again? ^[[5m#UNDER CONSTRUCTION^[[0m
The writing style is clever and funny. You should keep writing!
I think this post just changed my position on censorship :p
Will it still work if I omit the closing bracket? Or put it in a different commit message, further down the page?
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.
The author uses female pronouns.
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.
On the matter of education, singular they is historically supported: https://en.wikipedia.org/wiki/Singular_they#Older_usage_by_r...
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.)
In the world of ANSI escape codes and terminal emulators things are never that easy.
Works for OS X apparently.
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.
[0] https://news.ycombinator.com/item?id=10035008
[1] https://github.com/minimaxir/big-list-of-naughty-strings/blo...
I wrote a little thing that helps you make your commits ๐ข๐ต๐ฑ๐ฏ๐ ๐๐ด๐ข๐ฐ๐ฌ๐ช๐ข: http://antglove.com/erger/
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.
[0]: https://github.com/tillberg/ansi-log (Go logging library with support for ANSI colors and interleaving multiple writers)
I think this is quite harmful, especially the character movement ansi escapes could be used for nefarious purposes.
Like what?
- Push malicious commit
- 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.
If you can commit, why not just enter something like "Small fix in formatting" instead of drawing of LOT of attention to malicious comit?
Hiding changes on previous lines.
Annoying your coworkers, for one
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)
I personally just find the committer to be immature, nothing else.
Immature to one is playful to another. :-)
It's all going to depend on the team; it would be a mistake to conflate seriousness with competence.
I personally see it as a filter to exclude those who find things too seriously.
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.
iTerm2 has an option in your Profile: Text tab > Text Rendering: "Blinking Text Allowed"
Off by default; enable and blink like its 1989.
same here
I wonder if GitHub do/will support this and parse it to HTML
If they did they'd have to wrap it a <blink> tag. Anything else would just be sacrilege
Unfortunately most browsers don't have <blink> support anymore
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].
[0] http://webpages.charter.net/danrollins/techhelp/0087.HTM
[1] http://sourceforge.net/p/linux-fbdev/mailman/message/7849329...
Its not supported currently at least. I get
[5mFoo[0mThere's absolutely no reason for it to be ever supported.
Killer feature :D
Doesn't work in my gnome-terminal. Looks like the commands get escaped by git somehow. Did anybody test it?
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 blink is only implemented on the Mac's terminal, not in Linux-land.
...Lord, when did I get so old? :/
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.
What?
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.
You can set Xterm and Konsole to be VT100 compatible. I dunno about Gnome Terminal.
Anyway, they default to "linux" for more than a decade.
It does work in urxvt and konsole (and there's an option to turn it off). And as tempodox said, this is just VT100 stuff.
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?"
Every time I use a control character, my mind strays back to CHR$141.
Although I do wonder what havoc you could wreak on hosted git services with cunning sequences of control characters. Smacks of injection.
If anyone else is curious about CHR$141, it's how you can show doubly-tall letters on an Acorn BBC Micro's teletext display...
First emojis, now blinking text, this has to stop.
Can you turn it off? I'd imagine a big project (e.g. Linux Kernel) could start to look like a Christmas tree...
ok now i need a spam filter for git log - everything is flashing like "look at my nice changes here!" :)
THIS COMMIT IS REALLY IMPORTANT!!11
YOU ARE THE 1000000th VISITOR OF THIS GIT LOG!
You were more concerned with whether or not you could you never stopped to think whether or not you should
Nah, they just want to watch the world burn.
After the emoji, the blinking... Will git commits become like the 2000s web? :p
Wait 'till someone figures out he/she can store a webpage inside commit message.
and wait 'till someone figures out they can store ads inside commit messages.
actually, this could be done by github for some extra buck.
We just need a marquee now.
I say leapfrog directly to WebGL commit messages.
All this talk about ASCII control codes and no one mentions 0x07 aka โ?
Surely, there is a way to do this in Sublime?
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.