set "CONDA_SUBDIR=win-arm64"
conda create -n newenv python
conda activate newenv

This gives you a minimal python environment. You can play around with this untested python binary and provide feedback.

Here's some thoughts on the development so far:

On conda-forge CI, we are cross-compiling builds for win-arm64 from win-64 platform. Therefore these are untested so far. Microsoft has generously donated VMs for these packages to be tested, but they are not setup yet as we need more support in conda/conda-build.

When bootstrapping a new platform, we first cross-compile from another platform until we get to a point where we have conda, conda-build, and build-tools like ninja. This lets us run conda-build natively on the new platform and we do not need cross-compilation anymore. On osx-arm64, we kept on doing cross-compilation as we did not have any CI for osx-arm64 natively.

For win-arm64 we do have VMs donated by Microsoft, but we are not at the point where we have conda, conda-build and build-tools like ninja built yet. That requires more support for cross-compilation on windows in conda-forge as most of our infrastructure is focused on UNIX-like platforms. For example: cross-python package is a series of hacks that are hung together by a thread to make cross-compiling work since python does not support cross-compiling by default. It'd be quite a lot of work to make it work on windows.

Some build systems like autotools do work, but it was a challenge to get things like CC_FOR_BUILD working since usually Visual Studio only keeps one VS build system active at one time. This was fixed by calculating paths manually to set CC_FOR_BUILD. Another issue was that some build systems don't really like spaces in the path of the compiler in CC_FOR_BUILD. This was fixed by creating virtual drive to avoid spaces.

Some packages do require MinGW gcc builds, but upstream support for Windows on Arm64 platform is still not complete.

We have a migration for windows-arm64 platform in the conda-forge status page. Currently we only try to build conda,conda-build,mamba,rattler-build and pixi as given in the explicit list.

Looking at the graph, there are nodes that are clearly unneeded for the packages given in the list. Help is welcome to debug the bot on trimming down the graph here so we can focus on the packages actually needed for getting the build tools out.

The Numbers​

Let's look at how Python 3.14 compares to previous releases at the 100-day milestone:

Binary Packages Only​

Python 3.14 leads with 1,932 binary packages, beating the previous record holder (Python 3.11) by nearly 100 packages.

Including noarch and ABI3 Packages​

When we count packages that transitioned to noarch: python or ABI3 (stable ABI) builds since the Python 3.10 migration, the numbers are even more impressive:

Why Python 3.14 Adoption Was So Fast​

Several factors contributed to this record-breaking adoption:

1. Better Utilization of Release Candidates​

The migration started much earlier than previous versions. Around 40 days before the final release, the migration really kicked into gear. By the time Python 3.14 was officially released, over 1,000 packages were already built and waiting.

2. Improved Tooling and Automation​

The regro-cf-autotick-bot has become increasingly effective at opening "Rebuild for Python 3.14" PRs on feedstocks where all dependencies are ready. This automation significantly reduces the burden on maintainers.

3. Growing Use of noarch and ABI3​

More packages have transitioned to noarch: python or ABI3 builds, which work across Python versions without rebuilding. This means that once Python 3.14 was released, these packages were immediately available without any additional work.

Using Python 3.14​

If you're looking to try Python 3.14 on conda-forge, you can create a new environment using:

conda create -n py314 python=3.14
conda activate py314

If a package is missing, you can lookup on the Status page of the Python 3.14 what is blocking it.

Data for this analysis was generated using conda-forge repodata from January 15, 2026. The analysis tracks packages that have python_abi dependencies for specific Python versions, as well as packages that transitioned from version-specific builds to noarch or ABI3 builds.

The @conda-forge/r team currently maintains 4.4K+ feedstocks for the two latest minor R releases, and will continue to do so. At the time of writing, these are R 4.5 and R 4.4. Older versions are still available but won't receive any updates or rebuilds. When R 4.6 is released, 4.5 will still be maintained and 4.4 will stop receiving updates, and so on.

If you have any questions, please do not hesitate to open an issue in the r feedstock or in our Zulip chat instance.

Today, we announce the availability of gcc, g++ compilers on macos. You can install them using:

conda install gcc gxx

Currently we support only gcc 15 and will not support gcc 14 or previous versions.

The main difference between these packages and a vanilla gcc installation or the installation from Homebew is that they use libomp as the default OpenMP library and libc++ as the default standard C++ library. This difference makes binaries compiled with gcc, g++ compatible with binaries compiled with clang, clang++.

Another interesting consequence of the infrastructure work done to enable this is that this enables cross compilation of C/C++ sources using gcc, g++ to cross-compile macOS binaries from Linux (previously only clang supported this) and also cross-compile windows binaries from macOS using the GCC/MinGW compilers.

To use them in conda-build recipes, you can use

requirements:
  build:
    - {{ compiler('gcc') }}   # [osx]
    - {{ compiler('gxx') }}   # [osx]
    - {{ stdlib('c') }}

You can also do

c_compiler:             # [osx]
  - gcc                 # [osx]
c_compiler_version:     # [osx]
  - 15                  # [osx]
cxx_compiler:           # [osx]
  - gxx                 # [osx]
cxx_compiler_version:   # [osx]
  - 15                  # [osx]

in conda_build_config.yaml and continue to use the well-established {{ compiler("c") }} and {{ compiler("cxx") }} macros in the recipe; be aware that you're then responsible for updating the version roughly once per year (to keep pace with the rest of conda-forge).

When you are using gcc locally, similar to clang, we make some guesses about where the macOS SDK is located. This might fail sometimes and setting the environment variable SDKROOT to the root of the macOS SDK should make gcc look in that folder.

We also add by default -L $CONDA_PREFIX/lib -Wl,-rpath,$CONDA_PREFIX/lib when linkingfor local builds with the conda-gcc-specs package that is installed by deault with gcc package. If you want to avoid that you can install the gcc-no-conda-specs package alongside gcc.

