Slashdot Mirror

Dennis Ritchie, the creator of the C Programming Language, along with Ken Thompson, co-creators of the UNIX Operating System, Brian Kernighan, and many, many others, laid the groundwork for ALL Operating Systems, and technology that followed. Linux, all flavors of UNIX, Android, etc... lead the world in O/S's, NOT Apple.

Steve Jobs would still be a amateur Geek in his garage if it were not for all the Giants of the industry that came before.

Considering that they only died 6 days apart, where is Dennis's stamp?

Dennis's home page: http://cm.bell-labs.com/who/dm...

===
YES YES YES

Dennis Ritchie, the creator of the C Programming Language, along with Ken Thompson, co-creators of the UNIX Operating System, Brian Kernighan, and many, many others, laid the groundwork for ALL Operating Systems, and technology that followed. Linux, all flavors of UNIX, Android, etc... lead the world in O/S's, NOT Apple.

Steve Jobs would still be a amateur Geek in his garage if it were not for all the Giants of the industry that came before.

Considering that they only died 6 days apart, where is Dennis's stamp?

Dennis's home page: http://cm.bell-labs.com/who/dm...

Or if you're looking for a live image to play with...

Typically you just verify that the sourcecode you build from matches the published source through the use of checksums and/or gpg signatures...

And how do you know that *your compiler* can be trusted? http://cm.bell-labs.com/who/ke... (Reflections on Trusting Trust). Any way you slice it, this is a *hard* problem.

> whose founders hail from the NSA

> CEO Raj Shahsays he worked in the Air Force Reserve supporting the NSA

They aren't really the same thing now are they?

Hmm, you've landed upon Slashdot rather roughly. Yep, you've entered English text, so that works, but it's plainly obvious you're not from this planet. Right?
No worries, you're among friends -- takes one to know one, and all that -- better luck next time, though.
Now, if you do want to survive you'll need to read this crasher-course to get acquainted with some basics about UNIX, compilers, and the state of Earther computer security.

Quite a painless tutorial, as acceptance speeches go, eh? Now, in addition to the content of the page which is extremely germane to our topic, I want you to pay close attention to two things about this document:
0. The 'Acknowledgment' section at the bottom.
1. The publication year at the top -- keep that number in mind, if not immediately relevant it will become so soon.

You should be able to clean yourself up with your towel. Not to worry, the feeling will soon pass; Just keep repeating "mostly harmless" and failing that, read The Guide's cover.
Welcome! And remember: You're here forever.

You don't trust your compiler (and compiler vendor)?
http://cm.bell-labs.com/who/ken/trust.html

There are several real Plan9 variants and they are all FOSS (LPL is OSI approved) 9atom: http://9atom.org/ 9front: https://code.google.com/p/plan9front/ 9legacy: http://www.9legacy.org/ and the real bell labs distro: http://plan9.bell-labs.com/plan9/

Agreed. I use coreboot on all my systems. I put my /boot/ on the firmware, and used a saved configuration so there's no searching for IDEs, etc. at boot. I boot to the login in less than a second.

I do a little firmware / OS dev of my own. Coreboot is far superior than "Secure Boot". Here's why: An OS must kick off its own crypto chain to verify executables and maintain the security provided by signed boot loader. Instead of having to go into the BIOS and enter some long hex code that you and your users WILL mess up for UEFI, I just put the crypto stub of my OS in the firmware. The BIOS just needs an option to say:
[x] Allow OS install on next boot. Then the BIOS can load a stub of the OS into firmware.
That's far simpler, and just as secure -- I mean, if the (possibly PW protected) BIOS can be exploited beyond boot-time then Secure Boot isn't secure either. Bonus: You don't have to implement a FAT32 file system and risk getting sued by MS, like you do with UEFI.

Public key crypto means my OS stub in firmware doesn't have to change every time the kernel does. It can just validate the OS image signature. The benefit is that you don't have to pay the Microsoft tax to get the security features of secured boot sectors. Additionally, if your OS boot payload is small enough then you can deliver the whole thing, and use it as a fall-back if the up to date kernel is missing or corrupt. Let me tell you, today's firmware has space enough for a full OS already -- Complete with animated graphics, backgrounds, and sound effects on many systems. If an OS stub in firmware isn't enough then a second stage loader or data file can be loaded from storage and verified (especially useful for between-boot configuration stuff, to select what OS to multi-boot by default, etc. -- If missing, use sane defaults from firmware install).

