Slashdot Mirror

And since you didn't write your own compiler, it's pointless.

The diverse double-compiling construction described by David A. Wheeler reduces the probability of a meaningfully compromised compiler to a negligible level, so long as at least three independent compilers for the language exist and one of them is free software.

Contract clauses that forbid benchmark publication (unless the vendor likes them) are called DeWitt clauses. The clause was originally created to squelch database research being performed by Dr. David DeWitt. These should be illegal, but Oracle certainly rigorously enforces them. There was a law passed in 2016 that prevented similar problems for Yelp, but DeWitt clauses haven't been struck down yet (and should be). See my post, "The DeWitt clause’s censorship should be illegal" by David A. Wheeler (2017-06-25): https://www.dwheeler.com/essay...

One _single_ act doesn't magically negate the 20 years of why Microshaft sucks.

Have they disabled telemetry in Windows 10 yet? Why was ON in the _first_ place??

Can I buy an license for Windows 7? Forced upgrades are bullshit.

Can Explorer show me folder sizes yet? This isn't fucking rocket science, just basic computer science.

There are numerous technical reasons why Windows is still crap.

Microshit's "innovation" is total joke.

It will show the data that Microsoft wants you to know that it is taking. Unless this tool is open source you would be unwise to assume that it was showing you everything; even then: does the operating system keep (or make visible) all the files that it sends ?

Open sourcing the tool wouldn't help you as long as the operating system underneath can be doing absolutely anything with your data without you knowing. If Windows lies to the tool about the data it's forwarding there's no way you could ever tell. You would need to open source the entire operating system and then make sure you compiled it safely from that source.

It' not proof assuming such a link exists (which you did not provide) since it is a video. Show me the link to the source and the docs that let me reproduce it. Until then all we have is proof that you don't understand the scientific process.

The link was provided way up in the thread, on a comment that you responded to.
So you don't miss it again, I'll place it inline here.

David Wheeler's Diverse Double-Compiling
https://www.dwheeler.com/trusting-trust/

A link to a page that explains the video is on that main page. But again, so you don't miss it, I'll place it inline here.

PhD Public Defense of Fully Countering Trusting Trust through Diverse Double-Compiling
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-video.html

You can download the video in webm format:
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-ddc-presentation.webm

Or you can download the video in mp4 format:
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-ddc-presentation.mp4

The links to the pages with the source and the docs that let you reproduce it are also on the main page.
But yet again, so you don't miss them, I'll place them inline here.

Tiny C Compiler (tcc or TinyCC) related files
https://www.dwheeler.com/trusting-trust/tcc.html
(See Section Detailed data for duplicating the ACSAC experiment)

David A. Wheeler’s Page on "Fully Countering Trusting Trust through Diverse Double-Compiling" (Trojan Horse attacks on Compilers) Dissertation
https://www.dwheeler.com/trusting-trust/dissertation/
(See Section Key Materials)

It' not proof assuming such a link exists (which you did not provide) since it is a video. Show me the link to the source and the docs that let me reproduce it. Until then all we have is proof that you don't understand the scientific process.

The link was provided way up in the thread, on a comment that you responded to.
So you don't miss it again, I'll place it inline here.

David Wheeler's Diverse Double-Compiling
https://www.dwheeler.com/trusting-trust/

A link to a page that explains the video is on that main page. But again, so you don't miss it, I'll place it inline here.

PhD Public Defense of Fully Countering Trusting Trust through Diverse Double-Compiling
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-video.html

You can download the video in webm format:
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-ddc-presentation.webm

Or you can download the video in mp4 format:
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-ddc-presentation.mp4

The links to the pages with the source and the docs that let you reproduce it are also on the main page.
But yet again, so you don't miss them, I'll place them inline here.

Tiny C Compiler (tcc or TinyCC) related files
https://www.dwheeler.com/trusting-trust/tcc.html
(See Section Detailed data for duplicating the ACSAC experiment)

