Recently there was a supply chain attack on the xz package -- CVE 2024-3094 (https://www.openwall.com/lists/oss-security/2024/03/29/4) from a trusted maintainer, intended to backdoor ssh in Debian and Redhat based distros. It was a long process, involving a maintainer making changes to the xz distribution over more than a year.

In short, a new(ish) trusted maintainer made tarball releases that included attack code that was not in the git repo, that used binary test artifacts to affect the build process. The original maintainer brought on this new maintainer because he was overwhelmed.

There are a few factors in the ability to release and obscure this attack:

1. a single active maintainer
2. release artifacts that were not traceable to the git repository
3. opaque binary test data on the build system
4. a complicated build system

Looking at these items, we're in pretty good shape for three of them.

• We have a core team of 8 members. Pull requests and activity on the main and versioned branches are watched.
• our test data is python scripts, though there are some vendored javascripts and images.
• Python artifacts are nowhere near as complicated to build as system libraries.

The release artifacts are one place where we can definitely improve the transparency -- as they're currently built on a developer system.

• Python Package
• Docker Images
• Debian .deb package

Ideally, there should be a reproducible build and upload path using CI (likely Github Actions) where the code that is executed to build and upload is entirely specified by the contents of the repository. This protects against both an untrustworthy maintainer and a compromised developer machine. It has a nice side benefit of making the actual release easier to perform.

PyPi and Docker both have relatively straightforward methods to run GH Actions and upload. I'm less sure about uploads to packaging.ckan.org.