Hi Samuel, On Sun, May 28, 2023 at 12:17:21PM +0100, Samuel Henrique wrote: > 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).
Thank you, I believe this is very important information to allow to decide on the unblock. Make sense now to me and for security-tracker point of view I have marked the issue as unimportant (due the implication of binary packages not affected from the affected source). > 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. Understood, I think. > 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. Ok. I have updated the security-tracker accordingly, since we have source fixed, but binary packages not affected. > > 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. Did not do much, but was sitting together with Paul from the release team to go trough some unblock requests fixing CVEs and curl was yet still on the radar of packages which did not pass. > > 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). Ok. Regards and thanks for your work on curl! Salvatore
