Towards a more secure conda ecosystem

Mamba now implements package signing and verification!

AdrienDelsalle
5 min readNov 16, 2021

Supply chain security is crucial to the overall security of package managers, which are a major attack vector of information systems. Today, we are pleased to announce that mamba has gained the ability to cryptographically verify package and repository signatures, and includes an implementation of the TUF protocol (The Update Framework). This will be key to securing conda channels across a network of online mirrors.

Trusting package managers

When end-users install software using package managers such as apt, yum, mamba, they implicitly trust that the content they are downloading is legitimate.
It’s the job of the package manager to offer sufficient guarantees about the authenticity of the content.

Before the support of package signing, Mamba already offered the following guarantees:

  • the package checksum is validated against the repository index file,
  • checksums of individual files expanded from the tarball are validated.
Status of the mamba/conda security checks before package signing

There is a trust chain between validations:

  • repository index metadata serve to validate the tarballs
  • tarballs metadata serve to validate the files

To completely secure the content provided by the server, the repository index should also be verified.

Implementing the package index validation

Securing a package manager is a multi-faceted problem to tackle:

  • on the one hand, we must naturally secure the connection with the package server
  • on the other hand, the server should provide some verifiable proof of the origin of the artifacts (packages’ index and packages)

For the former, the industry standard is SSL/TLS, which guarantees a private and unaltered communication with the package server (e.g. no man-in-the-middle).

For the latter, an asymmetric cryptographic signature of the payloads should be provided. An industry standard for asymmetric cryptography is OpenPGP but unfortunately it does not fully address our use case. Using a single key is still not enough to prevent from a wide range of attacks and building a solution upon PGP would require engineering a complete solution upon a low-level solution.

Asymmetric cryptography means that the key securing the data is split into two parts: the public key and the private/secret one.
It is well known to provide emails encryption but could also be used to guarantee public data validity by producing a signature over data using a private key.

TUF: The Update Framework

TUF was created to define a robust and audited process around cryptographic techniques for package management and supply chain security. It relies on:

  • defining multiple roles for responsibility separation and minimized key/role risk
  • using a multi-signature trust (using thresholds)
  • bringing explicit and implicit revocation (key rotation and expiration)

Well, that fits our needs perfectly!
It also ensures compatibility with conda that implemented an early TUF specification in conda-content-trust.

TUF has been increasingly adopted:

- TUF is already used by Docker in its content trust implementation called Notary

- there is an ongoing implementation for PyPI (see PEP440 and PEP480)

- a prototype has been tested on rubygems

- compatibility with other OCI security frameworks such as sigstore is ongoing

Implementing TUF

TUF has been implemented in Mamba on both server (mamba, micromamba) and client (quetz) sides to provide the additional security data and perform validation:

What does it change for the end users

You probably want to know how it looks like to use this feature.
Well, it’s totally transparent to the end-user:

A working demo of package signature verification in micromamba

We also aim to give informative messages in case of failure. Here in the test suite:

Heavily tested implementation with informative log messages on failure

Such informative messages are also available from the command line utilities:

micromamba catching an invalid package signature

Looking for security at scale

We aim to provide this enhanced security to every users of the conda ecosystem, which means convince standard sources of packages such as conda-forge to rely this new feature to provide package signatures.

For that, we need to create, test, and refine smooth workflows to encourage adoption from maintainers/packagers that may have to sign their artifacts or let servers automatically produce signatures depending on the security model chosen by a project.
It comes with some technical challenges about offline package signing, reproducible builds or synchronization with online CI pipelines.

We are enthusiastic about this feature and we cannot wait to seeing it used by everyone!

Acknowledgments

The initial development of Mamba by QuantStack was funded by Bloomberg.

Substantial improvements of the micromamba C++ implementation were funded by RoboCorp.

The support of package signing by conda-forge is funded by the Chan Zuckerberg Initiative. You can find a more detailed announcement here.

About the author

My name is Adrien Delsalle and I am a scientific software developer at QuantStack, currently working on the mamba stack.

--

--

No responses yet