So what they see is "picture.jpg" If they don't notice the picture icon next to it that would be the same as a .exe, then they fall for it.

Actually it will show the embedded icon from the .exe which can easily be set to look like a picture file.

But what has always confused me is the filename actually shows as "picture.jpg", while an actual picture.jpg would show as just "picture", right? Therefore it should still be possible to distinguish them because a real one does not have ".jpg". Though I can imagine people not noticing, I'm wondering if there is (or was) a much worse bug, such as the display truncating at the first period while file-type lookup used the last period?

Anybody know? I don't have windows here to test.

Also the A380 is pretty silly looking. Have you seen one? It's like a fat guppy.

And they use more burp and fart sound effects than all of Hollywood!

As pointed out in the article, the program must use gethostbyname() on a name supplied by the attacker.

A much more mitigating factor is that the bug is only exercised if the name looks like a numerical id, and according to their search most software first checks this using inet_aton() and only calls gethostbyname() if this fails, thus avoiding the bug.

I have yet to have one such buffer overflow bug in my code

Yea, right. You know the authors of this function probably thought that too. They had no counter examples until now, just like you and your code.

strncpy will not overflow the buffer provided you pass the size of the buffer (if you don't pass the size of the buffer, *none* of the safer functions are going to help). It's problem is that it will not write a nul at the end of the buffer, thus reading will read right off the end. It also wastes a huge amount of time filling the unused part of the buffer with nul.

strlcpy is far, far better and does pretty much what is wanted.

However in this case they really did try to figure out if the buffer would overflow, so neither strlcpy or strncpy should be needed. They did the calculation wrong, claiming it needed 4-8 bytes less than it really did.

My theory is that a competitor airline is needed.

AB airlines flys A->B, and also A->B->C. Without any other reason, an A->B->C ticket would cost more or equal to the A->B ticket.

But AC airlines flies A->C, and is charging a smaller price than AB airlines.

AB airlines decides to complete by lowering the price for A->B->C so that it is less or equal to AC airlines A->C price. But they are not competing on A->B so they keep the price higher for A->B.

No, stop being an idiot.

"regular users" click on files in a list or 2-d grid. They would not even notice if the filesystem allowed more than one file with the same name, and the certainly do not give a damn about case insensitivity. Even if they type at a terminal they use filename-completion and do not care either.

It is also clear that it has nothing to do with user-friendliness or they would map more common errors, such as multiple spaces to single ones, removing leading and trailing whitespace, or mapping equivalent unicode to the same files. They don't do this because they realize that such complex details of the encoding do not belong in the file system api.

Case-insensitivity is a throwback to ancient ASCII-only systems. If you live in the stone age you may think it is a good idea. If you have been exposed to it all your life you may think it is a good idea. But if you were actually intelligent you would know it is wrong.

All modern systems are capable of storing different strings for filenames in different cases. So no, Linux has it right and Windows has it wrong. Sorry to burst your bubble, but you are simply Wrong, with a capital W.

No. Two different byte strings should identify two different files (unless one or both of them are invalid byte streams). Anything else is introducing complexity into the filesystem and potential bugs and security violations, of which this it an excellent example. Sorry, but Unix has it right, and Microsoft and lots of other systems are *WRONG*.

The new news that the government thinks they did it certainly changes my opinion, though I would be curious exactly what the evidence is. I find it hard to believe they would risk making a stupid blunder of an incorrect accusation, so the info must be pretty good, such as directly from a spy inside NK at the hacker facility.

My gut feeling is this is disgruntled Sony employees. Somebody thought it would sound cool to threaten theaters and are probably amazed at the result.

Chrome also complains about self-signed https, so you lose. Sorry.

Except NK denied being behind the hacking.

Now there is no reason to believe anything NK says, but I would think they would be very proud of their computer achievements if they had been behind it.

The reason they don't falsely claim they are behind it is because they are worried the actual hackers would be found and then it would be clear they were lying.

Because they wanted to arrest him for drug trafficking.

Deporting him would mean he would probably sneak back or arrange with his friends still in the USA to continue drug trafficking. If you assume that drug trafficking is something that you don't want (and under current USA laws is something the police are supposed to prevent) then this is a totally logical approach.

I suspect the North Korean will not have a problem getting the USA to give him a tourist visa. He *will* have some trouble getting access to ask the USA for one, and for actually getting out of North Korea to use it.