A brief history of one line fixes

http://www.tedunangst.com/flak/post/a-brief-history-of-one-line-fixes

by coconutrandom • 12 years ago

264 153 12 years ago

claudius2• 12 years ago

Regarding the Debian OpenSSL disaster, the question was 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%?

tokenrove• 12 years ago

It's sarcasm. You've missed the rhetorical point of the article.

(To be more clear, each comment mimics the comments made about the "goto fail" bug, and the crucial point is not pure mockery or a defence of Apple, but rather the final paragraph.)

thezilch• 12 years ago

The point is that because there are always mistakes in everything, that the NSA is never involved? Strange, because I'm sure they've been implicated more than zero times.

NOTE: I have no opinion on their involvement in the goto fail;

TwoBit• 12 years ago

Probably a lot of people missed this point of the article. It certainly seemed odd to me.

claudius2• 12 years ago

Oh. Okay. Sorry.

chengiz• 12 years ago

If there is sarcasm or rhetorical point to the article, it is not made clear at all. This is just poor writing.

mpetrov• 12 years ago

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't the cause of the security blunder.

wging• 12 years ago

The commentary does fit the recent Apple 'goto fail' bug. I think this post may've originally included it. Perhaps the wrong commentary got deleted.

clarry• 12 years ago

It is kind of on purpose, that's the whole point of the writeup. It's taking a little jab at everyone who proclaims a "simple and obvious" way any given error could've been avoided. Fact is, making the programmer type more (braces or other stuff) doesn't save him from himself; the goto fail error could've been made with braces just as well as without.

The other examples are make the same point. There are ways to help catch specific bugs. But there is no magic "fix it" button. Consider static analysis for example: you actually have to run it and inspect the output. You have to interpret it right. You have to fix it right. And so on. Human error can ruin each step, as has happened.

mst• 12 years ago

Yes. That was the joke.

adamlj• 12 years ago

"This is an important lesson to learn: Mistakes can happen any time a piece of code is modified."

From http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-... regarding the Tarsnap bug.

Solution: write more unit tests.

peterhunt• 12 years ago

Or use better abstractions / static analysis.

jodrellblank• 12 years ago

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.

fjarlq• 12 years ago

A favorite of mine, in C:

  ASSERT(apples = 1);
  VERIFY(oranges = 2);

(Note the '=' means assignment, not comparison.)

Both are assertion-testers resulting in a core dump if the test fails, but ASSERT is only defined for DEBUG builds.

Since the assignments are to nonzero (true) values, buggy values of 'apples' are silently corrected -- but only during test runs. Buggy values of 'oranges' are always silently corrected.

Hilarity ensued. Afterwards, 'gcc -Wparentheses' became mandatory.

fooyc• 12 years ago

One way to avoid this kind of mistakes is to use Yoda conditions [0]:

    ASSERTS(1 == apples);

If you forget one `=`, it doesn't compile.

[0] https://en.wikipedia.org/wiki/Yoda_conditions

deletes2• 12 years ago

I don't think learning this is worth it. Using this will not always warn you( complicated expression or variables ) and you still might miss something.

+EDIT: In those occasions when you actually compare to a integer, the expression is so simple that you immediately understand the whole line. In case of an actual typo the compiler will warn you, and the inversion is not needed. Nowadays, there is simply no excuse for a ignored or missed( bad compiler ) warning.

Assignment in an If statement must produce a warning!

hibbelig2• 12 years ago

I like Yoda conditions not only because it protects against the missing "=", but also because often the constant is the shorter side, so reading

    if (42 == some_long_expression_here)
    {
        ...
    }

It is immediately clear that the rest of the line after the two equals signs must be an expression because the curly brace in the beginning of the next line. So folks don't have to bother that much about counting parens.

chris_wot3• 12 years ago

Don't most compilers give a warning for this sort of thing?

oneeyedpigeon• 12 years ago

On the other hand, Yoda conditions are - as implied by the name - counterintuitive and, as pointed out below, aren't really necessary when compilers pick up this kind of error anyway. The real problem is that this kind of mistake is even possible in the first place.

