[fpc-devel] Re: EBCDIC (was On a port of Free Pascal to the IBM 370)

[Mark Morgan Lloyd]

Hans-Peter Diettrich wrote:
> 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?

Please note that I'm not being critical, simply attempting to summarise 
the situation for somebody who might not appreciate the nuances, 
particularly in view of an earlier comment that it might not be possible 
to do the final build on a PC.

> 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.

I'm not sure that an authenticate-by-source-digest approach would 
prevent the sort of problem that Thompson described, unless there was 
also a mechanism to validate that a particular binary was accurately 
described by its professed source package.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]