[Mono-list] bootstrapping mono with free software?

Robert Shade rshade@dvsconsulting.com
Tue, 23 Mar 2004 13:36:22 -0500


Instead of going outside of the project, why don't we just ask to have 
the distribution files include a PGP signed MD5Hash?  This is pretty 
much standard practice for many projects.

rob

Noa Resare wrote:

> Hello friends
> 
> I had a look at mono again yesterday for about a year away from it, and
> you guys have really been productive.
> 
> One thing however that I think is a bit frustrating with mono is that to
> bootstrap it you distribute quite a lot of binary files (in the
> mono/runtime directory). This is maybe convinient, but from a security
> standpoint it means that you need to "blindly" trust whoever has control
> over the distribution path of the binaries.
> 
> (Modifying mcs.exe that makes string comparisons always succeed if
> compared with the magic string "LawrJj4joR6c" and adding code that makes
> mcs.exe compiled with that "tainted" mcs.exe do the same thing without
> the source code for it is left as an exercise to the reader.
> 
> If such a binary was ever included in the mono distribution someone
> would have a magic password that worked here and there and detecting the
> backdoor would be non-trivial.)
> 
> A solution to this problem would be to have the ability to bootstrap the
> mono environment from a verifiable source. I immediately come to think
> about Portable.NET, since the cscc compiler is written in c and the
> system bootstraps from a standard c environment without any binary code.
> 
> I just tried to this, with mixed success. A trivial patch to mcs/decl.cs
> to work around a bug in enum initialization in cscc made mcs.exe
> compile. Some more kluges applied to to the mcs sources made mcs.exe
> work in the Portable.NET environment for simple test cases, like
> compiling a runnable HelloWorld.exe.
> 
> Trying to compile mono's mscorlib.dll however is a completely different
> experience. Exceptions from
> Mono.CSharp.RootContext.BootCorlib_PopulateCoreTypes decendands all over
> the place.
> 
> So I was hoping that someone with deeper understanding than me of the
> mono internals could do an estimation on how much work it would need to
> get mono's corlib to compile with mcs.exe executed from the Portable.NET
> runtime.
> 
> These are the non-trivial stuff that fails right now:
> 
> error CS0518: The predefined type `System.Char*' is not defined or
> imported
> 
> the same goes for 'System.Void*'
> 
> Method SetCorlibTypeBuilders is missing from
> System.Reflection.Emit.AssemblyBuilder (btw, isn't there a better way to
> do this than adding non-standard methods to the corlib?)
> 
> cheers
> /noa
>