Displaying posts by Brett Smith
Debian’s Luke Faraone on Why He’s a Conservancy Supporter
byon December 28, 2016
Luke Faraone is a Debian developer involved in our Debian Copyright Aggregation Project. He’s also a Conservancy Supporter because, in his words, Conservancy is “one of the best defenders of the ideals of free software.” Join Luke as a Conservancy Supporter today to help sustain that important work through 2017.
Report from the 2016 Reproducible Builds Summit
byon December 26, 2016
A couple of weeks ago I was at the Reproducible Builds Summit in Berlin. Over sixty representatives from all kinds of projects came together for three days to share information and ideas, plan solutions, and even squeeze in a little time to hack. It was my first real opportunity to dive into this work. I learned a ton, even enough to chip in a little, and I’m looking forward to working more on reproducible builds from here on out.
When we talk about reproducible builds, what we mean is a build process that produces the exact same binary every time you run it with the exact same inputs (like source code versions and compiler settings). If you’re interested in the details, check out the definition on the Reproducible Builds site—a bunch of folks hammered that out during the Summit.
You might think most build processes would be reproducible most of the time, but often the binaries include small inputs that are hard to reproduce, such as timestamps or build paths. Much of the work toward reproducible builds so far has focused on improving the inputs: removing inputs that aren’t really necessary to the final product, and better recording the ones that are. Once that’s done, most build processes are as reproducible as you’d expect. There’s still more to do there, but there’s enough of a foundation that we can start seeing some benefits from reproducible builds. Many of the discussions at the Summit were about planning those next steps.
Conservancy is really excited to help reproducible builds. Having a clear and trusted link from source code to binary helps the community in many different ways:
- The most obvious is security. When builds are reproducible, everyone can check for themselves that binaries they download actually come from the expected source code. We can demonstrate that unwanted code isn’t being added to distributors’ binaries, either accidentally or maliciously.
- A reproducible build is a documented build. When everyone can see exactly what inputs and build steps generated a binary, everyone can review and comment on that build process. It becomes easier to find binaries with “bad” inputs (like a version of a library with a critical bug) and plan an upgrade process for them.
- Reproducible builds can make license compliance easier for binary distributors. When a free software license requires distributors to provide source code, sometimes it can take a little work for them to figure out exactly what the right source code is. For example, if they have three versions of a development library installed on their build system, how do they know for sure which one went into the binary and should be included in the source code release? Reproducible builds record the answer unambiguously, in a format that can make it simple to put all the source code together.
We’ll reap the most benefits if there’s support at every level of the stack. Debian kickstarted the reproducible builds effort, and at the Summit there was a lot of great discussion about reaching out to other communities. Right now the focus is on other package distributors, so it was great to see representatives from Fedora, openSUSE, F-Droid, and Nix there. But our discussions also recognized the need for outreach to other projects that can play a role in this work, like build tools and other software that generates binaries that get shipped to users (such as filesystems or bytecode compilers). If you’re involved in a project like that, I encourage you to join us on the general mailing list for reproducible builds and introduce yourself. The more people working on this, the merrier!
Many thanks to all the Summit organizers for planning and running a productive working space. I’m already looking forward to the next reproducible builds meeting.
Chromium's Alice Boxhall Explains Why She Supports Conservancy
byon December 20, 2016
Alice Boxhall helps develop Chromium, with a focus on accessibility features. In this video, she talks about some of her favorite Conservancy member projects and why she supports the organization. Do you want free software to be for everyone too? Support Conservancy today!
System improvements at Conservancy
byon December 7, 2016
When I joined Conservancy, we discussed system administration as one of my early responsibilities. (One of many—you might remember the long list of possible functions for my position.) Like any organization our size, there are plenty of improvements to our systems that we wanted to make, but were tough to prioritize against our other responsibilities. Since I joined in August, I’ve kept an eye out for easy opportunities to invest a little time now that will save us effort in the long run. As we start looking back on 2016, I wanted to highlight some of the public-facing improvements that I’ve made as part of this effort, and share a little about the tools and services that make them possible.
I deployed domain keys on our mail servers. Now each outgoing e-mail is signed to demonstrate that it came from an authorized user at Conservancy, and not an impostor. To make a long story short, this means our mail is more likely to land in your inbox, and not in your spam folder.
Thanks to our friends at Let’s Encrypt, all of Conservancy’s web sites are served over HTTPS exclusively. This includes not just our main site here and copyleft.org, but also web front-ends for Mailman and Kallithea. Using HTTPS everywhere helps keeps everyone’s communications with us more secure.
It’s nice that Let’s Encrypt offers free SSL certificates to save us money, but I think what I like even more is that the service saves us time. Using their client software, I’ve mostly automated the process of obtaining and renewing certificates. We don’t have to manually track expiration dates, renew certificates, and install them on our systems anymore. That time is freed up to help our member projects.
I wrote systemd service definitions for several public-facing services that didn’t already have them. Before this, each service was managed by ad hoc scripts, which could fail if something unusual happened. systemd has given us a simple, standard way to manage each service and its runtime environment. We get more service reliability and security for less effort.
I built tools to help automate some of Conservancy’s day-to-day accounting work. Our biggest project here is the payment and reimbursement request system, which is still in development. Behind the scenes, I’ve also written some scripts to help automate smaller tasks like saving and filing receipts from our different accounts.
I upgraded our Kallithea installations to the latest stable version, here and on copyleft.org. This was my first time working with Kallithea, but their documentation made the upgrade process a breeze. We’ve seen improved service stability and uptime with the new version, too. Kudos to the entire Kallithea team for a job well done.
A typical Conservancy office
© Karen Sandler, CC BY-SA
This is all in addition to some usual day-to-day system administration: buying and managing domains, keeping up-to-date with security fixes, and so on. All this work should all make Conservancy’s systems a little nicer for everyone who uses them today, and free up all our time for more important work tomorrow. I love having this opportunity to put some of my technical know-how to good use, so Conservancy can better serve its member projects and the broader FOSS community, and that wouldn’t happen without help from the Supporters who sustain our operations. If you’re already a Supporter, thank you for making this work possible. If not, please join today so we can continue providing necessary infrastructure for important FOSS projects.