yitchelle• 12 years ago

Side fun question: what was Yoda conditions called before Star Wars was in the cinemas?

wglb• 12 years ago

This technique was taught to me by Charles Fiterman, before he was at geodesic. And while compilers are a bit better about this nowadays, back then this was a good technique to use.

CUViper2• 12 years ago

Coverity has ASSERT_SIDE_EFFECT for exactly this sort of case.

chimeracoder• 12 years ago

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.

I get that this is trying to make fun of the response to Apple's "goto fail;", but this logic ("These similar errors predate 2013 → Apple's similar error was not an NSA backdoor") seems rather faulty. There are a number of flaws with this line of reasoning. To name a few:

* The NSA could have been involved with backdoors before 2013 (unlikely in Debian, but mentioning 2013 is a bit of a red herring)

* 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)

Whether or not this incident was the result of the NSA's prompting is something we'll probably never know[0], but this article doesn't do much to argue one way or the other.

[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's possible to prove the existence of something (ie, a backdoor attempt), but impossible to prove the absence of something.

yeukhon4• 12 years ago

It's pointless to discuss whether this is an intentional flaw or a mistake because the problem lies in code review and tool. As someone has said in the past to me that compiler can catch these errors, well, if so, what flags do they use and should we have a standard list of flags to enable to test these problems? Do we have tools to show these errors instead of going through a 1000 pages compiled log?

rjzzleep2• 12 years ago

i don't think it's pointless to discuss. sometimes it is sometimes it isn't.

in the apple case though the two revision numbers we have are 55179.13 and 55471. i don't know how apple numbers, so i'm not entirely sure what the .13 is, but theoretically we could have 292 patches between the two we see publicly.

it's impossible for us to know if there would have been a code change that could have caused a merge conflict at that place.

throwaway812• 12 years ago

The logic at the end is still in parody mode. Flawed is the point.

xenophanes• 12 years ago

What you've argued is faulty logic was actually sarcasm. One major clue is that the previous paragraph also contained heavy sarcasm.

joe_the_user• 12 years ago

Uh yeah, you're right. I'm surprised that didn't jump off the page at me but hey, I read the comments first and then the article too, failing "like a good banker", meaning succeeding in not spotting the bullshit but not any worse than my fellow hn-ers who also upvoted it.

I amazed your at bottom of the comments. But then again I was silly enough to upvote the parent before I read the full text.

"A sound banker, alas, is not one who foresees danger and avoids it, but one who, when he is ruined, is ruined in a conventional and orthodox way with his fellows, so that no-one can really blame him" - JM Keynes

GuiA2• 12 years ago

impossible to prove the absence of something.

If p => q, then ¬q => ¬p. So if p is "The goto fail was setup by the NSA", then surely we can come up with a reasonable q which could be (dis)provable?

GhotiFish2• 12 years ago

would it be something like this:

  if "setup by the NSA" then "goto fail"

I can think of a q that disproves p then!

  not goto fail.

problem is

  goto fail.

since q is true, p is either false or true, with no distinction either way. So... impossible to prove.

lstamour• 12 years ago

My takeaway was that the NSA could have been involved in all the above, we just weren't paying as much attention before ;-)

Of course, whether the NSA was involved or not isn't the point of this article. The point is that high severity one-liner bugs have been made before.

I feel partly to blame. Until my comment on HackerNews revealing where the source code was, no one seemed willing to post more details about the bug (based on Twitter posts). But I think it will end well, as more people will pay attention to the code in future. Sadly, Apple has yet to share revised source code for the 10.9.2-shipping security library that I'm aware of.

mindslight8• 12 years ago

Cough, there's one major thing all of these bugs have in common - they're all in C code.

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.

dror• 12 years ago

And C has this thing called lint that's only been around since 1979 that can detect many of these issues.

mindslight8• 12 years ago

Yes, many tools have been built to address the problems with C, and one is remiss if they ignore the greater development ecosystem.

But, that they're not integrated into the language itself means those tools can only ever make suggestions in a separate context, and so cannot function cohesively to permanently rule out classes of bugs in a way that can simply be taken for granted.

In fact, the Debian OpenSSL bug was actually caused [1] by a message from one of these tools being uncritically acted upon.

[1] the job of failure analysis is to find all contributing factors, not just pin everything on one.

philh2• 12 years ago

"Over half" is dubious.

The compiler could have prevented 'X' by not permitting "function == int" comparisons. That's 1/5.

The only thing you might be referring to with "cleverbait syntax" is the ++ fix in tarsnap, but note that the bug was not including ++. Being generous, we could say that if ++ wasn't allowed, it might have been more obvious that the code was broken, getting us 2/5. And being extra generous, maybe if `!i` was disallowed, they would have gone straight for `i <= 0` instead of `i != 0`. So 3/5, but yeah, dubious.

The only other one that's remotely like a C misfeature is that the compiler apparently didn't warn about 'unused parameter' in the Android bug.

mindslight8• 12 years ago

Yes, those are the three I am referring to, but I don't agree that any are generous or dubious. Out of the C context, what does "not integer" possibly mean? `i` should either have been a boolean, or apparently an explicit multi-state enum, rather than the ever-favored weakly-typed ubiquitous `int` that C makes so attractive.

I'm not claiming the unused parameter bug, because there can be legitimate unused function parameters, and we can easily envision a very similar bug that still used all parameters.

But add in the current Apple bug that precipitated this post, and you have 4/6.

The general defense by C programmers is that everything works as long as you do the right thing. I have been there. However as these bugs illustrate, vigilance does not scale.

emillon• 12 years ago

The compiler could have prevented 'X' by not permitting "function == int" comparisons. That's 1/5.

0 is also a special case litteral for the null pointer, and function names are valid in pointer contexts, so I'm not even sure that "f == 0" is badly typed.

stusmall4• 12 years ago

I would be more willing to blame C if these bugs were unsafe memory operations. Unused parameters, logic errors and assignment instead of comparison aren't unique to C and the language isn't without counter measures for them.

The X one is probably the only very C bug on the list and compiler warnings and/or a good static code checker would have found it.

mindslight8• 12 years ago

I deliberately did not address unsafe memory operations, because the current widely-accepted state of the art for memory safety is garbage collection, which has significant overhead. I could have also tooted the horn for Rust (or Felix/BitC/Deca), but my goal was not to point out blank-slate solutions, but just how much of C itself could be trivially fixed.

fulafel• 12 years ago

Compilers can't tell if a shared library symbol resolves to null.

asveikau• 12 years ago

I heard people working in those other languages never make mistakes.

chetanahuja11• 12 years ago

Yup. We found an exhaustive list of all ze software bugs and ... cough, cough, gasp, gasp... all happen to be in C. Whatever shall we do?

kcbanner• 12 years ago

C is the least of the problems here.

_pmf_• 12 years ago

How is this possible? Does nobody use a compiler that warns about comparisons always being false?

External symbols are resolved at link time; as far as the compiler is concerned, setuid might be a symbol declared as __weak.

I don't particularly like the snide remarks towards the maintainers of these libraries.

GhotiFish2• 12 years ago

I suspect the author is parodying the reaction towards apples mistake, and bares these maintainers no ill will.

spc4764• 12 years ago

I ran the following code through GCC:

    #include <stdio.h>
    #include <unistd.h>
    #include <sys/types.h>

    int main(void)
    {
      if (getuid() != 0 && geteuid == 0)
      {
        printf("only root\n");
        return 1;
      }
      printf("okay\n");
      return 0;
    }

With just a plain GCC (no options), the code compiled and exhibited the bug (it always printed "okay"). That's to be expected. What was not expected what when I compiled the code with "gcc -ansi -Wall -Wextra -pedantic". NOT ONE ERROR OR WARNING!

How is that happening?

Well, C allows function pointers. Also, in C, a value of 0 used in a pointer context is treated as a NULL pointer. So that one line is seen as:

    if (getuid() != 0 && geteuid == NULL)

Now, let's play compiler. geteuid() is a function and it's defined. So the compiler can generate:

    if (getuid() != 0 && false)

The result of this expression can never be true. But because the call to getuid() could cause side-effects (the prototype for getuid() does not include the GCC extension marking it as a "pure" function) the compiler has to emit a call to the function, but otherwise, it ignores the result since it doesn't matter what the result is. The resultant code is:

    int main(void)
    {
      getuid();
      printf("okay\n");
      return 0;
    }

And thus, it's possible, even with the commonly used "-Wall -Wextra" options to GCC. To detect this, you will also need to add "-Wunreachable-code" (why that isn't included with '-Wall' is a good question).

