Given 5000 deaths per year and 110 million mines, we'd be better off ignoring them. Most of the mines would decay into uselessness long before they killed someone (at the current death rate, in a century, 99% of the mines will not have been stepped on, and that's ignoring the fact that the mines won't last a century.).
Except that developing the tech to clear existing mine fields efficiently may help when some idiot in the future lays a bunch of new mines. Ideally developing the tech would make traditional mines so ineffective no one would bother using them, but such a notion may be a bit optimistic. However expecting treaties banning mines to end the use of mines may be even more optimistic.
Develop the tech, it will probably have numerous other uses too.
The odds, it depends on the circumstances. That security software that was mentioned, was it just released? If so it would not be too weird to have multiple companies point such a tool at their own infrastructure. In short something like this may break the assumptions regarding independent events. I'm not saying this happened here, just that the odds are not necessarily as astronomical as they may appear. More info is needed.
In practice I found the vendors of proprietary libs that I used were very responsive to bug reports. I've noticed my fixes get merged into the source promptly. Perhaps I had better luck since these vendors were usually small companies not mega corporations.
Did you miss the first sentence: "If robots can weld then a remotely operated welding machine is doable."
Robotic welding has been around for decades. Replace pre-programmed and computer vision controlled movements with a human operator. It works for aircraft.
The sci fi reference was merely an example of why you might do it, i.e. hazardous environments where the tasks and circumstances are not predictable enough to go 100% automated.
Sorry, I clicked "submit" when I meant "continue editing"...
That said, proprietary code can be open too.
No, it can't, by definition. If it's not available to everyone, then it's not "open" in this context.
It absolutely can be open. You can retain full ownership and control of your source code and still let your users have access it to it.
To quote the OSI [opensource.org], "Open source software is... GNU project's four freedoms [gnu.org]...
Good thing I didn't say proprietary software is FOSS, mere that it can be open. Sorry but OSI and GNU don't get to redefine the word open.
And you don't get to move the goal post. This discussion is about inspecting source code for bugs. And in this sense proprietary can be as open as FOSS.
I went into more detail in another post but the program I was looking into had an aviation "guarantee". Two summer breaks at Quantico (OCS), commission upon college graduation and if the aptitude and medical tests for aviation are passed then a slot in flight school was "guaranteed".
The way it was explained to me at the time is that they could care less about the degree major. They were going to give me all the aptitude and medical tests relevant to aviation so the degree was more of a "social" requirement, a tradition that aviators are "gentlemen", and not really relevant.
This program was more of an infantry track, the aviation thing was a minor sideline. The Marines require that their pilots go through the same OCS as infantry officers.
It was not quite ROTC, no drilling or classes during the school year, but when I looked into it the Marines had a program (Platoon Leaders Program ?) where you spent two summer breaks at Quantico (OCS) and received your commission upon college graduation. You had no obligation during the school year nor between your second summer at Quantico and graduation. Although God help you if you showed up after graduation unable to pass the PT test.
The unique thing about this program was that, at the time, it had an aviation "guarantee". If you earned your commission through this program and passed the naval flight physical and other aviation specific aptitude tests then you got a slot in flight school.
That said, having grown up around a number of family members who had served I knew enough to not fully trust any aviation guarantee nor any promised training or career track, and that before signing I should be entirely willing to end up crawling through the mud with a rifle for a couple of years.
Yeah, no one tested it with the source before going against the binaries. Are you fucking high?
No, I merely read the account written by the folks who found heartbleed. It was automated testing of a live system. Closed or open source happens to be irrelevant for this particular discovery.
"“We developed a product called Safeguard, which automatically tests things like encryption and authentication,” Chartier said. “We started testing the product on our own infrastructure, which uses Open SSL. And that’s how we found the bug.”" http://readwrite.com/2014/04/1...
Its been a while since I spoke to an officer recruiter and I was a CS major at the time but what I was told was accredited 4 year degree program (i.e. BS or BA) and at least a 2.0 GPA (C). I am curious as to what you mean by the previous being "not quite" right. Note "accredited", the creationist museum people would not count, even deeply religious Texas denies accreditation to them.
With respect to the discovery of heartbleed closed and open are equivalent. The bug was found by testing the binary not by eyes on source code.
That said, proprietary code can be open too. Some proprietary libraries are available with a source license option. You may have to ask, their ads don't necessary mention the source license option. It confuses some readers.
... that someone who spent 4 year learning music means they get to be a barrista.
Or they get to be an officer in the military. The military does not care what your degree is in, just that you earned it at an accredited four year college.
The flight school they are talking about is for commercial multi engine aircraft, like college it is expensive and takes a long time. We are not talking about the local flight school where you can get your private pilots license in a Cessna 152.
Being tied down for the length of a commission is not very relevant if you are flying military aircraft, it will probably be the best flying time of your life.
You can cut college costs in half by going to your local state university. Working a part-time and summer job can put a big dent into state university costs.
How is telecommuting a possibility for the highly paid welder that we are talking about here?
If robots can weld then a remotely operated welding machine is doable.
FWIW, some science fiction I read decades ago had welders and others operating heavy machinery used in new lunar construction operating the equipment remotely from inside the existing lunar habitat.
Since you're constantly cycling through canned food for a significant portion of your diet, you're getting a lot more sodium and sugar and a lot less vitamins, phytochemicals and other good stuff; that shortens your lifespan, reducing the amount of time you'll have to suffer in a post-apocalyptic wasteland. And "maintaining preparedness" by eating out of cans all the time instead of enjoying fresh food reduces your quality of life, so you'll be happy that your life is being shortened!
The fresh things like veggies are in the fridge. Which are the first things eaten if the power goes out, then the somewhat fresh stuff in the freezer, then the canned goods. If power is out for a few days, as we saw for many during Sandy. then the cupboard. BTW, did you miss the reference to dry goods in the cupboards, that would incude rice, beans, etc.
Do you realize what careful is? For example when living in earthquake country believing that three days of supplies as recommended by the government is optimistic. So you buy three cases (adjust for family size) of bottled water rather than one, and as you use one case through normal activity you replace it so you always have 2-3 on hand. For your cupboard you purchase six cans (adjust for family size) of a particular canned good you use, when you get down to three you purchase three more, that way you always have 3-6 on hand. Do so each for canned chile, soup, peaches... whatever you normally use. Similar story with dry goods, 1-2 boxes on hand, snack foods, etc. 1-2 packages of toilet paper. 1-2 boxes of plastic garbage bags on hand, toilet liners if water is out. 1-2 packages of batteries for some LED flashlights. A basic first aid kit with antiseptic, gauzes, tape, bandaids, aspirin/tylenol, etc; no wilderness self-surgery kit necessary. If a disaster occurs eat what is in your refrigerator first, then your freezer, then your canned goods. You can have a week or two of food just by not letting your cupboard go bare. Nothing special or exotic needed, no freeze dried food good for years necessary. No special gear beyond what a boy scout might take on a weekend camping trip is necessary.
Pretty much all you need is the stuff you normally buy and use anyway. You just don't let inventories get to zero.
What is a developer to do? People want to try before buying.
Personally, in the things I publish, ex Perpenso Calc, a RPN Sci Stat Biz Hex Bill/Tip calculator that supports fractions and complex numbers, I like the idea of two apps. A fully paid app that is ad free and includes all functionality and a second free app that has only basic functionality, scientific functionality, but is expandable and ads are removable (Biz, Hex etc are in-app purchase). The later lets people try things out. As an incentive to buy the fully paid version I offer it at a bundled price, less than if all in-app purchases are made in the free version.
I understand the controversy but this is the best solution I've come up with so far. I would be happy to hear other suggestions.
There's no indication yet that any of the big U.S. corps most affected by this want to pony up the cash for a full security audit, though maybe some have employees working on it internally (for their own servers' versions, or maybe to share upstream).
Perhaps the money is going to a more qualified team, the OpenBSD team (fyi - OpenSSH is also theirs, OpenSSL was not). They are doing a massive cleanup pass on the OpenSSL code which is to be followed by a security audit of the code.
Didn't that make a mockery of all the "many eyes" arguments oft touted in favor of Open Source?
Nope. Once the bug was noticed it was fixed very quickly: i.e. it was a shallow bug. If you think than phrase means OSS is bug free, you have misunderstood it.
The quote is often misunderstood, its hyperbole. It illustrates a point nicely but in reality few users are developers and few developers are qualified readers.
More importantly the bug was not discovered by eyeballs on source code. The techniques used seem to be the same applied to proprietary closed source code. They were testing the binary.
"“We developed a product called Safeguard, which automatically tests things like encryption and authentication,” Chartier said. “We started testing the product on our own infrastructure, which uses Open SSL. And that’s how we found the bug.”" http://readwrite.com/2014/04/1...
A second and more important fact is that the bug was not discovered by eyeballs on source code. The techniques used seem to be the same applied to proprietary closed source code.
"âoeWe developed a product called Safeguard, which automatically tests things like encryption and authentication,â Chartier said. âoeWe started testing the product on our own infrastructure, which uses Open SSL. And thatâ(TM)s how we found the bug.â"
So you're say that when I, as a (professional;-) programmer, create a chunk of code that tests for something, you don't think I should get any credit for what it discovers, because it's the code that discovered it, not me....
You are offering a strange misinterpretation of what I have said. I am saying that this bug was not found by someone examining source code. That if you fuzz or otherwise test the binary then whether the code is proprietary or FOSS is irrelevant.
OK fine. It would not be possible if you did not have access to the source code. It is true that you can buy access to the source from some closed source software. But the fact that you are choosing software based on whether you are able to access the source code, I would argue is a point in favor of open source software rather than closed source proprietary software (the vast majority of which you can not buy source code access).
I never said I was against FOSS. I'm merely pointing out that access to source code is hardly unique to FOSS.
As far as how common access to source is in proprietary software, I think it is far more common than most FOSS advocates are aware of. For some of what we had used in the past there was no public offering of a source license. Yet when we specifically asked about it a deal was made. Many things that appear set are in fact negotiable. FWIW, we were a small company with no particular leverage.
Proprietary or open seems irrelevant to this discovery.
You can't make such conclusions from one bug.
Good thing I was commenting on only this one bug. That said, one can absolutely make the statement that fuzzing and other penetration testing works equally well on proprietary and FOSS code. The binary being tested doesn't care about the nature of it license.
Bugs will happen, and bugs will go unnoticed. The question is about whether the open source nature of a piece of software decreases the frequency of those events.
No one is arguing whether bugs will occur and go unnoticed. What is being argued is that the value of the "many eyeballs" concept is often exaggerated. Few users are developers. Few developers are qualified readers.
At my company we use open source software libraries for our commercial products. When we find anomalies, we are actually able to figure out if bugs are in our own software or in the open source libraries we use. In fact, we actually run static analysis tools on every piece of open source software that we use because we care about the security of our own applications. We don't use openSSL, but if we did, we may have actually found this bug. That wouldn't be possible if the source was closed.
That is not true. At past jobs where we used proprietary libraries in our commercial products, I always advocated for buying the more expensive source licenses rather than the less expensive binary only licenses. We even chose vendor A over vendor B due to A have a source option and B not having one. Fortunately all the libraries we used had source options, obviously YMMV. Management was always reluctant until we found and resolved problems in these proprietary libraries just as you describe doing in open source. Management quickly became believers in buying the source licenses so that our fate was not in a 3rd party's hands.
Why are you so adamant that it was not "eyeballs". So they fizzed their own infrastructure and found the issue. The article you posted is scant on the details if the tool and a google search did not turn up any salient details on the tool. From the description it appears to be black box testing SSL/TLS for obvious overruns.
And such testing would find such a bug equally well in proprietary or open source code. It seems fairly clear that the bug was not discovered by someone reading the source code, despite the code being available for two years and the code being absolutely critical to networking.
The value of many eyeballs is often exaggerated. Few users are developers. Few developers are qualified readers.
Slashdot Mirror
Given 5000 deaths per year and 110 million mines, we'd be better off ignoring them. Most of the mines would decay into uselessness long before they killed someone (at the current death rate, in a century, 99% of the mines will not have been stepped on, and that's ignoring the fact that the mines won't last a century.).
Except that developing the tech to clear existing mine fields efficiently may help when some idiot in the future lays a bunch of new mines. Ideally developing the tech would make traditional mines so ineffective no one would bother using them, but such a notion may be a bit optimistic. However expecting treaties banning mines to end the use of mines may be even more optimistic.
Develop the tech, it will probably have numerous other uses too.
The odds, it depends on the circumstances. That security software that was mentioned, was it just released? If so it would not be too weird to have multiple companies point such a tool at their own infrastructure. In short something like this may break the assumptions regarding independent events. I'm not saying this happened here, just that the odds are not necessarily as astronomical as they may appear. More info is needed.
In practice I found the vendors of proprietary libs that I used were very responsive to bug reports. I've noticed my fixes get merged into the source promptly. Perhaps I had better luck since these vendors were usually small companies not mega corporations.
Did you miss the first sentence: "If robots can weld then a remotely operated welding machine is doable."
Robotic welding has been around for decades. Replace pre-programmed and computer vision controlled movements with a human operator. It works for aircraft.
The sci fi reference was merely an example of why you might do it, i.e. hazardous environments where the tasks and circumstances are not predictable enough to go 100% automated.
That said, proprietary code can be open too.
No, it can't, by definition. If it's not available to everyone, then it's not "open" in this context.
It absolutely can be open. You can retain full ownership and control of your source code and still let your users have access it to it.
To quote the OSI [opensource.org], "Open source software is ... GNU project's four freedoms [gnu.org] ...
Good thing I didn't say proprietary software is FOSS, mere that it can be open. Sorry but OSI and GNU don't get to redefine the word open.
And you don't get to move the goal post. This discussion is about inspecting source code for bugs. And in this sense proprietary can be as open as FOSS.
That said, proprietary code can be open too.
No, it can't, by definition. If it's not available to everyone, then it's not "open" in this context.
It absolutely can be open. You can retain full ownership and control of your source code and still let your users have access it to it.
I went into more detail in another post but the program I was looking into had an aviation "guarantee". Two summer breaks at Quantico (OCS), commission upon college graduation and if the aptitude and medical tests for aviation are passed then a slot in flight school was "guaranteed".
The way it was explained to me at the time is that they could care less about the degree major. They were going to give me all the aptitude and medical tests relevant to aviation so the degree was more of a "social" requirement, a tradition that aviators are "gentlemen", and not really relevant.
This program was more of an infantry track, the aviation thing was a minor sideline. The Marines require that their pilots go through the same OCS as infantry officers.
It was not quite ROTC, no drilling or classes during the school year, but when I looked into it the Marines had a program (Platoon Leaders Program ?) where you spent two summer breaks at Quantico (OCS) and received your commission upon college graduation. You had no obligation during the school year nor between your second summer at Quantico and graduation. Although God help you if you showed up after graduation unable to pass the PT test.
The unique thing about this program was that, at the time, it had an aviation "guarantee". If you earned your commission through this program and passed the naval flight physical and other aviation specific aptitude tests then you got a slot in flight school.
That said, having grown up around a number of family members who had served I knew enough to not fully trust any aviation guarantee nor any promised training or career track, and that before signing I should be entirely willing to end up crawling through the mud with a rifle for a couple of years.
Yeah, no one tested it with the source before going against the binaries. Are you fucking high?
No, I merely read the account written by the folks who found heartbleed. It was automated testing of a live system. Closed or open source happens to be irrelevant for this particular discovery.
"“We developed a product called Safeguard, which automatically tests things like encryption and authentication,” Chartier said. “We started testing the product on our own infrastructure, which uses Open SSL. And that’s how we found the bug.”"
http://readwrite.com/2014/04/1...
Not quite true. Go talk to a Officer Recruiter, not the Recruiter in the mall that is trying to find qualified bodies to enlist.
"A college graduate with at least a four-year degree"
http://www.goarmy.com/ocs.html
Its been a while since I spoke to an officer recruiter and I was a CS major at the time but what I was told was accredited 4 year degree program (i.e. BS or BA) and at least a 2.0 GPA (C). I am curious as to what you mean by the previous being "not quite" right. Note "accredited", the creationist museum people would not count, even deeply religious Texas denies accreditation to them.
With respect to the discovery of heartbleed closed and open are equivalent. The bug was found by testing the binary not by eyes on source code.
That said, proprietary code can be open too. Some proprietary libraries are available with a source license option. You may have to ask, their ads don't necessary mention the source license option. It confuses some readers.
... that someone who spent 4 year learning music means they get to be a barrista.
Or they get to be an officer in the military. The military does not care what your degree is in, just that you earned it at an accredited four year college.
The flight school they are talking about is for commercial multi engine aircraft, like college it is expensive and takes a long time. We are not talking about the local flight school where you can get your private pilots license in a Cessna 152.
Being tied down for the length of a commission is not very relevant if you are flying military aircraft, it will probably be the best flying time of your life.
You can cut college costs in half by going to your local state university. Working a part-time and summer job can put a big dent into state university costs.
How is telecommuting a possibility for the highly paid welder that we are talking about here?
If robots can weld then a remotely operated welding machine is doable.
FWIW, some science fiction I read decades ago had welders and others operating heavy machinery used in new lunar construction operating the equipment remotely from inside the existing lunar habitat.
And you get great synergistic effects, too.
Since you're constantly cycling through canned food for a significant portion of your diet, you're getting a lot more sodium and sugar and a lot less vitamins, phytochemicals and other good stuff; that shortens your lifespan, reducing the amount of time you'll have to suffer in a post-apocalyptic wasteland. And "maintaining preparedness" by eating out of cans all the time instead of enjoying fresh food reduces your quality of life, so you'll be happy that your life is being shortened!
The fresh things like veggies are in the fridge. Which are the first things eaten if the power goes out, then the somewhat fresh stuff in the freezer, then the canned goods. If power is out for a few days, as we saw for many during Sandy. then the cupboard. BTW, did you miss the reference to dry goods in the cupboards, that would incude rice, beans, etc.
After all, you can never be too careful, right?
Do you realize what careful is? For example when living in earthquake country believing that three days of supplies as recommended by the government is optimistic. So you buy three cases (adjust for family size) of bottled water rather than one, and as you use one case through normal activity you replace it so you always have 2-3 on hand. For your cupboard you purchase six cans (adjust for family size) of a particular canned good you use, when you get down to three you purchase three more, that way you always have 3-6 on hand. Do so each for canned chile, soup, peaches ... whatever you normally use. Similar story with dry goods, 1-2 boxes on hand, snack foods, etc. 1-2 packages of toilet paper. 1-2 boxes of plastic garbage bags on hand, toilet liners if water is out. 1-2 packages of batteries for some LED flashlights. A basic first aid kit with antiseptic, gauzes, tape, bandaids, aspirin/tylenol, etc; no wilderness self-surgery kit necessary. If a disaster occurs eat what is in your refrigerator first, then your freezer, then your canned goods. You can have a week or two of food just by not letting your cupboard go bare. Nothing special or exotic needed, no freeze dried food good for years necessary. No special gear beyond what a boy scout might take on a weekend camping trip is necessary.
Pretty much all you need is the stuff you normally buy and use anyway. You just don't let inventories get to zero.
What is a developer to do? People want to try before buying.
Personally, in the things I publish, ex Perpenso Calc, a RPN Sci Stat Biz Hex Bill/Tip calculator that supports fractions and complex numbers, I like the idea of two apps. A fully paid app that is ad free and includes all functionality and a second free app that has only basic functionality, scientific functionality, but is expandable and ads are removable (Biz, Hex etc are in-app purchase). The later lets people try things out. As an incentive to buy the fully paid version I offer it at a bundled price, less than if all in-app purchases are made in the free version.
I understand the controversy but this is the best solution I've come up with so far. I would be happy to hear other suggestions.
There's no indication yet that any of the big U.S. corps most affected by this want to pony up the cash for a full security audit, though maybe some have employees working on it internally (for their own servers' versions, or maybe to share upstream).
Perhaps the money is going to a more qualified team, the OpenBSD team (fyi - OpenSSH is also theirs, OpenSSL was not). They are doing a massive cleanup pass on the OpenSSL code which is to be followed by a security audit of the code.
Didn't that make a mockery of all the "many eyes" arguments oft touted in favor of Open Source?
Nope. Once the bug was noticed it was fixed very quickly: i.e. it was a shallow bug. If you think than phrase means OSS is bug free, you have misunderstood it.
The quote is often misunderstood, its hyperbole. It illustrates a point nicely but in reality few users are developers and few developers are qualified readers.
More importantly the bug was not discovered by eyeballs on source code. The techniques used seem to be the same applied to proprietary closed source code. They were testing the binary.
"“We developed a product called Safeguard, which automatically tests things like encryption and authentication,” Chartier said. “We started testing the product on our own infrastructure, which uses Open SSL. And that’s how we found the bug.”"
http://readwrite.com/2014/04/1...
It may be to a lesser degree but legal businesses are the victims of theft and extortion too.
A second and more important fact is that the bug was not discovered by eyeballs on source code. The techniques used seem to be the same applied to proprietary closed source code. "âoeWe developed a product called Safeguard, which automatically tests things like encryption and authentication,â Chartier said. âoeWe started testing the product on our own infrastructure, which uses Open SSL. And thatâ(TM)s how we found the bug.â"
So you're say that when I, as a (professional ;-) programmer, create a chunk of code that tests for something, you don't think I should get any credit for what it discovers, because it's the code that discovered it, not me. ...
You are offering a strange misinterpretation of what I have said. I am saying that this bug was not found by someone examining source code. That if you fuzz or otherwise test the binary then whether the code is proprietary or FOSS is irrelevant.
OK fine. It would not be possible if you did not have access to the source code. It is true that you can buy access to the source from some closed source software. But the fact that you are choosing software based on whether you are able to access the source code, I would argue is a point in favor of open source software rather than closed source proprietary software (the vast majority of which you can not buy source code access).
I never said I was against FOSS. I'm merely pointing out that access to source code is hardly unique to FOSS.
As far as how common access to source is in proprietary software, I think it is far more common than most FOSS advocates are aware of. For some of what we had used in the past there was no public offering of a source license. Yet when we specifically asked about it a deal was made. Many things that appear set are in fact negotiable. FWIW, we were a small company with no particular leverage.
Proprietary or open seems irrelevant to this discovery.
You can't make such conclusions from one bug.
Good thing I was commenting on only this one bug. That said, one can absolutely make the statement that fuzzing and other penetration testing works equally well on proprietary and FOSS code. The binary being tested doesn't care about the nature of it license.
Bugs will happen, and bugs will go unnoticed. The question is about whether the open source nature of a piece of software decreases the frequency of those events.
No one is arguing whether bugs will occur and go unnoticed. What is being argued is that the value of the "many eyeballs" concept is often exaggerated. Few users are developers. Few developers are qualified readers.
At my company we use open source software libraries for our commercial products. When we find anomalies, we are actually able to figure out if bugs are in our own software or in the open source libraries we use. In fact, we actually run static analysis tools on every piece of open source software that we use because we care about the security of our own applications. We don't use openSSL, but if we did, we may have actually found this bug. That wouldn't be possible if the source was closed.
That is not true. At past jobs where we used proprietary libraries in our commercial products, I always advocated for buying the more expensive source licenses rather than the less expensive binary only licenses. We even chose vendor A over vendor B due to A have a source option and B not having one. Fortunately all the libraries we used had source options, obviously YMMV. Management was always reluctant until we found and resolved problems in these proprietary libraries just as you describe doing in open source. Management quickly became believers in buying the source licenses so that our fate was not in a 3rd party's hands.
Why are you so adamant that it was not "eyeballs". So they fizzed their own infrastructure and found the issue. The article you posted is scant on the details if the tool and a google search did not turn up any salient details on the tool. From the description it appears to be black box testing SSL/TLS for obvious overruns.
And such testing would find such a bug equally well in proprietary or open source code. It seems fairly clear that the bug was not discovered by someone reading the source code, despite the code being available for two years and the code being absolutely critical to networking.
The value of many eyeballs is often exaggerated. Few users are developers. Few developers are qualified readers.