David A. Wheeler’s Page on "Fully Countering Trusting Trust through Diverse Double-Compiling" (Trojan Horse attacks on Compilers) Dissertation
https://www.dwheeler.com/trusting-trust/dissertation/
(See Section Key Materials)

It' not proof assuming such a link exists (which you did not provide) since it is a video. Show me the link to the source and the docs that let me reproduce it. Until then all we have is proof that you don't understand the scientific process.

The link was provided way up in the thread, on a comment that you responded to.
So you don't miss it again, I'll place it inline here.

David Wheeler's Diverse Double-Compiling
https://www.dwheeler.com/trusting-trust/

A link to a page that explains the video is on that main page. But again, so you don't miss it, I'll place it inline here.

PhD Public Defense of Fully Countering Trusting Trust through Diverse Double-Compiling
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-video.html

You can download the video in webm format:
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-ddc-presentation.webm

Or you can download the video in mp4 format:
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-ddc-presentation.mp4

The links to the pages with the source and the docs that let you reproduce it are also on the main page.
But yet again, so you don't miss them, I'll place them inline here.

Tiny C Compiler (tcc or TinyCC) related files
https://www.dwheeler.com/trusting-trust/tcc.html
(See Section Detailed data for duplicating the ACSAC experiment)

David A. Wheeler’s Page on "Fully Countering Trusting Trust through Diverse Double-Compiling" (Trojan Horse attacks on Compilers) Dissertation
https://www.dwheeler.com/trusting-trust/dissertation/
(See Section Key Materials)

It' not proof assuming such a link exists (which you did not provide) since it is a video. Show me the link to the source and the docs that let me reproduce it. Until then all we have is proof that you don't understand the scientific process.

The link was provided way up in the thread, on a comment that you responded to.
So you don't miss it again, I'll place it inline here.

David Wheeler's Diverse Double-Compiling
https://www.dwheeler.com/trusting-trust/

A link to a page that explains the video is on that main page. But again, so you don't miss it, I'll place it inline here.

PhD Public Defense of Fully Countering Trusting Trust through Diverse Double-Compiling
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-video.html

You can download the video in webm format:
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-ddc-presentation.webm

Or you can download the video in mp4 format:
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-ddc-presentation.mp4

The links to the pages with the source and the docs that let you reproduce it are also on the main page.
But yet again, so you don't miss them, I'll place them inline here.

Tiny C Compiler (tcc or TinyCC) related files
https://www.dwheeler.com/trusting-trust/tcc.html
(See Section Detailed data for duplicating the ACSAC experiment)

David A. Wheeler’s Page on "Fully Countering Trusting Trust through Diverse Double-Compiling" (Trojan Horse attacks on Compilers) Dissertation
https://www.dwheeler.com/trusting-trust/dissertation/
(See Section Key Materials)

It' not proof assuming such a link exists (which you did not provide) since it is a video. Show me the link to the source and the docs that let me reproduce it. Until then all we have is proof that you don't understand the scientific process.

The link was provided way up in the thread, on a comment that you responded to.
So you don't miss it again, I'll place it inline here.

David Wheeler's Diverse Double-Compiling
https://www.dwheeler.com/trusting-trust/

A link to a page that explains the video is on that main page. But again, so you don't miss it, I'll place it inline here.

PhD Public Defense of Fully Countering Trusting Trust through Diverse Double-Compiling
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-video.html

You can download the video in webm format:
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-ddc-presentation.webm

Or you can download the video in mp4 format:
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-ddc-presentation.mp4

The links to the pages with the source and the docs that let you reproduce it are also on the main page.
But yet again, so you don't miss them, I'll place them inline here.

Tiny C Compiler (tcc or TinyCC) related files
https://www.dwheeler.com/trusting-trust/tcc.html
(See Section Detailed data for duplicating the ACSAC experiment)

David A. Wheeler’s Page on "Fully Countering Trusting Trust through Diverse Double-Compiling" (Trojan Horse attacks on Compilers) Dissertation
https://www.dwheeler.com/trusting-trust/dissertation/
(See Section Key Materials)

