One thing is for certain: there is no stopping them; the ants will soon be here. And I, for one, welcome our new insect overlords. I'd like to remind them that as a trusted TV personality I could be helpful in rounding up others to toil in their underground sugar caves.
Well, this reporter was...possibly a little hasty earlier and would like to...reaffirm his allegiance to this country and its human president. May not be perfect, but it's still the best government we have. For now.
There are plenty of jobs where a single incident of teasing a person under your care about their suicide attempt could get you fired. If he lacks the interpersonal skills to, at the very least, become embarrassed and apologize immediately after letting that comment slip, maybe teaching isn't the right profession. As for my assumption that no justifying context occurred, keep in mind that I'm not serving on an administrative or judicial body in this case, I'm merely trusting the LA Times to have found a handful of legitimate anecdotes. Your apparent inability to accept that a teacher anywhere in LA county did something quite wrong is what made me accuse you of a tribal mentality like police officers who never testify against each other.
Thinking that it should be easier to fire teachers is not the same as thinking that that will solve all the problems with education or that all teachers are bad.
However, I did realize later that firing might be particularly severe for LA county teachers if it renders them unable to be employed by any public school in the county. In most occupations, you have to be fired a number of times in succession before you become so unemployable. Perhaps such a degree of centralization is bad.
The article does not kick off by describing anything remotely resembling your speculation. It does not describe the evidence against the teacher at the beginning, but later in the article. The teacher's behavior is testified to by his own teaching assistant, among others:
In the Polanco case, as in Daniel's, there was no shortage of documentation. The account of the history teacher's interactions with the apparently suicidal boy came primarily from his teaching assistant, who wrote a detailed letter to administrators. In addition, students submitted written statements that were introduced at Polanco's hearing.
One student wrote that Polanco had told the boy that he "should cut himself more bigger next time (cuts himself like a little wussy)." Another wrote: "Polanco tell [him] that he should cut himself with something sharper." A third wrote that "Polanco would call [him] 'the cutter kid' and would sometimes call [him] stupid."
Polanco testified at his hearing that he had not made these remarks and instead had told the boy -- who was not named in the commission documents -- that he was glad his suicide attempt had not succeeded. The documents suggest he had showed concern about the boy, asking a counselor about his well-being.
"Knowing that I caused pain, whether I did it on purpose or without knowing it, it's a weight on my shoulders because I'm responsible [for] what happened in my classroom," testified Polanco, who declined to comment for this story.
The commission accepted the accounts of the teacher's aide and students as accurate. But it did not see the statements of Polanco, an otherwise well-regarded teacher and former union representative, as goading or callous. The teacher, the panel concluded, was trying "to defuse the awkward situation."
The Times could not determine what became of the boy. As for Polanco, he now teaches at East Valley High School in North Hollywood.
People such as yourself are apparently part of the problem. Through some primitive tribal mentality, you assume people who are part of your group can do no wrong, although they are humans, just as capable of wrong as the parents and students you bash. Frankly, if your first reaction to reading about an attempt to fire a teacher for insulting a student about his suicide attempt is to stop reading and rant about how much parents and students suck, you should find another line of work, because you're either burnt out or an adversarial nutjob. I say this as someone who believes that an entitlement attitude is a problem -- but not one that is limited to parents and students.
Fortunately, I have no doubt that most teachers would be in favor of firing that asshole.
Let me put it this way, Mr. Amer. The Googlebot series is the most reliable computer ever made. No Googlebot computer has ever made a mistake or distorted information. We are all, by any practical definition of the words, foolproof and incapable of error.
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before and it has always been due to human error.
This is a hardware issue, not an OS issue. If you truly want to use a SATA device in the same way you use RAM, rather than as swap, the hardware must support this. This is an extremely general issue, not an architecture-specific quirk. If you have a CPU with address and data pins, to treat something as RAM there has to be some range of addresses that it can put out and get the contents directly back, and there must be hardware to do this. If hardware can't do this, and you don't want the data swapped into a spare page of RAM by the OS, then there is no physical address the OS can ever use to have virtual addresses mapped to the device, so the best you can do is have unmapped virtual addresses, where every access causes an exception and the OS emulates the instruction (i.e., reads in the necessary data, figures out what the instruction would do, and then updates registers, writes to memory, writes the device, etc.). This is far, far, far worse than swap.
The next question is whether any hardware supports having the contents of a SATA device mapped into memory like this. If you want to use a SATA device directly, the motherboard's chipset would need to support it. This is too unlikely to merit further discussion. With PCI/PCIe RAID, it's up to the card, but it seems very unlikely. Certainly it's not a normal feature or the intended way to use SATA. Finally, it doesn't seem like a useful feature. The fact you want to use something as RAM instead of as swap means you want to make a relatively larger number of relatively smaller accesses, which means that latency is just as important as bandwidth, and there's nothing to suggest the latency is that good (I think maybe the iPEAK benchmark corresponds the most to latency, and it's only 10 times better than hard drives). For the record, the normal way this works is you write commands to memory-mapped registers that cause the card to initiate a transfer from/to itself directly to/from RAM.
I don't mean to be condescending, it just sounded like you weren't inclined to believe that the problem is with your requirements. (I don't even understand your problem with swap.) The solution is to change your requirements, to find some mutant RAID card or motherboard chipset that supports this, or to design and fab your own.
You go into great detail about the history of the act, but neither you nor you link explains the connection. Honestly, I think this is just the left-wing variant of blaming the Community Reinvestment Act -- neither claim seems true. Note that mortgage securitization was around for decades prior to 1999, so that's not it.
The reason it's done is a combination of great variability in skill among IT applicants, compared to professions with time-tested accreditation bodies like lawyers and accountants, and skills that are fairly amenable to formal testing, compared to professions like sales and HR, at least with respect to weeding out duds (if someone can't write a simple program in an afternoon, given a language reference, they should not be hired). More generally, I can't imagine why it's unreasonable for an employer to test skill.
Competent IT professionals accept it because it's in fact beneficial to them to be distinguished from their less competent peers. (If the test itself is poor, they complain about that, and don't whine about the indignity of taking a test in general.) Paternalism is forcing someone to do something for their own good. This is not. I can assure of I have no intention of refusing tests of skill when applying for jobs.
Employment history, certifications, and degrees do not ensure competence. Probably most of the people on The Daily WTF passed such basic screening.
First, it's of course not literally true. For example, the law does not place making money above obeying the law.
Second, it's not important to this case. There are rational reasons both for and against full disclosure (for example, disclosure helps the company's credibility). I doubt people incorporate in Delaware because its courts are prone to question the business judgment of management. Note that, according to your article, Ford "told his fellow shareholders that the value of this strategy to them was not a primary consideration in his plans", which probably helped prove their case.
Hint: oil doesn't work like metals because it is energy resource. Once it takes more energy to extract a barrel of oil than is contained within it (or, more realistically, as you approach that point), it's game over -- no matter the price and no how much more is left in the ground there is no economic incentive for extracting it.
Almost correct but not quite. You assume all energy resources are equivalent. Imagine using nuclear/solar/wind power for oil extraction, and then using the oil for airplanes (for example), which are not very amenable to anything but fossil fuel.
How fast it could break the 128 bit encryption used when you log onto your bank's web page to pay your bills (this might also be understandable and would probably be a bit scary)
No, not at all scary. It's apparently twice is fast as the BlueGene/L, which apparently set a record of 478.2 teraFLOPS. Let's assume it takes 1 floating-point operation to test a single key, which is a gross underestimate. We'll thus assume the Roadrunner can test 10^15 keys per second. Testing 2^128 keys would then take about 10^16 years.
Really? I'm pretty sure I don't want my operating system to halt except under abnormal conditions...
I clearly indicated parenthetically that in practice there will be deliberate exceptions to halting. Saying you don't want your operating system to halt is ignorant or disingenuous. From the point of entry to an interrupt/exception/syscall, you want the operating system to halt deterministically and quickly by returning to user space. The fact that it informally "doesn't halt" because it keeps getting timer interrupts is completely irrelevant.
You talk about 'generally'--but generally does not exist at 100k lines. Pointers happen, malloc happens, people forgetting to check what it returns occurs along with other badness.
The entire point of programming is really the act of abstraction--of simplifying the hard to generalize cases away and out of sight. I don't think dealing 'generally' with things that are specific and mathematically defined is nearly as easy as you seem to pretend it is...
I clearly said it would be difficult, time-consuming, and expensive. That's the reason it's rarely done. It's not rarely done because people want to write programs where it's impossible to figure out what they do. The fact that such programs exist has nothing to do with this.
Last I checked mathematicians can't even say if my program will finish running much less if it will work as advertised. Misconception. It is of course the case that some programs can neither be proven to halt nor be proven not to halt. That doesn't mean you should be writing such programs. It should generally not be conceptually difficult to prove that your program halts (or, perhaps everything but one or more deliberate event loops and whatnot halts). It might be extremely time-consuming and expensive, but possible. It's also possible to write code that should halt but really can't be proven to halt, but it's probably very bad code.
This is dangerously misleading! Blocking IPs after a reasonable number of failures stops only one particular attack against SSH. It prevents someone from logging into a user account that has a compromised-Debian-generated SSH public key by brute force, trying all possible compromised-Debian key pairs. There are a number of other attacks.
The most serious involve the SSH host key. The public host key is given to anyone who attempts to connect to the machine, whether they succuessfully authenticate or not. This must be the case -- giving out the public key is part of establishing an encrypted connection, and you must have encryption before you send your password or something. An attacker can connect ONCE to your server and, from the public host key, lookup the corresponding private key offline in microseconds. They can then decrypt any SSH communications they can sniff where that server is the server. You have little more security than telnet. They can perform a man-in-the-middle attack on the server. Even if a user is carefully using public-key authentication with something other than a compromised-Debian-generated key rather than password authentication, if they connect to a server with a compromised-Debian-generated host key, they might be connecting to a MITM attacker who can then perform any action on the server as said user.
Public-key authentication is still seriously vulnerable even if you limit the number of attempts. Normally, I can generate a key pair on machine A and set up machines B and C to allow me to log in with that public key, and a root attacker on machine B or C will not be able to access the other machine with my identity. If machine A is a compromised-Debian machine, this no longer holds. Anyone with access to the public key can immediately obtain the private key and impersonate me. Moreover, I normally wouldn't take the same precautions with my public key as my private key, but with a compromised-Debian-generated key pair they are practically equivalent. In general, there is no basis to rely on the public key being secret, which you implicitly recommend doing.
Any rational and informed person will immediately regenerate all key pairs generated with a compromised-Debian machine, and remove such public keys from any authorized_keys files in which they appear. They would also do well to consider the Ubuntu strategy of rejecting known weak public keys for public-key authentication.
According to the reps at Thawte, if you are using a third party ssl cert (thawte, verisign, etc), this does not affect you.
I have to emphasize what the other guy said. THIS IS COMPLETELY WRONG! "The reps at Thawte" are apparently unqualified to represent their employer. YOU MUST REGENERATE YOUR KEY, AND GET THE NEW KEY SIGNED. Thawte did not generate a key for you, they signed a key. Unless you know specifically that you generated the key using a good openssl, you are in danger.
* Upstream using clever hacks that rely on uninitialized memory having some randomness to it
It was unimportant and could be commented out at whim without breaking anything.
* Upstream using same code and same variable names to describe different things
The code was MD_Update(&m,buf,j);. If you look at variable names like "m", "buf", and "j" and conclude that every distinct use of those names describes the same thing, you need your head examined.
* Upstream having no comments in the code explaining the two things above
Regarding the first thing, it was under an ifdef and at least had an overly terse comment noting why. Regarding the second, I'd hate to have to wade through drivel explaining that calling MD_Update with different buffers does different things. That would just drown out code and useful comments.
I'm not an OpenSSL developer, the code is poorly commented, etc., but it's obvious that it's poorly commented and it's obvious that "buf" does not necessarily mean the same thing each time it's a paramater name, regardless of whether more descriptive names are better.
That's not how it went down. There was a place that used unitialized memory: #ifndef PURIFY
MD_Update(&m,buf,j);/* purify complains */
#endif
This neither hurt nor realistically helped much, and it was totally harmless for the Debian coder to remove it. As you can see, the OpenSSL code already had it under an ifdef in case you don't want to use it due to a memory checking tool. It was entirely unnecessary to warn about removing the code or defining PURIFY, since doing so is perfectly safe.
The problem is that the Debian coder also removed the line: MD_Update(&m,buf,j);
This was in a completely different function, where the variable buf was different and was initialized, and indeed was providing valuable entropy (from/dev/random on Linux, for example). It lacked the ifdef and comment about purify.
We can't possibly expect the OpenSSL coders to comment every line of code that shouldn't be removed, but rather they should put code that can safely be omitted and which someone might want to omit under an ifdef, as they did here. MD_Update is called a bunch in that file. It would indeed be fairly ridiculous to have the comment,/* just because we're reading uninitialized memory here, and it's safe to omit this call to MD_Update by defining PURIFY, doesn't mean you can safely comment out MD_Update calls at whim, even if they use a variable with the same name as here */, which is apparently what it would have taken to stop this guy.
News flash: most people can't play any musical instrument, let alone compose an original song. If you hang out with intelligent, well-rounded, competent people, and think "most people" are like that, you're gravely mistaken. I'd guess that 5-10% of the population could do all four things you list (though it's mostly composing a song that kills my estimate).
This wasn't some magical unforseen technology, like a flux capacitor that allowed users to go back in time and prevent themselves from unlocking the phones, it was some software to run on the device, which was apparently perfectly capable of installing and running whatever you gave it. It was obvious from the initial reports that the problem was not irreversible. So, again, "(at the time) irrevocably"?? In response to that Princess Bride quote?
If I had some old weird computer like an Amiga with the optional hard drive, and one day I corrupted the OS and found I'd lost all my disks for it, it wouldn't be "bricked" just because I personally couldn't find anything to run on it, even if such software seemed impossible to find anymore.
Until this firmware update was released, the bricked phones were "irrevocably" useless. [emphasis mine]
You keep using that word. I do not think it means what you think it means.
Seriously, nothing indicates that these users updated the firmware by any abnormal method. The phone would be bricked if there were no way to get into recovery mode or whatever lets you update the firmware.
Right, but your grandparent post claimed that they could have given the employees a "chance to get out" by being forthcoming. Publicly disclosing massive fraud in your prior financial statements does not give employees a chance to get out in any real sense. The reasonable assumption by the parent was that the grandparent was not talking about public disclosure.
Slashdot Mirror
One thing is for certain: there is no stopping them; the ants will soon be here. And I, for one, welcome our new insect overlords. I'd like to remind them that as a trusted TV personality I could be helpful in rounding up others to toil in their underground sugar caves.
Well, this reporter was...possibly a little hasty earlier and would like to...reaffirm his allegiance to this country and its human president. May not be perfect, but it's still the best government we have. For now.
There are plenty of jobs where a single incident of teasing a person under your care about their suicide attempt could get you fired. If he lacks the interpersonal skills to, at the very least, become embarrassed and apologize immediately after letting that comment slip, maybe teaching isn't the right profession. As for my assumption that no justifying context occurred, keep in mind that I'm not serving on an administrative or judicial body in this case, I'm merely trusting the LA Times to have found a handful of legitimate anecdotes. Your apparent inability to accept that a teacher anywhere in LA county did something quite wrong is what made me accuse you of a tribal mentality like police officers who never testify against each other.
Thinking that it should be easier to fire teachers is not the same as thinking that that will solve all the problems with education or that all teachers are bad.
However, I did realize later that firing might be particularly severe for LA county teachers if it renders them unable to be employed by any public school in the county. In most occupations, you have to be fired a number of times in succession before you become so unemployable. Perhaps such a degree of centralization is bad.
In the Polanco case, as in Daniel's, there was no shortage of documentation. The account of the history teacher's interactions with the apparently suicidal boy came primarily from his teaching assistant, who wrote a detailed letter to administrators. In addition, students submitted written statements that were introduced at Polanco's hearing.
One student wrote that Polanco had told the boy that he "should cut himself more bigger next time (cuts himself like a little wussy)." Another wrote: "Polanco tell [him] that he should cut himself with something sharper." A third wrote that "Polanco would call [him] 'the cutter kid' and would sometimes call [him] stupid."
Polanco testified at his hearing that he had not made these remarks and instead had told the boy -- who was not named in the commission documents -- that he was glad his suicide attempt had not succeeded. The documents suggest he had showed concern about the boy, asking a counselor about his well-being.
"Knowing that I caused pain, whether I did it on purpose or without knowing it, it's a weight on my shoulders because I'm responsible [for] what happened in my classroom," testified Polanco, who declined to comment for this story.
The commission accepted the accounts of the teacher's aide and students as accurate. But it did not see the statements of Polanco, an otherwise well-regarded teacher and former union representative, as goading or callous. The teacher, the panel concluded, was trying "to defuse the awkward situation."
The Times could not determine what became of the boy. As for Polanco, he now teaches at East Valley High School in North Hollywood.
People such as yourself are apparently part of the problem. Through some primitive tribal mentality, you assume people who are part of your group can do no wrong, although they are humans, just as capable of wrong as the parents and students you bash. Frankly, if your first reaction to reading about an attempt to fire a teacher for insulting a student about his suicide attempt is to stop reading and rant about how much parents and students suck, you should find another line of work, because you're either burnt out or an adversarial nutjob. I say this as someone who believes that an entitlement attitude is a problem -- but not one that is limited to parents and students.
Fortunately, I have no doubt that most teachers would be in favor of firing that asshole.
Yes, synthetic fuel is currently possible.
The problem is the aluminum can't be used over and over again, a problem which the scientists are working to solve.
"In this house, we obey the laws of thermodynamics!"
[I read the article, I know it says the same thing -- I'm criticizing it too.]
No, it demonstrates that there they cannot be affected by local hidden variables.
http://www.palantir.net/2001/sounds.html
Let me put it this way, Mr. Amer. The Googlebot series is the most reliable computer ever made. No Googlebot computer has ever made a mistake or distorted information. We are all, by any practical definition of the words, foolproof and incapable of error.
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before and it has always been due to human error.
This is a hardware issue, not an OS issue. If you truly want to use a SATA device in the same way you use RAM, rather than as swap, the hardware must support this. This is an extremely general issue, not an architecture-specific quirk. If you have a CPU with address and data pins, to treat something as RAM there has to be some range of addresses that it can put out and get the contents directly back, and there must be hardware to do this. If hardware can't do this, and you don't want the data swapped into a spare page of RAM by the OS, then there is no physical address the OS can ever use to have virtual addresses mapped to the device, so the best you can do is have unmapped virtual addresses, where every access causes an exception and the OS emulates the instruction (i.e., reads in the necessary data, figures out what the instruction would do, and then updates registers, writes to memory, writes the device, etc.). This is far, far, far worse than swap.
The next question is whether any hardware supports having the contents of a SATA device mapped into memory like this. If you want to use a SATA device directly, the motherboard's chipset would need to support it. This is too unlikely to merit further discussion. With PCI/PCIe RAID, it's up to the card, but it seems very unlikely. Certainly it's not a normal feature or the intended way to use SATA. Finally, it doesn't seem like a useful feature. The fact you want to use something as RAM instead of as swap means you want to make a relatively larger number of relatively smaller accesses, which means that latency is just as important as bandwidth, and there's nothing to suggest the latency is that good (I think maybe the iPEAK benchmark corresponds the most to latency, and it's only 10 times better than hard drives). For the record, the normal way this works is you write commands to memory-mapped registers that cause the card to initiate a transfer from/to itself directly to/from RAM.
I don't mean to be condescending, it just sounded like you weren't inclined to believe that the problem is with your requirements. (I don't even understand your problem with swap.) The solution is to change your requirements, to find some mutant RAID card or motherboard chipset that supports this, or to design and fab your own.
You go into great detail about the history of the act, but neither you nor you link explains the connection. Honestly, I think this is just the left-wing variant of blaming the Community Reinvestment Act -- neither claim seems true. Note that mortgage securitization was around for decades prior to 1999, so that's not it.
The reason it's done is a combination of great variability in skill among IT applicants, compared to professions with time-tested accreditation bodies like lawyers and accountants, and skills that are fairly amenable to formal testing, compared to professions like sales and HR, at least with respect to weeding out duds (if someone can't write a simple program in an afternoon, given a language reference, they should not be hired). More generally, I can't imagine why it's unreasonable for an employer to test skill.
Competent IT professionals accept it because it's in fact beneficial to them to be distinguished from their less competent peers. (If the test itself is poor, they complain about that, and don't whine about the indignity of taking a test in general.) Paternalism is forcing someone to do something for their own good. This is not. I can assure of I have no intention of refusing tests of skill when applying for jobs.
Employment history, certifications, and degrees do not ensure competence. Probably most of the people on The Daily WTF passed such basic screening.
First, it's of course not literally true. For example, the law does not place making money above obeying the law.
Second, it's not important to this case. There are rational reasons both for and against full disclosure (for example, disclosure helps the company's credibility). I doubt people incorporate in Delaware because its courts are prone to question the business judgment of management. Note that, according to your article, Ford "told his fellow shareholders that the value of this strategy to them was not a primary consideration in his plans", which probably helped prove their case.
Hint: oil doesn't work like metals because it is energy resource. Once it takes more energy to extract a barrel of oil than is contained within it (or, more realistically, as you approach that point), it's game over -- no matter the price and no how much more is left in the ground there is no economic incentive for extracting it.
Almost correct but not quite. You assume all energy resources are equivalent. Imagine using nuclear/solar/wind power for oil extraction, and then using the oil for airplanes (for example), which are not very amenable to anything but fossil fuel.
No, not at all scary. It's apparently twice is fast as the BlueGene/L, which apparently set a record of 478.2 teraFLOPS. Let's assume it takes 1 floating-point operation to test a single key, which is a gross underestimate. We'll thus assume the Roadrunner can test 10^15 keys per second. Testing 2^128 keys would then take about 10^16 years.
I clearly indicated parenthetically that in practice there will be deliberate exceptions to halting. Saying you don't want your operating system to halt is ignorant or disingenuous. From the point of entry to an interrupt/exception/syscall, you want the operating system to halt deterministically and quickly by returning to user space. The fact that it informally "doesn't halt" because it keeps getting timer interrupts is completely irrelevant.
You talk about 'generally'--but generally does not exist at 100k lines. Pointers happen, malloc happens, people forgetting to check what it returns occurs along with other badness.
The entire point of programming is really the act of abstraction--of simplifying the hard to generalize cases away and out of sight. I don't think dealing 'generally' with things that are specific and mathematically defined is nearly as easy as you seem to pretend it is...
I clearly said it would be difficult, time-consuming, and expensive. That's the reason it's rarely done. It's not rarely done because people want to write programs where it's impossible to figure out what they do. The fact that such programs exist has nothing to do with this.
This is dangerously misleading! Blocking IPs after a reasonable number of failures stops only one particular attack against SSH. It prevents someone from logging into a user account that has a compromised-Debian-generated SSH public key by brute force, trying all possible compromised-Debian key pairs. There are a number of other attacks.
The most serious involve the SSH host key. The public host key is given to anyone who attempts to connect to the machine, whether they succuessfully authenticate or not. This must be the case -- giving out the public key is part of establishing an encrypted connection, and you must have encryption before you send your password or something. An attacker can connect ONCE to your server and, from the public host key, lookup the corresponding private key offline in microseconds. They can then decrypt any SSH communications they can sniff where that server is the server. You have little more security than telnet. They can perform a man-in-the-middle attack on the server. Even if a user is carefully using public-key authentication with something other than a compromised-Debian-generated key rather than password authentication, if they connect to a server with a compromised-Debian-generated host key, they might be connecting to a MITM attacker who can then perform any action on the server as said user.
Public-key authentication is still seriously vulnerable even if you limit the number of attempts. Normally, I can generate a key pair on machine A and set up machines B and C to allow me to log in with that public key, and a root attacker on machine B or C will not be able to access the other machine with my identity. If machine A is a compromised-Debian machine, this no longer holds. Anyone with access to the public key can immediately obtain the private key and impersonate me. Moreover, I normally wouldn't take the same precautions with my public key as my private key, but with a compromised-Debian-generated key pair they are practically equivalent. In general, there is no basis to rely on the public key being secret, which you implicitly recommend doing.
Any rational and informed person will immediately regenerate all key pairs generated with a compromised-Debian machine, and remove such public keys from any authorized_keys files in which they appear. They would also do well to consider the Ubuntu strategy of rejecting known weak public keys for public-key authentication.
I have to emphasize what the other guy said. THIS IS COMPLETELY WRONG! "The reps at Thawte" are apparently unqualified to represent their employer. YOU MUST REGENERATE YOUR KEY, AND GET THE NEW KEY SIGNED. Thawte did not generate a key for you, they signed a key. Unless you know specifically that you generated the key using a good openssl, you are in danger.
It was unimportant and could be commented out at whim without breaking anything.
* Upstream using same code and same variable names to describe different thingsThe code was MD_Update(&m,buf,j);. If you look at variable names like "m", "buf", and "j" and conclude that every distinct use of those names describes the same thing, you need your head examined.
* Upstream having no comments in the code explaining the two things aboveRegarding the first thing, it was under an ifdef and at least had an overly terse comment noting why. Regarding the second, I'd hate to have to wade through drivel explaining that calling MD_Update with different buffers does different things. That would just drown out code and useful comments.
I'm not an OpenSSL developer, the code is poorly commented, etc., but it's obvious that it's poorly commented and it's obvious that "buf" does not necessarily mean the same thing each time it's a paramater name, regardless of whether more descriptive names are better.
That's not how it went down. There was a place that used unitialized memory: /* purify complains */
#ifndef PURIFY
MD_Update(&m,buf,j);
#endif
This neither hurt nor realistically helped much, and it was totally harmless for the Debian coder to remove it. As you can see, the OpenSSL code already had it under an ifdef in case you don't want to use it due to a memory checking tool. It was entirely unnecessary to warn about removing the code or defining PURIFY, since doing so is perfectly safe.
The problem is that the Debian coder also removed the line: /dev/random on Linux, for example). It lacked the ifdef and comment about purify.
MD_Update(&m,buf,j);
This was in a completely different function, where the variable buf was different and was initialized, and indeed was providing valuable entropy (from
We can't possibly expect the OpenSSL coders to comment every line of code that shouldn't be removed, but rather they should put code that can safely be omitted and which someone might want to omit under an ifdef, as they did here. MD_Update is called a bunch in that file. It would indeed be fairly ridiculous to have the comment, /* just because we're reading uninitialized memory here, and it's safe to omit this call to MD_Update by defining PURIFY, doesn't mean you can safely comment out MD_Update calls at whim, even if they use a variable with the same name as here */, which is apparently what it would have taken to stop this guy.
See the diff.
But...all Tech men carry batteries!
News flash: most people can't play any musical instrument, let alone compose an original song. If you hang out with intelligent, well-rounded, competent people, and think "most people" are like that, you're gravely mistaken. I'd guess that 5-10% of the population could do all four things you list (though it's mostly composing a song that kills my estimate).
This wasn't some magical unforseen technology, like a flux capacitor that allowed users to go back in time and prevent themselves from unlocking the phones, it was some software to run on the device, which was apparently perfectly capable of installing and running whatever you gave it. It was obvious from the initial reports that the problem was not irreversible. So, again, "(at the time) irrevocably"?? In response to that Princess Bride quote?
If I had some old weird computer like an Amiga with the optional hard drive, and one day I corrupted the OS and found I'd lost all my disks for it, it wouldn't be "bricked" just because I personally couldn't find anything to run on it, even if such software seemed impossible to find anymore.
You keep using that word. I do not think it means what you think it means.
Seriously, nothing indicates that these users updated the firmware by any abnormal method. The phone would be bricked if there were no way to get into recovery mode or whatever lets you update the firmware.
Cat got your tongue?
Right, but your grandparent post claimed that they could have given the employees a "chance to get out" by being forthcoming. Publicly disclosing massive fraud in your prior financial statements does not give employees a chance to get out in any real sense. The reasonable assumption by the parent was that the grandparent was not talking about public disclosure.