CUViper2• 12 years ago

"gcc -ansi -Wall -Wextra -pedantic". NOT ONE ERROR OR WARNING!

  $ rpm -q gcc
  gcc-4.8.2-7.fc20.x86_64
  $ gcc -ansi -Wall -Wextra -pedantic test.c
  test.c: In function ‘main’:
  test.c:7:36: warning: the comparison will always evaluate as ‘false’ for the address of ‘geteuid’ will never be NULL [-Waddress]
         if (getuid() != 0 && geteuid == 0)
                                      ^

If fact, just -Wall is enough to enable that warning. Maybe the coverage of -Waddress has changed since your version?

w-m• 12 years ago

huh?

gcc 4.2 -Wall:

  warning: the address of ‘geteuid’ will never be NULL

gcc 4.8 -Wall:

  warning: the comparison will always evaluate as 'false' for the address of 'geteuid' will never be NULL [-Waddress]
       if (getuid() != 0 && geteuid == 0)

Also, as came up in the goto fail discussion, -Wunreachable-code was removed from gcc and doesn't warn on anything.

yeukhon4• 12 years ago

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's easier to catch. But that's a bet we have to put up with...

    >>> def f(a,b=[]):
    ...     b.append(a)
    ...     return b
    ...
    >>> print f(1)
    [1]
    >>> print f(1)
    [1, 1]
    >>> print f(1)
    [1, 1, 1]


    >>> import random
    >>> def key():
    ...     return random.randint(1,10000)
    ...

    >>> def f2(a, b=key):
    ...     return b()
    ...
    >>> def f3(a, b=key()):
    ....    return b
    >>> f2(1)
    3974
    >>> f2(1)
    8684
    >>> f3(1)
    2867
    >>> f3(1)
    2867

