[oe] [meta-networking][PATCH] networkmanager: Update to 1.18.0

[Khem Raj]

On Tue, May 28, 2019 at 11:06 AM Adrian Bunk <bunk at stusta.de> wrote:
>
> On Tue, May 28, 2019 at 09:14:17AM -0700, Khem Raj wrote:
> > On Tue, May 28, 2019 at 8:37 AM Andrei Gherzan <andrei at gherzan.ro> wrote:
> >
> > > On 28/05/2019 16.13, Khem Raj wrote:
> > > > Hi Andrei
> > > >
> > > > The musl patches need to be forward ported as well. They dont apply
> > > > cleanly anymore on top of this update.
> > >
> > > Seems like. So all the contributions now need to go through local musl
> > > and glibc testing? This sounds a little bit of an overhead and might
> > > discourage people in contributing because usually everyone is working on
> > > one libc variant. Just raising it as a concern. As per this specific
> > > case, I'm going to fix it and push a V2.
> >
> >
> > I understand that and in some cases it’s even narrower where one might just
> > be working on one distribution alone for single architecture for that case
> > failure on architectures they don’t care is
> > also a nuisance
> >
> > It’s wide and far testing we can achieve is good for end user same goes for
> > multiple architectures if someone tests a given architecture and reports
> > build  failures then it’s good to acknowledge that imo
> >
> > It’s not a blocker I expect someone interested in a given regression of
> > this kind to chime and help if possible so don’t see it as an impediment
>
> Is anyone actually using networkmanager with musl?
>

Yes.

> There are no obvious usecases where it makes sense, and OE seems to be
> adding security vulnerabilities in the musl build that are not in the
> glibc build (e.g. -Dsecure_getenv=getenv) so users should better not
> use it in any case.
>

That could be improved. Probably adding this function to musl is not a bad idea

something like

char *secure_getenv(const char *name)
{
 return issetugid() ? NULL : getenv(name);
}

will do the job. Once I am back I might propose this to musl if someone does
that before would be fine too.

> > If we remain cognizant of the fact that upstream might have wider usecases
> > we will generally be better off cumulatively
>
> Upstream ships a copy of systemd code for use as library.
>
> This already implies that trying to support it for musl will be a
> long-term pain of not upstreamable patches for OE contributors.
>

so far it has not been so much a pain but its good to monitor.

> cu
> Adrian
>
> --
>
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed
>