You can create a new environment by using:

conda create -n py314 python=3.14 -c conda-forge

At the time of writing, the Python 3.14 migration is 77% progressed. This means that:

• 1273 (41%) packages that needed a rebuild were built for Python 3.14
• 1115 (36%) have an open PR to get rebuilt for Python 3.14
• 704 (23%) packages are still waiting for a dependency to be rebuilt.

What is already usable?​

While most binary packages needed to be rebuilt for Python 3.14, we did not need to rebuild packages that are abi3-compatible. Here, you can use the builds that were done with previous Python versions. Similarly, all pure Python packages (i.e. the ones we call noarch: python in the conda world) didn't need to be rebuilt and can be used directly.

Still, as the statistics above show, not all packages are available for Python 3.14 yet. The most prominent here include pytorch, numba, and cytoolz. For the latter two, we need to wait for them to provide new releases that make them compatible with 3.14. In the case of PyTorch, we either need to wait for the new 2.10.0 release or may be able to backport changes to the 2.9.0 release. You can track the progress on the upstream side in pytorch#156856 and on the conda-forge side in pytorch-cpu-feedstock#420. For numba, we expect the necessary changes to land in 0.63. As a there is already a beta available, we will wait here for the final release and won't backport any changes. For other packages, similar approaches will be taken. You can track the progress for each of them if you click on the respective link on the status page.

If you face any issue with the Python package itself, please report that on the python-feedstock. For problems with individual packages, please do so on the respective conda-forge/<package>-feedstock repository.

How was conda-forge able to provide release day availability?​

Like we already did in the releases for Python 3.13 and Python 3.12, we have started building packages for Python 3.14 once the release candidate was available. As ABI-stability is guaranteed between release candidates, these packages are also usable with the final Python release. Thus, we were able to start building packages for this release already on August 20. Unfortunately, as part of this release process, the magic number stored in Python bytecode (.pyc) was bumped in RC2 and RC3. This means that the bytecode will be regenerated on the first run for packages built with a version earlier than RC3. As the impact of this has been minor, we did not rebuild the respective packages and expect that through package updates, this will quickly become unnoticeable.

Note that the current migration only includes the "default" flavour of Python. We have not yet started building packages for the freethreading version. Once work on making the migrator more selective has progressed, we will start to build packages.

Details​

Back in April 2024, we started a conversation with OSTIF that would result in a partnership with 7ASecurity. The security audit took part from February to May, where 7ASecurity reported all their findings. The conda-forge/core team assessed the reports and submitted the necessary fixes to our infrastructure and involved tooling, from which we highlight:

• Three incidents in conda/conda-build.
• Two incidents in conda-forge/conda-forge-webservices.
• Two incidents in conda-forge/conda-smithy.
• One incident in conda/constructor.
• One incident in conda-forge/conda-forge-ci-setup.
• One incident in conda-forge/infrastructure.

7ASecurity also contributed a detailed threat model and a supply chain security analysis. CVEs, Github Advisories and related contributions are available in the final report.

We are incredibly grateful for the support offered by OSTIF and STA, and we are delighted to have worked with 7ASecurity during all these months! You can read their blog posts at:

• conda-forge Audit Complete!, ostif.org.
• Conda-Forge Security Audit by 7ASecurity, 7asecurity.com.

Final notes​

We want to take this opportunity to remind our users that we do not recommend that you use conda-forge in environments with sensitive information. conda-forge's software is built by our users and the core dev team cannot verify or guarantee that this software is not malicious or has not been tampered with.

Our best defense against security incidents in conda-forge is you! Our feedstock maintainers are in the best position to notice incidents and issues. Please responsibly report anything you find to us by following our security policy.

Join us in this Zulip thread and share how you got involved with conda-forge, how this community has helped you, or just to show appreciation to the thousands of volunteers that make this effort possible!

To many more years! 🎉

One billion downloads per month​

While there are too many important milestones to name across those 10 years, just a few days ago, we passed 1,000,000,000 monthly downloads across all packages for the first time ever. 🥳

In total, we have served almost 27 billion downloads, and that's not even counting all those that happen behind various institutional caching layers. This tells us that the fruits of this community collaboration are having an enormous impact. If you'd like to share where conda-forge has saved you hours of work, streamlined your processes, or made some ideas possible at all, please also jump in on the Zulip link above!

Why today?​

This date can be found as the creation date of the conda-forge Github organization:

$ curl "https://api.github.com/orgs/conda-forge"
{
  "login": "conda-forge",
  "id": 11897326,
  "node_id": "MDEyOk9yZ2FuaXphdGlvbjExODk3MzI2",
  "url": "https://api.github.com/orgs/conda-forge",
  "repos_url": "https://api.github.com/orgs/conda-forge/repos",
  "events_url": "https://api.github.com/orgs/conda-forge/events",
  "hooks_url": "https://api.github.com/orgs/conda-forge/hooks",
  "issues_url": "https://api.github.com/orgs/conda-forge/issues",
  "members_url": "https://api.github.com/orgs/conda-forge/members{/member}",
  "public_members_url": "https://api.github.com/orgs/conda-forge/public_members{/member}",
  "avatar_url": "https://avatars.githubusercontent.com/u/11897326?v=4",
  "description": "A community led collection of recipes, build infrastructure and distributions for the conda package manager.",
  "name": "conda-forge",
  "company": null,
  "blog": "https://conda-forge.org",
  "location": null,
  "email": null,
  "twitter_username": "condaforge",
  "is_verified": false,
  "has_organization_projects": false,
  "has_repository_projects": true,
  "public_repos": 25378,
  "public_gists": 0,
  "followers": 1103,
  "following": 0,
  "html_url": "https://github.com/conda-forge",
  "created_at": "2015-04-11T07:37:06Z", // <----------------- See here!
  "updated_at": "2025-03-13T11:32:03Z",
  "archived_at": null,
  "type": "Organization"
}

