I set the date to

• allow us a few days for more deliberating on the vulnerability, to really think it through, write the advisory, understand it proper. Rinse and repeat.
• give "distro people" a few days to prepare patched updates
• allow a few days for the project (and me) to line up things to prepare for the new release
• we can spread the word about the pending release and the main reason for it in the mean time
• the release needs to work with my personal schedule and Wednesdays are our standard release days

Sure, there is a minuscule risk that someone can find this (again) before we ship the patch, but this issue has stayed undetected for years for a reason. I think taking a few days to make sure we do a solid release is worth this risk.

I'm wondering about the term "distro people": who is this exactly and how do they handle this case?

I guess that they already know more than we, the public, do. How can we be sure they will fix this issue in time and make sure those doing derivative work will also follow in time?

Let's say, if Red Hat can already prepare updates because they have access to some still secret information, how can the creators of all its clones, like Rocky, Alma, Oracle, CensOS and the like also provide updates in time?

Usually trusted people from mainstream Linux distributions have the proper contacts (and/or are on the proper private mailing lists) to receive patches and more information than the general public early enough. I can only assume that this is the case here as well....

The "distro people" I refer to above are the ones subscribed to the distros mailing list.

Being one of those "distro people" maintaining an internal distribution for my company only, it would be beneficial if we could somehow get access to a patch that can be applied to the 8.3.0 source as soon as possible.

I'm sorry, but if I would give you that information it would help identify the problem (area) with a very high accuracy so I cannot do that ahead of time. The "last several years" of versions is as specific as I can get.

Every security flaw requires a set of conditions to apply for the problem to trigger. The pending security vulnerabilities are no different. I cannot comment on what that set is ahead of time.

The severity level is a blunt tool. This is a HIGH severity problem but there is still going to be a large chunk of users who will not be affected by these problems.

Yes it will. In general terms: everything that uses libcurl could theoretically use libcurl in a way that triggers this vulnerability, assuming that the conditions apply and that a vulnerable libcurl version is used. Of course some/many users will also use libcurl without being able to trigger the vulnerability.

It is impossible for me to make affirmative statements about specific libcurl users now.

In case you’re asking if the patch to libcurl will require a redistribution of pycurl: most distros ship pycurl with dynamic linkage of libcurl (rather than static linkage). In that case, pycurl would almost certainly benefit from the changes to the (dynamically linked) libcurl without repackaging/redistribution.

(I say “almost certainly” because the libcurl patch might introduce a relevant ABI change which would require changes to pycurl but I find that very unlikely since there’s no such notice in the OP above.)

There is no API nor ABI change in the coming curl release. Updating the shared libcurl library should be enough to fix this issue on all operating systems.

Then again there will also be countless docker (and similar) images that feature their own copies, so there will still be quite a large number of rebuilds necessary I bet.

#12026 (reply in thread)