PR 193 sitting for uClibC fix

PR 193 sitting for uClibC fix

[William Roberts]

This PR:
https://github.com/SELinuxProject/selinux/pull/193

Has been sitting forever. I looked through the mailing list and didn't
see any patches hit the list,
we should either close it, or merge it.

Thoughts? If we need it to hit the list, can I grab it and sign-off on
it and post it?

Bill

Re: PR 193 sitting for uClibC fix

[Stephen Smalley]

On Thu, Mar 26, 2020 at 12:22 PM William Roberts
<bill.c.roberts@gmail.com> wrote:
>
> This PR:
> https://github.com/SELinuxProject/selinux/pull/193
>
> Has been sitting forever. I looked through the mailing list and didn't
> see any patches hit the list,
> we should either close it, or merge it.
>
> Thoughts? If we need it to hit the list, can I grab it and sign-off on
> it and post it?

You can't sign-off on someone else's patch without them first signing off on it
or otherwise certifying to you that it falls under clauses (a), (b),
or (c) of the DCO.
You could create your own patch to achieve the same end, especially
since this one is trivial and seems
to be modeled after an existing commit,
ab0e27003ef245f20512d1808b1dfee662ab8f41, so it
seems like it is relatively safe.

Re: PR 193 sitting for uClibC fix

[William Roberts]

On Thu, Mar 26, 2020 at 11:44 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Thu, Mar 26, 2020 at 12:22 PM William Roberts
> <bill.c.roberts@gmail.com> wrote:
> >
> > This PR:
> > https://github.com/SELinuxProject/selinux/pull/193
> >
> > Has been sitting forever. I looked through the mailing list and didn't
> > see any patches hit the list,
> > we should either close it, or merge it.
> >
> > Thoughts? If we need it to hit the list, can I grab it and sign-off on
> > it and post it?
>
> You can't sign-off on someone else's patch without them first signing off on it
> or otherwise certifying to you that it falls under clauses (a), (b),
> or (c) of the DCO.

For some reason I just assumed it had a signed-off line, it doesn't though.

> You could create your own patch to achieve the same end, especially
> since this one is trivial and seems
> to be modeled after an existing commit,
> ab0e27003ef245f20512d1808b1dfee662ab8f41, so it
> seems like it is relatively safe.

I thought about creating it, but it's like how do I create such a trivial patch
and not get hit with I copied it.

Re: PR 193 sitting for uClibC fix

[Stephen Smalley]

On Thu, Mar 26, 2020 at 12:46 PM William Roberts
<bill.c.roberts@gmail.com> wrote:
>
> On Thu, Mar 26, 2020 at 11:44 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Thu, Mar 26, 2020 at 12:22 PM William Roberts
> > <bill.c.roberts@gmail.com> wrote:
> > >
> > > This PR:
> > > https://github.com/SELinuxProject/selinux/pull/193
> > >
> > > Has been sitting forever. I looked through the mailing list and didn't
> > > see any patches hit the list,
> > > we should either close it, or merge it.
> > >
> > > Thoughts? If we need it to hit the list, can I grab it and sign-off on
> > > it and post it?
> >
> > You can't sign-off on someone else's patch without them first signing off on it
> > or otherwise certifying to you that it falls under clauses (a), (b),
> > or (c) of the DCO.
>
> For some reason I just assumed it had a signed-off line, it doesn't though.
>
> > You could create your own patch to achieve the same end, especially
> > since this one is trivial and seems
> > to be modeled after an existing commit,
> > ab0e27003ef245f20512d1808b1dfee662ab8f41, so it
> > seems like it is relatively safe.
>
> I thought about creating it, but it's like how do I create such a trivial patch
> and not get hit with I copied it.

IANAL, but IIUC when something can only be done one way, it isn't copyrightable.
Other possible ways to differentiate:
- libselinux/src/Makefile provides a FTS_LDLIBS ?= definition, which
was missing from their patch.
Not sure that matters.
- Instead of adding it LDLIBS for everything, could just add it where
needed, similar to PCRE_LDLIBS.

Re: PR 193 sitting for uClibC fix

[Stephen Smalley]