And the anaconda.org production channel:

$ curl -s "https://api.anaconda.org/user/conda-forge" | jq
{
  "company": "",
  "created_at": "2015-04-11 10:15:08.727000+00:00",
  "description": "A community-led collection of recipes, build infrastructure, and distributions for the conda package manager.",
  "location": "",
  "login": "conda-forge",
  "name": "conda-forge",
  "url": "",
  "user_type": "org"
}

If you want to learn more about the early history of conda-forge, check this draft PR, where we're in the process of crystallizing the collective memories of many current and prior contributors into a cohesive account of the most important events and milestones.

During this process, OSTIF and their contractor uncovered misconfigured infrastructure which exposed the anaconda.org token for the conda-forge channel to all feedstock maintainers. The token was exposed from on or about 2025-02-10 through 2025-04-01. See our GitHub Security Advisory for more details.

We have requested a CVE from GitHub and will amend this announcement once it is issued. Our response to this incident is detailed below, but TL;DR, as best as can reasonably be determined, no packages were compromised during this time.

Thank you for using conda-forge, please contact us if you have further questions, and please follow our security process for responsible reporting of vulnerabilities.

Finally, as a reminder, conda-forge packages are built by strangers on the internet (our wonderful feedstock maintainers!) and are not suitable for use cases that require secure software provenance.

Response timeline​

The timeline and details of our response to this security incident are as follows:

