Well, IP addresses don't exactly have a language associated with them. Hell, it's been hard enough to try and get the IETF to add a "language" field to TCP packets.
Reading uninitialized memory when gathering entropy is harmless and potentially beneficial, but can't properly be considered not-an-error. More to the point, your entropy-gathering system should be no worse for the wear if you *don't* read the uninitialized memory, since on many systems, uninitialized memory could have zero entropy (thus, you can't rely on it as a source of entropy).
The problem is that a person broke the code while in the process of fixing the Valgrind warning -- not that fixing the warning was what broke the code.
In fact, this is the kind of error that an automated system warns about and doesn't fix because it's not always obvious what the programmer was intending to initialize the memory to. It's safer to warn that to initialize to something arbitrary. However, had an automated system fixed the Valgrind warning instead of the human (by initializing the memory to, presumably, zero), the vulnerability never would have existed, because the automated system wouldn't have made other errors along the way.
however note those words were written in 1916 and education standards are somewhat lower now
Do you have a citation for this? I think today's college matriculant tends to have a better understanding of mathematics than in the early 20th century.
Certainly, over a much smaller number of samples and time period, Feynman disagreed with you.
Just as hard with SSL. All you know is that it's being sent to someone who paid a CA for a certificate. And a CA is a business, they are in it to make money, and thus will sell a certificate to anyone.
It's enormously easier to MitM an HTTP session than it is to both MitM an HTTPS session and falsely obtain a certificate.
On top of that, simply trusting every CA out there is just the default stance of modern browsers. You can, however, choose only to trust particular CAs, implement a different or additional verification layer, run your own CA internally, et cetera. SSL gives you a lot of options with which to address the problem. HTTP gives you no tools.
When we got a certificate at work, the only check was that we could receive an e-mail. An e-mail sent over plain unencrypted SMTP.
Yes, there are different levels of validation for certificates and different qualities of CAs. These are well-known and addressable problems.
Even easier to MITM than HTTP, because SMTP isn't real time. You just send a mail, and it arrives at some point in the future.
Easier, yes, but the attack window is substantially smaller. Man-in-the-middle doesn't make a lot of sense, here. It's a more reasonable concern that someone is able to masquerade as the real domain owner to the CA.
The exchange of credentials has always been over HTTPS. It's just that the later communication redirects to HTTP (and includes your session cookie, which can be then used for sidejacking). Of course, it's easy to turn it on for "some users", since your credential exchange is over HTTPS, and after that, you know who the user is and can have the later communication be HTTP/S as appropriate.
Having a login page (e.g., http://www.twitter.com/) transmitted over HTTP is unsafe, since it's hard to verify where the login data is actually being sent. That is, an attacker could modify the login page to send credentials to a third party with a legitimate certificate instead of to Twitter, and since the login page wasn't HTTPS-protected, you wouldn't detect this. But, that's another story.
HTTPS for session communication -- what they're talking about here -- has been available as a feature for a while now. They're just changing what the default is for some users.
Actually, : is still the directory separator on Mac OS X. The BSD APIs silently interchange : and / so that / is the directory separator through the BSD APIs. (The : character is the only character not allowed in HFS+ filenames, although nulls will cause lots of problems, even if you use the fake UTF-16 representation of null that Apple uses.)
You can see this for yourself if you make a file or directory with / in it in the Finder and then ls it from the Terminal (or vice versa).
In the 1800's plenty of people had proven that manned flight was impossible.
FTL within the bounds of Newtonian physics is impossible.
Within the bounds of all known physics, including general relativity and quantum mechanics. Faster-than-light travel is actually accepted by Newtonian mechanics, but we've learned relativity in the meantime.
We have pretty much proven that with quantum physics there are a lot more things about the universe than Newton would have ever expected.
Quantum physics is about specific things, not "there's lots about the universe we don't understand", and it's not about Newton at all.
I believe on a small scale we have already seen FTL movement of particles through quantum entanglement.
Don't talk about science and use the word "believe". Quantum entanglement (and quantum teleportation) involve apparent action-at-a-distance that violates light-speed limitations, but it in reality, it doesn't.
Also, while travel on a galactic scale is probably pointless without FTL
It's pointless for the people who aren't traveling. Thanks to time dilation, travelers who are moving at a large fraction of c make the trip in a relatively short amount of time.
Comics aren't really movies or books, but ignoring that, superhero comics aren't among the very best written works. You may like them, but that's not really relevant.
Or subverted a wireless network the user is on. Or published fake BGP routes that cause traffic to go through a node you control. Or any of the dozens of other fine ways to execute a man-in-the-middle attack.
Foreshadowing! Back in the day, people went to see plays when they already knew the story. At the opera, it was expected that you'd have read the summary of the plot so you'd know what was going on. The chorus would give you a rundown of the entire plot at the beginning of the play.
Some of the very best movies and books are based around a mystery.
For one, The Matrix and The Watchmen are not among "the very best movies and books".
For another, the best movies and books -- or, in my opinion, basically all of them really worth reading or watching -- are based on good storytelling. They're as enjoyable even if you know exactly what's going to happen.
Well-designed systems are already decently good at this. A typical system where this is a problem has a single high-demand process and a lot of low-demand processes. A good scheduler will dedicate the high-demand process to a core, with no context switches.
I don't know if it's easy to set processor affinity in Linux, but it's easy to set in Windows, with the net result that you can basically dedicate cores to individual threads.
I elided the sciencey bit because I suspect you don't care what heat capacity is. Though if you're not at least familiar with simple thermodynamics, I can't imagine how you would manage to accurately evaluate the scientific rigor of a large field of research where a good grasp on thermodynamics is necessary.
The mechanism by which CO2 is theorised to retain heat is poorly understood and far from proven.
It's actually very well-understood. Arrhenius figured it out ages ago. The details in situ turn out to be moderately more complicated, but no intractable.
Water vapour has a far higher heat capacity to act as a greenhouse gas and yet isn't accounted for in most of the models,
I suspect talking science at you is like talking to a wall, but it's not heat capacity. Heat capacity is a different thing. Water vapor is a stronger greenhouse gas, It's also accounted for in most of the models, funny that. The reason it's not as significant a factor is that it's difficult to actually change the amount of water vapor in the atmosphere (overall).
That's a gross abuse of qualitative reasoning and dramatically different timescales. It's akin to saying, "I'm going to die eventually, so there's no reason to step off the tracks so this oncoming train doesn't hit me."
do you really want to use something new and unproven without a robust support system?
The only one of those adjectives that doesn't usually apply to specialty commercial software is "new". The support is sometimes better, but you'll usually pay an arm and a leg for it. Better to have an employee or contractor who's familiar with the OSS.
Slashdot Mirror
Well, IP addresses don't exactly have a language associated with them. Hell, it's been hard enough to try and get the IETF to add a "language" field to TCP packets.
Reading uninitialized memory when gathering entropy is harmless and potentially beneficial, but can't properly be considered not-an-error. More to the point, your entropy-gathering system should be no worse for the wear if you *don't* read the uninitialized memory, since on many systems, uninitialized memory could have zero entropy (thus, you can't rely on it as a source of entropy).
The problem is that a person broke the code while in the process of fixing the Valgrind warning -- not that fixing the warning was what broke the code.
In fact, this is the kind of error that an automated system warns about and doesn't fix because it's not always obvious what the programmer was intending to initialize the memory to. It's safer to warn that to initialize to something arbitrary. However, had an automated system fixed the Valgrind warning instead of the human (by initializing the memory to, presumably, zero), the vulnerability never would have existed, because the automated system wouldn't have made other errors along the way.
however note those words were written in 1916 and education standards are somewhat lower now
Do you have a citation for this? I think today's college matriculant tends to have a better understanding of mathematics than in the early 20th century.
Certainly, over a much smaller number of samples and time period, Feynman disagreed with you.
We're just sticking to the original Latin, rather than that hideous Anglo-Norman patois.
Well, that would be more dangerous, yes. Although putrescene would be more dramatic.
Just as hard with SSL. All you know is that it's being sent to someone who paid a CA for a certificate. And a CA is a business, they are in it to make money, and thus will sell a certificate to anyone.
It's enormously easier to MitM an HTTP session than it is to both MitM an HTTPS session and falsely obtain a certificate.
On top of that, simply trusting every CA out there is just the default stance of modern browsers. You can, however, choose only to trust particular CAs, implement a different or additional verification layer, run your own CA internally, et cetera. SSL gives you a lot of options with which to address the problem. HTTP gives you no tools.
When we got a certificate at work, the only check was that we could receive an e-mail. An e-mail sent over plain unencrypted SMTP.
Yes, there are different levels of validation for certificates and different qualities of CAs. These are well-known and addressable problems.
Even easier to MITM than HTTP, because SMTP isn't real time. You just send a mail, and it arrives at some point in the future.
Easier, yes, but the attack window is substantially smaller. Man-in-the-middle doesn't make a lot of sense, here. It's a more reasonable concern that someone is able to masquerade as the real domain owner to the CA.
The funniest bit is how he just ASSumes that regardless of the evidence the 'deniers' will just keep on denying
To be fair, studies show that this is exactly the most likely response when people are presented with evidence that is contrary to what they believe.
I can be convinced. But I want a little actual evidence first.
You have chosen to either willfully ignore the substantial body of evidence and research, or this statement is not actually true.
Well, 385 ppm elemental mercury ingested once really isn't that dangerous.
I think a fair deterrent would be 385 ppm putrescene.
The exchange of credentials has always been over HTTPS. It's just that the later communication redirects to HTTP (and includes your session cookie, which can be then used for sidejacking). Of course, it's easy to turn it on for "some users", since your credential exchange is over HTTPS, and after that, you know who the user is and can have the later communication be HTTP/S as appropriate.
Having a login page (e.g., http://www.twitter.com/) transmitted over HTTP is unsafe, since it's hard to verify where the login data is actually being sent. That is, an attacker could modify the login page to send credentials to a third party with a legitimate certificate instead of to Twitter, and since the login page wasn't HTTPS-protected, you wouldn't detect this. But, that's another story.
HTTPS for session communication -- what they're talking about here -- has been available as a feature for a while now. They're just changing what the default is for some users.
Actually, : is still the directory separator on Mac OS X. The BSD APIs silently interchange : and / so that / is the directory separator through the BSD APIs. (The : character is the only character not allowed in HFS+ filenames, although nulls will cause lots of problems, even if you use the fake UTF-16 representation of null that Apple uses.)
You can see this for yourself if you make a file or directory with / in it in the Finder and then ls it from the Terminal (or vice versa).
Or that black professors choose to work at more teaching-focused schools with weaker research programs.
Increased terrestrial conflict due to resource exhaustion.
DARPA doesn't do baby steps. You're thinking of different research agencies.
In the 1800's plenty of people had proven that manned flight was impossible.
FTL within the bounds of Newtonian physics is impossible.
Within the bounds of all known physics, including general relativity and quantum mechanics. Faster-than-light travel is actually accepted by Newtonian mechanics, but we've learned relativity in the meantime.
We have pretty much proven that with quantum physics there are a lot more things about the universe than Newton would have ever expected.
Quantum physics is about specific things, not "there's lots about the universe we don't understand", and it's not about Newton at all.
I believe on a small scale we have already seen FTL movement of particles through quantum entanglement.
Don't talk about science and use the word "believe". Quantum entanglement (and quantum teleportation) involve apparent action-at-a-distance that violates light-speed limitations, but it in reality, it doesn't.
Also, while travel on a galactic scale is probably pointless without FTL
It's pointless for the people who aren't traveling. Thanks to time dilation, travelers who are moving at a large fraction of c make the trip in a relatively short amount of time.
Comics aren't really movies or books, but ignoring that, superhero comics aren't among the very best written works. You may like them, but that's not really relevant.
Or subverted a wireless network the user is on. Or published fake BGP routes that cause traffic to go through a node you control. Or any of the dozens of other fine ways to execute a man-in-the-middle attack.
Foreshadowing! Back in the day, people went to see plays when they already knew the story. At the opera, it was expected that you'd have read the summary of the plot so you'd know what was going on. The chorus would give you a rundown of the entire plot at the beginning of the play.
Some of the very best movies and books are based around a mystery.
For one, The Matrix and The Watchmen are not among "the very best movies and books".
For another, the best movies and books -- or, in my opinion, basically all of them really worth reading or watching -- are based on good storytelling. They're as enjoyable even if you know exactly what's going to happen.
Wait, peer review is related to sample size?
Or he managed to be lucky for a while, which is far more likely.
Well-designed systems are already decently good at this. A typical system where this is a problem has a single high-demand process and a lot of low-demand processes. A good scheduler will dedicate the high-demand process to a core, with no context switches.
I don't know if it's easy to set processor affinity in Linux, but it's easy to set in Windows, with the net result that you can basically dedicate cores to individual threads.
I elided the sciencey bit because I suspect you don't care what heat capacity is. Though if you're not at least familiar with simple thermodynamics, I can't imagine how you would manage to accurately evaluate the scientific rigor of a large field of research where a good grasp on thermodynamics is necessary.
The mechanism by which CO2 is theorised to retain heat is poorly understood and far from proven.
It's actually very well-understood. Arrhenius figured it out ages ago. The details in situ turn out to be moderately more complicated, but no intractable.
Water vapour has a far higher heat capacity to act as a greenhouse gas and yet isn't accounted for in most of the models,
I suspect talking science at you is like talking to a wall, but it's not heat capacity. Heat capacity is a different thing. Water vapor is a stronger greenhouse gas, It's also accounted for in most of the models, funny that. The reason it's not as significant a factor is that it's difficult to actually change the amount of water vapor in the atmosphere (overall).
That's a gross abuse of qualitative reasoning and dramatically different timescales. It's akin to saying, "I'm going to die eventually, so there's no reason to step off the tracks so this oncoming train doesn't hit me."
do you really want to use something new and unproven without a robust support system?
The only one of those adjectives that doesn't usually apply to specialty commercial software is "new". The support is sometimes better, but you'll usually pay an arm and a leg for it. Better to have an employee or contractor who's familiar with the OSS.