Earlier quoted context omitted.
Are you kidding me? There is no possible universe in which 'param' is an acceptable name for an argument.
What about this? class Function { public apply(T param); }
OK. One possible universe.
OpenSSL Security Advisory
121–130 of 142 posts
Re: OpenSSL Security Advisory
#122Interesting part is that the bug was introduced in the latest versions and has been fixed by the person who inserted it :-) Bug added: https://github.com/openssl/openssl/commit/da084a5ec6cebd67ae... Bug removed: https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365... Although that's just the committer: https://twitter.com/agl__/status/619129579580469248
/* Remember how many untrusted certs we have */
j = num;
Re: OpenSSL Security Advisory
#123I am hardly astonished that a 319-line function that opens by declaring x, xtmp, xtmp2, chain_ss, bad_chain, param, depth, i, ok, num, j, retry, cb, and sktmp variables had a bug. Before someone provides the standard "submit a patch" retort, I'll note that the variable naming is in full compliance with https://www.openssl.org/about/codingstyle.txt even if the function length isn't. A quick sample of other files sugge…
You seriously have trouble reading "i", "j", "param" and "num"? Hell, "ok", "depth" and "retry" are already in your English-language dictionary! I'll grant that having variables named with "tmp" is confusing out of context, I guess. But if you're trying to start a Java-style war over this stuff, just recognize that most of the world has moved on and views names like those as perfectly fine when used within standard i…
A three hundred nineteen line function though with all those variables is more than a bit big. Modern compilers are rather good at inlining code, so it's doubtful there will be very much, if any effect on codesize there. The multitude of temporary variables also suggests that there are probably portions of that function that need factored out. OpenSSL suffers from a severe thousand paper cuts problem. While its warts aren't that bad when viewed individually, the sheer multitude shows a severe lack of organization of the project from top to bottom.
Re: OpenSSL Security Advisory
#124How is it that we still depend on something so broken?
If you think you can write a better implementation then put your hands where your keyboard is. Show us the code. If not, submit patches. An OpenSSL team member said, "If you're in a position to offer technical criticism you're in a position to offer technical help." While it sounds like their pleading for help, its because WE ARE. There are 3 full time maintainers, 1 is a dog :P and only ~10-16 regular patch submitte…
> If you think you can write a better implementation then put your hands where your keyboard is. Show us the code.
Here you go!
Re: OpenSSL Security Advisory
#125Earlier quoted context omitted.
You seriously have trouble reading "i", "j", "param" and "num"? Hell, "ok", "depth" and "retry" are already in your English-language dictionary! I'll grant that having variables named with "tmp" is confusing out of context, I guess. But if you're trying to start a Java-style war over this stuff, just recognize that most of the world has moved on and views names like those as perfectly fine when used within standard i…
The use of shorthand names like that is a strong indication that the variables don't need to be live for ~319 lines. If you reduce the live range of your variables, you reduce the complexity of your function. Less complex functions are less likely to have bugs and are easier to diagnose when they do.
Good points, but if you are able to do that, doesn't it suggest the function could easily be split into multiple, more specific functions?
Re: OpenSSL Security Advisory
#126Re: OpenSSL Security Advisory
#127Earlier quoted context omitted.
The use of shorthand names like that is a strong indication that the variables don't need to be live for ~319 lines. If you reduce the live range of your variables, you reduce the complexity of your function. Less complex functions are less likely to have bugs and are easier to diagnose when they do.
Good points, but if you are able to do that, doesn't it suggest the function could easily be split into multiple, more specific functions?
Yes, of course, it's just the first step. In fact you'd probably need to introduce a couple more variables. For example, i gets defined three times:
i = sk_X509_num(ctx->chain);
i = check_trust(ctx);
i = X509_chain_check_suiteb(&ctx->error_depth, NULL, ctx->chain, ctx->param->flags);
Re: OpenSSL Security Advisory
#128Earlier quoted context omitted.
> nothing proved to be more reliable to this moment. Huh? Of the 22 vulnerabilities OpenSSL has disclosed since March (4 high severity, 14 moderate, 4 low), LibreSSL has been vulnerable to 8 (0 high, 6 moderate, 2 low). References: March: https://marc.info/?l=openbsd-cvs&m=142677372515025&w=2 June: https://marc.info/?l=openbsd-announce&m=143406498020131&w=2 Today: https://marc.info/?l=openbsd-tech&m=143645910727507&w…
And how long is LibreSSL on the market? A year? It's hard to call it proof . It's easy to point intervals longer than whole LibreSSL lifetime with no security bugs in OpenSSL.
LibreSSL is a cleanup of the OpenSSL base. They started with OpenSSL and worked from there. They have mostly deleted code, not added it, so they shouldn't be adding many new vulerabilities. On top of this, it is being written by the OpenBSD/OpenSSH people, who have a good history with writing secure software.
Re: OpenSSL Security Advisory
#129I am hardly astonished that a 319-line function that opens by declaring x, xtmp, xtmp2, chain_ss, bad_chain, param, depth, i, ok, num, j, retry, cb, and sktmp variables had a bug. Before someone provides the standard "submit a patch" retort, I'll note that the variable naming is in full compliance with https://www.openssl.org/about/codingstyle.txt even if the function length isn't. A quick sample of other files sugge…
And the coding style doesn't exactly avoid errors as well. "Do not unnecessarily use braces around a single statement: if (condition) action(); and if (condition) do_this(); else do_that(); " Didn't people learn from the goto fail bug ? http://embeddedgurus.com/barr-code/2014/03/apples-gotofail-s...
> Do not unnecessarily use braces around a single statement
If you consider all braces to be necessary, then that's a truism and you can safely ignore it. "I didn't unnecessarily use them: we always use them because that's the safe thing to do."
Re: OpenSSL Security Advisory
#130Earlier quoted context omitted.
I mean, OpenSSH is such a piece of buggy garbage... /s
I once worked with some Linux admins who told me that SSH public key authentication wasn't secure.
While that's certainly possible, it's an extraordinary claim because it flies in the face of generally accepted beliefs. If your coworker was Bruce Schneier, I would pay close attention to his explanation. If they were your standard issue sysadmin types, then I'd want to know:
1) Why they believe so,
2) Why they haven't filed security advisories to advise the rest of us, and
3) Why you don't hear about banks being wiped clean because crackers were able to bypass SSH's security measures.
It's possible they're right, but as with all extraordinary claims, the onus of proof is on the ones making them.