On Thu, Mar 26, 2020 at 12:52 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Thu, Mar 26, 2020 at 12:46 PM William Roberts
> <bill.c.roberts@gmail.com> wrote:
> >
> > On Thu, Mar 26, 2020 at 11:44 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > >
> > > On Thu, Mar 26, 2020 at 12:22 PM William Roberts
> > > <bill.c.roberts@gmail.com> wrote:
> > > >
> > > > This PR:
> > > > https://github.com/SELinuxProject/selinux/pull/193
> > > >
> > > > Has been sitting forever. I looked through the mailing list and didn't
> > > > see any patches hit the list,
> > > > we should either close it, or merge it.
> > > >
> > > > Thoughts? If we need it to hit the list, can I grab it and sign-off on
> > > > it and post it?
> > >
> > > You can't sign-off on someone else's patch without them first signing off on it
> > > or otherwise certifying to you that it falls under clauses (a), (b),
> > > or (c) of the DCO.
> >
> > For some reason I just assumed it had a signed-off line, it doesn't though.
> >
> > > You could create your own patch to achieve the same end, especially
> > > since this one is trivial and seems
> > > to be modeled after an existing commit,
> > > ab0e27003ef245f20512d1808b1dfee662ab8f41, so it
> > > seems like it is relatively safe.
> >
> > I thought about creating it, but it's like how do I create such a trivial patch
> > and not get hit with I copied it.
>
> IANAL, but IIUC when something can only be done one way, it isn't copyrightable.
> Other possible ways to differentiate:
> - libselinux/src/Makefile provides a FTS_LDLIBS ?= definition, which
> was missing from their patch.
> Not sure that matters.
> - Instead of adding it LDLIBS for everything, could just add it where
> needed, similar to PCRE_LDLIBS.

Or you could just ping them on the github issue and ask if they will
at least certify
to the DCO as a github comment (or better, push a revised commit with sign-off)
and then you can take it from there.

Re: PR 193 sitting for uClibC fix

[William Roberts]

On Thu, Mar 26, 2020 at 11:57 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Thu, Mar 26, 2020 at 12:52 PM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Thu, Mar 26, 2020 at 12:46 PM William Roberts
> > <bill.c.roberts@gmail.com> wrote:
> > >
> > > On Thu, Mar 26, 2020 at 11:44 AM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > > >
> > > > On Thu, Mar 26, 2020 at 12:22 PM William Roberts
> > > > <bill.c.roberts@gmail.com> wrote:
> > > > >
> > > > > This PR:
> > > > > https://github.com/SELinuxProject/selinux/pull/193
> > > > >
> > > > > Has been sitting forever. I looked through the mailing list and didn't
> > > > > see any patches hit the list,
> > > > > we should either close it, or merge it.
> > > > >
> > > > > Thoughts? If we need it to hit the list, can I grab it and sign-off on
> > > > > it and post it?
> > > >
> > > > You can't sign-off on someone else's patch without them first signing off on it
> > > > or otherwise certifying to you that it falls under clauses (a), (b),
> > > > or (c) of the DCO.
> > >
> > > For some reason I just assumed it had a signed-off line, it doesn't though.
> > >
> > > > You could create your own patch to achieve the same end, especially
> > > > since this one is trivial and seems
> > > > to be modeled after an existing commit,
> > > > ab0e27003ef245f20512d1808b1dfee662ab8f41, so it
> > > > seems like it is relatively safe.
> > >
> > > I thought about creating it, but it's like how do I create such a trivial patch
> > > and not get hit with I copied it.
> >
> > IANAL, but IIUC when something can only be done one way, it isn't copyrightable.
> > Other possible ways to differentiate:
> > - libselinux/src/Makefile provides a FTS_LDLIBS ?= definition, which
> > was missing from their patch.
> > Not sure that matters.
> > - Instead of adding it LDLIBS for everything, could just add it where
> > needed, similar to PCRE_LDLIBS.
>
> Or you could just ping them on the github issue and ask if they will
> at least certify
> to the DCO as a github comment (or better, push a revised commit with sign-off)
> and then you can take it from there.

Already pinged once, I can try again and see. Give them to next week and if no
response submit something like this:

diff --git a/libselinux/utils/Makefile b/libselinux/utils/Makefile
index 361506384d08..32da04068b3c 100644
--- a/libselinux/utils/Makefile
+++ b/libselinux/utils/Makefile
@@ -10,6 +10,8 @@ else
 COMPILER ?= clang
 endif

+FTS_LDLIBS ?=
+
 ifeq ($(COMPILER), gcc)
 EXTRA_CFLAGS = -fipa-pure-const -Wpacked-bitfield-compat -Wsync-nand
-Wcoverage-mismatch \
        -Wcpp -Wformat-contains-nul -Wnormalized=nfc -Wsuggest-attribute=const \
@@ -45,7 +47,7 @@ endif

 override CFLAGS += -I../include -D_GNU_SOURCE $(DISABLE_FLAGS) $(PCRE_CFLAGS)
 override LDFLAGS += -L../src
-override LDLIBS += -lselinux
+override LDLIBS += -lselinux $(FTS_LDLIBS)
 PCRE_LDLIBS ?= -lpcre

 ifeq ($(ANDROID_HOST),y)