GuiA2• 12 years ago

Well, any Python developer worth his salt knows that initializing default parameters that way is a big no-no. I actually use code with those exact mistakes in interviews, as it is a good way to tell Python beginners from more enlightened users.

raverbashing• 12 years ago

Correct

Unfortunately a lot of people still use it

(and it's actually correct, IF you don't modify it)

It's a risk not worth taking (to me, at least)

dbaupp• 12 years ago

It's easy to make mistakes, especially when the compiler/interpreter gives no assistance/warnings.

mpyne3• 12 years ago

The "No True Scotsman" helps out for essentially every language though.

avar• 12 years ago

    > But since Python syntax is arguably cleaner
    > and more readable, it's easier to catch.

I've seen nasty bugs in Python code having to do with the end of blocks losing their indentation due to someone's merge/editor mistake.

Having braces or other explicit start/end markers for blocks would have prevented those issues. So Python's syntax can in some cases encourage these sorts of mistakes.

yeukhon4• 12 years ago

Yeah, that's an excellent point. I remember arguing with friends about this vs braces. Mis-indent error is also a hard-to-detect bug in general. Also, a joke from Python-dev:

>> from __future__ import braces

rjzzleep2• 12 years ago

i'm actually a little surprised about the openssl one. I always assumed it would be good practice to number error codes negatively. OTOH that's also kinda expected behavior for reverse engineers. if the return value is negative you can be almost certain it's an error code

i guess whoever wrote that line thought the same.

matt__rose• 12 years ago

with the X bug, building X has always triggered tons of warnings, it's easy to see why they're overlooked http://keithp.com/blogs/xserver-warnings/

IvyMike• 12 years ago