• 2025-04-01 13:35 UTC: OSTIF and their contractor notified conda-forge of the leaked token.
• 2025-04-01 14:00 UTC: The conda-forge/core team acknowledged receipt of the report and started conducting the investigation.
• 2025-04-01 14:15 UTC: The conda-forge/core team disabled the token and stopped uploads to anaconda.org.
• 2025-04-01 14:20 UTC: We posted an incident to our status page reporting that uploads were temporarily paused.
• 2025-04-01 15:19 UTC: We audited all uploads to the conda-forge channel, looking for uploads that bypassed our upload staging process. We did not find any. This check is not completely robust, but it does indicate that nothing was obviously compromised.
• 2025-04-01 15:53 UTC: We decided to delay disclosure by one day to 2025-04-02 in order to not generate confusion (2025-04-01 is April Fools' Day in some countries when people commonly engage in practical jokes).
• 2025-04-01 21:39 UTC: We deployed a fix to our infrastructure.
• 2025-04-01 22:20 UTC: We then deployed a new token to our infrastructure and restarted uploads.
• 2025-04-01 23:02 UTC: The status page incident was marked as resolved.
• 2025-04-02: We published this announcement and the advisory. GitHub produced CVE-2025-31484 for us based on our security advisory.

rattler-build and the v1 spec​

The v1 recipe format has a number of benefits:

• It always parses as valid YAML which makes it much easier to modify it with the bot infrastructure of conda-forge. While meta.yaml looks like YAML, it can contain Jinja logic that is incompatible with the YAML specification, which significantly complicates parsing and automated manipulation. Additionally, the new recipe format has a published JSON schema which means that the editing experience in VS Code is greatly improved with contextual help.
• The new recipe format enables much faster builds due to design decisions that eliminate the need for recursive parsing.
• Some features of conda-build, such as multiple outputs, had a lot of implicit behavior. We are fixing that in the v1 recipe.

conda-forge uses rattler-build as its default build tool for the v1 recipe format. rattler-build currently has some significant benefits:

• rattler-build is built on top of rattler, a modern re-implementation of the conda standards in Rust, enabling extremely fast recipe builds.
• The log output of rattler-build is greatly improved, always showing the user what the final files in the package are and the final metadata.

You can read much more about the v1 recipe format in the https://rattler.build docs and the two CEPs CEP-0013 and CEP-0014. With the new format comes also a new build tool called rattler-build which is developed by prefix.dev. It is a reimplementation of conda-build in Rust, on top of the rattler libraries.

A simple v1 recipe looks something like the following:

context:
  # we define named variables in the context instead of `{$ set ... %}` directives
  version: "23.0.0"

package:
  name: "boltons"
  # note that we use "GitHub" inspired syntax to access context / Jinja variables
  version: ${{ version }}

source:
  url: https://github.com/mahmoud/boltons/archive/refs/tags/${{ version }}.tar.gz
  sha256: 9b2998cd9525ed472079c7dd90fbd216a887202e8729d5969d4f33878f0ff668

build:
  noarch: python
  script:
    - python -m pip install . --no-deps -vv

requirements:
  host:
    - python
    - pip
    - setuptools
  run:
    - pip

about:
  license: BSD-3-Clause
  license_file: LICENSE

How to use the v1 recipe format on conda-forge​

If you are adding a new recipe on staged-recipes, then it's easy: just submit a recipe.yaml file instead of a meta.yaml file. In case you already maintain a feedstock, then the conversion can be semi-automated with a tool created by Hadrien Mary called feedrattler. The tool will take care of the basic conversions steps and uses conda-recipe-manager by Anaconda / Schuyler Martin under the hood to parse the recipe and convert it to the new format.

# One liner with Pixi
pixi exec feedrattler my-awesome-package-feedstock gh_user
# With conda or mamba (as $CONDA)
$CONDA create -n feedrattler feedrattler
$CONDA activate feedrattler
feedrattler my-awesome-package-feedstock gh_user

To do the conversion by hand, you need to do the following things:

• In the feedstock's conda-forge.yml, add conda_build_tool: rattler-build
• Remove the meta.yaml file and add a recipe.yaml file following the v1 spec
• Rerender the feedstock using conda-smithy rerender
• Push your changes to your fork and open a PR to see the CI build your package

Transition plans​

For the foreseeable future, conda-forge is going to support both formats, v1 and v0. We envision a gradual transition over at least one year to the new spec. There are a couple of places where the v1 spec also needs to finalize / stabilize. One notable place is the cache-based multi-output feature, where CEP discussions are ongoing. This stabilization in the format should happen within Q1 of 2025.

Since the beginning of 2025, the bot has gained more capabilities for the v1 format, such as automatically bumping versions (the "autotick-bot"). There are a number of other migrators and mini-migrators that need to be fully ported to the v1 spec before we can claim 100% compatibility with the conda-forge infrastructure.

As of today, over 700 of the 25000 recipes on conda-forge have been converted.

For now, the recommendation on staged-recipes is: if it's a simple noarch: python recipe, it should probably be a v1 recipe. The same goes for Rust or Go projects that have a simple structure.

Where to learn more​

There are very helpful docs located at https://rattler.build that explain the differences of the new recipe format pretty well. You are also very welcome to chat with us on the conda-forge Zulip, or chat with the rattler-build developers on their Discord.

You can also read more about rattler-build and the v1 format in the following blog posts:

• https://prefix.dev/blog/rattler_build_on_conda_forge
• https://prefix.dev/blog/the_love_of_building_conda_packages
• https://prefix.dev/blog/rattler_build_a_new_parser

conda-forge packages have always been batteries included. When a package has some build options turned off by default to reduce dependencies, we have enabled these options to give the most functionality and performance to our users.

In the Python world, some packages are written in C/C++/Cython to get the most performance out of a package. However these packages sometimes have a reference implementation written in Python. The Python reference implementation is a good way to check the C/C++/Cython code against a much simpler python implementation and is also useful for platforms like PyPy where the C/C++/Cython implementation can be slower than the Python reference implementation due to the emulation of the Python C/C++ API by PyPy. For example for the Cython package, setting the CYTHON_NO_COMPILE environment variable when building the Cython wheel itself, it will use the Python reference implementation. The only way to figure out if a package has a Python reference implementation is to look at the library's source code to see if extensions are optional.

To support platforms like PyPy, some packages build wheels with compiled extensions for the platforms that are known to be more performant with the compiled extension, but also provide a universal pure Python wheel for the other platforms. This also provides a way for new Python versions and variants like the free-threading Python build to use these packages by the early adopters of these Python versions.

On conda-forge we usually have compiled Python packages, but provide no reference implementation. This means early adopters of new Python versions need to wait for the conda-forge bot managed by @conda-forge/bot team to start the migration and rebuild the packages. For example the free-threading Python 3.13 build is still paused as conda-forge has decided to focus on the default (GIL enabled) Python 3.13 build first while upstream packages work on supporting free-threading. Another issue is that some packages have cyclic dependencies at build or test time and this requires some manual handling.

We have been adding noarch: python variants for some feedstocks so that the compiled extension has higher priority and the pure Python extension has lower priority, which makes the conda solver use the noarch: python variant if no suitable compiled variant is available. One issue is that the linter might not like selectors on noarch recipes. We added an option

linter:
  skip:
    - lint_noarch_selectors

to conda-forge.yml that will make the linter skip this warning/error.

We build the two variants using a recipe/conda_build_config.yaml with the contents,

use_noarch:
- true       # [linux64]
- false

Then in recipe/meta.yaml we make the following changes

build:
  noarch: python           # [use_noarch]
  track_features:          # [use_noarch]
    - pyyaml_no_compile    # [use_noarch]

requirements:
  build:
    - {{ compiler('c') }}
    - {{ stdlib("c") }}
  host:
    - python                        # [not use_noarch]
    - python {{ python_min }}.*     # [use_noarch]
    - setuptools
    - pip
  run:
    - python                        # [not use_noarch]
    - python >={{ python_min }}.*   # [use_noarch]
    - yaml

test:
  requires:
    - pip
    - python {{ python_min }}.*     # [use_noarch]

Finally in the build script, we use the env variable use_noarch to set an option to force the extension to be pure python. In the case of pyyaml, we can force that by setting the env variable PYYAML_NO_LIBYAML. A recipe/build.sh might look like,

if [[ "$use_noarch" == "true" ]]; then
  export PYYAML_NO_LIBYAML=1
fi
$PYTHON -m pip install .

We list some PRs here as a reference for conda-forge maintainers who want to experiment.

• pyyaml
• coverage
• cython
• aiohttp

conda create -n py313 python=3.13 -c conda-forge

This will create a new environment with Python 3.13 with the global interpreter lock (GIL) enabled. A migration is underway that builds Python extensions like those included in numpy and scipy as conda packages. The migration is 55% complete at the time of writing.

New in this Python release is the python-freethreading build which removes the GIL and enables free threading. To install a freethreading build, you can do:

conda create -n py313 python=3.13 python-freethreading -c conda-forge

Analogous to this package we also have a metapackage to explicitly install the GIL variant:

conda create -n py313 python=3.13 python-gil -c conda-forge

Note that there are no conda packages for freethreading Python extensions yet and we hope to start a migration for freethreading extensions in the coming weeks. Till then, you should use pip to install a package unless the package and all its Python dependencies are noarch in which case conda installing the package will work.

Another new feature of this release is the experimental just-in-time (JIT) compiler included in the Python interpreter. This interpreter is experimental, but can be used by setting the environment variable

export PYTHON_JIT=1

You can also use the convenience conda package to set this environment variable for you:

conda install python-jit

Note that the JIT is available only for x86_64 builds of python in conda.

You can also use debug builds of Python on conda-forge for non-Windows systems by using the conda-forge/label/python_debug label.

Any issues with python conda package itself can be reported at python-feedstock.

Acknowledgements​

Thanks to Uwe Korn (@xhochy) for getting us started and for Jonathan Helmus (@jjhelmus) for guidance. Also thanks to conda-forge/core and all the maintainers of feedstocks in conda-forge for the hard work in getting the Python 3.13 migration underway.

To the best of our knowledge, conda-forge's artifacts for xz are not affected.

Our response​

We immediately checked which xz artifacts had been published in our channel:

• Our latest build for xz (recipe source available in the xz-feedstock) is for version 5.2.9 and was uploaded on 2022-12-08. See artifacts in anaconda.org.
• The backdoored versions of xz belong to the 5.6.x series.

We are monitoring the situation develop and will update this announcement accordingly if needed.

Closing thoughts​

We, the conda-forge core dev team, want to thank everyone for their patience and support as we have responded to the various security incidents and bugs detailed above. It goes without saying that the public nature of conda-forge's infrastructure carries risks. On the other hand, by being public, anyone can look and verify our artifact builds. Security for conda-forge is about reducing risk, and we will continue to do our best.

As a reminder, we do not recommend that you use conda-forge in environments with sensitive information. conda-forge's software is built by our users and the core dev team cannot verify or guarantee that this software is not malicious or has not been tampered with.

Our best defense against security incidents in conda-forge is you! Our feedstock maintainers are in the best position to notice incidents and issues. Please responsibly report anything you find to us at condaforge+security@gmail.com or using the process described in our Security policy.

The issue could, under specific conditions, unintentionally delete files from your system during the uninstallation process. Anaconda has published more details in the related blogpost about the security fix for the miniconda and Anaconda Distribution Windows installers as well.

conda-forge is committed to fix the miniforge and mambaforge installers equally to reduce the possible impact on conda-forge users and has worked with Anaconda to mitigate the issue.

• As such, we are strongly recommending all users of miniforge and mambaforge to update immediately to the latest versions of miniforge and mambaforge. Please download them from the miniforge repository's main page or the release specific page.
• For older versions, we are providing a security patch for already installed miniforge and mambaforge installations. You can download these from release specific page as well, under the names Miniforge3-uninstaller-patch-Windows-x86_64.exe and Mambaforge-uninstaller-patch-Windows-x86_64.exe.

In order for this flaw to be triggered, a specific combination of factors must align, including uninstallation permissions, system access, usage of Windows, and an existing installation of miniforge or mambaforge.

We have produced a list of all possibly compromised artifacts.

If you use conda-forge in very sensitive environments (which we do not recommend!), please remove these artifacts from your system.

To date, we know of no compromised artifacts in conda-forge.

API tokens for the main conda-forge channel were never exposed and remain secure to our knowledge.

Our Response​

We took the following steps to respond to this incident.

• We immediately started a token rotation of all of our feedstock tokens and our staging area upload tokens as precautionary measures. This token rotation hit a few bugs, but was completed as of January 13, 2023.
• We produced a census of all packages uploaded between December 19, 2022 and January 13, 2023. This data is available for download as a JSON file.
• We examined all the artifacts built during this time period for the malicious files listed by CicleCI. We did not find any of those files in our artifacts.
• As detailed below, we have begun retooling our system for feedstock tokens to be more robust and enable greater flexibility in our response to incidents like this.
• We have begun systematically invalidating old tokens, decommissioning old bots, and minimizing permissions of our current tokens in order to further enhance conda-forge's security.

Rotating all of our tokens was taken as a precautionary measure. Unfortunately, during this token rotation, one of our bots encountered a bug which resulted in us losing the tokens for a very large fraction of feedstocks. This situation resulted in an extended outage that lasted about five days and was resolved on January 13, 2023, when the full token rotation was completed.

What did we learn?​

We learned a few things about our system for feedstock tokens and general maintenance of our CI service integrations. We probably should have known them already, but here we are.

• We used the same feedstock token across multiple CI services. This limited our ability to immediately invalidate tokens associated with a single CI service and exposed all services if any single service had an incident.
• Our token system only allowed one valid token per feedstock. This limitation means that we cannot recover from partially failed token resets/rotations and are subject to race conditions during the reset/rotation process that can cause failed package uploads.
• We need to be more proactive about cleaning up deprecated/removed CI services. The use of CircleCI in conda-forge has been deprecated for quite a while. Had we taken the time, and had the foresight, to remove all of our secrets from CircleCI when it was deprecated, we could have avoided the security incident all together.

We have begun retooling our system for feedstock tokens in order to fix the issues identified above and allow us to have more flexibility in responding to security incidents. We have also started the process of decommissioning several of our old CI services. These changes will take time to implement. You can follow the progress on our various public issue trackers.

Closing Thoughts & What can you do?​

We, the conda-forge core dev team, want to thank everyone for their patience and support as we have responded to the various security incidents and bugs detailed above. It goes without saying that the public nature of conda-forge's infrastructure carries risks. On the other hand, by being public, anyone can look and verify our artifact builds. Security for conda-forge is about reducing risk, and we will continue to do our best.

As a reminder, we do not recommend that you use conda-forge in environments with sensitive information. conda-forge's software is built by our users and the core dev team cannot verify or guarantee that this software is not malicious or has not been tampered with.

Our best defense against security incidents in conda-forge is you! Our feedstock maintainers are in the best position to notice incidents and issues. Please responsibly report anything you find to us at condaforge+security@gmail.com.

The first issue I started working on when the internship began was Better anchoring of announcements(#1611). The goal of this issue was to fix the anchor for each year and also specific announcements in the Announcements section so as to provide better navigation of the Announcements page. This was also the time when I was feeling quite overwhelmed and anxious since I was just starting and was unsure if I would be able to give my best. But thanks to my awesome mentors @Katherine and @Matt, who have always been so helpful, I was able to have a good start. We solved this issue in two parts. The first part was to add anchors to each year which is solved with Improve anchors for each year in the Announcements section. (#1766), and the second part was adding anchors to each announcement and fixing the RSS feed.

The part of the documentation I focused on after completing the first issue was Maintainers' Documentation. Many open issues needed to be taken care of to make the Maintainers' documentation more useful and accessible for new maintainers. The open tickets that we have worked on are:

1. Document extras feedstock-name (#1769) and Explain how to become a maintainer (#1331). Closed with add extra section-recipe maintainer and feedstock-name (#1772).

   As we started with improving the Maintainer documentation, these were the issues we picked first to work on. The first issue was documenting how maintainers can use the "feedstock-name" directive for naming feedstocks differently than their package names in staged recipes. The second issue was documenting how one should become a package maintainer.

2. Add more steps in Improve the documentation section (#1651). Closed with Update "Improve the documentation" section with more steps (#1776).

   In this issue we added some additional steps for people who would like to start contributing to conda-forge, especially to documentation.

3. Add more information about Grayskull in the documentation itself (#1655). Closed with #1777.

   The documentation on Grayskull in docs lacked the answers to questions like what exactly Grayskull is and how one should use Grayskull to generate a recipe. With this issue, we added more documentation on Grayskull for users.

4. Clarify feedstock LICENSE.txt (#803). Closed with Add Feedstock repository structure section (#1786).

   The docs for contributing and maintaining conda recipes discuss when and how to distribute the license for a particular package. The auto-generated feedstock repositories also include a license in the root, which is different from the related package license. With this issue, we added documentation on the differences between those two licenses and briefly explained the feedstock repository structure.

5. DOC: New maintainer (#1117). Closed with Add "How regro-cf-autotick-bot create version update PR?" section. (#1788).

   With this issue we improved docs for the new maintainers and the working of the bot. A "How does regro-cf-autotick-bot create automatic version updates?" section was added to the docs, which explains the whole process of creating an automated version update PRs by bot.

6. Add Perl package hints to documentation (#1536). Working on this #1790.

   With this issue we added ​​packaging instructions for Perl packages with different build systems in the documentation.

7. DOC: Update documentation about tokens (#1532). Closed with #1793.

   Feedstocks have stopped storing encrypted tokens to upload packages, but outdated information on tokens was still present in the documentation. With this issue we removed the outdated information and also added a new section "How to update your feedstock token?" for maintainers.

8. Improve the documentation on arch_rebuild.txt (#1668). Closed with #1794.

   With this issue we improved the documentation on arch_rebuild.txt and how maintainers can add a feedstock to arch-rebuild.txt if it requires rebuilding with different architectures/platforms (such as ppc64le or aarch64).

9. Document migrators (#1355), Update migration docs (#862), and document migrators (#737) . Closed with Documenting Migrators and Migrations. (#1801).

   With these, we added more documentation on migrations and migrators, which would help maintainers find answers to questions like - What is a migrator/migration, and what does it do? When can (and why would) they should reject a migration PR? And so on.

10. Add a section in docs on security aspects of conda-forge (#1808). Closed with #1812.

    Currently, information regarding the security considerations of conda-forge builds is scattered throughout the documentation, and therefore it is hard to find and read. With this issue, we will put all the information together in one place, which will help maintainers and users to know more about how conda-forge secures its packages and infrastructure.

I met some wonderful people during the internship who helped me with all my questions and doubts that I had. The experience during the internship also helped me get better opportunities after completing the Outreachy internship. I have learned so many things during the internship that it would make a long list if I were to write all of those. But the most important things I learned are:

• The importance of documentation and how to write good documentation.
• The best practices to follow while writing documentation.
• More about conda-forge and packaging tools.

And above all, Outreachy helped me feel more confident about my skills and overcome the imposter syndrome I had before. Thanks again to my awesome mentors and the kind people of the conda-forge community! :)

Recently we've been able to add GPU-enabled TensorFlow builds to conda-forge! This was quite a journey, with multiple contributors trying different ways to convince the Bazel-based build system of TensorFlow to build CUDA-enabled packages. But we managed, and the pull request got merged.

We now have a configuration in place that creates CUDA-enabled TensorFlow builds for all conda-forge supported configurations (CUDA 10.2, 11.0, 11.1, and 11.2+). Building out the CUDA packages requires beefy machines -- on a 32 core machine it still takes around 3 hours to build a single package. Our build matrix now includes 12 CUDA-enabled packages & 3 CPU packages (because we need separate packages per Python version). As one can imagine, this isn't easily possible on an average "home computer".

For this purpose, we have written an Ansible playbook that lets us boot up cloud machines which then build the feedstock (using the build-locally.py script). Thanks to the generous support of OVH we were able to boot multiple 32-core virtual machines simultaneously to build the different TensorFlow variants.

We have open-sourced the Ansible playbook in GitHub and we're working towards making it (more) generally useful for other long-running builds!

With the TensorFlow builds in place, conda-forge now has CUDA-enabled builds for PyTorch and Tensorflow, the two most popular deep learning libraries.

We are still missing Windows builds for TensorFlow (CPU & CUDA, unfortunately) and would love the community to help us out with that. There is an open PR, but it probably needs some poking in Bazel to get it to pass: conda-forge/tensorflow-feedstock#111.

We hope that these new GPU builds will enable many more packages to be added to the conda-forge channel! We are already looking forward to the 2.6.2 and 2.7 releases of TensorFlow and to adding Windows support in the future. We hope you enjoy this work.

Installation​

You can now select between GPU enabled (default) and CPU packages using the tensorflow-gpu and tensorflow-cpu packages. Just run

mamba install tensorflow-gpu -c conda-forge
# OR
conda install tensorflow-gpu -c conda-forge

When installing the tensorflow package, the package resolution will now default to the GPU-enabled builds of tensorflow if the local machine has a GPU (these builds can be identified by "cuda" at the beginning of the version number). Note that GPU-enabled packages can also work on CPU-only machines, but one would need to override the enviornment variable CONDA_OVERRIDE_CUDA like below. This could be handy if you are in a situation where your current node (e.g. login node) on an HPC does not have GPUs, but the compute nodes with GPUs do not have internet access.

CONDA_OVERRIDE_CUDA="11.2" conda install tensorflow cudatoolkit>=11.2 -c conda-forge
# OR
CONDA_OVERRIDE_CUDA="11.2" mamba install tensorflow cudatoolkit>=11.2 -c conda-forge

Note that you should select the cudatoolkit version most appropraite for your GPU; currently, we have "10.2", "11.0", "11.1", and "11.2" builds available where the the "11.2" builds are compatible with all cudatoolkits>=11.2. You could also force a specific version of cudatoolkit by specifying it like above. Moreover, you could ensure you get a sepcific build of tensorflow by appending the package name like tensorflow==2.7.0=cuda* or tensorflow==2.7.0=cuda112*. If you want the slimmer "cpu-only" package, then you can install tensorflow-cpu directly or equivalently tensorflow==2.7.0=cpu*. At the time of writing (February 2022), on a machine without a GPU, one would always get the -cpu variant unless overriden like above. This decision has been made to allow greater accessibility for users with limited bandwidth and resources.

Thanks to​

• Mark Harfouche (@hmaarrfk) & Ista Zahn (@izahn) for their initial work on the TensorFlow GPU builds, and all other TensorFlow maintainers. Uwe Korn (@xhochy) for his work on the Bazel scripts & TensorFlow -- and all the other maintainers of the TensorFlow feedstock!
• NVIDIA for pushing cudatoolkit and cudnn on conda-forge that makes this possible
• OVH for their generous sponsoring of large build machines that we could use to build the recipes
• Bloomberg for their sponsorship of QuantStack's involvement with conda-forge
• Andreas Trawoger (@atrawog) for the Ansible scripts that this is based on
• Thorsten Beier (@derthorsten) and Adrien Delsalle (@adriendelsalle) for their contributions to the recipe

Our Response​

We took the following steps to respond to this incident.

1. We immediately turned off all builds on Travis CI by suspending the Travis CI GitHub App.
2. We immediately disclosed the bug to Travis CI through our contacts there.
3. Once Travis CI indicated to us that they were ready, we rotated all feedstock tokens and later our anaconda.org token for our staging channel. The anaconda.org token for the main conda-forge channel was never disclosed in this incident. Further, only ~70 feedstocks had their tokens exposed in this incident.
4. We examined our artifacts and marked as broken any artifacts that were uploaded from PRs. We think we found everything, but we are not completely sure. Our criterion for marking things broken was more generous than it needed to be.
5. We issued PRs to rebuild any broken artifacts via our bots.
6. We put in changes to conda-smithy to help prevent inadvertent uploads of artifacts from PRs in the future.

Closing Thoughts & What can you do?​

I (MRB) want to recognize the quick work of our core dev team in handling this incident. It goes without saying that the public nature of conda-forge's infrastructure carries risks. On the other hand, by being public, anyone can look and verify our artifact builds. Security for conda-forge is about reducing risk and we will continue to do our best.

Our best defense against security incidents in conda-forge is you! Our feedstock maintainers are in the best position to notice incidents and issues. Please responsibly report anything you find to us at condaforge+security@gmail.com.

As the introduction for Grayskull reads; "The main goal of this project is to generate concise recipes for conda-forge." In this tutorial we learn how to contribute a Python package to the conda-forge channel using Grayskull to generate the recipe.

Let us get started.

1. Install grayskull using conda through the conda-forge channel:

   $ conda install -c conda-forge grayskull
   

2. Fork and clone the conda-forge staged-recipes repository from GitHub.

3. Checkout a new branch from the master branch.

4. Through CLI, cd inside the 'staged-recipes/recipes' directory.

5. Call grayskull and pass the pypi repository, followed by the name of the package you want to contribute to conda-forge. For example: grayskull pypi abc

   Or you could use grayskull pypi abc --strict-conda-forge to remove some selectors which are not necessary for conda-forge and adapt recipes to fit better in the conda-forge ecosystem.

   Grayskull will create a folder with the same name as the package (in this case: 'abc') in the 'recipes' folder of the 'staged-recipes' directory. This folder will contain the meta.yaml file and also the license file if the package includes a license in the PyPI distribution.

6. Go through the generated meta.yaml file. For simpler packages, the generated recipes are nearly perfect, but for some packages you might need to make certain tweaks.

7. Commit and push the changes. git add recipe/abc/meta.yaml git commit -m "add a commit message" git push

8. Create a PR.

9. Once the CI is passing, post a comment saying: This is ready for review @conda-forge-admin, please ping team

Once the PR gets merged, your package will be available on the conda-forge channel. Tada! It's that easy.

Participant Application Process:​

First, please review the Outreachy Eligibility and Application Information page to learn more about eligibility for Outreachy.

Steps for applicants to conda-forge:​

1. Confirm your eligibility on the Outreachy site
2. Look at the Conda-forge projects available on the Outreachy site, consider your options, and if you have questions, communicate with the project mentors.
3. Begin by contributing to the project by looking at our issues page. As you make contributions, record them on the Outreachy site.
4. Once you have made a few contributions, begin to write your application. Ask the mentors to review the application before you submit it.

Participant Expectations​

You will be working full-time on your project for three months. You will meet with your mentor(s) frequently and participate in the open-source development process -- writing code, reviewing code, testing, and so on. You will be expected to write a blog entry each week.

Project Contribution Information​

As part of the application process, all applicants must make at least one contribution to be accepted as an intern for this project. Only applicants who make a contribution will be eligible to be accepted as interns.

While we don't have one we highly recommend the first-time contributor to be a conda user and/or submit a package to conda-forge via staged-recipes. That will ensure the contributor understands the value of what we do and means that they are willing to participate in our community.

Applicants can contribute to this project through the project repository or contribution page. The project uses an issue tracker to keep information about bugs to fix, project features to implement, documentation to write, and more. Applicants can look for newcomer-friendly issues to use for their first contributions by looking for the following issue tags in the project issue tracker: Docs, Good first issue

We here at conda-forge have a large number of potential Outreachy endeavors around documentation, maintenance, and development. These tasks are high-impact, affecting the entire conda-forge ecosystem. They also cover multiple systems including databases, conda's CDN provider, continuous integration providers, and user interactions on GitHub.

How do I work with the conda-forge community?​

Outreachy applicants can get help and feedback from both mentors and community members. Community members discuss their contributions in a public chat. Outreachy applicants can often learn from those discussions.

Please introduce yourself on the public project chat:

• Gitter - Follow this link to join this project's public chat.
• Outreachy mentors will often be in the community public chat. The project mentor's usernames are: @viniciusdc.

Here are some ready-to-go ways you can get started contributing on your own.

• Find an open issue to tackle or report a bug to the issue tracker;
• Don't be afraid to communicate: Ask if you can help write a new feature or help Automate project setups;
• Improving current tooling and testing features is always welcome.

As this project main goal is enhancing our current documentation, here are some preliminary tasks that you can inspect to get ideas:

• Write and improve the project's documentation;
• Link to duplicate issues, and suggest new issue labels, to keep things organized;
• Go through open issues and suggest closing old ones;
• Ask clarifying questions on recently opened issues to move the discussion forward;
• We also have issues regarding the main functionalities of our bot, in particular the autotick bot. You could find some new information or ideas for your contributing proposals.

Good starter tasks:​

Small Starter Tasks​

As with most organizations, there are lots of small issues that need addressing usually related to problems such as bad recipes, old documentation and others. These will make good first issues to resolve or "update". This will also be an opportunity to familiarise yourself with the conda-forge environment.

Larger tasks​

There are a few potential larger tasks that can come after a few smaller task contributions. These are included into our three main bases:

• Users: In this case, some good starter tasks are mainly checking the actual contents of conda-forge users documentations, and ideas to better express its contents.
• Maintainers: There are a bunch of missed topics in this area, some information have to be updated or rewritten for better understanding. Writing a complete guide containing the actual steps and standard model for a package recipe, building process (just a simple discussion) and how conda-forge bot recognize defective licenses, recipes and packages in general is highly welcomed. For further understanding of the general system check this link.
  • It can be funny to say, but lots of helpful ideas and bug solutions appear on our gitter channel, so if you have time to write guides about them... it's also an incredible task.
• And organization Our environment is changing everyday, because of that a lot of information is lost in this process or even worse, not documented at all! which leads to some difficulties inserting new members to develop and further enhance the current process.
  • The related work on this matter is highly welcomed and for a better grasp of the situation you can start with this guideline and read some of our posts in our blog
  • Revitalizing ideas/projects for the conda-forge blog are definitely welcomed;
  • Currently we have some interesting projects going on inside our ecosystem, which in return will need good documentation... Some of the projects conda-forge is affiliated include the auto-tick bot, symbol-exporter and a new service we are eager to start developing is the distributed-bot. All of them have a great coverage of subjects and lots of people to help and give advice about the service structure and functionalities.

Improving the documentation​

You can help improve the documentation as it is version-controlled in the conda-forge.github.io repository on GitHub. The source text is stored there in the src/subdirectory and is formatted using Python's reStructuredText system.

You can propose quick edits directly through the GitHub website, if you have an account there --- for instance, this link will take you directly to a web-based editor for this section page in our docs. In general, the file corresponding to each page in the GitHub browser has a little pencil icon in its top-right that lets you open it up for editing.

The more manual process is as follows:

• Fork the conda-forge.github.io repository to your own GitHub user account.
• Clone that fork onto your computer.
• Check out a new branch deriving from master to do your work.
• Make and commit your changes.
• Submit a pull request to the main repository proposing your changes.

Happy editing!

Strong Growth​

The conda-forge community has grown immensely this year. Here are some numbers to help give you an idea of the scale of our growth.

• The community has added 3,751 new, unique conda packages this year, along with a corresponding number of new feedstocks.
• For the majority of 2020, the conda-forge channel on anaconda.org exceeded 100 million downloads per month.
• In July of 2020, the conda-forge channel passed 2 billion total, all-time downloads.
• We've grown our core developer community, adding seven new members to the conda-forge Core team and at least two members to the staged-recipes team.
• We now have over 2,500 recipe maintainers in the conda-forge GitHub organization.

Big New Features​

We've also shipped a ton of big updates to our core infrastructure this year. These updates include

• PyPy support: We added support for PyPy 3.6 and now supply one of the biggest stacks of PyPy-enabled packages in the PyPy ecosystem.
• automerge: We now support the automatic merging of PRs on feedstocks using the automerge label or through an opt-in setting in the conda-forge.yml.
• R 4.0 migration: This migration was the first one to use our automerge infrastructure at scale. With it, we completed a complete rebuild/upgrade of the R ecosystem in about a week.
• Python updates: We deprecated Python 2.7, completed the Python 3.8 migration, and got about 75% of the way through the Python 3.9 migration.
• compiler upgrades: We upgraded our compiler infrastructure to GCC 9 and clang 11.
• CentOS 7 and CentOS 6 EOL: We shipped an option to enable our compilers to use the CentOS 7 sysroot in preparation for the CentOS 6 EOL. We hope to complete the move to CentOS 7 early next year.
• miniforge: We built our own standalone, miniconda-like installers. These support a broad range of platforms, including osx-arm64 and linux-aarch64.
• standalone Windows stack: We fully decoupled our Windows recipes from the defaults channel by rebuilding the msys2 recipes.
• Apple silicon support: We added support for Apple silicon with our osx-arm64 platform. This platform is our first one to use a fully cross-compiled infrastructure.
• CUDA support: We added support for building CUDA packages on windows and added CUDA 11.0 support.

We know that this year has been extremely difficult for so many of our community members and that the fantastic success of conda-forge would not have been possible without the active participation and support of our community. Thank you everyone so much for the work you put into conda-forge this year, making it the wonderful, community-led resource that it is.

We wish everyone a happy, healthy, and peaceful new year!