Skip to main content

How to fix a security vulnerability

It may happen that a security vulnerability is discovered in a version of a published package that is still in use. In case of urgent issues, it may be desirable not to wait for a new software release, but instead apply a patch in the feedstock instead. It may also be a good idea to prevent the vulnerable version from being installed.

Preventing the vulnerable version from being installed​

In order to quickly prevent a specific version from being downloaded, the relevant packages can be marked broken. This requires marking all the artifacts built for the vulnerable version as broken, following the guide to removing broken packages.

Once the packages are marked broken, they are no longer available from the conda-forge channel. Users will no longer be able to install them by default. However, it will still be possible to download them directly via URL in lockfiles, manually from anaconda.org packages, or by requesting the broken label.

Pushing a new package version​

If a new version of the software has been published with the fix for the vulnerability, the feedstock can be updated to build the new version as usual. Users can upgrade to the new version as soon as it is built, provided that there is no dependency pinning involved.

If the package participates in the global pinning, it may either be necessary to update package pins or patch the currently pinned version instead. In the latter case, maintaining several versions of the package may be necessary.

There may also be packages that explicitly pin to a specific dependency version. In these cases, it may also be necessary to patch the respective dependency versions, or work towards enabling support for the newer version of the dependency in them.

Creating a patched version​

If no new version is available or contains breaking changes (alongside the vulnerability fix), it may be desirable to apply a patch in the feedstock instead. It may especially be necessary if the vulnerability affects multiple old versions, so downgrading to an earlier version cannot be a feasible solution.

First, download or create an appropriate patch file. For GitHub repositories, .patch can be appended to the commit or pull request URL to obtain a patch file. For example, to obtain a patch from rencode commit 572ff74, you can run the following command:

wget -O recipe/patches/cve-2021-40839.patch \
  https://github.com/aresch/rencode/commit/572ff74586d9b1daab904c6f7f7009ce0143bb75.patch

For local git repositories, git format-patch -1 {commit_id} can be used instead. diff -duR {dir1} {dir2} can be used to construct a patch from the differences between two directory trees.

The patch file needs to be placed in the recipe directory (often under a patches/ subdirectory) then, and added to the patches: list in the recipe. The build number also needs to be bumped. For example:

recipe/meta.yaml or recipe/recipe.yaml
source:
  ...
  # the paths are relative to the recipe/ directory
  patches:
    # https://github.com/aresch/rencode/commit/572ff74586d9b1daab904c6f7f7009ce0143bb75
    - patches/cve-2021-40839.patch

build:
  # incremented from 0
  number: 1
  ...

Once the new builds are published, they will be picked as soon as users upgrade. If you also decide to mark the vulnerable packages as broken, make sure you don't accidentally include the most recent, already-fixed builds (pay attention to the build number).