[OE-core] musl patches

[Andreas Müller]

On Tue, Apr 17, 2018 at 4:53 AM, Khem Raj <raj.khem at gmail.com> wrote:
>
> On Mon, Apr 16, 2018 at 7:02 PM ChenQi <Qi.Chen at windriver.com> wrote:
>>
>> On 04/16/2018 07:05 PM, Andreas Müller wrote:
>> > Hi,
>> >
>> > I am not happy plastering patches around for musl. This gets even
>> > worse when I see patches like this [1]: Just wipe away security checks
>> > unconditionally - the developers did introduce this check not just for
>> > fun I guess...
>> >
>> > I have seen this already elsewhere so: musl maintainers please take
>> > care not to modify code for glibc!
>
>
> The idea of musl is not to create a cocoon and live in it but on the
> contrary it’s about fixing the packages such that they work on any posix
> complaint libc regardless having said that there are packages which are
> coded for glibc and we
> Might have to keep trying to fix them upstream
>
> So in the spirit we are making changes such that
> They work across the board and then also push
> These patches to respective upstreams so far we
> Have done good job and upstreamed a whole bunch of patches this would not
> have been possible if we did the conditional approach
>
> We would not like to introduce regressions for sure and if you see
> regressions please report them ASAP and if you have fixes even better
>
> I am hoping that in the end applications will
> Become more portable and we will also see
> The cruft clearly that has gone into glibc over the years and be able to
> address it as you can see  there is lot of cleanup happening in glibc
> already as a result
>>
>>
>> >
>> > [1]
>> > https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/systemd/systemd/0001-Use-getenv-when-secure-versions-are-not-available.patch
Let's talk about this patch (same in meta-network/networkmanager):
Without further wisdom I cannot see the 'spirit' of this. It just
opens the chance of vulnerabilities for glibc builds and this for
components as systemd and networkmanager. I wonder what upstream would
say about this patch...

So as long as musl (or clean for posix) patches are not upstreamed I
would ask to keep glibc builds as are designed and tested upstream
either by

* SRC_URI_append_libc-musl or
* #if defined(__GLIBC__) in the code

My 2ct...

Andreas