Forgot your password?

Comment: Re:I would think (Score 1) 372

by WaffleMonster (#46809485) Attached to: OpenSSL Cleanup: Hundreds of Commits In a Week

If your IDE is automatically coloring them out, you might as well actually throw them out. They do not help.

The code does not help me but it does help other people. Throwing it out just because I don't care is selfish and counterproductive.

They only take up space. They won't be tested. They will bit rot as the surrounding code changes.

See above.

It's a lot of mental work to remember all the subtle differences, and why bother if you can just use the standard functions that are everywhere and have been there for 15 years?

Back in the real world we often have to deal with decades old crap including ancient platforms with broken or missing implementations of basic functionality. Closing your eyes, pretending otherwise or not understanding this reality out of ignorance solves nothing.

Okay, I get it. You're a genius superhuman elite hero. You are better than the OpenSSL developers; you wouldn't make a mistake they made with one of these crazy functions that looks standard but isn't.

I'm a superhuman idiot zero who has been contributing to open source projects for decades. What crazy functions specifically are you referencing?

You are better than the OpenBSD developers who need to restyle the code and remove wrappers and layers to make it less confusing to work with.

It does not take a rocket scientist to see the hubris billowing out of unprofessional commit comments. Been around enough to see the difference between making a difference and scratching obsessive compulsive itch. See also hasty deletes subsequently being reversed.. "oops".

Why don't you make your own fork and show the world how much better you are? You could probably do it. The most secure SSL/crypto library. Or would you rather run upstream OpenSSL

I'm happy with OpenSSL project especially now they recently added crypto features I have been waiting the better part of a decade to become field deployable.

If I find any problem in the code I have no reason to believe a vigorous patch would not be happily accepted by the OpenSSL team. OpenSSL is also heavily used by tiny companies like Google. They have made a great number of important contributions.

Or would you rather run upstream OpenSSL since you seem to have disregarded all the bugfixes the OpenBSD developers did, and claim they have no security value?

I made no such claim. I have never said OpenBSD devs have done nothing of value. I simply question the aggregate value of the changes commensurate with the hype used to describe them and think most of the commits I have checked with my own eyes are counterproductive or worthless. Most of them by volume are nothing more than adjustments to spacing between variable names and equal signs.

Of course you know better. You probably audited all the code already...

I will say the absence of anyone publically announcing discovery of any new bugs of substance post heartbleed is telling in and of itself. While I assume OpenSSL is full of undiscovered (or at least undisclosed) security critical bugs if all the code "sucks" as bad as heartbleed did I would expect to see quite a different outcome.

Compared with other security critical system that is as widely deployed I don't know that OpenSSL 's vulnerability track record is out of line from what can be expected.

People talk about OpenBSD developers as if they are gods yet a few seconds of googling shows plenty of dangerous CVE's for OpenSSH flaws disclosed during OpenBSD ownership of the project.

I think more eyes are good. I think anyone who wants to contribute bug fixes or make the project better is good. My objection is in unnecessary removal of functionality others still need and the characterization of OpenBSD commits as substantive when they are mostly shallow format/delete/function swaps. I welcome any and all serious attempts at re-architecting OpenSSL to reduce complexity, chance of error and structures which promote systematic verification of correct behavior. I don't see OpenBSD team doing any of these things as of yet. If they do I am more than happy to cheer them on.

security critical bugs but look at OpenSSH they have had severe problems

important bugs in OpenSSL

headlines of all the shallow bugs in OpenSSL found thanks to increase in number of eyes is itself quite telling.

new eyes finding zillions of shallow actionable bugs

Comment: Re:I would think (Score 1) 372

by WaffleMonster (#46808561) Attached to: OpenSSL Cleanup: Hundreds of Commits In a Week

#ifdef VMS
  #define SOMEFUNC(x,y,z) SomeVmsFunc (z,y,x)
  #define SOMEFUNC(x,y,z) TotallyOtherFunc (x,y,z)

You don't see how that fucks up the legibility of code?

No, when the function is used I know what it is doing because I know what SOMEFUNC is supposed to do. If SOMEFUNC does something other than what it is supposed to do then I can trace it and go find out why.

You encounter SOMEFUNC(1,2,3); and you have no idea what it does and your damn IDE can't colour-code that away either.

If you don't know what a function does you can check the documentation, ask someone who knows or go read the source code. This is applicable to every function. If I'm in my IDE I can step into the function and see what it does for myself. The comment coloring applies when a block is not applicable to my environment. For example the VMS definition. I does not hide the fact that it is a preprocessor def.

What do you think autotools is? Every open source project I have ever seen is littered with this compatibility crap. Entire header files dedicated to providing replacements and making up for lack of support for god knows what. All manner of functions individually probed by a gnarly meta program at compile time. Do you not realize just about every open source package included with any mainstream distro does this shit?

Comment: Re:What's the range of an EMP? (Score 1) 267

A good EMP keeps you guessing and has a dozen or so employees walking hundreds of kilometers of wire trying to find the failure.

This never happens.

See also

Some EMPs can fry pacemakers and pretty much anyone on life support is dead in a massive EMP.

How do you know that? Have these machines been tested? What is the basis?

Comment: Re:Half a million in minutes? (Score 1) 267

That's list contains almost exclusively those in planes and those dependent on medical devices.

Is there experimental evidence or other reasons for thinking planes would fall out of the sky or is this just an assumption? Our current fleets of flying aluminum cans routinely get hit by lightning and come out more or less unscathed. A direct localized strike has got to be competitive with high altitude nukes perhaps increased length of exposure from a gnarly CME could have a different/worse effect.

Comment: Re:A chilling EMP scenario (Score 2) 267

The degeneration of society seems to be pretty plausible. Kind of ties in with the "post-apocalyptic skills" thread of a few weeks ago.

I hope people take the time to read EMP commission report. While there is no question it would suck and hard to predict aggregate effect on society there are some interesting and counter-intuitive tidbits. Some of my favorites:

Systems designed to protect against EMF also protect against EMP. When tested new cars were no worse off than old cars due to EMF tolerance requirements. I believe none of the cars tested actually broke down although some had to be turned off and started right back up.

Simple changes such as changing from wires with parallel to twisted conductors make wires significantly less visible to induced currents ... even using steel conduit is something like 10 times less effective than likes of twisted romex.

Ethernet is galvanically isolated and will tolerate surprising amounts of abuse - while long loops of cable will induce harmful current less likely for damage to propagate and crispify other components beyond PHY.

Electronic gizmos are primarily vulnerable by way of induction from interface wiring / antennas and stand a chance of not being directly crispified when unconnected/stored.

Comment: Re:I would think (Score 1) 372

by WaffleMonster (#46806005) Attached to: OpenSSL Cleanup: Hundreds of Commits In a Week

Yes, it does. Using these macros everywhere makes the code more opaque, thus less legible, and therefore less secure.

Is this 2014 or 1994? My IDE automatically colors out dead sections where preprocessor macros don't apply to me. Honestly if you are unable to understand or mentally deal with a few preprocessor macro's I don't want you anywhere near openSSL.

They are hardly "everywhere" mostly in the headers and abstraction layers which provide a common target and normalized behavior for supported platforms.

"Many eyes" can't make all bugs shallow if those eyes don't understand what the hell they are looking at.

If eyes stumble on a few preprocessor definitions the chance of them discovering anything useful in this project is zero. I'm all for making shit easier to understand but this specific kind of "premature optimization" accomplishes nothing.

Comment: Re:Some (backward) progress (Score 1) 372

by WaffleMonster (#46801017) Attached to: OpenSSL Cleanup: Hundreds of Commits In a Week

However many of their patches will help the openssl project if someone on that team can be made to have an interest in actually improving the security of openssl.

To say that nobody cares about security is not a serious statement. There is a difference between not getting your way and bitching publically about it and working whatever politics are necessary to gain consensus necessary to have your changes accepted.

Having looked I don't see much value in these patches. Many of them are just cosmetic and or yank functionality without a legitimate cause. I don't see where code quality or real bugs have been appreciably addressed. The sheer number of commits and lines of code changed are mostly worthless noise.

Comment: Re:I want to know... (Score 1) 372

by WaffleMonster (#46800569) Attached to: OpenSSL Cleanup: Hundreds of Commits In a Week

Elimination of the custom memory management in favor of the native OS code (particularly when the OS takes pains to clear out free memory -- which would have stopped heartbleed cold on some platforms)

I see a number of people here making this false argument.

In most servers the private key is stored in actual allocated memory. This bug allowed carte blanche access to whatever relative process memory location you want.

Most systems hang on to freed memory for some time before eventual eviction from process heap. Fragmentation avoidance is complex, unpredictable and non-standard.

Comment: Re:list of changes (Score 1) 372

by WaffleMonster (#46800493) Attached to: OpenSSL Cleanup: Hundreds of Commits In a Week

So far as all the "won't this introduce more bugs than it fixes" comments go, this is a recurring argument I have at work. I am of the "clean as you go", "refactor now" school.
  Everyone else says "If it works don't fix it"(IIWDFI), "don't rock the boat" etc.

This is like making political arguments for pure capitalism or socialism. None of them alone work in practice correct answer is always somewhere in between AND context dependent.

These changes amount to rearranging deck chairs on a sinking vessel. Deleting code is redundant when a preprocessor macro has the same effect. Changing wrapper functions and flavors of system calls could be good or bad depending on specifics.

Heartbleed is what happens when the IIWDFI attitude wins.

Heartbeat was a totally new feature.

Bugs lurk under layers of cruft, simple changes become nightmares of wading through a lava flow of wrappers around hacks around bodges

In this specific case the new code itself was sloppy and failed to perform the necessary checks.

Whenever anyone says IIWDFI, remind them that testing can only find a small proportion of possible bugs, so if you can't see whether it has bugs or not by reading the code, then no matter how many test cases it passes, it DOESN'T WORK.

Risk mitigation is important. From diffs by volume this is not what has actually been committed. I would be all for changes that for example improved protocol parsers or did more up front validation of protocol fields before they were ever passed off internally or improving a plugin architecture for TLS extensions. Search and replace sprint/snprintf might be a good idea but I would hardly call that refactoring. I don't see any refactoring having actually taken place.

See also:

Comment: Re:I would think (Score 1) 372

by WaffleMonster (#46800153) Attached to: OpenSSL Cleanup: Hundreds of Commits In a Week

If you look at the actual commits, you will see removal of dead code such as VMS-specific hacks, but also weeding out a lot of fairly obvious bugs, unsafe practices such as trying to work around the mythical slow malloc, feeding your private key to the randomness engine, use after free, and so on.

VMS is not dead. A number of open source projects continue to support it because users still need it. Preprocessor macro's containing code specific to VMS don't hurt anyone but VMS users.

Having spent some time looking thru diffs it is not obvious to me much of anything was actually fixed. Mostly doing by hand what code re-formatting tools can do automatically and with much less chance of error.

We should expect to see a lot more activity before the code base is declared stable, but by now it's clear that the burden of main source maintainership moved to a more responsive and responsible team.

From what I have seen from changes there is no evidence this team is acting responsibly.

Comment: Some (backward) progress (Score 1) 372

by WaffleMonster (#46800057) Attached to: OpenSSL Cleanup: Hundreds of Commits In a Week

Pet peeve of mine when developers make style change thinking they are accomplishing anything worthwhile. By quantity most changes are BS to scratch itch of obsessive compulsives.

Others such as removal of jems like:

if (strlen(outdir) >= (size_t) (j ? BSIZE - j * 2 - 6 : BSIZE - 8)) {

Could be seen as progress except to accomplish it look at all extra code, memory allocation and new exception checks required to pull it off. The new code in aggregate not much better and no less complex.

Then in the same commit they just invoke asprintf as if it is no big deal with no attempt to provide compatibility for number of target platforms lacking it. This code won't even compile here anymore.

This commit is really amusing is a8d4234ebc7fd70a8e5cf34da650a6a1f89f4568

You can't make this shit up... description "ReadFile() and GetStdHandle() are not very POSIX."

These functions were ONLY used for win32 targets.

-#if defined(_WIN32) && defined(STD_INPUT_HANDLE)
-raw_read_stdin(void *buf, int siz)
- DWORD n;
- if (ReadFile(GetStdHandle(STD_INPUT_HANDLE), buf, siz, &n, NULL))
- return (n);
- else
- return (-1);
-raw_read_stdin(void *buf, int siz)
- return read(fileno(stdin), buf, siz);

Their solution was to use read and write which won't even compile on the only target platform where those functions would ever be used is now broken....because why?

More totally unnecessary breakage of code for platforms they simply don't care about.

And this "OPENSSL_gmtime() is really just gmtime_r(); ok guenther"

- ts = OPENSSL_gmtime(&t, &data);
+ ts = gmtime_r(&t, &data);

More wholly unnecessary and useless breakage of platforms the committer personally does not care about. See crypto/o_time.c

Hubris in comments speak for themselves:
"remove FIPS mode support. people who require FIPS can buy something that
meets their needs, but dumping it in here only penalizes the rest of us."

Cuz not setting OPENSSL_FIPS macros is simply not enough for an obsessive compulsive.

At this point I'm done...there is no serious attempt to make OpenSSL more secure only nitpicking things you personally either don't understand or don't like.

Comment: Re:Figures (Score 1) 154


From parent following statements are valid:

The adversaries of Israel are not above using a nuclear bomb to get what they want

The adversaries of Israel are not above using a nuclear bomb to get a tiny strip of land

The adversaries of Israel are not above using a nuclear bomb to get the whole western world

I don't know exactly who is considered "adversaries of Israel" I do know there are some dozen countries who don't recognize Israeli passports and more than half will either throw you in jail or not let you in if you so much as have an Israeli stamp on your passport. At least one such country already has nukes.

While I'm sure there really are people or groups of people who would actually Nuke x if they could for reason y this represents a tiny subset of "adversaries of Israel" .. the same statement probably holds true for just about every country in the world making it rather worthless.

Comment: Re:Figures (Score 2, Insightful) 154

Their adversaries and a few other rogue states and groups are not above using a nuclear bomb to get what they want, a tiny strip of land or even the whole western world.

The construction of this statement is priceless if not vague, inaccurate and worthless. The intersection of adversaries of Israel and lunatics particularly is quite laughable.

Comment: I don't trust "secret circles" (Score 1) 188

by WaffleMonster (#46788083) Attached to: Heartbleed Sparks 'Responsible' Disclosure Debate

This is foolish when you apply a patch to an open source project it essentially becomes public knowledge to anyone who is paying attention at that point. The more you do this the more eyes on patches. This only yields ignorance and suppresses urgency.

Only telling a select few (normally by subscription to very expensive security services) gives giant media an advantage it is not clear to me they have a right to or in any way deserve.

Finally as much money locked up in black/gray hat activities we don't need to be enriching anyone for contributing to an industry of an elite few none of us have any reason to trust.

Behavior of crowd at recent BlackHat toward Mr. Alexander made crystal clear to me kids have all grown up and money runs the show now. The more money the more "ethics" bend towards production of additional money.

"Atomic batteries to power, turbines to speed." -- Robin, The Boy Wonder