I know the water is fine, but if I lived in Portland and they hadn't emptied the reservoir I would have been looking at the tap water a little more suspiciously, and if I was someone who sometimes bought bottled water I probably would have been a little more likely to buy some. I have no doubt many of you are the same.

Someone peeing in the tap water is icky, it doesn't matter if it's irrational, we are irrational, and as costs of irrationality goes emptying a single reservoir is pretty damn cheap. There's times to stand on scientific principal, this isn't one of them. There's no point in grossing out an entire city, reducing confidence in the municipal water supply, and impacting human health and the environment by pushing people towards bottled drinks, just because it's irrational. Sometimes the most rational thing you can do is accommodate your irrationality.

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.

See above.

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.

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

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".

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.

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.

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

You've just stated you completely fail to understand the nature of EMP. The most dangerous EMP event is a large nuclear warhead exploded high above the ground, too high to do any meaningful damage on the ground. The damage is caused by the electromagnetic radiation released from the blast as EMP. It only takes one explosion. That isn't a nuclear Armageddon. It is returning a major post-industrial computer based society to a horse and wagon based economy in seconds, without having the horses and wagons to do the work not to mention the computers, computer controlled vehicles (engines), and other electronics.

Having watched Dark Angel I used to think a hydrogen bomb could do that kind of damage. But AFAIK the biggest man-made EMP ever to damage a city was caused by Starfish Prime. It was a 1.44 megaton H-bomb detonated high in the atmosphere, which caused damage in Hawaii, 1,445 kilometres (898 mi) away. The power didn't go out, though, and the damage was limited. Clearly, the EMP from an H-bomb is bad for electronics, but I doubt there's any way that a single bomb of realistic size could knock the entire United States back to a "horse and wagon based economy".

You have to ask: if someone wants to attack with an H-bomb, what is more likely: that they would use it as a normal bomb to kill people, or as an EMP to knock out power and damage electronics in less than a 1000-mile radius? Given the seemingly limited devastation (and the need for a rocket in addition to the bomb itself), I think terrorists would surely choose option one. I imagine option two might be considered as part of a World War 3, in which case the aggressor might well use several bombs, and EMPs could be just the beginning of our worries: "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones."

There is another source of EMP that could be more devastating than any single man-made bomb: see the Carrington Event.

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.

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?

http://www.cvedetails.com/vuln...

This never happens.

http://en.wikipedia.org/wiki/C...

See also

http://en.wikipedia.org/wiki/B...

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

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.

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.

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.

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.

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.

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.

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.

Heartbeat was a totally new feature.

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

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:

http://en.wikipedia.org/wiki/C...

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.

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

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)
-int
-raw_read_stdin(void *buf, int siz)
-{
- DWORD n;
- if (ReadFile(GetStdHandle(STD_INPUT_HANDLE), buf, siz, &n, NULL))
- return (n);
- else
- return (-1);
-}
-#else
-int
-raw_read_stdin(void *buf, int siz)
-{
- return read(fileno(stdin), buf, siz);
-}
-#endif

Their solution was to use read and write which won't even compile on win32...so 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.

You need to point the finger to understand why they're fighting.

The Palestinians in 1948 had a valid grievance, for decades while the British ruled Palestine they allowed European Jews to buy up huge chunks of the country with the goal of creating a friendly Jewish state in Palestine, then the UN partition made it official with a split they didn't agree to. The Palestinians (and sympathetic Arabs) also had a valid grievance in 1967, after the war in 1948 they fled or were expelled from huge portions of Israel and weren't allowed back in to their land or property. The current Palestinians in addition to those previous grievances are now also dealing with the occupation, an occupation stemming from a war they didn't actually start (Egypt was threatening war but Israel launched a sneak attack) in addition to active land thefts.

There's times when both sides are to blame but not so much in this one, the Palestinians are obviously doing bad things but the ones instigating the conflict are obviously Israel.