Refresher on gcc port and the executables

[Tabitha McNerney]

Continuing this thread which was initiated in May of this year (2013), some
things in the world have revealed themselves such as the NSA leaks by Ed
Snowden. In particular the leaks of a few days ago were a *big* deal, as
Bruce Schneier has eloquently written about here:

http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying

and here:

http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance

Let me please call your attention to this excerpt by Bruce:

As was revealed
today<http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance>,
> the NSA also works with security product vendors to ensure that
> commercial encryption products are broken in secret ways that only it knows
> about. We know this has happened historically: CryptoAG<http://www.schneier.com/blog/archives/2008/01/nsa_backdoors_i.html>and Lotus
> Notes <http://www.heise.de/tp/artikel/2/2898/1.html> are the most public
> examples, and there is evidence of a back door in Windows<http://www.heise.de/tp/artikel/5/5263/1.html>.
> A few people have told me some recent stories about their experiences, and
> I plan to write about them soon. Basically, the NSA asks companies to
> subtly change their products in undetectable ways: making the random number
> generator less random, leaking the key somehow, adding a common exponent to
> a public-key exchange protocol, and so on. If the back door is discovered,
> it's explained away as a mistake. And as we now know, the NSA has enjoyed
> enormous success from this program.
>

My boss has been smiling at work a lot lately. He feels very vindicated for
having reasonably healthy "paranoia" about vendor compilers (e.g., Apple's
tools) just months ago before Snowden made headlines. My boss asked me and
my colleagues to read this seminal article by Ken Thompson of Bell Labs in
1984 (from the Turing Award Lecture) about how a trojan can be created in a
C compiler (he said he does not want the especially younger developers to
be too naive and also told us about the Clipper Chip from the 1990s that
never came to fore light but was very close to coming to fore):

https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

Therefore, in light of the very recent leaks, such as the NSA sitting on
encryption standards committees (NIST, etc.) and intentionally contributing
suggestions to help create workarounds for their own benefit, and in light
of the NSA working with vendors (per Bruce's excerpt aforementioned and
cited), I have to say my boss is looking pretty smart these days and I can
not help but wonder if Apple's developer tools, which MacPorts depends on,
could have backdoors planted in them for the NSA. After all, Al Gore is on
the Apple Board of Directors (and one might wonder, why on Earth would a
former U.S. politician who was in favor of the Clipper Chip be useful to a
technology company like Apple on its board? The other Apple Board members
make more sense since they have science, technology and business
expertise).

I would suggest the MacPorts community should think about this and evaluate
what options we may have should we want to wean ourselves off of the Apple
developer tools. That article by Ken Thomson about trojans and C compilers
is quite telltale (to be honest I had not understood this before). Could a
trojan in Apple's compilers propagate into other tools made and compiled
for MacPorts?

Regards,

-Tabitha



On Thu, May 23, 2013 at 12:59 AM, Ryan Schmidt <ryandesign at macports.org>wrote:

>
> On May 23, 2013, at 02:15, Tabitha McNerney wrote:
>
> > For a particular project I am working on, my boss asked me if there was
> a way to compile some code from source (which depends on and will use of
> some advanced cryptography potentially for highly sensitive business), such
> that, in his words, "it is not dependent on any compiler tools from a
> corporation like Apple, Google or Microsoft" and he said "it should be the
> same as what is used by open source Linux distros". So this would mean gcc
> but it makes me think I might need to do something unique such as making
> gcc from source on my own since my boss doesn't want there to be any
> company fingerprints (he's really worried but also its his job that could
> be on the line). For special purposes, is it fairly easy to make gcc and
> g++ from source, on OS X, in a way that is in fact "divorced" from the
> Apple tools?
>
> If you don't trust the compilers provided by Apple in Xcode, then you
> can't trust any compiler built by MacPorts, since MacPorts will build its
> compilers using a compiler from Xcode.
>
> Not trusting your vendor's compiler seems needlessly paranoid. Then again
> I don't write security-critical software.
>
> Using, say, a compiler binary provided by Apple to compile your software
> does not somehow give Apple any rights to your software. That would be
> silly.
>
> You could ask your boss to clarify his intent, but it sounds like what he
> wants is for the source code you write to not *require* a specific
> compiler, but to be *portable* to any normal C compiler. That's a
> reasonable requirement, and is one that's followed by most of the software
> ported by MacPorts. The C language is standardized, as is C++; assuming you
> write standards-compliant code, and don't use e.g. Apple- or
> Microsoft-specific language or compiler extensions, you should have no
> problem compiling it on a variety of compilers. You can compile your code
> with a variety of compilers on a variety of systems to verify if you're
> succeeded in this goal.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20130907/e98d9a6a/attachment.html>