On Sep 11, 2013, at 3:22, Tabitha McNerney <tabith...@gmail.com> wrote:
> Ian and all, > > I have been doing some more research and spoke with some people in the > industry about certified compilers. Apparently a lot of progress has been > made in the recent past and money has been flowing into the arena of > certified compilers. What's preventing Apple from having a third party > independent audit of their developer tools (which MacPorts depends on, and > the rest of the world also depends on for a wide range of apps either for OS > X or iOS)? Seriously, how hard would this be and I can't imagine it being a > terrible expense to Apple to do this and show the world that its compilers > are trojan free. Apple's toolchain (clang, llvm, cctools, ld64) is Open Source. If you want to do an audit, have at it. Sources are available at http://opensource.apple.com ... as for hiring a 3rd party to do an audit, I can't really comment on that as I'm not "in the know" ... maybe Apple doesn't feel the need to hire a 3rd party auditing firm when it already hires bright engineers that can do the same task in house ... maybe Apple has and just doesn't feel the need to publish results ... maybe Apple feels that releasing its entire toolchain as OSS and developing it collaboratively with the community at large is the safest and most secure approach ... maybe nobody bothered to mention the idea to Apple ... maybe 3rd party firms saw too many $ in their eyes and quoted unreasonable prices and were turned down ... maybe ... (see there are plenty of possibilities) On Sep 7, 2013, at 22:56, Tabitha McNerney <tabith...@gmail.com> wrote: > 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). Al Gore's been out of politics for well over a decade, has no connection to the NSA, and focuses primarily on environmental impact these days. As a huge company making products with rare earth metals, using a lot of energy, and wanting to be environmentally conscientious, it makes sense for Apple to have him on the board for that reason. I'm sure his political past also provides some benefit in advising on how to deal with changing political landscapes, but I hardly doubt that he is planted there to pressure the board to authorize NSA back doors. > 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. I really don't see that happening. Of course you would need to let us know how thick your tin foil hat is before we can offer a solution to you. If you feel ok using Apple's tools to build an OSS compiler which you can use, then it's quite easy (just build/install the compiler, hack base to pick macports-clang-3.3 instead of clang by default). If you don't want to use Apple's toolchain AT ALL, then you have a chicken/egg problem as others have already mentioned. You'd need to build your compiler using an "untainted" compiler ... which in your world means something not Apple which means another toolchain on another platform (cross compilation). FreeBSD seems out of the question for you since they use the same toolchain family as Apple (llvm/clang) for base these days. So maybe pick OpenBSD. You'd need to build a cross compilation toolchain (maybe binutils and gcc will work), and then use those to rebuild the toolchain for running on the Mac, deploy them on your Mac. At that point, hopefully you'd feel comfortable using that gcc to build OSS clang, and then you could hack base to pick your clang. Of course, you can't escape linking against libSystem, communicating with xnu, daemons, etc ... unless you want to rebuild all of that as well ... I guess the real point is that if you don't trust Apple's toolchain, you can't trust the entire OS ... > 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? One could edit the linker to inject an initializer in every linked binary that would run when loading. All you'd need is for someone to run that executable under sudo, and you could have it do whatever I want. The problem with that is: 1) Developers would notice (open ports, odd load commands, weird extra symbols, etc) 2) The linker is OSS If you don't trust that the OSS version is the same, probe it with the same inputs to see if the outputs differ.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
