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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

A brief history of one line fixes

264 点作者 coconutrandom大约 11 年前

22 条评论

chimeracoder大约 11 年前
&gt; What do all these earlier mistakes have in common, apart from the obvious: being exemplars of “catastrophic loss of structural integrity”? They all date from before 2013. That’s how we know the NSA wasn’t involved.<p>I get that this is trying to make fun of the response to Apple&#x27;s &quot;goto fail;&quot;, but this logic (&quot;These similar errors predate 2013 → Apple&#x27;s similar error was not an NSA backdoor&quot;) seems rather faulty. There are a number of flaws with this line of reasoning. To name a few:<p>* The NSA could have been involved with backdoors before 2013 (unlikely in Debian, but mentioning 2013 is a bit of a red herring)<p>* Apple could have been encouraged to insert a backdoor and did so in a way that gave them plausible deniability (either because the NSA specified that, or because they wanted to cover their behinds)<p>Whether or not this incident was the result of the NSA&#x27;s prompting is something we&#x27;ll probably never know[0], but this article doesn&#x27;t do much to argue one way or the other.<p>[0] The only way we could know is if someone literally came out and admitted it (or someone like Snowden were to leak it). It&#x27;s possible to prove the existence of something (ie, a backdoor attempt), but impossible to prove the absence of something.
评论 #7326429 未加载
评论 #7326111 未加载
评论 #7326091 未加载
评论 #7326079 未加载
评论 #7326126 未加载
评论 #7326168 未加载
评论 #7328576 未加载
fjarlq大约 11 年前
A favorite of mine, in C:<p><pre><code> ASSERT(apples = 1); VERIFY(oranges = 2); </code></pre> (Note the &#x27;=&#x27; means assignment, not comparison.)<p>Both are assertion-testers resulting in a core dump if the test fails, but ASSERT is only defined for DEBUG builds.<p>Since the assignments are to nonzero (true) values, buggy values of &#x27;apples&#x27; are silently corrected -- but only during test runs. Buggy values of &#x27;oranges&#x27; are always silently corrected.<p>Hilarity ensued. Afterwards, &#x27;gcc -Wparentheses&#x27; became mandatory.
评论 #7326082 未加载
评论 #7326728 未加载
mindslight大约 11 年前
<i>Cough</i>, there&#x27;s one major thing all of these bugs have in common - they&#x27;re all in C code.<p>This is mostly due to the volume and prominence of C. But a language with the same fundamental semantics of C but lacking the cleverbait syntax and weakened types would have prevented over half of these mistakes.
评论 #7326338 未加载
评论 #7326172 未加载
评论 #7326098 未加载
评论 #7326761 未加载
评论 #7326118 未加载
评论 #7327290 未加载
评论 #7331871 未加载
mpetrov大约 11 年前
The commentary on last example from Tarsnap seems wrong. The error was that the nonce stopped being incremented (see the linked Tarsnap blog post), but the author suggests the issue there is the unbraced if. The unbraced if is still not great style, but it wasn&#x27;t the cause of the security blunder.
评论 #7326181 未加载
评论 #7325872 未加载
评论 #7326760 未加载
yeukhon大约 11 年前
I have done similar thing to myself in Python, sabotaging my own little project. The following is not a rare thing. Imagine this were initializing random key in TLS... But since Python syntax is arguably cleaner and more readable, it&#x27;s easier to catch. But that&#x27;s a bet we have to put up with...<p><pre><code> &gt;&gt;&gt; def f(a,b=[]): ... b.append(a) ... return b ... &gt;&gt;&gt; print f(1) [1] &gt;&gt;&gt; print f(1) [1, 1] &gt;&gt;&gt; print f(1) [1, 1, 1] &gt;&gt;&gt; import random &gt;&gt;&gt; def key(): ... return random.randint(1,10000) ... &gt;&gt;&gt; def f2(a, b=key): ... return b() ... &gt;&gt;&gt; def f3(a, b=key()): .... return b &gt;&gt;&gt; f2(1) 3974 &gt;&gt;&gt; f2(1) 8684 &gt;&gt;&gt; f3(1) 2867 &gt;&gt;&gt; f3(1) 2867</code></pre>
评论 #7326137 未加载
评论 #7326464 未加载
_pmf_大约 11 年前
&gt; How is this possible? Does nobody use a compiler that warns about comparisons always being false?<p>External symbols are resolved at link time; as far as the compiler is concerned, setuid might be a symbol declared as __weak.<p>I don&#x27;t particularly like the snide remarks towards the maintainers of these libraries.
评论 #7326485 未加载
评论 #7326304 未加载
claudius大约 11 年前
Regarding the Debian OpenSSL disaster, the question <i>was</i> brought up on the OpenSSL mailing list (and read there); regarding the Tarsnap bug, it is not an unbraced if but a non-incremented nonce. If two of the five comments in an article are obviously wrong, how much trust should I possibly put into the remaining 60%?
评论 #7325778 未加载
jodrellblank大约 11 年前
Another thing they have in common is trying to reason about security of SSL certificate chains and other high abstraction concepts in terms of C pointers and function return values.
IvyMike大约 11 年前
Maybe that will be my new way to measure the effectiveness of my test suite.<p>&quot;Imagine the NSA snuck a one line &#x27;fix&#x27; into your software overnight. Do your tests quickly and accurately detect the problem and point to the code that is broken? If not, your unit tests are broken.&quot;
评论 #7326357 未加载
评论 #7327408 未加载
MBlume大约 11 年前
Lint tools exist.<p>My number one take away from this is that <i>we should all be using them more</i>.
评论 #7326848 未加载
adamlj大约 11 年前
&quot;This is an important lesson to learn: Mistakes can happen any time a piece of code is modified.&quot;<p>From <a href="http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html" rel="nofollow">http:&#x2F;&#x2F;www.daemonology.net&#x2F;blog&#x2F;2011-01-18-tarsnap-critical-...</a> regarding the Tarsnap bug.<p>Solution: write more unit tests.
评论 #7325991 未加载
nemothekid大约 11 年前
A lot of arguments center around &quot;well, the compiler should have done X!&quot;<p>I don&#x27;t write a lot of C code, but when I did, and even more relevant - when I compile packages, the compiler tends to spit out chapters worth of warnings that I just ignore. How accepted is compiling C code in practice with Werror? Could it be the compiler did warn about goto fail, and the OP&#x27;s error, but it was 1 warning out of a million? Really interested in an answer from those who work in C shops.
评论 #7326906 未加载
评论 #7326644 未加载
评论 #7326642 未加载
评论 #7327641 未加载
评论 #7329833 未加载
Rygu大约 11 年前
1. Start writing tests. Tests will save your ass when you&#x27;re merging a feature branch. Cause are you sure everything still behaves correctly after those ingenious refactorings?<p>2. Use an IDE and&#x2F;or compiler that actually warns you about common human errors like unused variables, unreachable statements, and dumb mistakes like a case-block with silent fallthrough to the next case-block.<p>3. Acknowledge responsibility when writing security related code. Know that there&#x27;s no room for mistakes.
matt__rose大约 11 年前
with the X bug, building X has always triggered tons of warnings, it&#x27;s easy to see why they&#x27;re overlooked <a href="http://keithp.com/blogs/xserver-warnings/" rel="nofollow">http:&#x2F;&#x2F;keithp.com&#x2F;blogs&#x2F;xserver-warnings&#x2F;</a>
julie1大约 11 年前
openBSD credo: security bugs are just bugs.<p>Mostly human, and avoidable but always present because people don&#x27;t take the time to do it correctly. Quality, taking the time to make the things right, slowly, correctly, all that matters more than genius. Quality code at all level is the key to secure development. Every little things count.<p>I know a few openBSD developers, and their song about doing the right things, taking our times to do it correctly - simpler, with quality because it is the shortest path to correctness thus speed (what is the use of an incorrect program: none). This song is appealing. The fact they are strangely psychopathic paranoid nerds is not ;)<p>I think computer industry would be far better if we would slow down and focus on doing less software, but better built.<p>Less functionalities maybe, but the one that maybe more powerful. The stable foundation for sustainable progress.<p>And, if you like them -even though they are repulsing antipathic nerds- you can support them :)
评论 #7327100 未加载
chetanahuja大约 11 年前
To those learning C programming &quot;by reading other&#x27;s code&quot;, following is an example of what not to do (either the subtracted or the added line).<p>[Now I wait for a deluge or replies about how it&#x27;s &quot;idiomatic&quot; C. All I have to say to that is, s&#x2F;ma&#x2F;&#x2F; ]<p><pre><code> --- libc-a&#x2F;memset.c +++ libc-b&#x2F;memset.c @@ -1,6 +1,6 @@ void *memset(void *_p, unsigned v, unsigned count) { unsigned char *p = _p; - while(count-- &gt; 0) *p++ = 0; + while(count-- &gt; 0) *p++ = v; return _p; } </code></pre> [Edited later to use the code mode]
评论 #7326718 未加载
评论 #7328335 未加载
评论 #7326510 未加载
chris_wot大约 11 年前
Actually, with the Debian SSL &quot;fix&quot; that removed entropy, the dev who made the change <i>did</i> ask about it on IRC. Though a bad mistake, it&#x27;s understandable how it happened.
tbmatuka大约 11 年前
This one may not be as bad as the ones in the article, but it still gave us a few weeks of work upgrading kernels on a couple of thousand production servers: <a href="http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8176cced706b5e5d15887584150764894e94e02f" rel="nofollow">http:&#x2F;&#x2F;git.kernel.org&#x2F;cgit&#x2F;linux&#x2F;kernel&#x2F;git&#x2F;torvalds&#x2F;linux.g...</a>
ybaumes大约 11 年前
In the example of the Apple bug, I&#x27;ve read it took eighteen months (!!) to discover it after it has been committed in the source code base. As a consequence, I would be interested in knowing, for each bug, the time it took to discover them.<p>Also, I assume that once discovered, the time to fix it is usually negligible. Usually. And as long as you don&#x27;t count the time for full deployment in production...
rjzzleep大约 11 年前
i&#x27;m actually a little surprised about the openssl one. I always assumed it would be good practice to number error codes negatively. OTOH that&#x27;s also kinda expected behavior for reverse engineers. if the return value is negative you can be almost certain it&#x27;s an error code<p>i guess whoever wrote that line thought the same.
jonalmeida大约 11 年前
I&#x27;ve come across a bug that was probably caused by a developer that held the Ctrl key while pressing the up arrow which caused the selected line to move above another.<p>It luckily only took me a full day to find within the codebase..
dhugiaskmak大约 11 年前
&quot;Never write your own security code, because you&#x27;ll get it wrong. Leave it to the smart people.&quot;