Maybe that will be my new way to measure the effectiveness of my test suite.

"Imagine the NSA snuck a one line 'fix' 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."

ghayes• 12 years ago

If, per se, the NSA has your codebase, surely they would be able to find something you haven't tested. Your test cases should be extensive, but it's impossible to make them exhaustive.

mpyne3• 12 years ago

And even if you do, now you have a large and probably-buggy test base.

hughes• 12 years ago

But what if they "fixed" your unit tests? Gotta test the tests!

Rygu• 12 years ago

1. Start writing tests. Tests will save your ass when you're merging a feature branch. Cause are you sure everything still behaves correctly after those ingenious refactorings?

2. Use an IDE and/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.

3. Acknowledge responsibility when writing security related code. Know that there's no room for mistakes.

chetanahuja11• 12 years ago

To those learning C programming "by reading other's code", following is an example of what not to do (either the subtracted or the added line).

[Now I wait for a deluge or replies about how it's "idiomatic" C. All I have to say to that is, s/ma// ]

  --- libc-a/memset.c
  +++ libc-b/memset.c
  @@ -1,6 +1,6 @@
  void *memset(void *_p, unsigned v, unsigned count)
   { 
       unsigned char *p = _p;
  -    while(count-- > 0) *p++ = 0;
  +    while(count-- > 0) *p++ = v;
       return _p;
   }

[Edited later to use the code mode]

EdwardDiego2• 12 years ago

What is particularly bad? How would you have done it differently? I've not done much C, so I can't see the issue, although is it perhaps the types? Would count be modified by side-effect in the calling context also?

chetanahuja11• 12 years ago

"Would count be modified by side-effect in the calling context also?"

Questions like this and others (eg., does the pointer deref operation applies to incremented or non-incremented value of p?) that you have to answer before you can make sense of the code. The cognitive overload on the reader's brain is at least part of the reason that a bug like that went past code-review in memset function on a major platform. MEMSET !! Was the needless cleverness and terseness of the code worth it?

P.S. The answer to your question is No. The variable count as used in the body of this function is local to this function (it's passed by value... so it's a copy of what the caller passed).

bsder6• 12 years ago

Everything. The information density of the statement is enormous. Do you know the precendence of --, > , ++ and = by heart? Also if you lose a space you are relying on compiler maximal munch to process (count-->0) as --, > and not -, ->. Did p get incremented or did p get incremented? etc.

Finally, the same people who write that kind of code also write things like f(x++, (x+1)) without realizing that this is undefined in C.

Also, as an added bonus, postincrement/decrement sometimes creates extra unwanted copies in C++ so you need to use the pre- versions.

Compilers are good enough to handle tight loops like this even on very low optimization settings. Better to write that stuff out.

I have found that as I program more, I kind of agree with Crockford that ++, and -- are evil and should always be replaced by pp += 1; What that does is force you to avoid actions in conditional expressions and pull the mutators inside the block. It also forces you to be explicit about when you expect the increments to happen.

jleader• 12 years ago

I was going to complain about the 4 errors in 4 lines of code, until I realized that HN converts asterisk, text, asterisk into italicized text.

I assume you wanted your code to look like this:

    void *memset(void *_p, unsigned v, unsigned count) {
        unsigned char *p = _p;

    -   while(count-- > 0) *p++ = 0;
    +   while(count-- > 0) *p++ = v;

        return _p;
    }

In which case, I'm not sure what you're complaining about. Is it that memset here has a non-standard signature (v is supposed to be int, not unsigned)? Or that the "before" code ignored v? Or the un-braced loop body on the same line? Or is the some other problem I'm overlooking (which is possible, it's been about a decade since C was my main day-to-day language)?

[Edited to try to coax better text formatting from HN]

chetanahuja11• 12 years ago

Thanks for the formatting. I fixed my comment too. As for the bad legibility of the code as written (not due to formatting), where do I start...

Oh I know, the writer obviously wants very very badly to write this while loop as a one-liner. That's the start of all the other badness. As a reader of this code now, I have to keep every possible combination of post-increment side effects and precedence rules in mind before this code makes sense.

