On Thu, May 04, 2017 at 09:22:22PM +0200, Petr Lautrbach wrote: > On 05/04/2017 07:50 PM, Dominick Grift wrote: > > 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.override@xxxxxxxxx> 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 > > > I'm just building new set of updates in my COPR plautrba/selinux > repository [1]. It's based on latest upstream sources with some Fedora > patches on the top of it currently tracked in my github tree [2]. But > there are some problems and it's not ready yet. Most of the fedora specific patches I will probably not be able to test. I don't (can't) use semanage, policycoreutils-GUI etc. I am mainly able to test libselinux, libsepol and policycoreutils > > I used to build vanilla upstream sources [3] but the latest build is 15 > months old. I can restart this project if there's an interest. That would be nice, especially if it could be automated. So that I have some kind of assurance that it is maintained. I dont add COPRs much but when i do i intent to keep using them consistently. I wouldnt want to have dead COPR repositories to worry about. > > Since COPR provides API with an authentication token, builds can > automated and I have few scripts I used before. > > I think it could even work for Rawhide with less frequent update cycle. I would prefer Rawhide because then we reach a broader audience. > > [1] https://copr.fedorainfracloud.org/coprs/plautrba/selinux/ > [2] https://github.com/bachradsusi/selinux/tree/WIP-master > [3] https://copr.fedorainfracloud.org/coprs/plautrba/selinux-master/builds/ > > Petr Thanks! -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift
Attachment:
signature.asc
Description: PGP signature