It' not proof assuming such a link exists (which you did not provide) since it is a video. Show me the link to the source and the docs that let me reproduce it. Until then all we have is proof that you don't understand the scientific process.

The link was provided way up in the thread, on a comment that you responded to.
So you don't miss it again, I'll place it inline here.

David Wheeler's Diverse Double-Compiling
https://www.dwheeler.com/trusting-trust/

A link to a page that explains the video is on that main page. But again, so you don't miss it, I'll place it inline here.

PhD Public Defense of Fully Countering Trusting Trust through Diverse Double-Compiling
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-video.html

You can download the video in webm format:
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-ddc-presentation.webm

Or you can download the video in mp4 format:
https://www.dwheeler.com/trusting-trust/dissertation/wheeler-trusting-trust-ddc-presentation.mp4

The links to the pages with the source and the docs that let you reproduce it are also on the main page.
But yet again, so you don't miss them, I'll place them inline here.

Tiny C Compiler (tcc or TinyCC) related files
https://www.dwheeler.com/trusting-trust/tcc.html
(See Section Detailed data for duplicating the ACSAC experiment)

David A. Wheeler’s Page on "Fully Countering Trusting Trust through Diverse Double-Compiling" (Trojan Horse attacks on Compilers) Dissertation
https://www.dwheeler.com/trusting-trust/dissertation/
(See Section Key Materials)

Didn't you pay attention? It's on F-Droid. Unless Putin has somehow "On Trusting Trust"-ed F-Droid's compiler, you can calm down.

Even if they did use Ken Thompson's Trusting Trust Attack, there is David Wheeler's Diverse Double-Compiling that can fully counter it.

Even if you can cross-compile, you can't ensure that the cross-compiler binary is free of Ken Thompson's self-propagating "trusting trust" attack unless you bootstrapped it from an independently developed compiler.

Don't be fooled by offers to make source code available for closed-source products. If they don't deliver the product EVERY TIME with source, that you then compile and use -- instead of the other binary they provide -- it is fairly useless.

Updated code is/was a popular way to get malware into Google's Play Store for Android. The benign app was vetted by Google, allowing it in. Once installed, it phoned home and installed "updates" that change the function to something more malicious.

Properly executed MITMs are very effective. It's why we still use deep water submarines to splice into telecommunication cables. :-)

P.S. - Before anyone responds with Ken Thompson's 1984 talk "Reflections on Trusting Trust", please read Wheeler's paper on countering this threat and Double Diverse Compiling.

> And no, you cannot verify this by inspecting the compiler source

But you can detect something's fishy by diverse double compilation Find a compiler unlikely to have the same trojan behavior as your "regular" compiler, and compile your regular sources with each one. If it's all good, you now have two functionally equivalent binaries of your regular compiler, which are different binaries (because you used different compilers to build them). Recompile your regular sources with these two functionally identical differing binaries, and you should get identical binaries of your regular compiler. If they're identical, your regular compiler was clean. If not, you have problems...

Depending on the development environment in question, for added fun, you could still have problems even if you compile it yourself. On the bright side, things like diverse double compiling might be helpful in this area. -PCP

Denial is not just a river in Egypt.

* List of mergers and acquisitions by Microsoft

* Microsoft's "Innovations"

A language with only one compiler written in that selfsame language can't be trusted very easily because all available binaries might have trojans that self-replicate using the technique that Ken Thompson demonstrated in "Reflections on Trusting Trust". The usual way to detect a "Trusting Trust" trojan is David A. Wheeler's diverse double-compiling, which starts by bootstrapping a compiler's source code on three independent implementations of a language and seeing if the process of compiling a compiler with itself converges to identical binaries. But you can't do DDC if the only available Rust compiler is written in Rust. Sure, you can use OCaml to compile the old Rust frontend and use old Rust to compile the new Rust frontend, but then you'd need multiple independent OCaml compilers so that it can be verified using DDC.

gcc, which they trust, and shouldn't really, as it could have been compromised and no one could tell

