TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Show HN: Hiding code from Git diff

167 点作者 dimastopel超过 7 年前

13 条评论

pkamb超过 7 年前
The way I&#x27;ve noticed people (accidentally) &quot;hiding code&quot; is by making changes during the conflict resolution stage of a git merge.<p>This often happens <i>after</i> code review, and there&#x27;s no oversight of the conflict resolutions.<p>If the merge commit does get looked at, there will be potentially hundreds of lines and files of automated diffs within which the unrelated new code is hidden.
评论 #15918283 未加载
评论 #15918183 未加载
评论 #15918381 未加载
评论 #15918065 未加载
评论 #15920119 未加载
评论 #15918086 未加载
kbutler超过 7 年前
The issue with with terminal handling of escape sequences, rather than with git.<p>If you are concerned, you can use a gui diff tool, or you can pipe it through a filter that removes escape codes:<p><pre><code> seal:~&#x2F;work&#x2F;gitPocDiff$ cat &gt; uncolor #!&#x2F;usr&#x2F;bin&#x2F;env perl ## uncolor — remove terminal escape sequences such as color changes while (&lt;&gt;) { s&#x2F; \e[ #%()*+\-.\&#x2F;]. | (?:\e\[|\x9b) [ -?]* [@-~] | # CSI ... Cmd (?:\e\]|\x9d) .*? (?:\e\\|[\a\x9c]) | # OSC ... (ST|BEL) (?:\e[P^_]|[\x90\x9e\x9f]) .*? (?:\e\\|\x9c) | # (DCS|PM|APC) ... ST \e.|[\x80-\x9f] &#x2F;&#x2F;xg; print; } seal:~&#x2F;work&#x2F;gitPocDiff$ chmod a+x uncolor seal:~&#x2F;work&#x2F;gitPocDiff$ git diff eeeb ebc3 | .&#x2F;uncolor diff --git a&#x2F;main.c b&#x2F;main.c index 6daa9b2..0321ff2 100644 --- a&#x2F;main.c +++ b&#x2F;main.c @@ -3,4 +3,9 @@ int main() { printf(&quot;I&#x27;m just a stub!\n&quot;); + &#x2F;* + * Must always return a value Hidden &gt; *&#x2F;printf(&quot;Insert bad backdoor here...!\n&quot;);&#x2F;* + * TODO: Return result + *&#x2F; + return 0; } </code></pre> Credit to: gilles <a href="https:&#x2F;&#x2F;unix.stackexchange.com&#x2F;a&#x2F;14707" rel="nofollow">https:&#x2F;&#x2F;unix.stackexchange.com&#x2F;a&#x2F;14707</a>
评论 #15920392 未加载
mikedilger超过 7 年前
If the output of a git command was raw text sent to stdout, like cat, then I would argue that escape sequences should be ignored and passed through unmolested.<p>But the output of git tools is colored (if enabled) using terminal escape sequences. Given that, the output should fully comply with the appropriate terminal escape sequences and should filter the ones the author has discovered.
deathanatos超过 7 年前
Unix pipes lack any ability to say &quot;this is the <i>kind</i> of data that I&#x27;m pushing you.&quot; The push raw, unidentified bytes. If the downstream program had some idea what format the data was in, it would know how to output it.<p>Imagine an alternate universe where a pipe was a stream of bytes and a MIME type. If a terminal gets data written to it from a program in application&#x2F;terminal.vt100, then it knows it should process those escape sequences. If it get text&#x2F;plain; charset=utf-8, it knows it should not, and can take a different action.<p>I think such a universe would make for more pleasant piping, too. Imagine that every interactive command on a terminal ended with an imaginary |show command; it&#x27;s job is to read the mimetype and display, on the terminal, that data. A command that emitted CSV data could then automatically render in the terminal as an actual table. A program that emitted a PNG could render an ASCII art version of that image (or, since we&#x27;re in an imaginary universe, imagine our terminal has escape sequences for images – which actually exists in some terminals today – it could emit the actual image!). Essentially, the program emits the data in whatever form it natively speaks, and that implicit |show parses that into something appropriate for the terminal. (That way, the program can still be used in pipelines, such as make_a_png | resize_it.) If you want your raw bytes, then you can imagine<p><pre><code> make_a_png | force_type &#x27;application&#x2F;octet-stream&#x27; </code></pre> and then the final, implicit |show would perhaps output a nice hexdump for you. (Since emitting raw bytes to a terminal never makes sense.)<p>Now, I&#x27;m a bit fuzzy on exactly how the pipeline being executed, the shell, and the terminal all interact exactly, and I&#x27;m nearly certain such a change would require low-level, POSIX-breaking changes. But it was a dream I had, and I think it might be a better model than what we work w&#x2F; presently.<p>(In the article&#x27;s case, though, git log&#x2F;diff both emit terminal sequences, so even in my imaginary world, they&#x27;d need to know that they should escape them. It mostly works for simpler types, but git rm could conceptually emit just text, since I don&#x27;t think it ever colors.)
评论 #15918512 未加载
评论 #15918993 未加载
评论 #15919373 未加载
评论 #15918910 未加载
评论 #15918604 未加载
ComputerGuru超过 7 年前
I actually reported this same issue but under the context of a bug rather than as a security issue, exactly 2 months ago: <a href="https:&#x2F;&#x2F;public-inbox.org&#x2F;git&#x2F;CACcTrKctqAWeWWrc9Q+Y7ewXGc_o+uJoeHS83LDw5O_s1-3Nug@mail.gmail.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;public-inbox.org&#x2F;git&#x2F;CACcTrKctqAWeWWrc9Q+Y7ewXGc_o+u...</a><p>Same response, “it’s the pager’s job,” in that case.
评论 #15919028 未加载
CGamesPlay超过 7 年前
This is tenuous at best. iTerm2, at least, doesn&#x27;t support the &quot;conceal&quot; color (^[[8m) and any other color would rely on the &quot;victim&#x27;s&quot; color scheme to work properly. Git is safely removing sequences that could actually cause problems like OSC. This technique also wouldn&#x27;t stand up to review on Github or any other online code review platform.
carapace超过 7 年前
(Tiny grey sans-serif body text means you hate your readers&#x27; eyes.)
jsteemann超过 7 年前
One mitigation for this is to use `col -bp` as a git pager, but it seems clumsy. However, for completeness I post it here with an example for how this makes the backdoor visible.<p>Reproduce instruction:<p># clone repo and cd into it<p>git clone <a href="https:&#x2F;&#x2F;github.com&#x2F;twistlock&#x2F;gitPocDiff" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;twistlock&#x2F;gitPocDiff</a><p>cd gitPocDiff<p># show diff (this includes the backdoor but it won&#x27;t be visible)<p>git show ebc3f506a7ec8278e1a3ad4108612b66d10b41ca<p># expose the backdoor, using `col -bp` as pager<p>git show ebc3f506a7ec8278e1a3ad4108612b66d10b41ca | col -bp
评论 #15919063 未加载
tomcam超过 7 年前
Unfortunately had to stop reading due to their text-hiding scheme--miniscule light-gray text on white background
评论 #15918981 未加载
评论 #15920736 未加载
amigoingtodie超过 7 年前
What about code being &#x27;deleted&#x27; that git diff does not catch?<p>Is there a recommended external diff tool that ameliorates these issues?
评论 #15917905 未加载
评论 #15919038 未加载
ChuckMcM超过 7 年前
Interesting to see how the standardization of escape sequences by ANSI leads to a vulnerability in code obfuscation.
评论 #15919766 未加载
unhammer超过 7 年前
magit ftw: <a href="https:&#x2F;&#x2F;i.imgur.com&#x2F;a8Mvbkf.png" rel="nofollow">https:&#x2F;&#x2F;i.imgur.com&#x2F;a8Mvbkf.png</a><p>Though I&#x27;m sure Emacs has loads of other vulnerabilities :)
always_good超过 7 年前
Some pitiful Vimming right there. From holding down `h` for 30 seconds to go to the beginning of line to using :wq instead of :x.