And yes, I know code like this is quoted in books as example of how cleverly you can write "powerful" one-liners. As far as I'm concerned, it's just a dumb show of alpha-coder pride and it's not a surprise to me that a serious bug was buried here.

jsoffer• 12 years ago

I think it's ok. I was going to say "He should have used memset instead of this low level memory walking that belongs inside the implementation of... oh I see". This is a critical function; doing it the proper "machine-workings, helping the compiler" way is more important than having a first read immediate understanding. Not that an experienced C programmer won't have it anyway.

MBlume3• 12 years ago

Lint tools exist.

My number one take away from this is that we should all be using them more.

azernik2• 12 years ago

And ignoring compiler warnings less.

girvo2• 12 years ago

I only recently learnt C, and -Wall -Wextra -Werror was drummed into me as being "the right way". It certainly does catch a lot of my idiotic mistakes.

jonalmeida• 12 years ago

I'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.

It luckily only took me a full day to find within the codebase..

nemothekid• 12 years ago

A lot of arguments center around "well, the compiler should have done X!"

I don'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's error, but it was 1 warning out of a million? Really interested in an answer from those who work in C shops.

acomjean• 12 years ago

In my past experience writing and compiling c and c++ on Radar software: The project was big and fair amount of legacy code, there were a fair amount of warnings in the c code. A lot of code was in Ada, which I grew to really appreciate, but for some things we needed code in c.

I started work on a new from the ground up simulator in c++. The 12+ coders got used to the warning = errors (Werror). I think it made us better coders. We were able to do that because the project was from the ground up new. Most projects in the Radar field use a lot of previously tested legacy code that does issue warnings.

Gracana2• 12 years ago

I write my code with -Wall, -Werror, -pedantic, and a standard specified. If my code does something questionable, I need to instruct the compiler that I really mean for it to do that. Why tolerate unsafe and ambiguous behavior?

bsder6• 12 years ago

One problem is that -Wall doesn't actually enable all warnings. And that's nuts.

pm215• 12 years ago

The project I work on (QEMU) uses -Werror in development but defaults it to off for releases. This means that warnings don't sneak into the codebase but end users don't have to deal with unnecessary build failures just because they're using a newer and pickier compiler or oddball host system.

Putting in the effort to get down to "emit no warnings" (and then enforcing that you stay there with -Werror) is worth doing exactly because you then do get new problems drawn forcibly to your attention, IMHO.

LukeShu• 12 years ago

In the case of Xorg, if they had warnings enabled, it was one warning among pages and pages of them. Recently though, they cleaned it up, 1.16 and onward should compile without warnings[0].

[0] http://keithp.com/blogs/xserver-warnings/

GFK_of_xmaspast• 12 years ago

It's probably putting out warnings because you're being sloppy. Maybe that's ok, maybe it's not, but cleaning up warnings is like washing your hands on the way out of the restroom, it's good hygiene.

julie1• 12 years ago

openBSD credo: security bugs are just bugs.

Mostly human, and avoidable but always present because people don'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.

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 ;)

I think computer industry would be far better if we would slow down and focus on doing less software, but better built.

Less functionalities maybe, but the one that maybe more powerful. The stable foundation for sustainable progress.

And, if you like them -even though they are repulsing antipathic nerds- you can support them :)

nayden• 12 years ago

careful there. we're not all the same -- some are MUCH more paranoid than others and I am yet to meet an antipathetic developer. ;)

But thanks to those who support what we do!

ybaumes• 12 years ago

In the example of the Apple bug, I'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.

Also, I assume that once discovered, the time to fix it is usually negligible. Usually. And as long as you don't count the time for full deployment in production...

chris_wot3• 12 years ago

Actually, with the Debian SSL "fix" that removed entropy, the dev who made the change did ask about it on IRC. Though a bad mistake, it's understandable how it happened.

dhugiaskmak• 12 years ago

"Never write your own security code, because you'll get it wrong. Leave it to the smart people."

tbmatuka• 12 years ago

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: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...

A brief history of one line fixes

Related Stories