If there exist multiple C compilers, one of which is available to the public as source code, one can use David A. Wheeler's diverse double-compiling procedure to make the probability of a backdoor negligible.

1. Start with three compilers in executable form and one in source code form. We'll call the three DCC, ECC, and FCC, and the source one GCC.
2. Compile GCC with each, producing GCC-compiled-with-DCC, GCC-compiled-with-ECC, and GCC-compiled-with-FCC. Though these binaries will all be different, having been produced by different code generators, they should have exactly the same behavior, as they are all compiled from the same source code.
3. Compile GCC with each, producing GCC-compiled-with-GCC-compiled-with-DCC, GCC-compiled-with-GCC-compiled-with-ECC, and GCC-compiled-with-GCC-compiled-with-FCC. This second round of binaries should be identical, as they were all produced with GCC's code generator. If not, disable any timestamp feature in GCC or Binutils and try again.

If the resulting binaries of GCC-compiled-with-GCC are identical other than internal timestamps, one of the following is true: A. either GCC as compiled by DCC, ECC, and FCC is clean, or B. DCC, ECC, and FCC all share the same backdoor. Which is more likely in practice?

We can't solve all problems with laws, but some laws could reduce the problem. Here are some ideas: http://www.dwheeler.com/essays...

> I'd argue that they have never "innovative".

I would also agree with that assessment.

> Just stole.

I would replace the word stole with the more accurate term bought:

* DriveSpace aka DoubleSpace: Licensed from Vertisoft and then out-right copied Stac Electronics.
* Internet Explorer: Licensed Spyglass Mosaic and renamed it.
* Windows: Copied Apple who copied Xerox.
* Direct3D: Bought Rendermorphics, Ltd and renamed their shitty API RealityLab to Direct3D

Looks like David Wheeler (of readable S Lisp Expressions fame) agrees with us:

* http://www.dwheeler.com/innovation/microsoft.html

> I'd argue that they have never "innovative".

I would also agree with that assessment.

> Just stole.

I would replace the word stole with the more accurate term bought:

* DriveSpace aka DoubleSpace: Licensed from Vertisoft and then out-right copied Stac Electronics.
* Internet Explorer: Licensed Spyglass Mosaic and renamed it.
* Windows: Copied Apple who copied Xerox.
* Direct3D: Bought Rendermorphics, Ltd and renamed their shitty API RealityLab to Direct3D

Looks like David Wheeler (of readable S Lisp Expressions fame) agrees with us:

* http://www.dwheeler.com/innovation/microsoft.html

Hmm, you must be new here. Please see David A. Wheeler's 'Fully Countering Trusting Trust through Diverse Double-Compiling' ( http://www.dwheeler.com/trusti... ) and come back once you're properly enlightened.

When is the last time you check all the code.

True, practice not meeting theory led to Heartbleed. But Heartbleed woke the industry, and now audits of free software have become somewhat more common. Audits for binary blobs aren't practical at all.

http://c2.com/cgi/wiki?TheKenThompsonHack

Obsoleted by the David A. Wheeler defense.

This is just expensive hipster stuff with an ugly 3d printed case, no merit...

The merit is ability to show to suits that there exists a market for modular battery-powered computers with additive manufactured cases.

Ken Thompson's work was beautiful and subtle - a compiler disguised all evidence of its backdoor even when you write code to search for these backdoors or when you compile the compiler itself.

True. But that works only when there's one compiler available for a particular language. If you bootstrap a compiler with three independent compilers, the backdoor is highly unlikely to persist into all three according to "Diverse Double-Compiling" by David A. Wheeler. Compile the compiler A with multiple compilers B, C, and D, and then compile A with (A compiled with B), (A compiled with C), and (A compiled with D), and you end up with (A compiled with A), (A compiled with A), and (A compiled with A). If they're identical, then B, C, and D have either no backdoor or an identical backdoor. Which is more likely?

Of course, all this requires that source code for A be available to the public or at least to a person trusted by the public to release compiler binaries. This is true of TCC, GCC, and Clang, not so much for Microsoft C++.

