Could we have a shorter delay between official releases of refpolicy than
normal for this cycle?
Including the usrmerge patch in git makes most file context patches against
the release policy not apply to git which is a significant annoyance when
submitting patches upstream.
I would also like to get most of the systemd patches I have merged soon, which
also adds a significant point of conflict between release and git.
I can't speak for all the other people who have significant repositories of
policy patches. But one issue that hinders me in sending them upstream is the
fact that they usually don't apply cleanly to git. I'd like to see more
patches going upstream so we don't have such significant differences between
distributions. I hope that more frequent upstream releases can help in this
regard.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On 02/07/17 22:09, Russell Coker via refpolicy wrote:
> Could we have a shorter delay between official releases of refpolicy than
> normal for this cycle?
I'm open to something sooner, to a point; perhaps a month. I'd like to
make sure everyone, especially distros, have sufficient time to try out
the usrmerge stuff.
> Including the usrmerge patch in git makes most file context patches against
> the release policy not apply to git which is a significant annoyance when
> submitting patches upstream.
As a former distro maintainer, I sympathize. However, that kind of
problem is what you're signing up for when you do distro maintenance.
At least having two statements in differing order generally has no
impact for policy, unlike for code patches.
> I would also like to get most of the systemd patches I have merged soon, which
> also adds a significant point of conflict between release and git.
A large systemd change is another reason to provide enough time for
people to try out the changes.
> I can't speak for all the other people who have significant repositories of
> policy patches. But one issue that hinders me in sending them upstream is the
> fact that they usually don't apply cleanly to git. I'd like to see more
> patches going upstream so we don't have such significant differences between
> distributions. I hope that more frequent upstream releases can help in this
> regard.
>
--
Chris PeBenito
On Wednesday, 8 February 2017 4:40:17 PM AEDT Chris PeBenito wrote:
> On 02/07/17 22:09, Russell Coker via refpolicy wrote:
> > Could we have a shorter delay between official releases of refpolicy than
> > normal for this cycle?
>
> I'm open to something sooner, to a point; perhaps a month. I'd like to
> make sure everyone, especially distros, have sufficient time to try out
> the usrmerge stuff.
Are the other distro maintainers trying out the git changes?
I usually don't test git code, I only test it when it is part of a release.
I'll only test git code if there is a significant amount of time and patches
elapsed since the last release (like a year). If you are hoping that I will
test patches you accept from other people then it's not going to work out.
> > Including the usrmerge patch in git makes most file context patches
> > against
> > the release policy not apply to git which is a significant annoyance when
> > submitting patches upstream.
>
> As a former distro maintainer, I sympathize. However, that kind of
> problem is what you're signing up for when you do distro maintenance.
> At least having two statements in differing order generally has no
> impact for policy, unlike for code patches.
It's a problem that you sign up for, but also something that can be reduced as
a time sink by just not sending patches upstream as often.
> > I would also like to get most of the systemd patches I have merged soon,
> > which also adds a significant point of conflict between release and git.
> A large systemd change is another reason to provide enough time for
> people to try out the changes.
Again that theory only holds if people are actively testing git policy. Is
that happening?
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On Thu, Feb 09, 2017 at 12:27:53PM +1100, Russell Coker via refpolicy wrote:
> On Wednesday, 8 February 2017 4:40:17 PM AEDT Chris PeBenito wrote:
> > On 02/07/17 22:09, Russell Coker via refpolicy wrote:
> > > Could we have a shorter delay between official releases of refpolicy than
> > > normal for this cycle?
> >
> > I'm open to something sooner, to a point; perhaps a month. I'd like to
> > make sure everyone, especially distros, have sufficient time to try out
> > the usrmerge stuff.
>
> Are the other distro maintainers trying out the git changes?
>
> I usually don't test git code, I only test it when it is part of a release.
> I'll only test git code if there is a significant amount of time and patches
> elapsed since the last release (like a year). If you are hoping that I will
> test patches you accept from other people then it's not going to work out.
Yep. So let me explain gentoo's workflow a bit. It's a little different
cuz gentoo is rolling and not release based so waiting for refpolicy
releases doesnt really work.
I only use gentoo's hardened-refpolicy (official repo is here:
https://gitweb.gentoo.org/proj/hardened-refpolicy.git/ i mirror to my
github too). Our release script (gentoo/release-prepare.sh) makes a big
patchfile on top of the latest refpolicy release then our ebuilds
extract refpol and apply the patch on top.
Our releases are <base refpol version>-r<release of the gentoo poliy>.
eg currently for sec-policy/selinux-base:
Available versions: 2.20151208-r4 2.20151208-r6 2.20161023-r1 2.20161023-r3 (~)2.20161023-r4 (**)9999
The 9999 version will pull the latest git HEAD and its what swift and I
mostly use during dev.
Before each release we pull in any changes from the refpol upstream repo
and merge them into the gentoo one. For gentoo-specific things i'll
apply them to our repo (almost always inside an ifdef distro_gentoo
block). Otherwise I generally prefer to submit the patches upstream
first then pull back down. I'll skip upstream if its a policy that we
havent upstreamed yet or if something is super broken and I need to make
a release right away. (or if im lazy ...)
Mainly its cuz things are rolling, i'll only see that something is
broken when it gets installed on my or someones system and they file a
bug. so if eg apache had a problem and it just got stabilized i cant
wait months for the next refpol release because people are using it.
That said, more frequent releases is definitely not a bad thing at all,
it just isnt as vital for my workflow as others. I *think* nicolas has a
similar patchset on top of the git repo for Arch but not sure exactly.
So to come back to your original question, yes, upstream git is tested
very extensively on gentoo and the version numbers are somewhat
meaningless in a way. I've been meaning to make a few blog posts about
the selinux workflow in gentoo but havent had the time yet :(.
Kind Regards,
Jason
>
> > > Including the usrmerge patch in git makes most file context patches
> > > against
> > > the release policy not apply to git which is a significant annoyance when
> > > submitting patches upstream.
> >
> > As a former distro maintainer, I sympathize. However, that kind of
> > problem is what you're signing up for when you do distro maintenance.
> > At least having two statements in differing order generally has no
> > impact for policy, unlike for code patches.
>
> It's a problem that you sign up for, but also something that can be reduced as
> a time sink by just not sending patches upstream as often.
>
> > > I would also like to get most of the systemd patches I have merged soon,
> > > which also adds a significant point of conflict between release and git.
> > A large systemd change is another reason to provide enough time for
> > people to try out the changes.
>
> Again that theory only holds if people are actively testing git policy. Is
> that happening?
>
> --
> My Main Blog http://etbe.coker.com.au/
> My Documents Blog http://doc.coker.com.au/
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
On 02/08/17 20:27, Russell Coker wrote:
> On Wednesday, 8 February 2017 4:40:17 PM AEDT Chris PeBenito wrote:
>> On 02/07/17 22:09, Russell Coker via refpolicy wrote:
>>> Could we have a shorter delay between official releases of refpolicy than
>>> normal for this cycle?
>>
>> I'm open to something sooner, to a point; perhaps a month. I'd like to
>> make sure everyone, especially distros, have sufficient time to try out
>> the usrmerge stuff.
>
> Are the other distro maintainers trying out the git changes?
>
> I usually don't test git code, I only test it when it is part of a release.
> I'll only test git code if there is a significant amount of time and patches
> elapsed since the last release (like a year). If you are hoping that I will
> test patches you accept from other people then it's not going to work out.
>
>>> Including the usrmerge patch in git makes most file context patches
>>> against
>>> the release policy not apply to git which is a significant annoyance when
>>> submitting patches upstream.
>>
>> As a former distro maintainer, I sympathize. However, that kind of
>> problem is what you're signing up for when you do distro maintenance.
>> At least having two statements in differing order generally has no
>> impact for policy, unlike for code patches.
>
> It's a problem that you sign up for, but also something that can be reduced as
> a time sink by just not sending patches upstream as often.
True. To be clear, I don't want to make it hard on maintainers, I'd
rather it be easy. But I also don't want to put out releases every
month, without consideration of the policy state.
>>> I would also like to get most of the systemd patches I have merged soon,
>>> which also adds a significant point of conflict between release and git.
>> A large systemd change is another reason to provide enough time for
>> people to try out the changes.
>
> Again that theory only holds if people are actively testing git policy. Is
> that happening?
It's a fair question, but my understanding is some people to test it out.
--
Chris PeBenito
On Thu, Feb 9, 2017 at 3:16 AM, Jason Zaman via refpolicy <
[email protected]> wrote:
> On Thu, Feb 09, 2017 at 12:27:53PM +1100, Russell Coker via refpolicy
> wrote:
> > On Wednesday, 8 February 2017 4:40:17 PM AEDT Chris PeBenito wrote:
> > > On 02/07/17 22:09, Russell Coker via refpolicy wrote:
> > > > Could we have a shorter delay between official releases of refpolicy
> than
> > > > normal for this cycle?
> > >
> > > I'm open to something sooner, to a point; perhaps a month. I'd like to
> > > make sure everyone, especially distros, have sufficient time to try out
> > > the usrmerge stuff.
> >
> > Are the other distro maintainers trying out the git changes?
> >
> > I usually don't test git code, I only test it when it is part of a
> release.
> > I'll only test git code if there is a significant amount of time and
> patches
> > elapsed since the last release (like a year). If you are hoping that I
> will
> > test patches you accept from other people then it's not going to work
> out.
>
> Yep. So let me explain gentoo's workflow a bit. It's a little different
> cuz gentoo is rolling and not release based so waiting for refpolicy
> releases doesnt really work.
>
> I only use gentoo's hardened-refpolicy (official repo is here:
> https://gitweb.gentoo.org/proj/hardened-refpolicy.git/ i mirror to my
> github too). Our release script (gentoo/release-prepare.sh) makes a big
> patchfile on top of the latest refpolicy release then our ebuilds
> extract refpol and apply the patch on top.
> Our releases are <base refpol version>-r<release of the gentoo poliy>.
>
> eg currently for sec-policy/selinux-base:
> Available versions: 2.20151208-r4 2.20151208-r6 2.20161023-r1
> 2.20161023-r3 (~)2.20161023-r4 (**)9999
> The 9999 version will pull the latest git HEAD and its what swift and I
> mostly use during dev.
>
> Before each release we pull in any changes from the refpol upstream repo
> and merge them into the gentoo one. For gentoo-specific things i'll
> apply them to our repo (almost always inside an ifdef distro_gentoo
> block). Otherwise I generally prefer to submit the patches upstream
> first then pull back down. I'll skip upstream if its a policy that we
> havent upstreamed yet or if something is super broken and I need to make
> a release right away. (or if im lazy ...)
>
> Mainly its cuz things are rolling, i'll only see that something is
> broken when it gets installed on my or someones system and they file a
> bug. so if eg apache had a problem and it just got stabilized i cant
> wait months for the next refpol release because people are using it.
>
> That said, more frequent releases is definitely not a bad thing at all,
> it just isnt as vital for my workflow as others. I *think* nicolas has a
> similar patchset on top of the git repo for Arch but not sure exactly.
>
Actually there is no official policy for Arch Linux (I tried to maintain
one 1 or 2 years ago but I could not do this on my own) and I do not know
what users are using. I am mainly packaging the programs and libraries and
the free time I have recently spent on SELinux-related projects has been
taken by extensively testing the tools.
On my systems, I am using refpolicy's git master branch with about 100
patches (some for systemd support, one to convert /usr/sbin to /usr/s?bin,
some for custom policies for the programs I use, etc.). This way I am kind
of testing the git changes before they are released.
When refpolicy will fully support recent systemd systems, it will make
sense to create a policy package for Arch Linux to ease its installation
and I will also be interested in more frequent releases, to minimize the
differences between the release and git master. It won't be as integrated
with the package manager as in Gentoo, but it will hopefully provide a good
base for Arch Linux users.
Cheers,
Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20170209/00b6247d/attachment.html
On Thursday, 9 February 2017 10:48:39 AM AEDT Nicolas Iooss wrote:
> When refpolicy will fully support recent systemd systems, it will make
> sense to create a policy package for Arch Linux to ease its installation
> and I will also be interested in more frequent releases, to minimize the
I think we should concentrate on systemd support then.
After the patch I've just sent I have another smaller systemd patch and some
other daemon related patches that have systemd components.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/