From: dwalsh@redhat.com (Daniel J Walsh)
Date: Fri, 07 Sep 2012 07:22:52 -0400
Subject: [refpolicy] state of core/contrib split
In-Reply-To: <5049D3CE.7020806@trentalancia.com>
References: <5048D6E2.3030303@tresys.com> <5048DA26.3080703@trentalancia.com>
	<5049D3CE.7020806@trentalancia.com>
Message-ID: <5049D90C.2050701@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/07/2012 07:00 AM, Guido Trentalancia wrote:
> 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).
> 
Obviously if your patch is in Fedora, we give it an implicit ACK.
> 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.
> 
> _______________________________________________ refpolicy mailing list 
> refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
> 
SELinux userspace should be brought up on the selinux list.  Eric is getting
preparing a push, but has been held up because of linuxcon. If you do not see
your patch in his push, I would ping him.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBJ2QwACgkQrlYvE4MpobPhYQCgk4kB2Zp60HooTgOQuLi/BAzg
mVUAn1X2XWOo7hqoLLs4jAiuRSjGfQdm
=P6sN
-----END PGP SIGNATURE-----