Last but not least there is no real reason for somebody to start a second implementation.

Yes there is. A language with only one implementation cannot so easily become a formal International Standard the way C and C++ are. Nor can a language with only one implementation support David A. Wheeler's diverse double-compiling, the most practical countermeasure to the "Trusting Trust" attack described by Ken Thompson.

That is an awesome summary. I just put that in slide set 1 of graduate class materials on developing secure software: http://www.dwheeler.com/secure...

Old news and outdated. The compiler backdoors can now be prevented: http://www.dwheeler.com/trusti...

For those who don't know, COCOMO is an algorithm that was developed in 1981 by Barry Boehm for estimating the cost of building software (typically in person-hours). The numbers in the article were generated by the basic COCOMO calculation in David Wheeler's free SLOCCount toolset.

One drawback is that SLOCCount uses the basic COCOMO calculation, which is based on historical data gathered by Boehm in 1981. Here's a COCOMO-81 calculator in case you want to play with your own code. Sometimes its estimates are pretty good, but I've sometimes found that applying line counts from my projects in some modern languages (especially functional ones like Scala) throw it off. That could definitely affect the "1,356 developers 30 years" estimate in the article.

Wheeler has a good discussion of COCOMO in SLOCCount if you want to learn more about it.

For those who don't know, COCOMO is an algorithm that was developed in 1981 by Barry Boehm for estimating the cost of building software (typically in person-hours). The numbers in the article were generated by the basic COCOMO calculation in David Wheeler's free SLOCCount toolset.

One drawback is that SLOCCount uses the basic COCOMO calculation, which is based on historical data gathered by Boehm in 1981. Here's a COCOMO-81 calculator in case you want to play with your own code. Sometimes its estimates are pretty good, but I've sometimes found that applying line counts from my projects in some modern languages (especially functional ones like Scala) throw it off. That could definitely affect the "1,356 developers 30 years" estimate in the article.

Wheeler has a good discussion of COCOMO in SLOCCount if you want to learn more about it.

Incidentally, that problem has been solved: http://www.dwheeler.com/trusti...

It takes some effort though.

So long as two or more independently developed, self-hosting compilers for a language exist, with at least one as publicly available source code, a Ken Thompson attack on the public-source one is infeasible. David A. Wheeler proved it; here's the gist:

1. Use Visual C++, Intel C++, and Clang++ to compile g++. The binaries you get in this stage will differ, but if VC++, Intel C++, and Clang++ are uncompromised, they will have exactly the same behavior.
2. Use each of the three copies of g++ you compiled earlier to compile g++, disabling timestamps in the output. Because they all have the same behavior (the behavior of g++), they should all produce the same the output. Thus the binaries you get in this second stage will be identical unless one of the first compilers is compromised.

See this paper describing how to counter that problem. The trusting trust attack is not the end of software security.

What i don't get is how and why these people then tryto talk back to it.

For the same reason that people talk to Eliza, Alice, and other such entities - because it makes us feel good.

We intuitively associate the machines with humanness... Even when we know we shouldn't:

  * https://philosopherdeveloper.wordpress.com/2011/02/05/the-anthropomorphization-of-computers/
  * http://www.therefinedgeek.com.au/index.php/2010/09/22/dont-anthropomorphize-computers-they-hate-it-when-you-do-that/
  * http://www.dwheeler.com/blog/2013/08/06/

Also: you get to feel like part of history if the social media flunky at the the other end of the feed decides to reply to your post.

Why does this keep coming up?
This problem is solved: http://www.dwheeler.com/trusti...

My article How to Prevent the next Heartbleed lists in detail different ways that Heartbleed could have been found ahead-of-time. The point isn't to find it now, it's to learn from Heartbleed so we prevent a recurrence. There are many ways to detect vulnerabilities like this ahead of time... we need to start using some of them.

Fortunately, we know how to counter that threat.

Only Microsoft has the ability to counter that threat because only Microsoft owns a lawfully made copy of the source code to Visual C++. Microsoft also has an interest to promote BitLocker over TrueCrypt.

