Slashdot Mirror

Then my fortunes changed when I had the chance to buy a used Altos 8086 computer running Microsoft's version of AT&T Version 7 Unix called "Xenix" ( )

What was great about it, is that it had a program called "learn" ( ) which was a tutorial that taught both Unix and C.

It's a shame that "learn" is not included in modern Unix and Linux distros. That would be a valuable resource for students that would otherwise only be exposed to an OS (which will remain nameless here) that was designed for computer illiterates.

This is your chance to make sure the next generation can at least perceive the elegance and thought that went into making an OS and programming language that was designed by and for programmers, instead of by and for businessmen.

Here's what I got, so far. Sorry it's not tabbed and cross-referenced...

http://ask.slashdot.org/article.pl?sid=08/09/17/224230 -- in case anyone wants this page, too
http://www.quickref.org/
http://gotapi.com/
http://www.regular-expressions.info/ -- regular expressions
http://www.perlmonks.org/
http://www.rosettacode.org/wiki/Main_Page
http://perldoc.perl.org/
http://www.perlbuzz.com/
http://java.sun.com/reference/
http://forums.sun.com/index.jspa
http://developer.mozilla.org/ -- javascript
http://www.w3.org/MarkUp/Guide/
http://www.w3.org/MarkUp/Guide/Advanced.html
http://www.w3.org/TR/html4/
http://www.w3.org/TR/xhtml1/
http://www.w3.org/Style/Examples/007/
http://www.w3.org/Style/Examples/011/firstcss
http://www.w3.org/Style/CSS/learning
http://en.wikibooks.org/wiki/Programming:Tcl
http://www.acm.uiuc.edu/webmonkeys/book/c_guide/
http://cprogramming.com/
http://www.cplusplus.com/
http://cm.bell-labs.com/cm/cs/cbook/
http://www.parashift.com/c++-faq-lite/
http://en.wikibooks.org/
http://developer.apple.com/
http://cocoadev.com/
http://www.cocoabuilder.com/

http://www.perlmonks.org/
http://en.wikipedia.org/wiki/Scheme_(programming_language)
http://www.schemers.org/Documents/Standards/R5RS/
http://srfi.schemers.org/
http://mitpress.mit.edu/sicp/full-text/book/book.html
http://www.quickref.org/
http://java.sun.com/javase/reference/api.jsp
http://www.rosettacode.org/wiki/Main_Page
http://cprogramming.com/
http://www.stackoverflow.com/
http://cm.bell-labs.com/cm/cs/cbook/
http://yutaka.is-a-geek.net/
http://www.gotapi.com/
http://www.open-rsc.org/
http://www.users.bigpond.com/robin_v/resource.htm
http://www.geocities.com/orion_blastar/contact/
http://en.wikibooks.org/