An OS stub firmware loader far simpler, more flexible, has no vendor lock-in, and is just as secure (or more secure) than UEFI Secure Boot. Unfortunately, Coreboot isn't going to help if the HDD, GPU, etc firmware or chip microcode has been exploited by the Ken Thompson Hack. The answer is to demand the end of government secrecy -- We have no expectation of privacy outdoors, so we don't need wiretap spies -- Without it we still have more than enough spying. A government without secrets is immune to spies.

"roll your own", ah but you didn't, and by suggesting that you did only make Ken Thompson sad.

Just out of curiosity: Given a "black box" implementation of a random number generator, is it possible to test its output sufficiently to gain some faith in its proper randomness?

Yes and No. One can statistically analyze output of the (pseudo) RNG and compare it to pure randomness, like atmospheric noise. However, you can't be sure there is no message in the stream. For example: Strong crypto produces enciphered data that looks exactly like pure randomness. It's one way we test for cryptographic strength. Indeed, BSD will now pipe RNG output through Yarrow (a pRNG based on hash functions) to produce randomness. Considering that knowing the initial state of a PRNG reveals its full exact stream of bits, and that hashes produce the same output for a given input: I'm not satisfied with this result either, unless the input is sufficiently salted with device IO timing and other such quasi-random states as in Linux's /dev/random entropy pool.

Seeing as such a piece of hardware need not (and hopefully would not) have any inputs, only an output, it's hard to imagine how someone might hide (and later trigger) a back-door mechanism that could change its behavior post-testing. (But I'm sure there is some way to do it that I'm not thinking of ;))

Strong crypto needs strong randomness for initialization vectors.

While it's true the Ken Thompson Microcode Hack could exist in silicon (Chips could have full featured back-doors in them) it would be far less obvious and simpler to attack a single point of failure: The (hardware | pseudo) random number generator.

It's possible to build a (pseudo) Random Number Generator that is biased in a way that's not noticeably different from pure atmospheric noise in practice, and even passes all the NIST / Diehard tests for randomness. I built one such high entropy pseudo random number generator using a pool of 517 integers and a mixing system. I had arranged the mixing system such that based on a small sample of randomness (50 or so integers, ~1500 bits) one could deduce a weak signal inherent in the pool which then slowly revealed the entire random number generator state in a cascade effect via an Error correction coding present in the bit-stream.

Looking at the source code for my PRNG one wouldn't realize the thing had a back door in it via the selection of primes, constants, and the XOR, shift, AND, etc. mixing strategy itself. The implementation of error correction code akin to Reed Solomon Codes was hiding in plain sight. I sort of turned the weak signal bits on ear and presented them in the stream in "parallel" instead of "serial". The NIST tests chi-square, etc. against my PRNG proved indistinguishable from true random sources such as atmospheric noise, even with gigabytes of data to analyze thanks to the prime number sequence's weak enciphering of the bias pattern.

To make matters worse, I built the system around constants taken from a run of digits in Pi. When apparently any random values will do as inputs for an equation, a known source of digits like this is meant to put cryptographer's minds at ease in that the values aren't just 'magic numbers', pulled from thin air -- Constant numbers selected with possible nefarious purposes. For examples of such 'un-magic selections', see the initial constant states of nearly any hash function, such as MD5, SHA-1, or SHA-2, etc...

......!

According to RFC1925 - Rule 6(a), it's always possible to add another layer of indirection. So, I put my "careful number selection" to create the backdoor one level higher than the values themselves. I went looking for sources of workable constant values in the supposed accepted places. Of course anyone can supply their own pool sizes and init values to defeat my random attack, but in practice folks will use the default values

I suspect only with Visual Studio.

See Ken Thompson's compiler hack:
http://cm.bell-labs.com/who/ken/trust.html

