Mark Morgan Lloyd schrieb:
Sorry, you've missed my point. I've come across systems where compilers
have to be "blessed" by the local security administrator before they can
mark code as executable, and there's a progressively stronger chain up
to the point where nobody except that manufacturer can bless a compiler
such that it can generate the operating system kernel. The objective is
to try to avoid the situation described by Ken Thompson in his 1984
"Trusting Trust" paper http://cm.bell-labs.com/who/ken/trust.html
Unix does not have this mechanism: anybody can build a compiler which
can then build a new kernel.
This is how Unix and Linux evolved - everybody could play around with
it, and add new functionality. Blaming an compiler for buggy source code
IMO helps nothing. Recompiled kernels have to be booted, somehow, what
is nothing that ordinary users can do on an mainframe. And when every
user must manage his own system(s), what can he do but allow a just
installed compiler to do its job?
Trusting code is a different thing. With open source code you can be
halfways sure that the code has been tested by many people, and MD5
checksums prevent malicious modification of the downloaded sources. This
is how malicious modifications, also to the compiler itself, can be
detected and avoided.
Hackers are kind of evolutionary force, which makes the system software
coders aware of backdoors and other flaws. Monetary losses have two
benefits: they make intrusions visible, and they enforce improvement of
flawed software (to be paid for). Ask companies how much money they
invest in safe software, and compare that amount with the (claimed)
losses caused by hackers :-]
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
