This is all documented on the musl ML.
musl 1.1.17 was rushed due to this CVE:
<http://www.cvedetails.com/cve/CVE-2017-15650/>
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
it now.
In fact, Syrone Wong actually discovered the regression earlier.
<http://lists.infradead.org/pipermail/lede-dev/2017-October/009237.html>
(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>
Yes,
Main reason in that specific case was mainly for these 2 fixes:
/9e01be6 fix signal masking race in pthread_create with priority (I use
lots of threading & thread priority in my app) //51bdcdc fix OOB reads in Xbyte_memmem (used by memmem() ) /
fwiw, my 2 cents:
I try to carefully judge whether there's a good reason to bump head or
not, and I mostly wait for min 48 hrs to let the latest commits soak a bit.
One could argue for backporting only importing changes (which I've done
in the past), [1]
but it was argued that it's better sometimes to just bump the git head
instead
as it can take months before a new release is done containing critical
fixes, which is the reason for the switch to git download [2]
Maybe a balanced solution would be to wait for 1 .. 2 tested-by's
before pushing these to master?
Bleeding edge /can/ lead to cuts .. and lets all try to ensure it
doesn't exceed the severity of a papercut,
but thats the main reason why stable branches exist (like 17.01)
Basically,
As long as people bump something to head in a sanely fashion using
common sense and an educated reason .. we should be fine in the long run.
[1]
https://git.lede-project.org/?p=source.git;a=commit;h=2912f9f2a2e5997df069d38e20d85ff4cc51acef
[2]
https://git.lede-project.org/?p=source.git;a=commit;h=a8a5cb9595cd64a48c1cea6a1478c11e022474a9
Koen
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
