On Mon, 26 Feb 2007 12:21:07 -0800, Paul D. Fernhout  
<pdfernhout at kurtz-fernhout.com> wrote:

> A good question, but if you are serious about security, a much more  
> secure system is going to come from building a system up (especially up  
> from a textual description), and understanding what each component you  
> include does, and testing all their interactions, rather than just  
> accepting what results from some random shrink command that may or may  
> not remove code with various security problems. Security is not an  
> add-on -- if you want a secure application, the idea of security needs  
> to be woven throughout everything you do -- initial image or source,  
> code development processes, deployment approach, update streams, and so  
> on.

Perhaps I had not followed closely enough the discussion, but I thought we  
were talking about options in the absence of being able to grow from  
nothing. So:

>>> Why take a perfectly working application and start potentially   
>>> introducing all sorts of random errors into it at the last minute  
>>> just  to save a bit of storage space and network bandwidth (especially  
>>> these  days)?

I thought you were offering the option of:

a) Leave all code in.
b) Shrink, causing potential problems.

In which case, (b) is, if not more secure, easier to check, presumably. If  
we have another option:

c) Build, adding only what's needed.

Well, sure, I'll take (c). But I don't think we can ever escape (b)  
entirely, since our development image includes all our development tools,  
as opposed to simply being created by them. In fact, I wonder if that  
wouldn't resolve some issues: Having a development image which is used to  
build on a target image.

	===Blake===