In September 2024, the good name of crates.io was invoked and besmirched by a phishing attack that targeted the owners of many popular crates, much as other language ecosystems had been the target of attacks in the preceding couple of weeks.
This talk will go over how this all went down, what we did, and how a worldwide Rust Project <-> Rust Foundation <-> Alpha-Omega collaboration was crucial in its rapid mitigation.
Over the past few years, npm, PyPI, RubyGems, and Maven Central have implemented attestations to provide build provenance: linking a package to its exact source code and build instructions. Some of these ecosystems also implemented publish/release attestations detailing exactly what files a specific version of a package should contain. These attestations are distributed as Sigstore bundles, so we'll start out by going over enough Sigstore to understand how to verify and get the attestation information from these bundles, the APIs to get these attestations for each ecosystem, and discuss the implementation tradeoffs made by each ecosystem, as well as alternatives for non-programming language ecosystems to consider.
Package management systems tackle resolving package dependencies in different ways, which usually involves associating a package a name and version at least. In this talk I am doing a bit of an exploration of the solution space, including how dependencies are resolved in: - a language specific package manager with a lock file (example: cargo https://doc.rust-lang.org/cargo/) - by a typical distribution (example: Debian https://www.debian.org/ ) - by Nix(https://nixos.org/) and Guix(https://guix.gnu.org/) (example: Guix) Then I will reflect on these solutions from the perspective of reproducible builds(https://reproducible-builds.org/).
Package managers are legion. Every language and operating system has its own solution, each with subtly different semantics for dependency resolution. This fragmentation prevents multi-lingual projects expressing precise dependencies across language ecosystems, means external system and hardware dependencies are implicit and unversioned, and obscures security vulnerabilities that lie in the full dependency graph. We present the Package Calculus, a formalism for dependency resolution that unifies the core semantics of diverse package managers. Through a series of formal reductions, we show how real-world package manager features reduce to our core calculus. We define the language Pac to translate between distinct package managers and show we can perform dependency resolution across ecosystems.
While reproducible builds provide a gold standard for artifact integrity, they often treat the build process itself as a black box: either it matches or it doesn't. But in an era of sophisticated supply chain attacks like the XZ backdoor and Shai Hulud, understanding why a build behaves the way it does is just as critical as the final output. To secure the open-source package ecosystem, we needed to look inside this black box. In this talk, we explore how OSS Rebuild instruments the build environment to detect "badness" in real-time. We detail our open-source observability suite, featuring a transparent network proxy for uncovering hidden remote dependencies and an eBPF-based system analyzer for examining build behavior in fine detail.
At FOSDEM 2018, we introduced Package-URL (PURL: https://github.com/package-url/purl-spec), a "mostly" universal URL to identify and locate software packages: https://archive.fosdem.org/2018/schedule/event/purl/
Now, PURL is an international standard to accurately and consistently reference packages across ecosystems, regardless of whether you're working with language-specific managers, OS distributions, or containerized environments.
This talk highlights the journey of PURL, from its first presentation to Ecma standard and planned ISO standard. We'll share how PURLs enable accurate package tracking across ecosystems for vulnerability management (PURL is now part of CVE format), tool interoperability (already adopted by security tools, SCA platforms, and package registries), and compliance and security workflows (generating accurate and actionable SBOMs and VEXs).
Whether you maintain a package manager, build supply chain security tools, query packages or vulnerability databases, or just want better visibility into your polyglot dependencies, you'll learn how this lightweight standard is the essential infrastructure for modern software ecosystems.
Package manifests record source-level dependencies: pandas depends on numpy's code. The story is different for binary dependencies: numpy depends on OpenBLAS's binaries, but package managers can't easily see this. We must map the OSS ecosystem's binary dependency relationships to reliably (1) identify upstream security vulnerabilities and (2) properly credit and financially support maintainers. I propose solving this problem by creating a global index of binary dependencies, using a global linker that tracks binaries' symbols across the entire Open Source ecosystem, combined with auxiliary strategies like statically analysing build recipes. (read more)
Package registries are critical infrastructure used by almost all software. As they scale, package registries become critical points of supply chain security. They also become leveraged points of attack. Most registries operate on dwindling funding from grants, donations, and in-kind resources while facing increased costs across every facet of their operation and development. Something has to change.
The Alpha-Omega project has been raising the alarm, funding security improvements, and exploring a revenue-generating options with the major package registries. This is a hard problem with multiple players and tradeoffs.
This talk will go over the economic models underlying package registries, the security risks and expectations, and look at some of the revenue experiments happening today.
Homebrew released v5.0.0 in November 2025. I'll walk through some of the major changes that landed in that Homebrew version, what expectations we're aiming to improve based on other package managers and things other package managers could learn from Homebrew's approach.