From: dwalsh@redhat.com (Daniel J Walsh) Date: Thu, 06 Sep 2012 14:55:26 -0400 Subject: [refpolicy] state of core/contrib split In-Reply-To: <5048EF31.10902@redhat.com> References: <5048D6E2.3030303@tresys.com> <5048DA26.3080703@trentalancia.com> <1346954588.15262.89.camel@d30.localdomain> <5048EF31.10902@redhat.com> Message-ID: <5048F19E.7000301@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/06/2012 02:45 PM, Miroslav Grepl wrote: > On 09/06/2012 08:03 PM, Dominick Grift wrote: >> >> On Thu, 2012-09-06 at 19:15 +0200, 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. >>> >>>> Additionally, due to his many contributions to the policy and >>>> reviewing of others' patches, Dominick Grift has been given contrib >>>> commit access. >>>> >> I just made my first commit which was a trivial one and symbolic. Porting >> some of the fedora policy is harder than one might think. One issue is >> that it may require changes to refpolicy (not contrib) others have to do >> with how fedora deals with certain issues ( which are probably not >> acceptable by refpolicy ) >> >> One thing Fedora could do in my opinion is when it makes commits to its >> own git repository, take some time to see if this commit applies or is >> easily applied to contrib/refpolicy. >> >> That probably means keeping a local refpolicy/contrib policy and port the >> commits to that and then either submit the patches to this list or commit >> to refpolicy/contrib them selves. >> >> That requires extra work no doubt but maybe Miroslav and his employer are >> willing to take that extra effort in order to make the changes not bigger >> than they already are. >> >> Some changes refpolicy should not want as it sets a bad precedent IMHO. I >> have seen this. >> >> The last week i have been trying to write a systemd policy on top of >> refpolicy on a minimal fedora 18 system and i encountered issue that i >> would not have if i would write my systemd policy on to of fedora >> policy. >> >> This is due to some coarse rules added to fedora that hide/obscure some >> important issues that ideally need to be confronted head on. >> >> For example: dealing with inheriting and fd >> >> In the refpolicy we have the opportunity to not go the same route as >> fedora. (In some regard refpolicy also went astray in my opinion though , >> for example i suspect refpolicy made/makes domains unconfined to easily) >> That means that some changes, and their dependencies, downstream just >> cant apply to refpolicy. >> >> So its a tough situation that we probably only can resolve together i >> suspect. It requires that we agree on standards/rules and share the same >> values. Prefer quality over quantity, but i guess its also give and take >> on both sides of the isle. >> >> Some frank and open communication can go a long way, but i understand for >> many its a paid job with dead lines and stuff. >> >> So its not easy. >> >> I will do what i can to merge as much to contrib as i can as long as i >> can. I don't deal with employers and deadlines so much but i have my >> share of uncertainty that i have to deal with in my life. >> >> I like the split of refpolicy and contrib. unfortunately refpolicy does >> not build without contrib though due to optional policy i guess. >> >> It is also unfortunate that eclipse-slide is no longer in active >> development. This application really make life much easier and productive >> for policy writers > We have changed our structure to reflect upstream structure recently. And I > believe it will be easier to accept Fedora changes now (which I tried some > time ago and it was accepted). Now this is my goal to prepare good patches > which could be applied. > >> >> >>> _______________________________________________ refpolicy mailing list >>> refpolicy at oss.tresys.com >>> http://oss.tresys.com/mailman/listinfo/refpolicy >> >> _______________________________________________ refpolicy mailing list >> refpolicy at oss.tresys.com >> http://oss.tresys.com/mailman/listinfo/refpolicy > > _______________________________________________ refpolicy mailing list > refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy > The problem I saw when I started to merge changes in the past was that lots of new policies required changes to the base, especially corenetwork. As miroslav said, he has split out the policy to match upstream, so testing it against the upstream base might get a little easier. Having additional people like Dominick helping to merge would be great, since we never seem to have the time. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBI8Z4ACgkQrlYvE4MpobOPlwCfZhQOKLjV2qxaptB2KkjCkm55 dAkAoOBPa+uI31HPebW4/gLzAYysk3Rl =PTHn -----END PGP SIGNATURE-----