Vagrant Cascadian

Corrupted build environments can deliver compromised cryptographically signed binaries. Several exploits in in critical supply chains have been demonstrated in recent years, proving that this is not just theoretical. The most well secured build environments are still single points of failure when they fail. In 1984, Ken Thompson presented "Reflections on trusting trust" which described an attack on a build toolchain that would be impossible to detect through source code review ... in the decades since, what has been done to actually mitigate these types of attacks? Work in the Reproducible Builds and Bootstrappable Builds communities has been progressing steadily in recent years, and can be used to significantly reduce the risks of "Trusting Trust" and other supply chain attacks, by making it possible to independently review not only the end result, but the entire toolchain used to build a given artifact. This talk will focus on the state of the art from several angles in related Free and Open Source Software projects, what works, current challenges and future plans for building trustworthy toolchains you do not need to trust. https://reproducible-builds.org https://bootstrappable.org

The deep dark blackness of a screen with no backlight, the *sound* of a linux console screaming, laptops running (almost) silent in the night (and day), debian-installer on consoles unseen, welcome surprises landing late in the release cycle... and we must not forget the patches, oh, the terrrible patches! The Pinebook and the Pinebook Pro are two affordable laptops running on the arm64 architecture and are reasonably well supported in Debian Bullseye (for some values of reasonable). What works? What doesn't? Existence is rough for an arm64 laptop. Can two different Pinebooks learn how to share?

Reproducible Builds has been a project within the Debian community since 2013; huge progress has been made in those years, including broadening the community to projects outside of Debian! This talk will mention some historic blockers that "recently" have been solved, worked around, or are actively in progress. It will highlight some recent developments, with an eye to what might happen as Debian embarks upon the "Bookworm" development cycle. Will also point out some exciting milestones reached by projects outside of Debian.

Every computer needs power; much of the Earth is bombarded with power for significant parts of every day! What a useful cooincidence! I'd like to share my experiences moving my office to mostly using solar power, sparks and all! I'll go over the various components, including some of the free software and open hardware projects used in the system, give thanks to community members who helped, and delve into my future schemes for going further off-grid.

During this talk we aim to present current progress on RISC-V architecture in Debian.

Other people: Héctor Orón Martínez

Debian supports a growing number of development boards, mostly running one of Debian's *several* ARM architectures. More boards are released to the wild every month! Sometimes they go feral, abandoned by their manufacturers and supported by volunteer communities. A few of the more recent ones even act suspiciously like laptops. The challenge is that they are all so similarly different. In order to boot Debian on a new, unique board, changes may be required in several packages, some needing coordination upstream, and some packaging changes may be specific to Debian. I'll touch on my workflows, communication channels, observation habits in the wild, and more to inspire your very own adventure!

The goal of this talk is to give the whole Debian community an update on the state of Reproducible Builds in Debian and in the whole free software world as well as to explain what we are aiming for the bullseye release. It’s been 6 years since Reproducible Builds were first introduced to the Debian community at large at DebConf13 in Vaumarcus and much progress has been achieved since, yet the buster release has not really achieved reproducible builds. In this talk we will explain the current status, explain what's missing and hopefully present workable ideas how to improve things for bullseye.

Other people: Holger Levsen Chris Lamb

The Debian riscv64 port has made considerable progress, reaching 80% of packages built at the time of this writing! There is support upstream in linux, glibc, and important core toolchains. There is real-world hardware, and some of it is even in the hands of Debian Developers and other community members. There is support in Debian's qemu packages, for those who don't have hardware. What are blockers and other issues that need help to make this port a properly supported port for Debian? https://wiki.debian.org/RISC-V

GNU Guix is a build system... or is it a package manager... or an operating system? Regardless of what angle you're looking at it with, it brings a twinkle to my eye lately. As a user, maintainer and developer of Debian for the past sixteen years, I've tried various other Linux distributions but few really seem to offer anything significantly different. Other distros have rarely left me feeling the intense curiosity, excitement and maybe even a bit of swooning that you might find with something genuinely new in your life. Some of the exciting features of GNU Guix include functional package management, reproducibile builds by design, trivial container and virtual machine instantiation, transactional upgrades and rollbacks, user specific package installation, and user customized packages. There's even some configuration management built-in. It's a relatively new, small developer community. They understand Free Software in ways very similar to Debian. They're welcoming and make it easy to contribute improvements and fixes large and small. There are some rough spots, and I'll try not to glaze over them despite my enthusiasm. The grumpy old sysadmin within will have some thoughts to share as well. Perhaps most exciting is that love and crushes are not exclusive; Debian and GNU Guix can coexist concurrently on the same running system, it just requires setting some reasonable expectations, and being willing to work some things out now and then. https://www.gnu.org/software/guix/

I'd like to briefly share my experiences with enabling support for several ARM boards in Debian over the last years, and use this to highlight some of the issues encountered. Debian-Installer has had support for various flavors of ARM systems for quite some time, and it's arguably better now than ever... but it's still a very rough road. Some of that is just because ARM is, well, difficult, with individual boards requiring specific configuration. But some of it is in the design of debian-installer... I'd like a broad, open discussion to consider various methods of installing and configuring Debian systems: * Could we make installing from live images a default option? How could that simplify things, and what would we lose? * configuration management systems such as puppet, ansible, chef, propellor, etc. are widely used. How can this be integrated into an installer? * image-based creation tools (e.g. vmdebootstrap) are used to create ARM bootable images for many systems. * with virtualization and containers increasingly common, how does debian-installer fit in?

DescTBA

Other people: Ximin Luo Valerie Young

This workshop will give a hands-on look at the tools that we use at the Reproducible Builds project to analyze build products and make them more reproducible. We'll go through how to use tools like diffoscope and reprotest, and give a few exercises for participants to try out. Then we'll do a brief tour of the Debian reproducibility toolchain, pointing out things like SOURCE_DATE_EPOCH and strip-nondeterminism. Finally, we'll pick out an unreproducible package from Debian unstable and apply what we've learned to try to make it reproducible.

Bring a laptop and a project you want to make reproducible, including its build dependencies. We'll install diffoscope and reprotest during the session, but if you're not on a Debian system then you're welcome to test that these programs work on your OS beforehand and submit bugs if they don't.

Other people: Ximin Luo Valerie Young

The Reproducible Builds project aims to move towards a world where binary software can be independently verified, by anyone, as the product of a given source. Many people interested in Free Software rely on the distributors of binary software to respect their freedoms. Unfortunately, most software incorporates unintended information into the binaries, resulting in differences in the binaries between consecutive builds. If software normally produces different binaries every time it is built, how can we verify and prove that it is the intended result of the source code? By incorportating best practices documented by the Reproducible Builds project into software development projects, an independently verifyable chain from the source code to the binaries can be formed. Once independent verification becomes common practice, people can get back to working with software that respects user freedoms.

Describing the adventures building a build network of armhf machines to run reproducibility tests, using a variety of readily available consumer-grade boards to increase possible reproducibility problems due to hardware differences. I will endeavor to explain how it grew from a few cute machines into a (still a bit slow) monster. Rumours will be spread of other monsters lurking on the horizon. Comes complete with Colored Charts, Documented Side Effects, Power Consumption and Bandwidth figures, and 5-12 volt tentacle (mis)management, and perhaps most importantly, advice on avoiding (or falling prone to) the same fate yourself.