Live data from Hacker News

Apple's SSL/TLS bug

imperialviolet.org

101–110 of 295 posts

Re: Apple's SSL/TLS bug

#101
post #33
post #24

Earlier quoted context omitted.

Those kinds of tools aren't new or emerging. The "indent" utility for C has been around for decades. I first remember using it on 4.3BSD, but it may have been around before that.

indent - indent and format C program source HISTORY The indent command appeared in 4.2BSD. And for context, 4.2BSD was released in 1983.

cb(1) was in Seventh Edition (1979).

  NAME
    cb - C program beautifier

  SYNOPSIS
    cb

  DESCRIPTION
    Cb  places a copy of the C program from the standard input on the stan-
    dard output with spacing and indentation that displays the structure of
    the program.

Re: Apple's SSL/TLS bug

#102

Earlier quoted context omitted.

The real WTF is those Warn flags, then. In what sane world does "extra" mean more than "all", and "all" and "everything" mean different things?

Apple introduced -Weverything because suddenly changing the scope of gcc's -Wall (which indeed does not include everything) would break a lot of builds.

"suddenly" is a funny way to say "over a span of years"....

Re: Apple's SSL/TLS bug

#103

Earlier quoted context omitted.

The real WTF is those Warn flags, then. In what sane world does "extra" mean more than "all", and "all" and "everything" mean different things?

Apple introduced -Weverything because suddenly changing the scope of gcc's -Wall (which indeed does not include everything) would break a lot of builds.

Is "-Weverything" inclusive of new warnings? Because they're just kicking the can if not. What's next, "-Wreallyeverything"?

Re: Apple's SSL/TLS bug

#105
post #95

Earlier quoted context omitted.

I agree, I was thinking about what this situation would look like in other langs and when I turned to Go, I realized: While Go has goto for tricky situations like this, because it has defer you don't have to use it often, assuming the free calls were needed (and the vars were not going to be GC'd): defer SSLFreeBuffer(&hashCtx) defer SSLFreeBuffer(&signedHashes) if err = SSLHashSHA1.update(&hashCtx, &serverRandom); e…

I would probably flag the code above in a security review because it hides the key part at the end of a complex line. Unless you're coding on VT100 terminal it's worth the extra line to make the test logic incredibly obvious: err = SSLHashSHA1.update(&hashCtx, &serverRandom); if (err != nil) { return err; }

In actual code things would not be named as they were above and it would be shorter, I was just trying to make it look reasonably like the C for HN.

Re: Apple's SSL/TLS bug

#106

I installed this last night and the update came in at 15MB. Surely a one line bug shouldn't cause a 15MB update? Or is it that some things in iOS might be statically linked and those had to be pushed out as well?

The update probably includes the actual updater executable, not just the diff. This would allow you ship different kind of patches (from simple fixes to entire OS upgrades) using the same mechanism.

Re: Apple's SSL/TLS bug

#107
post #97

If blocks without curly braces ಠ_ಠ

Braces don't help in coding styles that put the opening brace on a separate line from the control statement. if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) { goto fail; } { goto fail; }

If you have a programmer on your team who is likely to modify

  if (condition)
  {
    doSomething();
  }
into

  if (condition)
  {
    doSomething();
  }
  {
    doAnotherThing();
  }
instead of

  if (condition)
  {
    doSomething();
    doAnotherThing();
  }

then that person needs some serious mentoring right away. 'Cuz. . . just wow.

As far as the original example goes, if it's an error it's most likely a copy/paste error. Curly braces help there, too. With three times as many lines in the block, the odds of a paste error resulting in code that even compiles is greatly reduced, and a compiler error should call attention to the issue.

Even assuming the bug was malicious, the curly braces would increase the odds of it being caught by another developer. This is particularly the case now that offside rule languages are common. A large chunk of younger devs cut their teeth on languages where

  if (condition)
    doSomething();
    doAnotherThing();
doesn't look odd in the slightest. But I think that the 2nd example above would still look immediately bizarre to nearly everyone.

Re: Apple's SSL/TLS bug

#109
post #97

If blocks without curly braces ಠ_ಠ

Braces don't help in coding styles that put the opening brace on a separate line from the control statement. if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) { goto fail; } { goto fail; }

That is a lot more obviously wrong that without the braces, though.

But yes, mandatory braces on the same line is the correct choice.

Re: Apple's SSL/TLS bug

#110
post #78
post #45

Earlier quoted context omitted.

There is no excuse to bypass static analysis nowadays. At very least should be part of the continuous integration build. The problem are the many developers that still think they are perfect and know the full C standard, including undefined parts.

That's a rare problem among developers. The more common problem is that developers make mistakes. All of them. Static analysis, regression tests and turning on all the warnings you possibly can should be mandatory, especially for such critical pieces of code.

And if you are going to disable a specific warning, it should only be for a limited section of code and include a detailed comment about why the warning is superfluous and why the code is safe.
Post reply on HN