On Tuesday, November 21, 2017 9:56:12 AM CET Koen Vandeputte wrote: > > 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() ) / > Hm? Are you now talking about something else? I remember seeing these commits listed in your musl update to 1.1.16+. <http://lists.infradead.org/pipermail/lede-dev/2017-October/009234.html>
But Felix did the update musl to 1.1.18 on the 5th (I noticed that he had a patch queued). This update included the changes you listed, right? > 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. "waiting" around doesn't help in regression cases. I think this glob-regression is another case in point. The issue was discovered more than a week before 1.1.17 was released: <https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09180.html> and when I posted the request to move to 1.1.17 (again). But it only received the attention, once people started testing the new 1.1.17 and did bisections. > 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? Great that you bring this up. So, did you test >this patch< already too? And if so, what's your verdict? Does it perform as expected on your cns3xxx? Can you please post a "tested-by" tag then? As for pushing to master: From most past experience, a patch usually sits in the patchwork queue for some time (a few days to months). Then one of the commiter adds it to his/her public staging tree and if all went well, the patch moves to master eventually. Regards, Christian _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