If this hadn't been done ten years before he talked about, it's been done by now. They have everything they want. Live accordingly.

Fortunately, we know how to counter that threat.

It also seems pretty unlikely that the NSA had enough foresight to get VC++ instrumented to subvert TrueCrypt. It's not impossible, but there have been a lot of similar tools over the years, and I don't think the compilers could have been modified to subvert all of them.

That's detectable. See here. If it had been done with any major compiler, I'm fairly confident it would have been detected by now.

It has undergone a LOT of changes in the name of security, so it may be a lot "tighter" than when you last looked at it, just a FYI.

It's not. They added signing etc, but the quality of the code is still like this. If anything, it's gotten worse in the past few years IMO, as a lot of their good programmers have left.

The process to detect this compromise not only exists, but can be automated. http://www.dwheeler.com/trusti...

I see your Ken Thompson and I raise you a David Wheeler http://www.dwheeler.com/trusti...

Would recompiling the entire system from source defeat "intercepted in transit and been tampered with for spying purposes"?

If you're worried that your compiler binaries have the "trusting trust" virus proposed by Ken Thompson, you can detect that with David A. Wheeler's "diverse double-compiling" construction. It involves "bootstrapping" a compiler (compiling it with another compiler and then recompiling it with the resulting compiler) and then making sure all copies are bit-identical. Install three different free C compilers, such as GCC, Clang, and TCC, and build GCC 4.7, the last version prior to GCC's switch to C++, with each of them. Then build GCC 4.7 with the three different resulting copies of GCC 4.7 that you just built. The results after this second pass should be bit-identical unless one of your original compilers was compromised. Finally use GCC 4.7 to bootstrap whatever compiler you prefer to use to build the rest of the system.

Don’t anthropomorphize computers, they hate that notes that most developers do use anthropomorphic language. I think there are probably a variety of good reasons for it, too. Here's one speculation: When we communicate with a human, we must use some language that will be more-or-less understood by the other human. Over the years people have developed a variety of human languages that do this pretty well (again, more-or-less). Human languages were not particularly designed to deal with computers, but languages have been honed over long periods of time to discuss human behaviors and their mental states (thoughts, beliefs, goals, and so on). In any case, the problem isn't anthropomorphic language, it's the use of a bad analogy.

Obviously every character except for the path separator and the string terminator should be valid. Why should the file system restrict what character encoding I want to use for my names other than restrictions that simply make implementation easier.

This article makes a pretty convincing case that we'd be better off with some restrictions on filenames. It's hard to argue the point that allowing certain characters in filenames causes more problems than it solves.

Sorry - if the tools that we have for managing the labels that humans wish to place on their objects are lacking, we should fix the tools, not the labels. For example, I've named my dog "Crankshaft" - does that confuse mechanics? The only thing we humans have is the ability to manipulate symbols. I'd prefer to have no restrictions on the labels that I use, since they simply refer to objects.

Obviously every character except for the path separator and the string terminator should be valid. Why should the file system restrict what character encoding I want to use for my names other than restrictions that simply make implementation easier.

This article makes a pretty convincing case that we'd be better off with some restrictions on filenames. It's hard to argue the point that allowing certain characters in filenames causes more problems than it solves.

Oh God. That's a pretty remarkable claim considering that no one at Canonical had anything to do with the discovery or the patching of the bug. Let's have a quick look at the actual sequence of events:
1. Shellshock was discovered by Stéphane Chazelas, who reported it to bash maintainer Chet Ramey and a few others, and assigned CVE identifier CVE-2014-6271.
2. "CVE-2014-6271: remote code execution through bash" by Florian Weimer of Red Hat (2014-09-24) was one of the first public disclosures of the problem.
3. Florian Weimer (Debian contributor and Red Hat employee) posts a patch for bash that counters the attack.
4. Red Hat, CentOS, Fedora, Oracle Linux, Debian, and Ubuntu adopt Weimer’s patch. Apple’s later OS X bash update 1.0 includes it as well.
5. Chet Ramey posts bash43-027 at 2014-09-27 22:50:07, accepting Weimer's patch into the upstream mainline.
Remember, it's always good to cite your sources (if you have any).
http://www.dwheeler.com/essays...
And now, it's been fun but good night!

