Skip to main content

Updating our Ubuntu base for Miniforge Docker images (20.04 → 24.04)

The base image for our Ubuntu Dockerfiles has been upgraded from Ubuntu 20.04 (focal) to Ubuntu 24.04 (noble) in PR #145. This change ensures continued support and access to newer packages and system libraries.

Downstream users building on top of the Ubuntu variant of our containers should verify compatibility with the updated environment.

Thanks to @rpanai for the contribution and to the reviewers for their input.

Security Incident with Package Uploads (CVE-2025-31484)

Yesterday, conda-forge was notified of a security incident reporting that the anaconda.org upload token for the conda-forge channel had been accidentally leaked between on or about 2025-02-10 to 2025-04-01. Our investigation resulted in the temporary artifact upload shutdown you observed yesterday (2025-04-01). The results of our analysis show that, as best as can reasonably be determined, the token was not used by any 3rd party to upload malicious artifacts.

More details in the corresponding blog post.

Updating our default docker images

TL;DR: We have made some updates to our Docker images and build time GLIBC selection.

  1. We've updated our default docker images to be based on alma9
  2. It is now easier to override c_stdlib_version (especially for CUDA-enabled feedstocks), though our baseline of 2.17 hasn't changed.
  3. Where necessary, you can more easily switch images by setting os_version: ... (see below).
  4. We've consolidated our image names to follow a consistent pattern:
linux-anvil-{x86_64,aarch64,ppc64le}:{cos7,alma8,alma9}

In general, it won't be necessary in the vast majority of cases to override the docker-image, but if you need to do so, you can add the following to conda-forge.yml

os_version:             # just to demo different values;
linux_64: cos7 # whenever possible, please use
linux_aarch64: alma8 # homogeneous distro versions
linux_ppc64le: alma9 # across platforms

Migration to Unique Feedstock Tokens per Provider

We will be slowly migrating conda-forge to use unique feedstock tokens per provider. The feedstock token is used to allow maintainers to copy packages from our staging area to the main conda-forge channel. This change will improve our security posture and help us limit the impact of any leaked tokens. During this migration we will also be using newly implemented feedstock token expiration times to avoid race conditions between token changes and running builds.

New time available for conda-forge core meetings

The core team has decided to change the time when core meetings happen to accommodate more attendees across different timezones. It will still happen every two Wednesdays, but starting next Wednesday, November 13th 2024, it will alternate between 17:00-18:00 UTC and 14:00-15:00 UTC.

For clarity, these are the next dates:

  • November 13th, 2024 at 17:00 UTC
  • November 27th, 2024 at 14:00 UTC
  • December 11th, 2024 at 17:00 UTC
  • December 25th, 2024 at 14:00 UTC
  • January 8th, 2025, at 17:00 UTC
  • ... and so on.

A new calendar is now available in the Community > Meetings section to help find the dates.

Changes to the Feedstock Output Validation Procedure

We have changed our feedstock output validation procedure. Instead of automatically adding new packages to existing feedstocks (e.g., when a new output is added), we will now require that maintainers submit a PR to add the new output via our admin-requests repository. New feedstocks created via staged-recipes will have their outputs added automatically. If you maintain a feedstock that regularly adds new outputs (e.g., llvmdev has libllvm18, libllvm19, etc.), you can use the admin-requsts repo to add a glob pattern that matches the pattern of your new outputs. We test these patterns aginst new outputs from the feedstock using the Python fnmatch module. Outputs from the feedstock that match a glob pattern will added automatically. Further details on package output validation can be found in our documentation.

Removing build in favor of python-build

For nearly two years now, we have favored the use python-build as the package name for the PyPA build project over build. In fact, the build feedstock on conda-forge is archived and has not had its version updated. To complete this transition, we are going to mark all existing build packages as broken, provide a more detailed linter hint, and turn off the migration infrastructure we've been using to help move feedstocks. Any questions or comments can be directed to the GitHub issue on this work.

Removing wheel and setuptools as Dependencies for pip

Starting with Python 3.13, pip will no longer have setuptools and wheel as dependencies by default. While this default made sense at the time conda-forge was started (over 8 years ago!), with the advent of Python packaging build backends (e.g., flit, poetry, hatchling, etc.), this default is no longer correct. Instead, you will need to specify wheel and/or setuptools explicitly in the host section of your recipe if you need them. At first, pip for versions of Python before 3.13 will be unaffected. However, after the completion of the Python 3.13 migration, we will remove these dependencies from pip for all versions of Python. Follow GitHub issue #2252 for more information and updates.

Sunsetting PyPy support

TL;DR: We are planning to remove PyPy from conda-forge feedstock recipes in a few weeks (and thus to stop building new releases of packages for PyPy), unless there is substantial enough interest to justify the continued maintenance effort.