The pressure from the International markets is only a smidgen of what MS deserves for helping the NSA all theses years starting when they got the pork handouts to port Omnivore away from Unix (Solaris) to MS's systems in 1998, and create Carnivore -- despite everyone else in the military, etc. having POSIX requirements... And despite Linux existing in 1998 if "miniaturization" (PCs) were what they were shooting for. Yeah, MS has been in the thick of this shit for a good while. Snowden's privilege escalation makes a hell of a lot of sense if ECHELON, PRISM, etc are running on Microsoft Windows, eh? If a contractor like Snowden can do it, then state sponsored enemy spies can get at even more.

Oh, MS is going to show the governments the source code so they can be sure that there are no back doors in the compiled code they sell them -- AND UPDATE REMOTELY? Hell, even if they never installed updates and gave them compilers to build the code with they'd be subject to the Ken Thompson Hack. Might as well just write, "Promise there's no backdoors -- Love, Billy and Ballzy" on a post-it note. The code only gives the governments another way to look for exploits.

MS? Openness? What, they'll publish one set of encryption protocols and use a slightly different algorithm? Like when they made their Office document format open?

Screw me once, MS, shame on me. Actively screw me continually for the past two decades? For Shame.

"They who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety and get IE6 instead."
- Benjamin Franklin's Grave Rolling Ghost.

Sure, it's nonsense. Then Stuxnet happened. When "someone" is investing that much effort into injecting malicious binary code into specific industrial equipment, I think anything is possible if there was sufficient motivation behind it. Ordinary people as targets? Obviously not worth the trouble, so for most of us it's something we can joke about and forget. But let's say someone is compiling programs to run some important industrial equipment along similar lines as Stuxnet's target. Maybe they're doing it precisely because they don't trust outside code that they can't audit themselves. In that circumstance I wouldn't put it past nefarious people trying to introduce something via the compiler itself. It is a possibility that people have pointed out for years as a theoretical possibility, even though it's probably a pretty challenging vector.

Checking licensing information is pretty far removed from actually injecting code, but if the process also involves automatically downloading updates, there are possibilities for making it happen (e.g., spoofing the update servers).

Based on the headline, I thought it was going to be about Ken Thompson's self-referencing compiler that not only inserted a back door whenever it saw that it was compiling the UNIX login command, it also inserted the back door insertion code whenever it saw it was compiling the compiler source code.

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

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

That reminds me of a very old hack described in http://cm.bell-labs.com/who/ken/trust.html

I would hope so since that's what he was referring to. What worries me is that it took this long in the comments for someone to reference "Trusting Trust." That should have been the obvious problem from the end of the first sentence of the summary.

