Looks really nice yet lack of SD and user replaceable battery is a deal breaker. Would think devices targeting cyanogen crowd would come standard with at least SD slot.
That's largely what the OpenBSD team is doing - ripping out all of that unneeded memory management crap, killing OS/2, VMS, and MacOS7 support code, etc. The payoff should be more people looking at it,
Pairing down unnecessary special memory routines and any silliness enabled by them is likely to be productive.
Removing windows code appreciably reduces pool of interested parties and hence the number of people who care to audit your OpenSSL fork.
Every fix length field should have a reserved value for an extension..
Without careful planning in advance of deployment reserved fields in protocols often go unused as subsequent modifications are not operationally viable.
Variable length addressing would have absolutely solved the problem only if it was defined from the beginning addresses may be between x and y bits in length and all systems handling addresses are expected to support the full range of address lengths.
The act of simply reserving a bit without defining what it does in advance solves NOTHING and does NOT result in a better solution than parallel deployment of IPv6.
By the time they are needed, namely in present day, it is a rather trivial mod to make network gear which reads another 32 bits past the end of the standard TCP/IP headers to collect the extended IP address, and presto IPv4 address shortage is gone.
Not on a production network it aint. You have no way of knowing what equipment along path supports what, which part of routing infrastructure does or does not support an extension, no way to understand a-priori which addressing system to use. You have no way of knowing whether that which touches an IP address supports the extended length. Without parallel deployment or flag day it is the same or worse than IPv6.
Because there is a very high one-time-only cost involved in switching to ipv6, compared to a small running continuous cost of continuing in ipv4, and for now, it is advantageous to become in ipv4. No one wants to be the one to switch first.
Nobody is switching to IPv6 they are *adding* IPv6. IPv4 is not being turned off by anyone well into the foreseeable future.
Most large content providers are already offering service via IPv6 and millions already have IPv6 access via their ISPs.
Just think of all sort of problems large ISPs will have to deal in terms of support if they switch to ipv6, in terms of phone service, visits, substitution of cable modems, support for old machines running none/bogus ipv6 implementation
The migration to IPv6 takes a while and does not involve turning off IPv4 anytime soon. There is no need to rush to replace gear. It will eventually break or become obsolete in the next few years anyway.
Not easy as flick a switch.
For most consumers it will be easier than a flick of a switch. They get it without having to expend any effort at all or ever even knowing they have it. This happens either immediately or after their old router or CE has broken and gets replaced.
We're running out of free ones. And like any freely available resource, they've been squandered. Once the free supply is exhausted, they'll simply no longer be free - meaning that actual incentive will exist to conserve them and organizations will have incentive to sell unneeded blocks. Economics 101, people.
There has been pressure for near two decades now in the form of allocation policy and documentation requirements where lack of plentiful IP resources has lead directly to proliferation of 1:Many NAT.
Years back, my boss got a whole class C for a company with ~5 employees and network footprint nothing more than one website. Maybe they can get some of the corporations with class As to give some back? (yeah yeah I know)
This comes at cost of increased route disaggregation pressure for little benefit in return.
Passwords need only be as secure as the effective aggregate retry policy of whatever is accepting credential inputs.
Half the problem are all these 'hashes' stored in the clear on disk where administrators incorrectly assume users are responsible to select big enough password to make up for lack of effective protections. This of course is a complete failure having never worked continuing to grow more laughably amusing over time as computing power per unit cost increases.
Next we have security standards actively mandating complexity AND password change policy with no regard for the collateral damage: post-it notes, password wallets with access passwords that never change, complacency regarding frequent administrative change requests.
Next we have the breathtaking idiocy of completely untrusted email systems where sender identities are trivially spoofed by anyone.. a height of insanity eclipsed only by those same email systems allowing for convenient file attachments and one click execution of untrusted code in the users security context.
What do you expect? Do you really think ANY amount of vigilance in such an environment is worth anything? The basic security problems enumerated in TFA are much more representative of underlying infrastructure failing to provide any useful contextual information to the user... aint the users fault. While it absolutely is productive to teach awareness of technical and social engineering threats most of it stems from catastrophic failures of systems and their administrators.
What pay phone? The only 3 that still exist in the US are also covered by cameras I'm sure.
Substitute payphone for VoIP gateway and you are left with the same problem. We routinely get anonymous whackos calling us from all over the world appearing to come from local numbers. It gets easier every day to make a practically untraceable call using IP as POTS overlay.
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
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?
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.
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.
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.
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.
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.
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.
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.
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.
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."
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"
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.
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.
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.
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.
Slashdot Mirror
Looks really nice yet lack of SD and user replaceable battery is a deal breaker. Would think devices targeting cyanogen crowd would come standard with at least SD slot.
That's largely what the OpenBSD team is doing - ripping out all of that unneeded memory management crap, killing OS/2, VMS, and MacOS7 support code, etc. The payoff should be more people looking at it,
Pairing down unnecessary special memory routines and any silliness enabled by them is likely to be productive.
Removing windows code appreciably reduces pool of interested parties and hence the number of people who care to audit your OpenSSL fork.
There is lesson to be learned here:
Every fix length field should have a reserved value for an extension. .
Without careful planning in advance of deployment reserved fields in protocols often go unused as subsequent modifications are not operationally viable.
Variable length addressing would have absolutely solved the problem only if it was defined from the beginning addresses may be between x and y bits in length and all systems handling addresses are expected to support the full range of address lengths.
The act of simply reserving a bit without defining what it does in advance solves NOTHING and does NOT result in a better solution than parallel deployment of IPv6.
By the time they are needed, namely in present day, it is a rather trivial mod to make network gear which reads another 32 bits past the end of the standard TCP/IP headers to collect the extended IP address, and presto IPv4 address shortage is gone.
Not on a production network it aint. You have no way of knowing what equipment along path supports what, which part of routing infrastructure does or does not support an extension, no way to understand a-priori which addressing system to use. You have no way of knowing whether that which touches an IP address supports the extended length. Without parallel deployment or flag day it is the same or worse than IPv6.
Because there is a very high one-time-only cost involved in switching to ipv6, compared to a small running continuous cost of continuing in ipv4, and for now, it is advantageous to become in ipv4. No one wants to be the one to switch first.
Nobody is switching to IPv6 they are *adding* IPv6. IPv4 is not being turned off by anyone well into the foreseeable future.
Most large content providers are already offering service via IPv6 and millions already have IPv6 access via their ISPs.
Just think of all sort of problems large ISPs will have to deal in terms of support if they switch to ipv6, in terms of phone service, visits, substitution of cable modems, support for old machines running none/bogus ipv6 implementation
The migration to IPv6 takes a while and does not involve turning off IPv4 anytime soon. There is no need to rush to replace gear. It will eventually break or become obsolete in the next few years anyway.
Not easy as flick a switch.
For most consumers it will be easier than a flick of a switch. They get it without having to expend any effort at all or ever even knowing they have it. This happens either immediately or after their old router or CE has broken and gets replaced.
We're running out of free ones. And like any freely available resource, they've been squandered. Once the free supply is exhausted, they'll simply no longer be free - meaning that actual incentive will exist to conserve them and organizations will have incentive to sell unneeded blocks. Economics 101, people.
There has been pressure for near two decades now in the form of allocation policy and documentation requirements where lack of plentiful IP resources has lead directly to proliferation of 1:Many NAT.
Years back, my boss got a whole class C for a company with ~5 employees and network footprint nothing more than one website. Maybe they can get some of the corporations with class As to give some back? (yeah yeah I know)
This comes at cost of increased route disaggregation pressure for little benefit in return.
Passwords need only be as secure as the effective aggregate retry policy of whatever is accepting credential inputs.
Half the problem are all these 'hashes' stored in the clear on disk where administrators incorrectly assume users are responsible to select big enough password to make up for lack of effective protections. This of course is a complete failure having never worked continuing to grow more laughably amusing over time as computing power per unit cost increases.
Next we have security standards actively mandating complexity AND password change policy with no regard for the collateral damage: post-it notes, password wallets with access passwords that never change, complacency regarding frequent administrative change requests.
Next we have the breathtaking idiocy of completely untrusted email systems where sender identities are trivially spoofed by anyone .. a height of insanity eclipsed only by those same email systems allowing for convenient file attachments and one click execution of untrusted code in the users security context.
What do you expect? Do you really think ANY amount of vigilance in such an environment is worth anything? The basic security problems enumerated in TFA are much more representative of underlying infrastructure failing to provide any useful contextual information to the user... aint the users fault. While it absolutely is productive to teach awareness of technical and social engineering threats most of it stems from catastrophic failures of systems and their administrators.
What pay phone? The only 3 that still exist in the US are also covered by cameras I'm sure.
Substitute payphone for VoIP gateway and you are left with the same problem. We routinely get anonymous whackos calling us from all over the world appearing to come from local numbers. It gets easier every day to make a practically untraceable call using IP as POTS overlay.
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
#ifdef VMS
#define SOMEFUNC(x,y,z) SomeVmsFunc (z,y,x)
#else
#define SOMEFUNC(x,y,z) TotallyOtherFunc (x,y,z)
#endif
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?
Perhaps the money is going to a more qualified team, the OpenBSD team
http://www.cvedetails.com/vuln...
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.
http://en.wikipedia.org/wiki/C...
See also
http://en.wikipedia.org/wiki/B...
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?
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.
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.
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.
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.
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.
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:
http://en.wikipedia.org/wiki/C...
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.
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:
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.
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"
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.
Oh?
From parent following statements are valid:
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.
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.
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.
Ah the good ole days before the IRS collected and data mined all our credit card transactions.
yeah and 99% of software engineers also seriously believe their initial time estimate to have that feature implemented by was actually realistic.
I'm privileged to be part of that 1% elite who believes all of their time estimates are wrong and laughably absurd while making them.