Matthew Garrett

Debian has infrastructure to ensure that users obtain unmodified versions of packages, but once they’ve hit disk that chain of trust vanishes. debsums allows admins to verify that the packages hash to a value stored in the dpkg package database, but in the face of active attack that provides no guarantees - an attacker can simply modify the stored hashes to match their modified binaries. The easiest approach is to use a read-only filesystem, but what if there were a stronger way to provide these guarantees without making system updates more difficult?

IMA, the Integrity Measurement Architecture, provides an in-kernel mechanism for verifying that binaries match associated signatures stored in extended attributes alongside the executable. These signatures can be generated at any point in the packaging process, from package build to archive processing. And with a simple addition of functionality to dpkg (already in progress), these signatures can be written out at package install time, allowing users to configure systems such that distribution binaries won’t run if they’ve been tampered with.

What needs to be done to make this possible in Debian? Is it worth the effort? And how do we do this in a way that avoids systems being locked down in ways that limit user freedom? This presentation will attempt to answer all of these questions.

It’s been 20 years since the Debian Free Software Guidelines were published as part of the Social Contract. In that time, free software has spread further than we could ever have imagined - everything from cars to watches are now dependent upon free software for at least part of their functionality. But in that time we’ve also seen huge shifts in how software is used and how it’s written, with people both becoming more dependent on remote services and on income related to free software development work. People now depend on free software to keep them safe from abusive governments, partners or parents, but have we become any better at designing and writing systems that ensure that their safety is preserved? And even though we’ve pioneered open discussion of diversity issues, why is free software still overwhelmingly produced by white men?

This talk is intended to challenge the status quo, to encourage us to revisit some of our preconceptions about what’s important about free software and what’s incidental, and to start a discussion on what the next 20 years of free software development and community growth should look like.