On Thu, May 04, 2017 at 07:42:40PM +0200, Dominick Grift wrote: > On Thu, May 04, 2017 at 11:50:15AM -0400, Paul Moore wrote: > > On Wed, May 3, 2017 at 12:51 PM, Dominick Grift <dac.overr...@gmail.com> > > wrote: > > > On Wed, May 03, 2017 at 12:14:16PM -0400, Stephen Smalley wrote: > > >> Part of the reason that we tend to not introduce a new policy > > >> capability more often is that it is painful to do so currently. We > > >> have to patch libsepol to recognize the new capability and patch the > > >> policy to declare it (although for the latter we can now declare them > > >> via a CIL module without modifying the base policy). And since the > > >> policy or module won't build without the updated libsepol, we can't > > >> turn on the capability by default in refpolicy without making it > > >> dependent on a new libsepol version. That's why extended_socket_class > > >> isn't yet enabled in refpolicy, for example. That causes enablement > > >> and adoption to lag behind. It also makes it harder to test the new > > >> kernel feature in the first place. > > > > > > I would like to see Fedora package the RC's in Rawhide as well (other > > > distributions could help by packaging the RC's in unstable as well). That > > > would atleast make the RC's a bit more accessible. > > > In Fedora it is usually not the kernel that is the problem, it is user > > > space that is generally to old. And as you've said policy is no longer a > > > problem with CIL. > > > > [NOTE: I'm still thinking about the rest of Stephen's email, and the > > follow up comments, but I wanted to reply to this particular comment > > separately.] > > > > I'm not sure I want to see SELinux userspace release candidates in > > normal Rawhide, but I think creating a COPR repository to > > build/distribute release candidates could be a good thing. We already > > do something similar for the kernel patches and it has been helpful in > > my opinion. > > Thanks, Yes i suppose you are right. Release Candidates would probably > potentially cause too much disruption even in Rawhide. > COPR should do the job, although will not be as accessible as Rawhide. It > won't get the same kind of attention, but it will do for me.
With COPR though we might be able to package more frequent and not just RC's (weekly's/nightly's)? If that can somehow be automated then we also do not have to worrie so much about keeping things maintained over time > > > > > https://copr.fedorainfracloud.org > > https://copr.fedorainfracloud.org/coprs/pcmoore/kernel-secnext > > > > -- > > paul moore > > www.paul-moore.com > > -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 > Dominick Grift -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift
signature.asc
Description: PGP signature