For C, use the most holy book:
K&R
(aka "The C Programming Language" by Kernighan and Ritchie, http://cm.bell-labs.com/cm/cs/cbook/)

...reading for anyone who references Trusting Trust alone! Here are links to the original Ken Thompson's "Reflections on Trusting Trust" (HTML/non-PDF version) and David A. Wheeler's "Countering Trusting Trust" which offers potential solutions to the issues raised in the original.

Basically so long as I have another set of compilers AND at least one is trustworthy then there is process I can follow to build a compiler I can trust (but where it would help to have the compiler sources). There are other reasons why such an issue might find it hard to propagate in a changing software stack but that's a side note.

This seems to be a very popular Slashdot meme - people keep mentioning Trusting Trust without also answering the points offered in more recent literature.

Anyone who mentions Ken Thompson's Reflections on Trusting Trustshould also mention David A. Wheeler's "Countering Trusting Trust". Those who don't should be punished by having to argue both sides of the debate.

I occasionally post the counter argument in a reply but no one sees it... Next time you see someone else with this behaviour tr, here's ammo for countering it.

(I believe the gcc rebuilds aren't so much to remove this type of intentional bugging but rather ensure the final binary is free from things like first compilation optimisation issues... Comparing the compiler binaries would probably indicate differences due to things like dates being present BUT hopefully what they would output on a given source would be the same)

If you want to understand just how scary a break-in like this is, read Ken Thompson's classic Turing Award Lecture, Reflections on Trusting Trust.

Make them read the Bible!

http://plan9.bell-labs.com/plan9/ http://plan9.bell-labs.com/wiki/plan9/installation_instructions/ there. Else Google is mining for text characters and will display a whole lot of options in return if you just put some in the little box.

http://plan9.bell-labs.com/plan9/ http://plan9.bell-labs.com/wiki/plan9/installation_instructions/ there. Else Google is mining for text characters and will display a whole lot of options in return if you just put some in the little box.

why is this thing running windows? anti virus software, come on guys.. will never get anywhere unless you start out right.

Do you know the source to your compiler? Do you know the source of the compiler used to compile your compiler? Ad infinitum?

How can you reference Ken Thompson's "Reflections on Trusting Trust" (HTML/non-PDF version) without also mentioning David A. Wheeler's "Countering Trusting Trust" (as found via Bruce Schneier's blog)? So to answer your question:

What if you can't even trust your compiler?

Well so long as I have another set of compilers AND at least one is trustworthy then there is process I can follow to build a compiler I can trust. After spotting differences in the resulting binary I would also need to (ah-ha) examine the source code of the used compilers and find out which one is mis-generating the binary and fix it.

At some point I need to be able to understand binary and read the source of the compiler that generated that binary to ensure that someone else is not jacking me.

Actual link: http://cm.bell-labs.com/cm/ms/what/shannonday/paper.html

"An entire complete operating system"? You mean a free re-implementation of UNIX? Get with history, bud.

Ritchie has some notes (apparently for a talk, circa 1972): http://cm.bell-labs.com/who/dmr/notes.html
UNIX was initially ported to the PDP-11 as a development tool, which just chanced to be so nice that everyone who used it to develop apps (intending to run them on bare metal) wound up keeping UNIX.

Since the OP said "outside of development tools", any re-implementations of UNIX are explicitly discounted. OSS is indeed useless.

You can't even be sure when you have the source code.

The point there is that you have to have the code for the whole stack not just an isolated application. For an application to be secure, you have to be able to do a valid code audit. For the code audit to be worth anything it has to be done all the way down to the core: compiler, libraries, utilities and operating system. So you can be sure when you have the source code, but you do have to have all of the source code.

So without even touching on the quality issues with MS, lack of code access rules out all MS products from the system on up to user applications. "Shared" source might be fine for specific, limited, platform-specific development contexts, but is basically the same as "escrow" And "escrow" is just another name for closed source, namely, as Ken Thompson point out, insecure. Ditching MS products won't automagically make your site secure, but it is a necessary first step.

Now there are some short cuts one can take in Ken Thompson's example. However, they all boil down to having the code for the whole system as he points out, not just parts. Even diverse double compiling requires, at the end of the day, a system that has been vetted top to bottom to use as the baseline.

Now the next step is to deal with smaller, more modular units of code. They're not only good design but also easier to manage. Again, that rules out a certain party ...

FWIW it's interesting that the ACM recently pulled the Thompson article. It had been available for over a decade. One wonders how much longer the ACM will be a useful source of technical information.

You can't even be sure when you have the source code.

Tell the folks who want this list that you must trust someone at some point and that will always leave you vulnerable.

Physics has a lengthy history of being funded by military operations. For example, the laser itself stems from research into radar guided bombing systems for the military.

http://www.bell-labs.com/history/laser/

http://plan9.bell-labs.com/magic/man2html/1/yesterday

If you are downloading from a mirror, someone could apply similar methods to insert malicious code in your version of the source. And checking all of the source code is no trivial matter, especially if you are looking for an intentionally obscure bit of code.

Also, you have to trust your compiler, which you *had* to get from someone else. Your compiler may be inserting malicious code.

No, it's probably you. In days of old, C's =- operator was equivalent to its present-day -= operator, as is clearly shown in the example. For conclusive evidence, see Dennis Ritchie's article, The Development of the C Language. See the section headed "More History." It discusses =+, which was a sibling of =- . Ritchie says it was fixed in 1976 (by allowing +=), but I remember compilers also accepting the deprecated =- until 1980 or so.

If you just turn FOSS against itself, it's quite easy to obscure your proprietary code even if you distribute the source.

The basic idea is here: http://cm.bell-labs.com/who/ken/trust.html

If one of your in-house customized versions of gcc knows that "\m" is a stand-in for your amazing proprietary extension to something under the GPL, you don't have to give anything away. The proprietary code is embedded into gcc, and you're not distributing gcc. It's safely tucked away in a different project, where you aren't obligated to do anything. The source for your upgraded GPL thingy only contains an extra "\m" or three, which isn't entirely useful for someone without your in-house version of gcc.

I smell a GPLv4 coming to prevent this...

Oh, that one again? It's 2008 — time to re-tire that M$ talking point. I suppose that Ken Thompson's presentation from 24 years ago is also not an endorsement of Open Source? Re-read A5-0264/2001 and European Commission technology strategy They're quite clear and the 2001 resolution even pre-dates the main start of MS EU-level lobbying efforts.

If M$ wanted to play, it's executives could decide to release product code as open source, but the company hasn't. Further, it can't. M$ products just aren't engineered for security. In fact, M$ code is so bad that it threatens US national security. So, although ditching M$ products won't in and of itself make your site secure, it's a necessary first step.

It's about security and for that you need open source.

Main-memory databases in the early 90s were figured out the issues when all pages can be accessed in constant time. A solid state
disk characteristics is no different from main memory.

See http://www.bell-labs.com/project/dali/ for one of such projects.

Windows is largely written in C++. Explains a lot, doesn't it?

C++ is derived from C. I've never seen any C++ code that wasn't 90% standard C.

So what have you proven? That Bjarne Stroustrup at Bell Labs in 1979 had 10% to add to C? Where are the Wonders of Microsoft in this equation? On that day Microsoft was still working on a version of DOS that might have subdirectories someday. They knew barely enough about compilers to get their stuff to run.

More importantly, what have they added of value since? Come on. They're the most powerful software company in the world. It's been almost thirty years. They must have contributed something persistent to the pool of common knowledge, eh? Or maybe not.

You can't even trust that, unless you wrote the compiler yourself. See Reflections on Trusting Trust by Ken Thompson, where he modified the C compiler to insert backdoor code into the Unix "login" command, and then modified the C compiler to insert the login-modification code into itself when someone was recompiling the C compiler, so even that source code read clean.

Oh really?

The first C compilers were written in assembly. What's GCC written in? C. More interestingly, what's Gnat (GNU Ada) written in? That's right. Ada.

How's that you ask? It's the very bootstrapping process you refer to.

As long as you can compile to machine code, there's no reason you ever need to write it. If you have a new machine, just make a cross-compiler in a high level language. Sure you need to have a native code generator at some level to createe the lowest level code that runs on the new machine, but that native code can be generated from as high a level language as you like once you have a sufficient software stack.

Of course, such bootstrapping has its own problems.

or the C/C++ compiler itself injects code to prevent such attacks (as many research projects are currently attempting to do [llvm.org]).
Or perhaps the C/C++ compiler itself will inject code to allow such attacks.

It's a little harder for the vast majority of people who don't have their own compiler, but want to modify an existing executable file to embed a message. The quick summary is that adding bytes into an executable file causes addresses to change, and these changes have to be propagated throughout the file. The most obvious changes involve things like branch targets: if you stick some additional instructions into the text section -- even if it's a single NOP -- then you have to also adjust the targets of various branch instructions in the code to account for this; less obvious, but just as important, are the changes necessary to the meta-data, e.g., section header table entries in the executable. In order to update addresses, you have to be able to distinguish addresses from things that might look like addresses but aren't, e.g., bitmasks (notice that address updates aren't limited to the code regions of the file: pointers into the code in other sections, e.g., jump tables in the data section, also have to be updated). This is an undecidable problem.

One True Regex

UTF-8 ftw

It is already free/open source, under the Lucent Public License (assuming you can bring yourself to run non-GPL code, I know it's hard for some people here). Plan 9 Port will allow you to run Venti on Linux, but ideally you just download Plan 9 and install it on your file server; you can then use v9fs to access Plan 9's fileservers.
I do my work natively under Plan 9, so I don't have much experience using Venti and Linux.

My data never goes away... I use Venti at work. Unlike Timemachine, it uses an intelligent backup scheme, coalescing blocks so a block of data will only ever be written once. That means that every time you save more mail, your 2GB mail file doesn't get completely replicated on Venti, just the new data.

As I said earlier, you can find impartial experts to review impartial software. There is no such thing, however, as an impartial ballot, since somebody has already used it to vote one way or the other.

"Impartial software?" "Impartial ballot?" That doesn't make sense. The issue is the partiality of people, not of inanimate objects.

If impartial people (or teams of people with balanced biases) can be found to review software, then impartial people (or teams of people) can be found to review ballots.

you have two candidates, and representatives for one side raise objections on a ballot that the other side thinks should count as a vote for them... That's way harder to resolve than the similar dispute over a voting machine.

You need three reviewers for contested ballots. One from Party A, one from Party B, one from a pool of people approved by both parties (unaffiliated voters, or community leaders of unimpeccable honesty).

Regardless, you could have checks from all the interested parties to at least get consensus [on voting machines]

You can also get consensus on methods and rules for counting paper ballots ahead of time.

Multiple recounts typically return an array of unique values.

Only if there's ambiguity in the ballot marking, or errors in counting. The latter can be eliminated by multiple rounds and by improved methodology - if Las Vegas casinos can count all that cash, we can find ways to count unambiguous ballots. The former problem should be very very rare in machine-printed voter receipts, or indeed in any sensible ballot design.

They trust ATMs and Credit Card processing machines...

Which give paper receipts, and whose results I can review and challenge. I've had erroneous or fraudulent charges against ATM cards and credit cards, but I could catch them because the bank sends me statements. I don't get a paper from Baltimore County saying "Here's how we recorded your vote. Call 1-800-SCREWUP if you wish to contest it."

a "back-door that effects all electronic machines by a manufacturer"...is still exactly equivalent to a mechanical voting machine.

Not at all. A mechanical voting machine can't do logic like "if (candidate.party == 'GREEN') then (candidate.votes += 100)". (Not unless your mechanical voting machine was designed by Charles Babbage...)

something like that should be caught in the independent review of the code

Bugs get through reviewed code. Deliberately obfuscated backdoors could too. Then there's the problem of trusting trust. If Ken Thompson says "You can't trust code that you did not totally create yourself...No amount of source-level verification or scrutiny will protect you from using untrusted code," maybe we ought to listen to him, instead of call him a Luddite.

Writing trusted systems is much harder than you seem to understand it to be.

You are taking the traditional luddite position, because you seem to be incapable of understanding how electronic voting could work securely.

My position is pretty much that of the ACM: "voting systems should enable each voter to inspect a physical (e.g., paper) record to verify that his or her vote has been accurately cast, and to serve as an independent check on the result produced and stored by the system." It's also pretty much the position of computer security experts like Avi Rubin and

Actually - and I attribute this to good ol' BK - GCC *could* make the problem go away, by recognizing when it is compiling the kernel, and inserting the code itself.

Just sayin'.

Read this -- http://cm.bell-labs.com/who/ken/trust.html

See also Ken Thompson's post on Reflections on Trusting Trust, where he reprints his article from the Communications of the ACM about the subject.

The actual bug I planted in the compiler would match code in the UNIX "login" command. The replacement code would miscompile the login command so that it would accept either the intended encrypted password or a particular known password. Thus if this code were installed in binary and the binary were used to compile the login command, I could log into that system as any user.

Such blatant code would not go undetected for long. Even the most casual perusal of the source of the C compiler would raise suspicions.

(...)

The final step is represented in Figure 7. This simply adds a second Trojan horse to the one that already exists. The second pattern is aimed at the C compiler. The replacement code is a Stage I self-reproducing program that inserts both Trojan horses into the compiler. This requires a learning phase as in the Stage II example. First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere.

That was Ken Thompson, coinventor of UNIX.

http://cm.bell-labs.com/who/ken/trust.html still holds true.

Plan 10 ... Yeah, cause Plan 9 from SCO would certainly suck much more than the real deal.

This is not true.

Yes, it is.

Plan 9?

Of course, when was the last time that you built your compiler from scratch. I hand-wrote your own. In binary. Without any tools. After all, all of the tools that you use to compile open source were compiled with a compiler that [were compiled with a compiler, etc.] that you didn't inspect. So the original person could have put in code that would do *anything*, including self-propagation. See Thompson's article "Reflections on Trusting Trust": http://cm.bell-labs.com/who/ken/trust.html

Especially since compiling the code yourself is completely sufficient to prevent security flaws. Erm. You were planning to audit it, right? Since everyone knows that's sufficient.

Computer security is hard. Doing it right is really hard.

I'm going to not only use TrueCrypt, I'm going to compile it myself.

That won't help you. You need to read Reflections of Trusting Trust by Ken Thompson: http://cm.bell-labs.com/who/ken/trust.html

The old management bought the product.

Not possible, as the University of California had significant IP in System V (going back to the 70's) and they've never transferred/assigned their rights to any entity other than BSDi. You can read here how AT&T/USL's attempted lawsuit against BSDi/UC over BSD Networking Release 2 made this pretty clear:
http://www.oreilly.com/catalog/opensources/book/kirkmck.html

So, SCO's argument changed mid-trial from "Linux violates UNIX System V IP" to "IBM violated license terms," and even that was shot down by Judge Kimball.

By the way, you can see a copy of UC's license to AT&T over contributed code/IP and documentation here:
http://cm.bell-labs.com/cm/cs/who/dmr/bsdi/bsdisuit.html

Yeah, seriously, why DMR going around inserting himself into music anyway? Can't he just stick to his Plan 9 stuff?

Something like this came up before: http://hardware.slashdot.org/article.pl?sid=07/11/11/2246246

Motherboards are mostly made in various Asian countries now, aren't they? How paranoid is it to imagine the Chinese deciding to infect motherboards with spyware?

Lest you think I've got my tinfoil hat on, check out some thoughts of Ken Thompson (which I found in the discussion from the "Trojan Found In New HDs" link I provided, at least I think that's where I got it from.) http://cm.bell-labs.com/who/ken/trust.html