[LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD
chunkeey at gmail.com
Mon Nov 20 13:49:10 PST 2017
On Monday, November 20, 2017 7:34:31 PM CET Karl Palsson wrote:
> Christian Lamparter <chunkeey at gmail.com> wrote:
> > On Monday, November 20, 2017 8:17:05 AM CET Syrone Wong wrote:
> > > Any specific reason to introduce these changes?
> > Actually yes. The LEDE Website prides itself with
> > "LEDE is actively updated [...]"
> > <https://lede-project.org/reasons_to_use_lede#security>
> Actively updated is one, "we're going to be standing on the
> bleeding edge at all times, you're gonna get cut" is another.
> Musl is also making releases quite regularly, it's not even 20
> days since 17, and only 30 since 16.
This is all documented on the musl ML.
musl 1.1.17 was rushed due to this CVE:
However, the 1.1.17 release had accumulated like 11 months of patches since
the previous 1.1.16 release. There have been several regressions that went
unnoticed. But this only really came to light after 1.1.17 was already
released. Because the different projects and people actually started to test
In fact, Syrone Wong actually discovered the regression earlier.
(Koen issued an patch to update to the latest 1.1.16 git head and part of
the later discussion was also CC'd to the musl ML.)
But this wasn't fixed in time for 1.1.17.
However, this regression and two other problems then let to the 1.1.18 release
shortly thereafter. <https://marc.info/?l=musl&m=150860332132027&w=2>
(I think you meant the 1.1.17 and 1.1.18 release, right?
Because the 1.1.16 release is according to:
<http://git.musl-libc.org/cgit/musl> now 11 months old.
> Surely musl would be considering a release too for these issues?
It's not just issues and regressions. It's also UAPI updates and
updates to the LEDE specific iconv patch that was broken due to
Rich reworking the iconv. All these changes already start to pile-up.
> > a71b46cf fix malloc state corruption when ldso rejects loading
> > a second libc The Thread on the MUSL ML is "[musl] diffutils
> > crash in malloc". Judging from the descussion, it can cause
> > programs to misbehave starting with 1.1.17 and 1.1.18.
> > And there's more:
> > 72656157 fix fgetwc when decoding a character that crosses
> > buffer boundary c21051e9 prevent fork's errno from being
> > clobbered by atfork handlers
> > ...
> > + some UAPI updates, which will be nice to have for 4.14 development.
> > And Also, Rich made big changes to iconv and it broke the
> > 900-iconv_size_hack.patch.
> > Regards,
> > Christian
More information about the Lede-dev