Actually, now that I think about it a bit more (same AC), the USB user input problem is very similar to the attack Ken Thompson described in Reflections on Trusting Trust (pdf), and the suggestion I gave in the previous post somewhat resembles David Wheeler's Diverse Double Compiling (pdf) solution to that.

In that vein of thought, if we require each input device to verify every other input device, then it stands to reason that any number of untrusted input devices could be validated as long as at least one isn't compromised. The combinatorial explosion of validations shouldn't really be an issue, since the number of input devices intentionally connected to the same machine is typically very small.

I've spent the past 5 years of my life fully employed in the design, creation, testing, and deployment of secure RNGs.

Citation needed. Seriously, this is /. where everyone is a world-class programmer (except me, of course).

The world is full of bad PRNGs, NRNGs, CSPRNGs, DRBGs, TRNGs and any other form of RNG.

I will grant you that one.

LibreSSL doesn't have a leg to stand on. A good secure RNG will return unpredictable output.

Bzzzzt! Sorry, you lose. As I have already said, this is not a LibreSSL problem - it's a Linux PRNG problem. Unless I am mistaken, the same issue is non-existent under OpenBSD, because it's PRNG is different from Linux, better seeded and because PIDs are randomized under that OS.

We know how to do these things. It isn't trivial, but it isn't hard either.

You contradict yourself: if programming PRNGs is, let's say, a medium difficulty task (neither trivial nor too hard), how come you have spent years designing and programnming PRNGs (your words, not mine) and how come the world is full of bad bad bad PRNGs? Surely, by now, everyone would have agreed on a reasonable implementation?

The truth is, PRNGs are HARD to program, because computers are not good at generating truly random numbers. Period. The best implementations all rely on some form of hardware generator. But don't take my word for it, go ahead and read this instead.

Allowing someone to extract predictable behavior from the service end of a security library is a gross failure and an exposition of incompetence.

As opposed to the magnificent job OpenSSL has done all these years, with information leakage, bug reports that went uncorrected for years and accumulated cruft for such modern OS as VMS, DOS and Windows 3.1?

I think you need to tone down the hysteria a notch right here.

As I commented years ago, the worst problem with the current IAU definition of "planet" is a practical one: we can't practically use it for objects orbiting other stars.

We are too far away to observe small objects around other stars, and I think we will always be able to detect larger objects but not smaller ones in many faraway orbits. So when we detect an object in another galaxy with the mass of Jupiter, and it’s orbiting a star, is it a planet? Well, under this current definition we don’t know if it’s a planet or not. Why? Because we may not be able to know what else is there in orbit. And that is a real problem. I think it’s clear that we will always be able to observe some larger objects without being able to detect the presence of smaller ones. If we can’t use the obvious word, then the definition is useless - so we need a better definition instead.

I think a much better definition of "planet" is "orbits a star, enough mass to become round". Yes, that means that Ceres and some Kuiper Belt objects become planets. That's a GOOD thing. A lot of people don't know of Ceres, yet that one object has about 1/3 of the ENTIRE mass of the asteroid belt.

Of course, none of this affects reality; this is merely a definition war. But clear terminology is important in any science.

This is a big deal. If you use a browser on Windows that does NOT counter this, such as Internet Explorer, then you ARE vulnerable. I imagine Microsoft will come out with a special-purpose patch, but still, this is a pretty nasty issue.

Untrustworthy CAs have been a problem for a long time; we need mechanisms to address them. The terrible cert revocation system makes it even worse; you can't be sure that the certs are checked in many cases. Chrome's CRLSets are not the answer; they are not even the beginning of an answer. We need to fix the whole revocation system. Sadly, there hasn't been enough work or enough urgency on these problems; maybe this will light a fire under those efforts. I doubt it, but it's worth hoping.