Slashdot Mirror

Well, DBAN is open source. If you have suspicions, you're welcome to review the source compile your own version with a trusted compiler. If that isn't to your liking, there are commercial tools that do the same thing.

This requires a) proving that the software is correct and b) verifying that the compiled result hasn't been tampered with. For the latter, I'll refer you to http://cm.bell-labs.com/who/ken/trust.html.

As for, "What if a drive is mishandled and doesn't get wiped," well, isn't that a concern with physical destruction too?

Sure, the process can still be subverted, but it's a lot easier to verify that a hard drive has been destroyed (along with inventory checks on all hard drives being removed from a facility) than it is to verify that a hard drive has been properly wiped.

I don't buy this. The earliest court document in USL v. BSDi is dated April 1992. By that time, Linux already had a series of active developers and even the first distributions had been created. In your interview, there is also no mention of the lawsuits. Linus was simply the first one to deliver a free unixoid operating system.

If the encryption should be absolutely safe, there has to be open source software, to be 100% sure that there is no back door. Or is every encryption technology reverse engineered to be able to say that no government idiot can type some cheat and decrypt all the data?

No amount of reverse engineering can prove that software does not have a backdoor. You can never be sure unless you write all of your tools yourself.

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

Then you should read Ken Thompson on putting backdoors in C compilers. Do you trust your build system?

I'm still confused. Is this the kind of book that has at least some equations and algorithms (I get that its not exclusively this) or is it the kind of book that mostly rampages on about Turing's love life and how the crude savages of the era screwed him over? I'm just trying to figure out how soft -n- fluffy it is.

Neither, and therein lies the weakness of this book. This review is spot on. The beginning chapters are all these interesting historical anecdotes that do a pretty good job of contextualizing the disjointed and awkward methods of transmitting and thinking about information in the pre-Shannon era. As a series of lesser-known historical anecdotes, it's quite fascinating to know that Babbage like to crack codes as a hobby and that Shannon and Turing directly influenced each other's work as they had regular lunchtime discussions at Bell labs. That is interesting thread that got me to read the book, it felt like a great set-up to a really interesting and accessible primer to information theory.

