From: guido@trentalancia.com (Guido Trentalancia) Date: Fri, 07 Sep 2012 13:00:30 +0200 Subject: [refpolicy] state of core/contrib split In-Reply-To: <5048DA26.3080703@trentalancia.com> References: <5048D6E2.3030303@tresys.com> <5048DA26.3080703@trentalancia.com> Message-ID: <5049D3CE.7020806@trentalancia.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 06/09/2012 19:15, Guido Trentalancia wrote: > On 06/09/2012 19:01, Christopher J. PeBenito wrote: >> The core/contrib split in the refpolicy repo has been around for a year. Unfortunately, I don't think it has gone as originally planned, as the people with commit access haven't really been committing anything. Differences between refpolicy and distro policies are pretty severe in some cases. What can we do to improve the situation? > > In my opinion, file contexts are probably impossible (or at least > extremely expensive) to tackle in a one-fits-all way for all possible > distributions and at the same time they are sort of silly blockers. In addition to the above, simple patches sometimes don't get through. Take for example, the cpucontrol module patch that I recently posted. It just ended up in nothing without sufficient follow-up. I am not trying to blame anyone in particular and for sufficient follow-up, I do simply mean that, in my opinion, there needs to be at least three kinds of tagging following the post of a patch: NEEDS_REWORK (patch is interesting and could be possibly applied with minor or major rework), MERGED (patch is applied straight), REJECTED_NO_FOLLOW_UP (patch is trying to gear current policy in a direction that is not acceptable/profitable and therefore it is not going to be supported). I have not received any of the above replies for some patches (including the cpucontrol module one), therefore I do not know how to proceed. There were problems with file-contexts, this is always going to happen to a certain extent until distributions interested in supporting SELinux will make a list of their file locations easily accessible from the web or ftp (e.g. http://www.distro1.org/filelist.txt, ftp://ftp.distro1.org/filelist.txt, ftp://ftp.distro2.org/filelist.txt). But apart from that it is entirely unknown to me whether it is worth or not keep working on that... It shouldn't be expensive for distributions to publish their latest file locations. It will allow SELinux policy developers to create policy based upon the latest location of their distributed binaries (because they often change suddenly and often tend to vary too much amongst different distributions, not necessarily with a consequent profit). Otherwise, the work-load on the policy developer might become too high. Other patches also got stuck in SELinux userspace. Most notably, one patch that aimed at re-stabilizing (read fixing a bug) policycoreutils/semanage ([PATCH v2]: seobject.py must skip comments while reading external configuration files, Aug 2012 and optionally [PATCH]: libselinux: improve the file_contexts.5 manual page, Aug 2012) after changes made to the policy ([refpolicy] [PATCH v1/v2]: clarify the file_contexts.subs_dist configuration file usage, Aug 2012). >> Additionally, due to his many contributions to the policy and reviewing of others' patches, Dominick Grift has been given contrib commit access.