Re: SEUL: Common SEUL/e-linux tools needed

[lso8219@cs.rit.edu (Loren S Osborn)]

> > 	Linux Emulator:
> > 		will emulate a virtual linux system, allowing
> > 		a safe environment to test-install packages that
> > 		must install and run as root... It may be nice to have
> > 		a version for each hardware platform...
> > 		This will run as batch, so speed isn't a concern!
> 
> Actually, a full chroot'd environment works perfectly for this.  I have
> built several complete, booted-the-first-time systems on alternate
> partitions using this method.  Simply do alternate-root rpm installs of
> the first few required packages, chroot to it with an NFS mount handy
> inside the root, and install away.

Well, for one thing, this is supposed to help catch non-well behaved programs.
Also, I would like to be able to check the program on all five popular Linux
hardware platforms (ix86, m680x0, PPC, Alpha, Sparc/Ultra ) through emulation.
Specifically, the ix86 cannot fully emulate itself... it can only emulate
a 8086/8088 in a Virtual CPU.  I think not doing a full emulation is
particularly dangerous for programs intended to run as root... (Not to mention
that a full emulation of the ix86 might give the Wine project a boost.)

> Baring poorly behaved applications, this is a very secure, safe
> rubber-room environment to do just about anything you want.  IMHO, RedHat
> should be using it for RPM builds.  If found out last night that the perl
> 5.004_01 rpm in the biltmore updates was set up with a BuildRoot of
> /var/tmp/perl_root.  How do I know this?  None of the CPAN modules would
> work, as Config.pm still pointed to /var/tmp/perl_root.  Major oversight,
> which I will be mentioning to RedHat tonight.

I'm quite hesitant to go with RPM for several reasons:
	1) I have found that the 'rpm' program from RedHat seems to keep
		records poorly, and is easy to confuse.
	2) I dislike that most RPM that are availible don't contain
		source-code, and the ones that do don't compile
		automatically in the background. 
	3) I think that if we want to have plug-in modules for this
		configuration tool included with *ALL* packages, then
		we need to have a new format that gaugentees that such
		a file does *INDEED* come with each package.
	4) The PGP key, and the integrity checking will provide a moderate
		level of security (protecting the user more from developer
		laziness, than developer hostility, but providing some
		consistancy too...)
I posted something to e-linux a while back concerning this, I'll see if I 
can dig it up...

I do realize that creating a new package format for our distributions will
lead to an *HUGE* amount of work for all of us, but I do believe it necessary.
Most likely *WE* will have to originally adapt each .tgz file to each package
until the developers themselves decide to champion this...  On the bright side,
however, the server system I envision will monitor the .tgz and attempt to 
automatically update when the program is updated...

I'll try to dig up that old e-linux post...

Comments? Suggestions?

Loren