??? How old ARE you? (OMG: I'm only 55 -- maybe I really am older and more paranoid than I thought.)

Let me get this straight: you gave away control of your unencrypted files to someone who wasn't a known personal friend and then am surprised that something happened to them??

I treat on-line services slightly differently: I keep local copies of EVERYTHING that goes out, and I'm surprised when it's still accessible online 5 minutes later, never mind 5 years later. And controlling exactly who has access to it? That's just a fantasy -- really. It's actually binary: either it's out there and they MIGHT have it, or it's not and they DON'T.

I do run Dropbox and use KeePass as a password manager. The credential store is encrypted, but even then the stored password there just isn't "quite right". Phone camera pics get uploaded to Dropbox. At times I'll AES encrypt and email or use Dropbox and expose. For stupid pics I'll just dump 'em out there straight. But I know what's exposed and encrypted-exposed. The latter die soon after they're used.

You store important and critical (tax receipts, lawyer-enforced) notices that might cause breach of contract? And you put control of that in someone else's hands, paid for or not? What kind of an IDIOT are you? Then again, you must not think much of the breaching penalties. That's great, I'm glad you're so confident at everyone always doing the right thing everywhere and nothing bad ever happening.

Me, if I'm going to have a some contract or data leakage it'll be because *I* did it myself and have no one else to blame. Then again, it's obvious digital computer files and paid services will stay around forever: Just ask MegaUpload, GeoCities, and LavaBit. Oh, and the data center located in the Twin Towers? Onsite backups sure came in handy there. Some got thru better than others: One, Two

Then again, there's this brand new data center that will hold all of your data for years -- all for free! I'm sure you can retrieve all of your data from that.

Really, I'm glad things are going so well for you, with the exception of a few bumps. And local storage doesn't solve everything either -- drives can be stolen, warrants can be served, computers can be hacked and data downloaded. But damn it, for 99.9% of my data, I'm 100% directly responsible for it. Offloading everything to the cloud is just offloading responsibility, never mind anything at all to do with the NSA.

Oh, one last thing. Even if all of the employees in the ISP, supporting companies, 3rd party vendors and everyone involved are all above reproach. are you sure? And even say all of the software is 100% vetted and accurate (ignoring accidental software bugs): oops.

Paranoid? Probably, but then again most things don't deserve multiple layers of defense. Only a few do, and of those only a select few get vetted, encrypted, backed up, and rotated offsite. But as for "What would you need if everything was suddenly gone (house fire) and you could only keep a couple of things?" Well there's your answer.

Good luck with it all; hope you produce a updated

That was Ken Thompson, co-developer of Unix, in "Reflections on trusting trust".

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

First, you need to read this, then consider a compiler with a payload that knows when it is compiling itself and doesn't insert the backdoor when doing so.

They said "no" to their operating system project, part of which was purchasing a computer.

... I am quite sure that at that time operating systems were not, for our management, an attractive area in which to support work. They were in the process of extricating themselves not only from an operating system development effort that had failed, but from running the local Computation Center. --- Dennis M. Ritchie

This paper should clear up some confusion.

Space Travel, though it made a very attractive game, served mainly as an introduction to the clumsy technology of preparing programs for the PDP-7. Soon Thompson began implementing the paper file system (perhaps `chalk file system' would be more accurate) that had been designed earlier. A file system without a way to exercise it is a sterile proposition, so he proceeded to flesh it out with the other requirements for a working operating system, in particular the notion of processes. Then came a small set of user-level utilities: the means to copy, print, delete, and edit files, and of course a simple command interpreter (shell). Up to this time all the programs were written using GECOS and files were transferred to the PDP-7 on paper tape; but once an assembler was completed the system was able to support itself. Although it was not until well into 1970 that Brian Kernighan suggested the name `Unix,' in a somewhat treacherous pun on `Multics,' the operating system we know today was born.

...this came after descriptions of how the original authors tried to get permission from Bell Labs to construct this thing. Instead, they built it on discarded hardware. This origin was not exactly company sanctioned.

"It's worth remembering that Unix got its start as more or less as a fun project - there wasn't a plan to conquer the world."

I'm not sure if you actually believe that or it is more trolling. In case you really believe it, feel free to stand corrected

Unix was a very serious project funded by a monopoly (at the time) called AT&T - specifically AT&T's Bell Labs, and the C language was literally invented by Kerhnigan and Ritchie just so they could develop it. The goal was certainly not to have fun.

You didn't get much right in your reply, in fact much of it is backwards. Allow me to correct you. They originally requested a computer to write an operating system, but that was denied. They then bootlegged a computer, wrote a game, and hacked on an operating system without it being an official project, and eventually got buy-in to buy a computer to build a text processing system, not an operating system. Unix was already in existence by the time they were allowed to purchase a computer for the text processing system. (I will also note that as a monopoly they were under very tight restrictions about what they could do with Unix in terms of sales.) From the above paper:

Throughout 1969 we (mainly Ossanna, Thompson, Ritchie) lobbied intensively for the purchase of a medium-scale machine for which we promised to write an operating system; the machines we suggested were the DEC PDP-10 and the SDS (later Xerox) Sigma 7. The effort was frustrating, because our proposals were never clearly and finally turned down, but yet were certainly never accepted. Several times it seemed we were very near success. The final blow to this effort came when we presented an exquisitely complicated proposal, designed to minimize financial outlay, that involved some outright purchase, some third-party lease, and a plan to turn in a DEC KA-10 processor on the soon-to-be-announced and more capable KI-10. The proposal was rejected, and rumor soon had it that W. O. Baker (then vice-president of Research) had reacted to it with the comment `Bell Laboratories just doesn't do business this way!' ....

Also during 1969, Thompson developed the game of `Space Travel.' First written on Multics, then transliterated into Fortran for GECOS (the operating system for the GE, later Honeywell, 635), it was nothing less than a simulation of the movement of the major bodies of the Solar System, with the player guiding a ship here and there, observing the scenery, and attempting to land on the various planets and moons. The GECOS version was unsatisfactory in two important respects: first, the display of the state of the game was jerky and hard to control because one had to type commands at it, and second, a game cost about $75 for CPU time on the big computer. It did not take long, therefore, for Thompson to find a little-used PDP-7 computer with an excellent display processor; the whole system was used as a Graphic-II terminal. He and I rewrote Space Travel to run on this machine. The undertaking was more ambitious than it might seem; because we disdained all existing software, we had to write a floating-point arithmetic package, the pointwise specification of the graphic characters for the display, and a debugging subsystem that continuously displayed the contents of typed-in locations in a corner of the screen. All this was written in assembly language for a cross-assembler that ran under GECOS and produced paper tapes to be carried to the PDP-7. ...

Space Travel, though it made a very attractive game, served mainly as an introduction to the clumsy technology of preparing programs for the PDP-7. Soon Thompson began implementing the paper file system (perhaps `chalk file system' would be more accurate) that had been designed earlier. A file system without a way to e

"It's worth remembering that Unix got its start as more or less as a fun project - there wasn't a plan to conquer the world."

I'm not sure if you actually believe that or it is more trolling. In case you really believe it, feel free to stand corrected. Unix was a very serious project funded by a monopoly (at the time) called AT&T - specifically AT&T's Bell Labs, and the C language was literally invented by Kerhnigan and Ritchie just so they could develop it. The goal was certainly not to have fun. You don't write a proposal and ask a company like AT&T to spend millions to have fun.

Furthermore, 30 years ago was 1983, meaning that Unix had been around for about 13 years already, and had already forked into BSD Unix and AT&T System V. It was already quite huge by that time.

Seems we need reminding of this classic by Ken Thompson... there are no changes in the distributed source code of either project

Someone would have found it with a debugger. Sure, they could change the compiler to insert code into a debugger to hide the patch. But this rapidly gets so complex and error-prone that the bloat would be noticed and it would fail to spot all debuggers and patch them all. It's an interesting theoretical attack, but not practical in the long run.

Seems we need reminding of this classic by Ken Thompson.

Slip a backdoor into a RHEL 6.x (or any other major Linux distribution) version of GCC and make it do two major things:
1. Slip a backdoor into any Linux kernel it compiles.
2. Replicate itself in any version of GCC it compiles.

Choose some entry point which changes very rarely so the chances of incompatibility with new code is small.

This would probably keep RHEL with any kernel version tainted for generations of releases without very little chance of being spotted, because there are no changes in the distributed source code of either project

Or bugs in the random number generator.

Seems we need reminding of this classic by Ken Thompson.

Slip a backdoor into a RHEL 6.x (or any other major Linux distribution) version of GCC and make it do two major things:
1. Slip a backdoor into any Linux kernel it compiles.
2. Replicate itself in any version of GCC it compiles.

Choose some entry point which changes very rarely so the chances of incompatibility with new code is small.

This would probably keep RHEL with any kernel version tainted for generations of releases without very little chance of being spotted, because there are no changes in the distributed source code of either project

Reflections on Trusting Trust

'linus' is an alias for 'root' on all systems running the kernel since Windo...err, Linux 3.11.
Password for said alias is 'root' (some of the backdoor-accessing programs don't accept blank passwords).

Never know, since it's not possible to look for such backdoors, unless it's open source.

And even IF it was, you'd have to worry about Trusting Trust.

(mostly sarcasm.)

Tell me, what hardware will you test the chips via?

You are now aware that the infamous Ken Thompson Compiler / Microcode Hack was well known to the government before he pontificated on it during his ACM acceptance speech / paper.

Acknowledgment
I first read of the possibility of such a Trojan horse in an Air Force critique (4) of the security of an early implementation of Multics.

Which was published in the very apt. year of 1984, I might add...

Tell me, indeed, how exactly would you select the chips that did not already have such modification for comparison? Oh it should take more time indeed, but far much more than you realize. Get out your Oscilloscope and Soldering Iron, you're going to be creating a reference implementation on a bread board the size of Texas.

Ken Thompson's article "Reflections on Trusting Trust" seems to apply here.
http://cm.bell-labs.com/who/ken/trust.html

Even if the numbers are corrected, we have no guarantee that a lower-level system isn't undoing that work. Backdoors can (and probably do) exist in not only compilers, but in hardware. If this is the case, then broken encryption parameters are far less important. For example, git uses SHA1 for encryption. Assuming the scheme isn't already broken, it is likely possible to generate a collision with brute-force (especially if you need only one number). If some link in the git chain were thus broken, a replacement file with a backdoor payload could be injected (eg. in the confusion surrounding the gnu.org repos being hacked). As ken points out, once that initial injection is made (assuming it is of sufficent quality) it can be used to add anything to future compiled versions.

This must be the reason my checking account never balances.....

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

quoting Ken Thompson
  I would like to criticize the press in its handling of the "hackers," the 414 gang
 

God I guess...
   

The 414s gained notoriety in the early 1980s as a group of friends and computer hackers who broke into dozens of high-profile computer systems, including ones at Los Alamos National Laboratory, Sloan-Kettering Cancer Center, and Security Pacific Bank.

They were eventually identified as six teenagers, taking their name after the area code of their hometown of Milwaukee, Wisconsin. Ranging in age from 16 to 22, they met as members of a local Explorer Scout troop. The 414s were investigated and identified by the FBI in 1983. There was widespread media coverage of them at the time, and 17-year-old Neal Patrick, a student at Rufus King High School, emerged as spokesman and "instant celebrity" during the brief frenzy of interest, which included Patrick appearing on the September 5, 1983 cover of Newsweek.
 

September 5, 1983 cover of Newsweek
  http://mimg.ugo.com/201102/0/6/5/175560/cuts/4c6de9daa1c16-23680n_480x480.jpg

Text from http://en.wikipedia.org/wiki/The_414s

Moral

The moral is obvious. You can't trust code that you did not totally create yourself..... A well installed microcode bug will be almost impossible to detect.

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

You and the submitter in on this one? As the answer is a resounding NO.

A well installed microcode bug will be almost impossible to detect.

For people like me that didn't know, microcode can also be known as firmware, bios update
or "code in a device" http://en.wikipedia.org/wiki/Microcode

Ken Thompson's Acknowledgment

I first read of the possibility of such a Trojan horse in an Air Force critique (4) of the security of an early implementation of Multics.

(4.) Karger, P.A., and Schell, R.R. Multics Security Evaluation: Vulnerability Analysis. ESD-TR-74-193, Vol II, June 1974, p 52.

So in theory you can't even trust the code you write as your video card could change it.

--
If you aren't paranoid yet, just wait

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. A well installed microcode bug will be almost impossible to detect.

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

But I prefer that my encryption tool and my cloud storage service be completely separate. (How do I know Lockbox isn't sending the keys to the NSA, or whoever?)

It's pointless anyway against the NSA. Seriously. Every single modern operating system (including on routers) has tons of unpatched exploit vectors. There's even a black market for them. The NSA can just infect your machines and ex-filtrate your data and/or the encryption keys... See the previous story:

[NSA] Budget documents say the $652 million project has placed 'covert implants,' sophisticated malware transmitted from far away, in computers, routers and firewalls on tens of thousands of machines every year, with plans to expand those numbers into the millions.

Hell we have multiple celebrations of insecurity every year called "computer security conferences" where without fail new systems are compromised. How can you even look at stuff like Pwn 2 Own, and not have your brain melting in cognitive dissonance as you try to believe there are network attached scenarios where your data is safe from the NSA?

You want your data kept secret? Use whole drive encryption on machines that are never connected to any networks -- And even then there's the Ken Thompson Microcode Hack, so your systems could be theoretically pre-hacked from the factory... I won't buy a CPU that has remote cellular capabilities... Like Intel's Sandy Bridge. Laughed my ass off when I heard about that! "Security Feature" indeed. At least if the machine can't get on the networks there's a much lower chance of your data escaping if it's pre-hacked.

I don't know of any hacker worth their salt -- black, gray or white hat -- that doesn't have a directory of unpatched zero day exploits.
I keep mine in: ~/with/great/power/comes/great/responsibility/
Me having to navigate the directory structure has saved many a newb... The NSA has no such sensibilities.
If the data's encrypted, they assume it could be from a foreigner, and thus give themselves license to get at it, and they can.
This is what happens when you let Threat Narrative run amok.

Yes I do find it easier because my mouse is always in easy reach of my right hand and the few milliseconds you save is probably blown by the 4 or 5 seconds to remember which of the bazillion combos you need for a particular task. It has been tested and documented that keyboard commanders are actually SLOWER than mouse users in pretty much any environment where a mouse is usable at all, a primitive CLI like DOS or Bash is the ONLY place where a keyboard commander gains ANY advantage and frankly if your PC is so shit that the only way it will run worth a piss is to not have any shells at all? Frankly you have bigger problems than remembering keyboard shortcuts as an 8 year old dumpster dived PC has more than enough power to run a modern shell.

If remembering a few keyboard shortcuts, even though the figures show you are being slowed down makes you happy? Then please use them, I'm all for personal choice. Where I have to throw the "bullshit on the field" flag is when keyboard commanders act like they are somehow faster or better because they know some arcane rarely used throwback to DOS when in reality the data shows all they are doing is slowing themselves down. Anybody who thinks about it for even a second will see why, we humans are VERY eye hand dominant and can pop GUI icons without even actual thought required whereas the simple act of recalling a keyboard shortcut adds seconds that simply aren't required to just pop an icon with a mouse.

Through I don't condone OP, down the rabbit hole we go: http://cm.bell-labs.com/who/ken/trust.html

That's Golang's Ken Thompson in case you were wondering...

As long as you trust the compiler and all of the code that went through it.

if I wanted to put a backdoor or vulnerability that could knock a plane out of the sky, how would I do it?

You don't put the backdoor in your code. Too many people would check that. Instead, you put it in the toolchain: you hack the compiler to insert the backdoor when it detects a certain innocuous pattern in the source code. Likewise, if you want to put a backdoor in an IC, you hack the Verilog/VHDL compiler to insert it.

The definitive description of this technique is Ken Thompson's talk, Reflections on Trusting Trust.

do they have access to the source code for the entire toolchain?

For the benefit of those who don't know why this is important, this is a good explanation.

Computing in the UK really had a head start on the US in many ways, but in usual form it was underfunded and lacked vision;

There was a considerable amount of important computer work done in the UK in the early years. For example, when considering Manchester's contributions one shouldn't overlook the pioneering work done with Atlas. But there is far more than that. In some cases you can trace the path of key developments we rely upon today, or that that probably most people have at least heard of, to things developed in Britain through some familiar names.

A notable example is the computer language, "BCPL", developed by Dr. Martin Richards at Cambridge in 1966. Dennis Ritchie ported BCPL to Multics. Ken Thompson and Dennis Ritchie used BCPL on Multics and from it derived the language "B". Some early Unix utilities were written in the BCPL derivative B. After additional rework of B, it became C, the heart of the Unix system. And of course C has led to the widely used derivatives C++ and Objective C.

BCPL was also used by Dr. Richards to develop the portable Tripos operating system, which was used on a variety of minicomputers. As microprocessors become ever more powerful and started forming the basis for powerful personal comptuers, Tripos was eventually selected to became the heart of the Amiga's AmigaDOS operating system.

BCPL has been available on many systems with familiar names, including (reportedly) the Raspberry Pi.

Classic BCPL

To anyone interested in the whys and wherefores of C, a passing acquaintance with BCPL is worthwhile. Viewed forwards through BCPL, rather than backwards through Java and C++, many C constructs, and idiomatic C ways of doing things, just make a lot more sense.

Beyond its historical importance, BCPL had intrinsic merits. In retrospect, what particularly impresses, is the elegant simplicity of its compiler. This is well documented in the book BCPL: the language and its compiler by Martin Richards and Colin Whitby-Stevens (Cambridge: Cambridge University Press, 1979). -- more

BCPL: A tool for compiler writing and system programming
THE PROGRAMMING LANGUAGE B
The Development of the C Language

Computing in the UK really had a head start on the US in many ways, but in usual form it was underfunded and lacked vision;

There was a considerable amount of important computer work done in the UK in the early years. For example, when considering Manchester's contributions one shouldn't overlook the pioneering work done with Atlas. But there is far more than that. In some cases you can trace the path of key developments we rely upon today, or that that probably most people have at least heard of, to things developed in Britain through some familiar names.

A notable example is the computer language, "BCPL", developed by Dr. Martin Richards at Cambridge in 1966. Dennis Ritchie ported BCPL to Multics. Ken Thompson and Dennis Ritchie used BCPL on Multics and from it derived the language "B". Some early Unix utilities were written in the BCPL derivative B. After additional rework of B, it became C, the heart of the Unix system. And of course C has led to the widely used derivatives C++ and Objective C.

BCPL was also used by Dr. Richards to develop the portable Tripos operating system, which was used on a variety of minicomputers. As microprocessors become ever more powerful and started forming the basis for powerful personal comptuers, Tripos was eventually selected to became the heart of the Amiga's AmigaDOS operating system.

BCPL has been available on many systems with familiar names, including (reportedly) the Raspberry Pi.

Classic BCPL

To anyone interested in the whys and wherefores of C, a passing acquaintance with BCPL is worthwhile. Viewed forwards through BCPL, rather than backwards through Java and C++, many C constructs, and idiomatic C ways of doing things, just make a lot more sense.

Beyond its historical importance, BCPL had intrinsic merits. In retrospect, what particularly impresses, is the elegant simplicity of its compiler. This is well documented in the book BCPL: the language and its compiler by Martin Richards and Colin Whitby-Stevens (Cambridge: Cambridge University Press, 1979). -- more

BCPL: A tool for compiler writing and system programming
THE PROGRAMMING LANGUAGE B
The Development of the C Language

Recompiling is not enough because you can't trust the compiler either, unless you write your own bootstrapping compiler to compile the compiler.

I can only recommend you to read this: http://cm.bell-labs.com/who/ken/trust.html

But unless and until he reads AND UNDERSTANDS every line of the source he is
always going to have to be trusting somebody somewhere.

Even if he reads and undertands every line of the source, he's still trusting someone. He has to read and understand every line of the source code of the complier he is using, and the compiler that compiled that compiler, and so on.

Reflections on trusting trust is almost 30 years old now. It should be well known.

However, thinking about this logically most places you can get the source code and executable from the same place... and if the executable matches... how paranoid can you be?

How paranoid do you want to be? Reflections on Trusting Trust - Ken Thompson

Today, in day to day practice, you are on "reasonably safe grounds" if you get the executable from either the authoritative source, or an associated mirror, and it matches the published cryptographic checksum/hash value. (md5, SHA, etc.) Of course if you can build from source, after checking the checksum of the source archive, and of any libraries you need to add, you should be in good shape as well. (And it isn't necessarily a bad thing to plan ahead and grab a copy, and then wait a little bit for either source or patches. Sometimes a patch turns out to break things. Rarely you will find out there was an intrusion last week at the site you grabbed your software from. Not being on the bleeding edge sometimes give you added buffer.) And I would avoid building and testing on production systems - use separate build & test systems, even if they are Virtual Machines like VMware or VirtualBox.

It is a good practice to make use of checksums to check the validity of important files being copied or archived as well since sometimes the process can go badly for various reasons.

Your point about Windows source from Nigeria is spot on. Dealing in stolen code, more generally, is seldom an aid to doing anything legal, and may cause enormous problems.

Who compiles the compiler?

I guess it's time to introduce another generation to the devious genius of Ken Thompson.

You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.)

OK, stupid.

Well, it was your idea.

Anyway, sometimes the binaries and the sources are downloaded together. This happens a lot in single-tarball releases, for instance.

But yeah, more often, if you don't want the binaries, you can certainly avoid downloading them, or unpackaging them and running them if you did download them.

Source-only tarballs, for instance, or just source packages.

Of course, you still have to run the binaries of your operating system. And your toolchain.

But no one would ever corrupt those.

That's not guaranteed to address the problem. http://cm.bell-labs.com/who/ken/trust.html To compile the source code you used the binary compiler...