Displaying posts tagged Reproducible Builds
Conservancy News Round-up
byon April 17, 2019
Check out these videos, blog posts from member projects, code releases and upcoming events.
- Bradley and Karen during their keynote at FOSDEM, "Can Anyone Live in Full Software Freedom Today? Confessions of Activists Who Try But Fail to Avoid Proprietary Software"
- Microblocks in use (it's in Catalan, but the smiling faces are understandable in any language!)
- Deb keynoted Gitmerge, "The Future of Free Software"
- Godot engine in use! These are from published games and games in development. Check out the Desktop / Console showreel and the Mobile Showreel.
- Bradley gave a talk at SCaLE, "If Open Source Isn't Sustainable, Maybe Software Freedom Is?" that got written up on LWN.
- The State of Godot address by Juan Linietsy
Our Member Projects Have Been Busy
- Outreachy getting ready for another round of interns! You can see the projects that are participating in this summer's program here.
- Lots of Reproducible Builds work in March
- Godot is receiving a MOSS Grant
- Inkscape's SCALE17x Hackfest 2019 launched plans for 1.0 release and more
- Recent Clojurists Together work funded through Conservancy
Some recent code releases:
What's coming up?
Catch up with staff:
- Deb speaks about governance at Open Source 101 on Thursday
- Swing by Bellingham to say hi to Bradley at our Linuxfest Northwest booth later this month
- Deb speaks about diversity at Red Hat Summit in May
Many of our projects have events coming up:
- Selenium Conf in Tokyo
- Ninth Annual RacketCon, plus Bradley will be there.
- Samba XP -- Karen is keynoting!
- One week blocks workshop for public school teachers, "Physical Computing with the BBC micro:bit"
- Teaching Open Source planning a summer POSSE meeting
Bonus news! GPLv3 code made the famous black hole picture possible. Congrats to Doctor Katie Bouman and her team!
Do You Know Where Your Code Came From? If You Don't Have Source You Aren't Secure
byon April 4, 2019
I sometimes work for Conservancy assisting in their compliance work. Conservancy follows the Principles of Community-Oriented GPL Enforcement, enforcement principles published by Conservancy and the Free Software Foundation. As the process goes, Conservancy receives complaints from users about products whose sellers aren't meeting their GPL license obligations and Conservancy may investigate. Many of these complaints are for hardware devices with embedded code. The complaints are almost always are that there is free software on the device but that the source code is not available.
Conservancy will purchase the complained-of device and independently determine whether or not there is a GPL violation, including requesting the source code. This is where the rubber meets the road, particularly for embedded devices. In phone calls with the hardware manufacturer, the manufacturer will almost always say that they don't have the code on hand and need to get it from their factory or vendor.
When I hear this, I want to gasp out loud. I'm not gasping because I find the non-compliance so surprising (it's not), but that a manufacturer is shipping a device that it has not independently confirmed was manufactured as spec'd. A manufacturer designs a device, say a home security camera, and has outsourced the manufacturing to a factory. The factory may have subcontracted with someone else for the component, who may have contracted with yet another company for the firmware. Yet despite the length and opaqueness of the supply chain, the companies we buy from are not doing any due dligence on the products they are selling. When a company tells me they don't have the source code available, I add them to the list in my head of brands I will not buy.
This is not a trivial oversight. Doorbell cameras, security cameras, televisions, baby monitors, and home audio equipment have a view into the most intimate parts of our lives, and yet the manufacturers are not doing everything they can to ensure that our private lives stay private. The component manufacturer, the firmware manufacturer, the factory, or all of them, could be adding malicious code to the device and the vendor has not taken the simplest step of verifying the software on the device does only what it is supposed to do and nothing more.
And it's an easy problem to solve. All the company needs is the source code. There is now even a free software project, Reproducible Builds, that can be used to verify that the source code provided compiles to exactly the object code found on the device.
And guess what? By performing the far more critical task of ensuring that a manufactured device has not been compromised, the source code compliance problem has been solved too.
Death, taxes and free software at DebConf this year
byon August 14, 2018
In case you missed it, our most excellent Executive Director, Karen Sandler and FSF Campaigns Manager, Molly de Blanc presented together at DebConf in Taiwan earlier this month on what *really* constitutes a software freedom issue. Turns out that lots of things are affected by the absence or presence of software freedom including; many serious topics like depression treatments, automated devices in our homes, public transportation, domestic violence and government data. There were also some very funny moments, but I won't spoil the video for you.
This year is the first time this critical event has taken place in Asia. Over 300 free software enthusiasts attended talks, squashed bugs and discussed critical issues like reproducible builds, what contributing is like around the world and how to increase diversity in free software projects. Both Karen and Molly have been to DebConf multiple times and highly recommend this event.
You can catch Karen next in New York in early October where she'll be keynoting PyGotham.
Molly's next public appearance is at the end of the month in Vancouver where she'll be participating in a panel that will be discussing ways to use metrics to help create common understanding around diversity and inclusion goals.
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.