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
You're living in fantasy land. There was a 1-2 line patch that would have fixed heartbleed sitting in the bug tracker waiting to be actioned for over 18 months.
Not necessarily. They are ripping out a lot of crap, much of which is portability done badly. The priority, it appears to is get back to a minimalist, secure code base, and then re-port it (to selected, actually used architectures, not big-endian x86 for example - which was some of the code removed) as time permits.
Yup. I can't believe that there were such dodgy trade-offs made for SPEED (at the expense of code readability and complexity) in openSSL. SSL/TLS is one of the things I don't care about speed on. I want a secure connection - i'll take my ADSL running like a 28.8k modem if that's what it takes.
CM is there for both preventing fuck ups and dealing with them when they occur. First things first: do you have a test environment? If not, build one. Do you have documented processes? If not, document them.
Proper change management ensures that: 1. people in the group know what is going on. 2. you have a second/third set of eyes to ensure that you have both a plan, a backout plan (or plan B in case it can't be backed out) and a test methodology to ensure that a change hasn't broken things. 3. to make you think about the implications of what you are doing, and 4. that business stakeholders are informed and know how to plan around any impact both expected and unforeseen.
If you aren't doing all of those things already, sorry dude but you are just winging it. That's efficient, etc. until one day it all goes horribly wrong and you need to figure it out on the fly how to get back to normality, with unpredictable outage durations, etc. All of that should be worked out before going live with your changes.
Yes, it sounds like a lot of faffing about for no real benefit, but really, one day it will save your arse. And really, you will be surprised at just how many effects even a single change to a production system can have.
Not necessarily. There is talk of energy being 10,000x more abundant for humanity if we were to put development into the LFTR reactor. If we have cheap electricity via safe nuclear power, then using some of it to generate fuel from sea-water is surely a lot better than putting the effort into getting it out of the ground and then shipping it half-way around the world.
Then again, with cheap nuclear power, we can also effectively supply hydrogen (which is obviously much cleaner) for other internal combustion engines.
Um. When safety standards change in the industry I am in (Mining) they do actually require everyone to immediately replace what is "working" with something deemed to be safe against the particular mode of catastrophic failure that has been observed.
XP can be made safe if it is kept patched or isolated from the network. Choose one. If it is isolated, who cares. If it is not, then you're simply rolling the dice.
Add the cost of re-training, software compatibility testing, a pilot program, etc. and those costs will blow out MASSIVELY.
Anyone in IT worth their salt knows that the software license cost is a tiny part of the TCO or cost to change. There are huge amounts of other costs involved and they are really hard to calculate. Switching platforms is a risk. Switching from XP to say, 7 is a big enough risk with big enough costs and there's a high level of application compatibility there. Switching to ChromeOS? Lol. Even if the software and hardware was FREE, it would still cost money. A lot. A very difficult to calculate number. Business decision makers do not like large, difficult to calculate $ values for risk. With good reason: being able to budget effectively goes out the window.
No, but XP isn't a hammer. It's a much more complicated piece of equipment than that. To use a workshop analogy - it's say, a bandsaw or hydraulic press that no longer meets any current safety standards. It is end of life and either needs to have safeguards installed (in XP's case, isolation from the internet and the rest of your production network) or be replaced.
Also... it is a cost of doing business. We all have the same issues. If you're not going to be bloody careful to isolate it, you are running the gauntlet and need to do a risk assessment and come up with a contingency plan for when it all goes pear shaped. Once you've done the risk assessment, you make the call on what to do. That may be upgrade, it may be isolate until the equipment goes end of life.
Sitting on your hands and whining "waaah it is too expensive" is a cop out - not an action plan. You need an action plan.
You isolate it from the general users production network and the internet and move on. From the sounds of it, that device should be running an embedded OS and should be treated as such.
You no longer have support for bugs, etc. deal with it.
However, you have had better learn for next time that when you purchase a device worth 100k pounds there sure as shit better be some sort of support contract in place. Or you're going to end up in the same situation next time.
Slashdot Mirror
You're living in fantasy land. There was a 1-2 line patch that would have fixed heartbleed sitting in the bug tracker waiting to be actioned for over 18 months.
Agreed. However fixing obviously brain damaged code is a start.
Not me. Exposing ssh to the entire internet unless required = retarded.
Not necessarily. They are ripping out a lot of crap, much of which is portability done badly. The priority, it appears to is get back to a minimalist, secure code base, and then re-port it (to selected, actually used architectures, not big-endian x86 for example - which was some of the code removed) as time permits.
Yup. I can't believe that there were such dodgy trade-offs made for SPEED (at the expense of code readability and complexity) in openSSL. SSL/TLS is one of the things I don't care about speed on. I want a secure connection - i'll take my ADSL running like a 28.8k modem if that's what it takes.
CM is there for both preventing fuck ups and dealing with them when they occur. First things first: do you have a test environment? If not, build one. Do you have documented processes? If not, document them.
Proper change management ensures that: 1. people in the group know what is going on. 2. you have a second/third set of eyes to ensure that you have both a plan, a backout plan (or plan B in case it can't be backed out) and a test methodology to ensure that a change hasn't broken things. 3. to make you think about the implications of what you are doing, and 4. that business stakeholders are informed and know how to plan around any impact both expected and unforeseen.
If you aren't doing all of those things already, sorry dude but you are just winging it. That's efficient, etc. until one day it all goes horribly wrong and you need to figure it out on the fly how to get back to normality, with unpredictable outage durations, etc. All of that should be worked out before going live with your changes.
Yes, it sounds like a lot of faffing about for no real benefit, but really, one day it will save your arse. And really, you will be surprised at just how many effects even a single change to a production system can have.
Nuclear fusion = not required.
Not if you run nuclear, solar, wind, etc.
really? can you tell me the key you hit before Y?
Take a trip to Germany, and hire a car. Drive to a few countries.
originally posted on another forum in 2006, it is now 2014. way to go, Slashdot!
Not necessarily. There is talk of energy being 10,000x more abundant for humanity if we were to put development into the LFTR reactor. If we have cheap electricity via safe nuclear power, then using some of it to generate fuel from sea-water is surely a lot better than putting the effort into getting it out of the ground and then shipping it half-way around the world.
Then again, with cheap nuclear power, we can also effectively supply hydrogen (which is obviously much cleaner) for other internal combustion engines.
If only we could extract CO2 from the atmosphere
You realise that doesn't make it a FOSSIL fuel right?
You mean like this?
Also, its about time we had another look at the LFTR reactors.
Um. When safety standards change in the industry I am in (Mining) they do actually require everyone to immediately replace what is "working" with something deemed to be safe against the particular mode of catastrophic failure that has been observed.
XP can be made safe if it is kept patched or isolated from the network. Choose one. If it is isolated, who cares. If it is not, then you're simply rolling the dice.
It's been on sale for more than the last 12 months, and it is a lot larger than GoogleTV or whatever they're calling it this week.
Sure. And the lowest risk option is Win7 32 bit. ChromeOS is a huge gamble.
... you're about 4-5 years late.
Add the cost of re-training, software compatibility testing, a pilot program, etc. and those costs will blow out MASSIVELY.
Anyone in IT worth their salt knows that the software license cost is a tiny part of the TCO or cost to change. There are huge amounts of other costs involved and they are really hard to calculate. Switching platforms is a risk. Switching from XP to say, 7 is a big enough risk with big enough costs and there's a high level of application compatibility there. Switching to ChromeOS? Lol. Even if the software and hardware was FREE, it would still cost money. A lot. A very difficult to calculate number. Business decision makers do not like large, difficult to calculate $ values for risk. With good reason: being able to budget effectively goes out the window.
No, but XP isn't a hammer. It's a much more complicated piece of equipment than that. To use a workshop analogy - it's say, a bandsaw or hydraulic press that no longer meets any current safety standards. It is end of life and either needs to have safeguards installed (in XP's case, isolation from the internet and the rest of your production network) or be replaced.
Also... it is a cost of doing business. We all have the same issues. If you're not going to be bloody careful to isolate it, you are running the gauntlet and need to do a risk assessment and come up with a contingency plan for when it all goes pear shaped. Once you've done the risk assessment, you make the call on what to do. That may be upgrade, it may be isolate until the equipment goes end of life.
Sitting on your hands and whining "waaah it is too expensive" is a cop out - not an action plan. You need an action plan.
You isolate it from the general users production network and the internet and move on. From the sounds of it, that device should be running an embedded OS and should be treated as such.
You no longer have support for bugs, etc. deal with it.
However, you have had better learn for next time that when you purchase a device worth 100k pounds there sure as shit better be some sort of support contract in place. Or you're going to end up in the same situation next time.
Correct. I'm in Australia. It's standard.