The question is whether an organization should have a designated leader who is on a sustained, public campaign advocating about an unrelated issue that many consider controversial. It really doesn t matter what your view about the controversial issue is; a leader who refuses to stop talking loudly about unrelated issues eventually creates an untenable distraction from the radical activism you re actively trying to advance. The message of universal software freedom is a radical cause; it s basically impossible for one individual to effectively push forward two unrelated controversial agendas at once. In short, the radical message of software freedom became overshadowed by RMS radical views about sexual morality.There is an open letter calling for the removal of the entire Board of the Free Software Foundation in response. I haven t signed the letter because the Free Software Foundation Board s vote to reinstate Stallman was not unanimous, so the call to remove all of them does not make sense to me. I agree with the open letter s call to remove Stallman from other positions of leadership. I hope that this whole situation can be resolved quickly.
Welcome to the February 2020 report from the Reproducible Builds project. One of the original promises of open source software is that distributed peer review and transparency of process results in enhanced end-user security. However, whilst anyone may inspect the source code of free and open source software for malicious flaws, almost all software today is distributed as pre-compiled binaries. This allows nefarious third-parties to compromise systems by injecting malicious code into ostensibly secure software during the various compilation and distribution processes. The motivation behind the reproducible builds effort is to provide the ability to demonstrate these binaries originated from a particular, trusted, source release: if identical results are generated from a given source in all circumstances, reproducible builds provides the means for multiple third-parties to reach a consensus on whether a build was compromised via distributed checksum validation or some other scheme. In this month s report, we cover:
If you are interested in contributing to the project, please visit our Contribute page on our website.
All computation that occurs inside a DetTrace container is a pure function of the initial filesystem state of the container. Reproducible containers can be used for a variety of purposes, including replication for fault-tolerance, reproducible software builds and reproducible data analytics. We use DetTrace to achieve, in an automatic fashion, reproducibility for 12,130 Debian package builds, containing over 800 million lines of code, as well as bioinformatics and machine learning workflows.There was also considerable discussion on our mailing list regarding this research and a presentation based on the paper will occur at the ASPLOS 2020 conference between March 16th 20th in Lausanne, Switzerland. The many virtues of Reproducible Builds were touted as benefits for software compliance in a talk at FOSDEM 2020, debating whether the Careful Inventory of Licensing Bill of Materials Have Impact of FOSS License Compliance which pitted Jeff McAffer and Carol Smith against Bradley Kuhn and Max Sills. (~47 minutes in). Nobuyoshi Nakada updated the canonical implementation of the Ruby programming language a change such that filesystem globs (ie. calls to list the contents of filesystem directories) will henceforth be sorted in ascending order. Without this change, the underlying nondeterministic ordering of the filesystem is exposed to the language which often results in an unreproducible build. Vagrant Cascadian reported on our mailing list regarding a quick reproducible test for the GNU Guix distribution, which resulted in 81.9% of packages registering as reproducible in his installation:
$ guix challenge --verbose --diff=diffoscope ...
2,463 store items were analyzed:
- 2,016 (81.9%) were identical
- 37 (1.5%) differed
- 410 (16.6%) were inconclusive
Jeremiah Orians announced on our mailing list the release of a number of tools related to cross-compilation such as M2-Planet
and mescc-tools-seed
. This project attemps a full bootstrap of a cross-platform compiler for the C programming language (written in C itself) from hex, the ultimate goal being able to demonstrate fully-bootstrapped compiler from hex to the GCC GNU Compiler Collection. This has many implications in and around Ken Thompson s Trusting Trust attack outlined in Thompson s 1983 Turing Award Lecture.
Twitter user @TheYoctoJester posted an executive summary of reproducible builds in the Yocto Project:
Finally, Reddit user tofflos
posted to the /r/Java subreddit asking about how to achieve reproducible builds with Maven and Chris Lamb noticed that the Linux kernel documentation about reproducible builds of it is available on the kernel.org homepages in an attractive HTML format.
debian-installer
package to allow all arguments and options from sources.list
files (such as [check-valid-until=no]
, etc.) in order that we can test the reproducibility of the installer images on the Reproducible Builds own testing infrastructure. (#13)
Thorsten Glaser followed-up to a bug filed against the dpkg-source
component that was originally filed in late 2015 that claims that the build tool does not respect permissions when unpacking tarballs if the umask is set to 0002
.
Matthew Garrett posted to the debian-devel
mailing list on the topic of Producing verifiable initramfs images as part of a wider conversation on being able to trust the entire software stack on our computers.
59 reviews of Debian packages were added, 30 were updated and 42 were removed this month adding to our knowledge about identified issues. Many issue types were noticed and categorised by Chris Lamb, including:
openstack_pkg_tools_python_shebang_and_dependencies
build_path_in_code_generated_by_dgbus_codegen
random_argument_handling_in_javatools_jh_build
fortran_captures_build_path
python-rpm-macros
(do not save time-based .pyc
files for tests)solfege
(filesystem ordering issue sent upstream via email; package is orphaned upstream)DVDStyler
(zip timestamps, submitted upstream)python-pikepdf
(recreate unreproducible .pyc
files)137
to Debian:
sng
image utility appears to return with an exit code of 1 if there are even minor errors in the file. (#950806)classes2.dex
, classes3.dex
from .apk
files extracted by apktool
. (#88)str.format
if we are just returning the string. [ ]Command.VALID_RETURNCODES
. [ ]Vcs-Git
to specify the debian
packaging branch. [ ]
reprotest is our end-user tool to build same source code twice in widely differing environments and then checks the binaries produced by each build for any differences. This month, versions 0.7.13
and 0.7.14
were uploaded to Debian unstable by Holger Levsen after Vagrant Cascadian added support for GNU Guix [ ].
SOURCE_DATE_EPOCH
documentation [ ] and normalised various terms to unreproducible [ ].
Chris Lamb added a Meson.build example [ ] and improved the documentation for the CMake [ ] to the SOURCE_DATE_EPOCH
documentation, replaced anyone can with anyone may as, well, not everyone has the resources, skills, time or funding to actually do what it refers to [ ] and improved the pre-processing for our report generation [ ][ ][ ][ ] etc.
In addition, Holger Levsen updated our news page to improve the list of reports [ ], added an explicit mention of the weekly news time span [ ] and reverted sorting of news entries to have latest on top [ ] and Mattia Rizzolo added Codethink as a non-fiscal sponsor [ ] and lastly Tianon Gravi added a Docker Images link underneath the Debian project on our Projects page [ ].
rdiff-backup
fixed, build date in Python manpageclick-man
fixed, toolchain, build date in Python manpagerpm
report filesystem-order related nondeterminismpython-enaml
report nondeterministic .enamlc
compiler outputk9s
datepython-xcffib
fix a test with a race conditionsnakemake
.designate
.pynwb
.python-oslo.reports
.mate-desktop
(forwarded upstream).javatools
.xavs2
.snapd-glib
(forwarded upstream).openstack-pkg-tools
.python-django
(Always build the documentation in English)python_example
(sort glob
/ readdir
)autogen
.autoconf
.m4
.intltool
.binutils-dev
.yodl-doc
.gdb-source
.automake-1.15
.libtool
.builtin-pho
database of .buildinfo
files. This has resulted in so that we now know that Debian bullseye contains 4,557 source packages for the amd64
architecture without corresponding .buildinfo
files and 25,668 source packages with .buildinfo
files. [ ][ ][ ][ ][ ]buildinfo@
to the root
user. [ ]devscripts
from buster-backports [ ].i386
architecture, to allow the latter to catch up a bit. [ ]arm64
architecture builders [ ]. The usual build node maintenance was performed by Holger Levsen, Mattia Rizzolo [ ][ ] and Vagrant Cascadian.
#reproducible-builds
on irc.oftc.net
.
rb-general@lists.reproducible-builds.org
This month s report was written by Bernhard M. Wiedemann, Chris Lamb and Holger Levsen. It was subsequently reviewed by a bunch of Reproducible Builds folks on IRC and the mailing list.
I agree with Paul on this topic and just signed up as a Supporter of Software Freedom Conservancy myself. Perhaps you should be a supporter too?The GPL is not magic pixie dust. It does not work by itself.-- Bradley Kuhn, in FaiF episode 0x57 As the Debian Website used to imply, public domain and permissively licensed software can lead to the production of more proprietary software as people discover useful software, extend it and or incorporate it into their hardware or software products. Copyleft licenses such as the GNU GPL were created to close off this avenue to the production of proprietary software but such licenses are not enough. With the ongoing adoption of Free Software by individuals and groups, inevitably the community's expectations of license compliance are violated, usually out of ignorance of the way Free Software works, but not always. As Karen and Bradley explained in FaiF episode 0x57, copyleft is nothing if no-one is willing and able to stand up in court to protect it. The reality of today's world is that legal representation is expensive, difficult and time consuming. With gpl-violations.org in hiatus until some time in 2016, the Software Freedom Conservancy (a tax-exempt charity) is the major defender of the Linux project, Debian and other groups against GPL violations. In March the SFC supported a lawsuit by Christoph Hellwig against VMware for refusing to comply with the GPL in relation to their use of parts of the Linux kernel. Since then two of their sponsors pulled corporate funding and conferences blocked or cancelled their talks. As a result they have decided to rely less on corporate funding and more on the broad community of individuals who support Free Software and copyleft. So the SFC has launched a campaign to create a community of folks who stand up for copyleft and the GPL by supporting their work on promoting and supporting copyleft and Free Software. If you support Free Software, like what the SFC do, agree with their compliance principles, are happy about their successes in 2015, work on a project that is an SFC member and or just want to stand up for copyleft, please join Christopher Allan Webber, Carol Smith, Jono Bacon, myself and others in becoming a supporter. For the next week your donation will be matched by an anonymous donor. Please also consider asking your employer to match your donation or become a sponsor of SFC. Don't forget to spread the word about your support for SFC via email, your blog and or social media accounts.
The first step is to choose a copyleft license for your code.
The next step is, when someone fails to follow that copyleft license, it must be enforced
and its a simple fact of our modern society that such type of work
is incredibly expensive to do and incredibly difficult to do.
The GPL is not magic pixie dust. It does not work by itself.-- Bradley Kuhn, in FaiF episode 0x57 As the Debian Website used to imply, public domain and permissively licensed software can lead to the production of more proprietary software as people discover useful software, extend it and or incorporate it into their hardware or software products. Copyleft licenses such as the GNU GPL were created to close off this avenue to the production of proprietary software but such licenses are not enough. With the ongoing adoption of Free Software by individuals and groups, inevitably the community's expectations of license compliance are violated, usually out of ignorance of the way Free Software works, but not always. As Karen and Bradley explained in FaiF episode 0x57, copyleft is nothing if no-one is willing and able to stand up in court to protect it. The reality of today's world is that legal representation is expensive, difficult and time consuming. With gpl-violations.org in hiatus until some time in 2016, the Software Freedom Conservancy (a tax-exempt charity) is the major defender of the Linux project, Debian and other groups against GPL violations. In March the SFC supported a lawsuit by Christoph Hellwig against VMware for refusing to comply with the GPL in relation to their use of parts of the Linux kernel. Since then two of their sponsors pulled corporate funding and conferences blocked or cancelled their talks. As a result they have decided to rely less on corporate funding and more on the broad community of individuals who support Free Software and copyleft. So the SFC has launched a campaign to create a community of folks who stand up for copyleft and the GPL by supporting their work on promoting and supporting copyleft and Free Software. If you support Free Software, like what the SFC do, agree with their compliance principles, are happy about their successes in 2015, work on a project that is an SFC member and or just want to stand up for copyleft, please join Christopher Allan Webber, Carol Smith, Jono Bacon, myself and others in becoming a supporter. For the next week your donation will be matched by an anonymous donor. Please also consider asking your employer to match your donation or become a sponsor of SFC. Don't forget to spread the word about your support for SFC via email, your blog and or social media accounts.
The first step is to choose a copyleft license for your code.
The next step is, when someone fails to follow that copyleft license, it must be enforced
and its a simple fact of our modern society that such type of work
is incredibly expensive to do and incredibly difficult to do.
ghci
and end up with a
small haskell program.
I still maintain plenty of perl code, but even when I do, I'm not thinking
in perl, but traslating from some internal lambda calculus. There's quite a
few new-ish perl features that I have not bothered to learn, and I can feel
some of the trivia that perl encourages be kept in mind slipping gradually
away. Although the evil gotchas remain fresh in my mind!
More importantly, my brain's own evaluation of code has changed; it doesn't
evaluate it imperatively (unless forced to by an appropriate monad), but sees
the gesalt, sees the data flow, and operates lazily and sometimes, I think
in parallel. The closest I can come to explaining the feeling is how
you might feel when thinking about a shell pipeline, rather than a for loop.
Revisiting some of my older haskell code, I could see the perl thinking
that led to it. And rewriting it into pure, type-driven, code that took
advantage of laziness for automatic memoization, I saw, conclusively
that the way I think about code has changed. (See the difference for yourself:
before
after
)
I hear of many people who enjoy learning lots of programming languages, one
after the other. A new one every month, or year.
I suspect this is a fairly shallow learning. I like to dive deep. It took
me probably 6 years to fully explore every depth of perl. And I never saw a
reason to do the same with python or ruby or their ilk; they're too similar
to perl for it to seem worth the bother. Though they have less arcania in
their learning curves and are probably better, there's not enough value to
redo that process. I'm glad haskell came along as a language that is
significantly different enough that it was worth learning. The deep dive
for haskell goes deep indeed. I'm already 5 years in, and have more to
learn now than I ever did before.
I'm glad I didn't get stuck on perl. But I may be stuck on haskell now
instead, for the foreseeable future. I'd sort of like to get really fluent
in javascript, but only as a means to an end -- and haskell to javascript
compilers are getting sufficiently good that I may avoid it.
Other than that, I sense adga and coq beckoning with their promises of proof.
Perhaps one of these years.
Of course if Bradley Kuhn is right and
perl is the new cobol,
I know what I'll be doing come the unix rollover in 2038. ;)
I m writing to announce three big changes for the project. First, OpenHatch is changing its organizational structure to reflect our not-for-profit goals. Second, we ll emphasize our new work beyond the website, building and promoting outreach events that bring new people into the free software community. Finally, I am taking a year to do that full-time as the project lead of OpenHatch in Somerville, MA.This change has been a long-time coming, and it's thanks to so many people who have given advice and feedback along the way. One special shout-out goes to Bradley Kuhn, who told me in March 2010 that OpenHatch should be a non-profit. I hope you'll read more.