That one is a must read. It definitely opened my eyes when I first read it, and I thought of myself as someone very security conscious at the time.

Since then, I think I've actually become less security conscious though. The sheer number of ways you as a user of any of the useful parts of the internet are screwed is mind boggling. At some point, you just throw your hands up in disgust.

Dude, I don't even trust code I do write myself. I can trust myself not to be malicious. But I can't trust myself to be perfectly vigilant against cutting corners all the time (everyone does this, especially those who think they don't). And I can't trust my coding to be perfect.

That is about as helpful as telling people that they can't trust food that they didn't grow themselves. Has no relevance in the modern world where unfortunately you can't easily grow your own food. In other words pick your poison and your battles.

Did you bother reading it? Did you get to this part:

To what extent should one trust a statement that a program is free of Trojan horses? Perhaps it is more important to trust the people who wrote the software.

I didn't read it.

My reaction was to the statement which I replied to. I would take that either as a summary of the document or your conclusion on the document.

Is it necessary to only comment after a full reading and understanding of the base document that someone is summarizing?

If someone pulls out a phrase "The press must learn that misguided use of a computer is no more amazing than drunk driving of an automobile." (from the same document) I think that stands on its own as worthy of replying back to without seeing what else has been written that might clarify it. I don't think this is cherry picking and pulling things out of context either.

First, I would expect that if someone like Ken Thompson says something like this there is more to the comment than you are going to get from the blurb. You really must read it.

Secondly, if you read it, you will recognize that what he is talking about is a real issue, particularly in the post-Snowden era and is totally relevant to the article. And his point really is that you can never be sure there isn't a backdoor planted somewhere in your software or hardware. Even if you write all the code yourself, it is still operating in an environment that you did not build.

Understanding this problem at its root is the beginning of an understanding into why depth is so important to IT security and why all our current approaches at trusted binaries are inadequate at least on their own.

Reading three pages by Ken Thompson takes effort. Retweeting some Snowden meme is easy.

What can you say to someone that thinks Ken Thompson has no relevance in the modern world or thinks he does not need to read something in order to judge if the one sentence he pulled out was taken out of context?

> What can you say to someone that thinks Ken Thompson has no relevance in the modern world or thinks he does not need to read something in order to judge if the one sentence he pulled out was taken out of context?

That those who do not understand UNIX (or history!) are destined to reinvent it badly (shamelessly stealing from Harry Spencer).

> Is it necessary to only comment after a full reading and understanding of the base document that someone is summarizing?

In my opinion, yes. I don't know how to say it politely so I apologize for the abrasiveness: I think that when someone comments on something with little to no knowledge of the subject they are talking out of their ass. I try to avoid doing this because it seems like a waste of time for everyone involved and is therefore rude to other members of the community who want to engage in an intelligent discussion.

> I don't think this is cherry picking and pulling things out of context either.

How would you know? Without reading the document you have no idea what the context is.