search

conan-io / conan-center-index

Recipes for the ConanCenter repository
https://conan.io/center
MIT License
960 stars 1.77k forks source link

[request] version bump for common offenders #23277

Open valgur opened 7 months ago

valgur commented 7 months ago

These are some of the most common offenders for version conflicts currently, in my experience. I propose doing a version bump for the listed recipes, about a 100 packages in total. I would add Boost to this list as well, but that would double the number.

I'm willing to create the PRs (at a reasonable rate) if I get greenlit for that. @jcar87, I think you advised against doing it unprompted it in one of the PRs by @mayeut, so I'm pinging you personally.

Alternatively, maybe some of the listed dependencies could be added to the permitted version ranges list.

expat -> [>=2.6.2 <3]

Version ranges for expat are allowed and recommended now: https://github.com/conan-io/conan-center-index/pull/23510#discussion_r1566001446

2.6.1 and below are vulnerable https://nvd.nist.gov/vuln/detail/CVE-2024-28757 https://repology.org/project/expat/information

libxml2 -> [>=2.12.5 <4]

23276

2.12.4 and below are vulnerable https://repology.org/project/libxml2/information

imath / openexr

imath/3.1.11: #23275 No vulnerable versions https://repology.org/project/imath/information

openexr/3.2.3 3.2.1 and below are vulnerable https://repology.org/project/openexr/information

xz_utils -> ~5.6.1~ 5.4.5

https://repology.org/project/xz/information

sqlite3 -> 3.45.3

3.43.1 and below are vulnerable https://repology.org/project/sqlite/information

freetype -> 2.13.2

2.11.1 and below are vulnerable https://repology.org/project/freetype/information

fontconfig -> 2.15.0

2.12.0 and below are vulnerable https://repology.org/project/fontconfig/information

glib -> 2.78.3

2.75.0 and below are vulnerable https://repology.org/project/glib/information

mayeut commented 6 months ago

3 weeks have gone by for this security related issue. Since then, expat<2.6.2 now all have known security issues.

I went ahead and started to create PRs in order to solve some of those.

I started to bump recipes using expat/2.6.0, if there were conflict with 2.5.0, then they were pre-existing conflicts and will still be there after this first batch.

If the recipe has other dependencies listed here, they'll be bumped as well (libxml2, opener, sqlite3,...) thus it would be ideal to get https://github.com/conan-io/conan-center-index/pull/23276 merged in order to bump libxml2 to the latest version at the same time.

The order in which to review / merge PRs is as follows:

jcar87 commented 6 months ago

3 weeks have gone by for this security related issue. Since then, expat<2.6.2 now all have known security issues.

Please remember that consumers have multiple ways in which to force the Conan solver to solve to a specific version, overriding the values in the recipes:

Thus, for security-minded users that identify affected versions, this is recommended, along with the use of lockfiles. The most important aspect here is that the version without the security issues is already available. Overriding the versions will cause Conan to identify which recipes need to be built from source against the new versions.

Amending many recipes, while desirable, still does not guarantee that all users will immediately benefit when solving their graphs:

In the same way that we expect users to follow a managed process to bring-in the latest updates, as part of the same process and due diligence they can audit their dependency graph and ensure they are using the versions they require, with overrides/replace_require as mentioned above - thus, it is entirely possible for users to bypass the PR process in Conan Center to ensure their graph has the versions they require.

I went ahead and started to create PRs in order to solve some of those.

I appreciate the sentiment behind this, but please avoid opening this many PRs, as it can overload the CI service. There are already 600 open PRs - opening this many new ones does not really help draw our attention to security-motivated issues.

On the other hand, a few comments:

As for the proposed solutions:

valgur commented 6 months ago

Added fontconfig and glib to the list as well.

glib is another good candidate for version ranges use.

mayeut commented 6 months ago

First of all, thanks for taking care of reviewing / merging the opened PR.

@jcar87,

Thanks for your detail answer. I do understand and appreciate everything you're saying about how users should take care of managing their graph and, that's just true. However, the unsaid & underlying assumption here, as I understand it, is: "CCI graph is outdated and unsafe by default". This is most likely not true but that's what your answer might suggest. I'm just not at ease with this situation even if only to contribute to recipes that will pull known unsafe dependencies in the process.

"Drop vulnerable versions" from the recipe (config.yml and the likes) really has no effect other than "no new recipe revsions will be published for this version"

Well, it has one major side effect which is to reduce CI / infrastructure load when rebuilding the recipe. Given that CI load is mentioned as an argument not to open too many PRs to bump dependencies, I would say it's not only major but probably critical (doing so respecting the rules you defined in your answer but also the one in https://github.com/conan-io/conan-center-index/blob/4d826813a0f07b7587de24a2356f5ade0fe98d27/docs/adding_packages/sources_and_patches.md?plain=1#L59-L70).

Also please note that we will welcome backporting patches to older versions to address security vulnerabilities (where there is trusted, auditable source for that patch) that would mean that specific issues can be addressed in a single PR, rather than this many. This is what the Linux distros have done for many years - it is unlikely that they just bump to an actually new version.

As I understand it, you choose either stable & secure or unstable & secure when you choose a Linux distro. So while some do backports of security/bug fixes (which can end up, but not necessarily, with "just take the last version and override the version"), others just live at edge, possibly with patches that gets removed once a new version for a package comes out.

Obviously, CCI can't possibly test all combinations, it's probably more likely that a new version will be contributed than a patch for security (especially for patch versions). This leads me to believe that CCI shall probably live at edge for its dependencies.

In the case of expat and libxml2, we are happy to consider a version range.

That's a good thing, thanks !

Another solution that's not been put on the table yet is whether or not it would be possible to create a bump PR with multiple recipes ?