On Oct 23, 2009, at 9:22 AM, Joshua Brindle wrote:
That is not the purpose of this patchset, and it was never claimed
to be the purpose of this patchset.
The purpose of this patchset is to start integrating policy support
into RPM, and for RPM to remain completely trusted. I did say that
we have an ultimate goal of breaking RPM up into pieces so we could
remove trust from the main parts, and to eventually be able to run
RPM in different security domains depending on different aspects of
the RPM (where it came from, who signed it, who is running RPM, etc)
but that is not something this patch set can accomplish and indeed
is a long term goal.
We can't very well go off for a long time and come back with a
patchset that completely changes the architecture of RPM, we are
doing this development in the open and therefore each individual
patch set along the way brings us closer, it doesn't completely
solve the problem.
No you can't. Nor can you wander around making contradictory statements
about what you intend publically.
So now the goal is "completely change the architecture of RPM" without
any statement of purpose (other than that you think the change is
needed)
and you claim to be doing development in the open.
If you stated your goals more clearly, with perhaps an illustration of
what you think needs doing, you might find better acceptance.
Each individual patch set I've seen is currently appearing, to somewhat
negative comments not just from me, and then you wander off
to re-appear with essentially the same patch set with almost exactly
the same issues (like the opaqueness of bz2 blobs embedded
in rpm headers, and the size of the unnormalized uncompressed
policy data, and the difficulties of executing helpers in empty
chroot's). Go read the comments, the issues were pointed out not just
by me.
Could you please state your goals more clearly so that a developer
might understand the reasoning behind an end-point that seems to
include "completely changes
the architecture of RPM" as an end-point (or why did you bother
mentioning).
Otherwise, piecemeal patching (as in the current patch set) closely
followed
by claims that you are going to move to "hi-level compilers to install
policy"
(my paraphrase from memory) seems more like a randopm walk than
anything else.
73 de Jeff
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
