[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SEUL: Common SEUL/e-linux tools needed
> > 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.
> > 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
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..