Hello Salvatore, > After a short discussion with Paul, wouldn't that imply though that > there is an soname bump needed? Do you know has upstream considered > this and if/or why not? Is there enough assurance nobody (even outside > Debian world) is using that symbol?
Those are all good questions, I should have done a better job at explaining this, so let me try doing it now. sergiodj@ did a lot of work investigating this as well, so most of the things I'll be saying here are his findings (although if I say anything wrong here, blame it on me). The "curl_jmpenv" variable declaration was guarded by a "#ifdef HAVE_SIGSETJMP", but the variable would only be used on "#ifdef USE_ALARM_TIMEOUT". For Debian, "HAVE_SIGSETJMP" is true but "USE_ALARM_TIMEOUT" is false, this is because we use the threaded resolver. This means that "curl_jmpenv" was dead code, and double checking for mentions of "curl_jmpenv" on codesearch.d.n only returns packages which bundles curl, nothing using it. Considering the variable was exposed, but not used anywhere (in our builds with threaded resolver), I don't think there was any possible way dependencies could be making use of it in any meaningful way (this is talking about things outside of our official repositories now). It doesn't make sense for upstream to bump SONAME because the variable can still be exposed depending on the build config, it's just that it wasn't supposed to be exposed for threaded resolvers first of all. The CVE that is being fixed by that change should not affect our binaries since we build with the threaded resolver, but I ended up making a decision to still apply the patch to safeguard even the sources. > These are just a couple of question trying to understand what > potential question from release team members my come for your unblock > request. Thank you for reviewing this. > p.s.: note it looks autopkgtest view for curl was still blocking it > because cwltool has a flaky test (on armel). Yeah, curl suffers quite a bit from these since tons of reverse-deps use it to fetch resources over the network and that's always flaky (not sure if it's the case with cwitool specifically, but I'm used to this sort of thing by now). Cheers, -- Samuel Henrique <samueloph>
