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

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

> > 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.)
> Keep in mind, however, that the best results to be obtained from a full 
> hardware emulator (not a JIT recompiler) are about 5 times slower than the 
> hardware itself.

This is actually quite optomistic, I was hoping for 20:1, so if we can do
5:1, this would be great!

> > I'm quite hesitant to go with RPM for several reasons:
> > 	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.
> Nope, we just include the file in the SPEC for the RPM.  Simple as that.  
> Requiring that a given file (config, in this case) exist is simply not in the 
> scope of a package manager.  That's not what it does.

I think you misunderstand:  I'm concerned (especially with end-users) of
using something that is called an 'RPM' when what our system will install
is a *SUBSET* of those rpm's availible (those which have our configuration
plug-in, and verification PGP stamp etc.) Calling our package an RPM would
confuse the end-users as to which ones will work and which ones won't.
I'm not concerned in the data format itself... (I even recommended using a
simple tar.gz as the file format)

Does this make sense?

> > 	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...)
> This is a feature, no?

Yes... A feature that not all RPM's have...

> > 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.
> Not true.  rpm (and/or dpkg) do everything we need.  There is no need to 
> write YAPF (yet another package format), and I have no plans to do so unless 
> it is demonstrated that indeed there are features that we need that cannot be 
> added to either rpm or dpkg.  IMO, if we end up in that situation, we need to 
> start over and rethink what the heck we're doing.

see above...

> > 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...
> Why?  We can't assume that the SPEC file or equiv will work on a new .tar.gz 
> (original source) unless that package is already set up precisely for that 
> purpose (as should be the case for our own software).  For production 
> systems, the only thing that is needed is a check for new, upated, packages, 
> as we find in RedHat.  There are several contributed packages that do just 
> that.

I admit that I need to be educated on rpm's, but my concern is we can't
require something of all RPMs that all rpm's don't have..

Comments? Suggestions?

Loren