But then, once Shannon is introduced, the author seems at a loss to explain what information theory is actually used for other than a vague sentiment that it's "useful everywhere, like in the internets and satellites and stuff". In fact, the narrative seems to fall into the same trap that is described wherein a bunch of non-mathematically inclined "visionaries" from psychologists to linguists and architects all jump on an ill-fated "information theory can explain everything" bandwagon without really understanding what it is that information theory can and can't do, leading to quasi-celebrity status for a (very bewildered) Shannon. This then devolves into an extended discussion of memes from the early work of Dawkins which met a similar fate (the "journal of mimetics" was short-lived due to a complete inability of it's founders to agree on exactly what belonged in it). The treatment of biological information is amazingly scant beyond some re-hashing of Dawkins and Gould, given how fundamental information theory is to the modern field of bioinformatics and the like. It then wraps up with with obligatory creation stories of wikipedia, google and discussions of information glut, the likes of which a slashdot audience would already know by heart and therefore find unenlightening.

The actual information theory examples explained in the book do not go beyond the toy examples from Shannon's paper, which is itself very well written and eminently accessible if you have a little statistics and math background. So if you are looking for that, go straight to the source instead instead of reading this book. If you are looking for some neat historical anecdotes about what people used to do to save money on telegraph messages and dreams that Ada Loveless had about being able to see a new world in her head where algorithm developers would someday rule the world, by all means enjoy the first 5 chapters, but the remainder is quite forgettable I'm afraid.

Link to Shannon's 1948 paper. http://cm.bell-labs.com/cm/ms/what/shannonday/shannon1948.pdf

I was thinking about that book myself - I don't know that I've ever read a better programming book. Not only could the guy invent a language but he could write well enough to explain it in as easy a manner as possible given the subject matter. That's a talented guy right there.

If you (or others) haven't read his essays on the history of C and UNIX, you should. He was a fantastic writer, and he managed to make such "dry" subjects palatable for even non-programmers. Indeed, reading memoirs of his time at Bell Labs during the 1970s takes you there, with him, while he and his colleges developed the core technologies that would create the world we're in today.

There are several other essays written by him, but those two are the ones I've had bookmarked for a very long time and stand out in my mind.

I was thinking about that book myself - I don't know that I've ever read a better programming book. Not only could the guy invent a language but he could write well enough to explain it in as easy a manner as possible given the subject matter. That's a talented guy right there.

If you (or others) haven't read his essays on the history of C and UNIX, you should. He was a fantastic writer, and he managed to make such "dry" subjects palatable for even non-programmers. Indeed, reading memoirs of his time at Bell Labs during the 1970s takes you there, with him, while he and his colleges developed the core technologies that would create the world we're in today.

There are several other essays written by him, but those two are the ones I've had bookmarked for a very long time and stand out in my mind.

It's up and running

The problem earlier was their nameservers.

Subject of several theses:

http://www.tug.org/docs/liang/

http://www.pragma-ade.com/pdftex/thesis.pdf

https://www.tug.org/docs/plass/plass-thesis.pdf

(John Hobby's on METAPOST http://ect.bell-labs.com/who/hobby/thesis.pdf )

Probably others. More information at

http://www.tug.org/

and

http://www.latex-project.org/

and

http://wiki.contextgarden.net/Main_Page

William

We know that the NSA has no back doors in a GNU/Linux platform because we have the source for everything. Do you know that about Windows?

This should be required reading. The relevant bit is this:

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.

The moral is obvious. You can't trust code that you did not totally create yourself.

Don't kid yourself that it's impossible for the NSA or whoever to have a backdoor in your program just because you can look at the source.

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

It is left as a exercise to the reader to see the point I'm trying to make.

I don't think that's any more relevant now than it has been for decades when using proprietary, binary-only development tools from MS and others. Thompson's point was that even having source, which was always assumed on Unix systems, is not sufficient to prevent trojans for being inserted into code.

The description "Compiler-as-a-Service" is misleading. It doesn't mean that people will ship their source to MS and get back object code. It simply means that the compiler exposes an API for introspecting code. Though it may be interesting, it's not a new idea by any stretch of the imagination. I think a far more relevant reference is to Greenspun's tenth rule.

I don't think you even really read the summary...

I don't think you read the (already classic?) Ken Thompson's Reflections on Trusting Trust

"You can't trust code that you did not totally create yourself." - if your binary compiler injects a backdoor in the object code, then even recompiling the compiler from source may not get you out of the woods.

Otherwise, let point to you the (in my opinion) relevant phrases in TFA:

Have you read all the code of your OS? Your compiler? Have your read the code of each compiler that was used in the chain, back to the very first one written in assembly/hex?

If not, then you are really not in much of a better position than you would be using a closed source compiler.

I don't think you even really read the summary...

I don't think you read the (already classic?) Ken Thompson's Reflections on Trusting Trust
"You can't trust code that you did not totally create yourself." - if your binary compiler injects a backdoor in the object code, then even recompiling the compiler from source may not get you out of the woods.

Otherwise, let point to you the (in my opinion) relevant phrases in TFA:

Today's commercial compilers are black boxes, Hejlsberg said.

While Hejlsberg is probably right, fortunately in this world there are such things as non-blackbox-compilers.

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

It is left as a exercise to the reader to see the point I'm trying to make.

Ken Thompson wrote a paper on how to do it http://cm.bell-labs.com/who/ken/trust.html, but did not actually do it ...(As far as we know)

The point about it is that there is no source tree to examine ...

The point about any hack of kernel.org, is that there is no central depository of code there that is the master copy, it uses git, so there are many copies (or partial copies) scattered around many machines, compromising all of them is very unlikely, many are behind much better firewalls, examining the source code for changes made by a hacker is trivial and automatic ...

Here is what it's referring to. CS graduates are expected to recognize instances of it instinctively.

Ah, so the statement was conceptual, not based on a hidden component within these boxes. Gotcha.

Correct me if I'm wrong.

Here is what it's referring to. CS graduates are expected to recognize instances of it instinctively.

You cannot prove that your computer is not a zombie. Consider the classic Reflections on Trusting Trust by Ken Thompson.

this could have been a perfectly typical and rational IT or CS decision, like the many similar decisions we all make every day

Actually the tradeoff may not have been rational.

Actually, the choice was rational (at least, on purpose) - you see, it's not about a single byte, it's about a new data type.

C treats strings as arrays of characters conventionally terminated by a marker. Aside from one special rule about initialization by string literals, the semantics of strings are fully subsumed by more general rules governing all arrays, and as a result the language is simpler to describe and to translate than one incorporating the string as a unique data type. Some costs accrue from its approach: certain string operations are more expensive than in other designs because application code or a library routine must occasionally search for the end of a string, because few built-in operations are available, and because the burden of storage management for strings falls more heavily on the user.

1. with NULL-terminated strings, there's no distinction (other than in the string.h and related library) between a char * and a other_type *. Inventing a "string" type in C (not C++) would have made the compiler more complex (see footnote **)
2. because char * is no different than other_type* , I can pass the address in the middle of the string char * for processing. Not so much for a std::string. How does it matter? Well, take parsing for example (the most trivial strtok) not only that one will need an extra string-len prefix, but you'll need to keep a separate "curr_pos".

If you have a NULL-terminated char* string, one can invent/use a std::string (or GString, or NSString, or Pascal-string). The reverse is not true: having the compiler accepting only Pascal-strings, it's not possible to start using the NULL-terminated convention.

many uses are much easier and faster when we know the length and for others few things beat a null-terminated string.

While in other cases (when you pass a std::string by-value and invoke the copy constructor, which tends to happen a lot), you have a hefty performance penalty.

Footnote ** - Dennis M. Ritchie on the C history.

C treats strings as arrays of characters conventionally terminated by a marker. Aside from one special rule about initialization by string literals, the semantics of strings are fully subsumed by more general rules governing all arrays, and as a result the language is simpler to describe and to translate than one incorporating the string as a unique data type.

Beyond those points:

It is interesting to compare C's approach with that of two nearly contemporaneous languages, Algol 68 and Pascal [Jensen 74]. Arrays in Algol 68 either have fixed bounds, or are `flexible:' considerable mechanism is required both in the language definition, and in compilers, to accommodate flexible arrays (and not all compilers fully implement them.) Original Pascal had only fixed-sized arrays and strings, and this proved confining [Kernighan 81]. Later, this was partially fixed, though the resulting language is not yet universally available.

C treats strings as arrays of characters conventionally terminated by a marker. Aside from one special rule about initialization by string literals, the semantics of strings are fully subsumed by more general rules governing all arrays, and as a result the language is simpler to describe and to translate than one incorporating the string as a unique data type. Some costs accrue from its approach: certain string operations are more expensive than in other designs because application code or a library routine must occasionally search for the end of a string, because few built-in operations are available, and because the burden of storage management for strings falls more heavily on the user. Nevertheless, C's approach to strings works well.

And that's coming from Dennis Ritchie, who was there.

And showing you the compiler wouldn't help; what if they implemented ken's hack?

There is a brand of diapers called "Unix"

Are those for boy or girls? Or just universal?

Apparently : they are unisex.

Unless they use the exact same compiler binary, with the same libraries, the source might not compile to the exact same object code.

And just because you have the compiler's source doesn't mean its binary can be created unless it is compiled with the same compiler the original compiler was compiled with, and so on.

Specifically, Ken Thompson's Reflections on Trusting Trust.

It would also be trivial to create a compiler that produces unique object code each time the same source code is compiled while having the code be functionally equivalent, all the while also hiding this capability from the compiler's source.

Awesome job; now you should use it to bootstrap your own trustable compiler.

Makefiles specify dependencies and recipes quite tidily. A simple implementation of make is provided in the "AWK book" as an example program- http://www.cs.bell-labs.com/cm/cs/awkbook/

. Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object', and it's pretty cool.

It is pointing out the obvious that a file is kind of object, with a certain defined behavior, strong namespaces and associated methods?

Systems like Plan9, where everything literally is a file make the painfully obvious. The only changes would be to make file properties be just more files that appear to live bellow the filename as if it were a directory and get rid of completely foreign namespaces like the network interfaces.

There is some extra syntatic sugar with object systems. The 'object' systems use dot delimited dereferencing for system enforced sub-classing - runtime resolution of the thingy being talked about. The file system's path separators are only meaningful on the filesystem meta-level for object...er...file isolation. Otherwise we are dithering over path separators to namespaces: /path/to/thingy instead of container.subelement.thingy.

Of course, PowerShell has the advantage of an actual design and uniform implementation. Even the traditional Unix utilities produce completely unique output formats that often require regular expressions to pull out meaningful data or at least massage the pipe. This is a possible consequence of unregulated organic growth.

Now, the author of TermKit has a valid point in his article on the sofware's design: not enough file handles are used by traditional Unix utilities. STDOUT and STDERR are both used to produce human-readable and machine-readable output. Instead make STDOUT,STDERR (FD 1 and FD 2) machine-only and FD 3 and 4 be used for human-consumable output. This could be much more flexible. (Of course, like most standards, nobody would have used it in the sake of rolling the next great thing.)

But this highlights that trivially parsable output combined with pure file semantics gives you the benefits pure 'object' environments like Powershell gives to users. So it appears the inconsistency between terminal applications is the real issue, not some mythical object-ness that Powershell proponents claim files don't have. And TermKit's plugins / adapters "fix" that.

After all, what are programing languages but syntactic sugar in our heads, mere mental layers on top of high and low voltages running through some hardware?

You should see it under Plan 9, where literally everything is a file, even things like windows, hardware, network connections, etc.

Port iOS to Plan 9!

I suggest you read about trusting trust. To be certain there isn't anything embedded in an open source program you need to read not only the program's source code, but also the source for the compiler that built it and every version of the compiler that built that compiler. You're probably going to be much better off just going through the disassembled machine code for the program, but in that case it no longer makes a difference if the code is open source or not.

Still, they Google to release the code so that we can verify that the binaries are not compromised through recompilation. That's the only way to validate a platform as base-level secure these days.

Read "Reflections on Trusting Trust"--Ken Thompson (found at http://cm.bell-labs.com/who/ken/trust.html ) to learn how recompiling code does NOT validate security. Then read the earlier Air Force article in the link at the end of Thompson's article. Then consider how BIOS and other firmware, and even CPU microcode patches might contain malicious vulnerabilities. You want certain security? Then don't even think about it, much less record it anywhere. ;)

In UNIX-land, no it isn't.

Sorry, but shipping code beats standards based theory, and pretty much every *nix vendor ships dc with the OS.

Oracle (nee Sun) Solaris, IBM AIX, HP HP/UX, SGI IRIX, Apple MacOS X, SCO Openserver, SuSE Enterprise Linux (dc listed on bc page), FreeBSD, OpenBSD ...

You also appear to missed a few things about the Open Group Base Specifications Issue 7 / IEEE Std 1003.1-2008 standard - it is in essence a floor, not a ceiling - vendors can ship more tools if they care to. Also, the discussion on bc notes that some implementations of bc are built on top of dc, and that is OK, as long as the behavior of bc is correct.

It is worth noting that dc was one of the earliest programs to run in Unix, making it in while Unix was still written in assembly language. If for some reason it was to be not only omitted, but actually excluded by the standard, it would still be found in the vast majority of shipping systems for years to come until said vendor decided to migrate their Unix system to the current standard, a process that often takes years.

So yes, for the vast majority of people using Unix, an RPN calculator is often only as far away as a shell prompt.

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

'nuff said.

Private Pilot flies the SR-71 simulator: http://www.wvi.com/~sr71webmaster/srsim~1.htm

Private Pilots fly the Mig-29 (with a Russian Pilot in the 2nd seat) http://plan9.bell-labs.com/who/ken/mig.html

In the case of Android, there's also the source code itself.

Unless you compiled the code yourself, or are running a binary signed by someone in trust, having some source code that purports to be what you're running is no defense, and the Android vendors are at liberty to add this kind of behavior if it suits them, and they are under no requirement to publish the source of their changes.

Ken actually used his nifty hack of the C compiler and the login program to break into the computer that stored the committee's votes and flipped his and Steve Ballmer's vote.

Linus was born in December 1969.

UNIX was started on the PDP-7 in 1969 (a few months = "long before"?), but the name UNIX wasn't even invented until 1970. UNIX was written in assembler then, since Ritchie only invented B in 1971; the actual port to C (which is where I consider the modern UNIX codebase to originate, though I understand not everyone would agree) was done in 1972/73. The UNIX most of us would recognize

Now there's two possibilities: either you, while (admirably) taking a stand for facts over Linux-is-the-universe fanboism, are engaging in your own spot of contrafactual UNIX-is-the-universe fanboism (in that case, educate yourself).... or you're just an AC troll (in that case, Troll Harder).

"Reflections on trusting trust", by Ken Thompson:

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

Paul B.

it's open-source and therefore, backdoors can't be hidden in the code

You really, really, REALLY need to read this:

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

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

Does it look to you like this GNU code was written by a wise old neckbeard? It's 780 lines of unreadable crap. This is what the code of a wise old neckbeard looks like.

It was a GNU project it was running on HURD not Linux.

Umm.. this wasn't a LINUX issue it was an SQL injection attack on a website. Are just trying to troll or do you really not know the difference?

This is definitely a LINUX issue because GNU utilities(like gcc) are bundled with almost every Linux distro. If someone were able to slip a trojan into gcc or any other GNU util, it's game over for every Linux installation. http://cm.bell-labs.com/who/ken/trust.html#fig6

You're the one who's shortsighted to think that it's isolated to HURD.

Add to that that gcc is hosted. Compromise gcc's source and you get access to everything you ever want. Obligatory Ken Thompson compiler trojan article link http://cm.bell-labs.com/who/ken/trust.html#fig6

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.

FIGURE 7

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.
Moral

The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect.

Erlang with it's CSP-style message passing would seem to fit this chip perfectly, as well as Go for example. Atleast if thread-like constructs of those languages would run across the separate operating system instances on each SCC core.

Distributed Plan 9 system sounds like a good match also. Communication with pipes from core to another should be quite fast and programs can still be built as serial filters. Work on Barrelfish is somewhat interesting too.

"You can write and prove a program that when fed a list of three integers of 32 bits or less will always return the largest. The range is limited so it is provable."

No, you cannot. You can prove that it should do so, but you cannot prove that it will always do so. For example, your assumption is that the interpreter or compiler behaves the way you think it does, when you in fact have operated on numerous unproved assumptions.

I thought it was nonsense for a different reason. From TFA:

Why do we still have to name variables OmegaZero when our computers now know how to render 0x03a9+0x2080 properly?

Ken Thompson's Plan 9 C compilers -- which are the C compilers distributed with Go -- allow Unicode for variable, function, and preprocessor names. If Poul-Henning Kamp, the author if this nonsense, had used any compilers that Rob Pike had a hand in making, or even bothered to read the papers written about them, he'd know this.

It's a shame I can't use UTF in a discussion about UTF. Commander Taco, tear down this ASCII wall.

It's not just Apple. The industry has been slowly honing and marketing DRM-only trusted computing type of boxes and delivery systems for about a decade now.

They're smart. They know that they can't just go from something like Windows XP to a completely locked down box and expect anyone to buy it. The idea is to gradually introduce this in the current generation devices such that at the end anything free (while possible) is a couple generations behind (and pretty sucky by comparison). Critical mass in market penetration is a tidal force.

Progression goes something like this

1) Game Console (cheaper than a computer, but _IS_ a computer ... you just can't run anything not blessed by the manufacturer. But it's OK ... it's only a console)
2) The whole idea of "Apps" for your phone. Different enough not to be a computer -- applications around 1990 shareware quality and cost a couple of dollars each. Useful because of new context.
3) The iPad (a bit above the phone...state of the art device -- but still a tablet, not a computer -- don't you worry)
4) Some sort of "app store" for the desktop that's the path of least resistance. Still, nothing "mandatory" per se on the desktop. [CURRENT ARTICLE]
5) ???
6) "Apps" instead of programs on any device you might care to own. Write free stuff if you want -- you'll only reach the jailbreaker fringe. (See Windows Phone 7 restrictions on free (as in beer) software).
7) Requirement of "Apps" instead of spyware-laden programs (if you can run them at all) by schools, corporations, etc. Very scary trojans. Reports of contaminated compiler chains in the wild (See http://cm.bell-labs.com/who/ken/trust.html ). Couple people have their bank accounts stolen by free software where the source code looks perfectly innocent. The FUD can create itself at this point...
8) PROFIT!!!

(and I mean profit -- why not code up a simple app and let MS/Apple/et al. market it for you in exchange for 50% of the profits -- it's a win-win scenario in the short run).

If you think the FSF will save you, remember that they don't make hardware. State of the art hardware is manufactured by corporations who have every interest in embracing DRM. You don't want free software stuck on the 2020 equivalent of the Arduino 10 years from now.

Any solutions?

What the heck is a beta?

I'm not sure, but remember - values of beta will give rise to dom!.

You're talking about the trusting trust attack, which was made famous by Ken Thompson.

There are lot of figures missing in this article. figure 1( On stage 1), figure 3 and 7 (Stage 3), is there anywhere I could find them, just trying to follow the article

You're talking about the trusting trust attack, which was made famous by Ken Thompson.

Figure 5 is missing as well, geez, I was trying to follow this interesting article.