Welcome to the July 2022 report from the Reproducible Builds project! In our reports we attempt to outline the most relevant things that have been going on in the past month. As a brief introduction, the reproducible builds effort is concerned with ensuring no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised. As ever, if you are interested in contributing to the project, please visit our Contribute page on our website.

Reproducible Builds summit 2022 Despite several delays, we are pleased to announce that registration is open for our in-person summit this year: November 1st November 3rd
The event will happen in Venice (Italy). We intend to pick a venue reachable via the train station and an international airport. However, the precise venue will depend on the number of attendees. Please see the announcement email for information about how to register.

Is reproducibility practical? Ludovic Court s published an informative blog post this month asking the important question: Is reproducibility practical?:

Our attention was recently caught by a nice slide deck on the methods and tools for reproducible research in the R programming language. Among those, the talk mentions Guix, stating that it is for professional, sensitive applications that require ultimate reproducibility , which is probably a bit overkill for Reproducible Research . While we were flattered to see Guix suggested as good tool for reproducibility, the very notion that there s a kind of reproducibility that is ultimate and, essentially, impractical, is something that left us wondering: What kind of reproducibility do scientists need, if not the ultimate kind? Is reproducibility practical at all, or is it more of a horizon?

The post goes on to outlines the concept of reproducibility, situating examples within the context of the GNU Guix operating system.

diffoscope diffoscope is our in-depth and content-aware diff utility. Not only can it locate and diagnose reproducibility issues, it can provide human-readable diffs from many kinds of binary formats. This month, Chris Lamb prepared and uploaded versions 218, 219 and 220 to Debian, as well as made the following changes:

• New features:
  • Support Haskell 9.x series files. [ ]
• Bug fixes:
  • Fix a regression introduced in version 207 where diffoscope would crash if one directory contained a directory that wasn t in the other. Thanks to Alderico Gallo for the testcase. [ ]
  • Don t traceback if we encounter an invalid Unicode character in Haskell versioning headers. [ ]
• Output improvements:
  • Improve output of Markdown and reStructuredText to use code blocks with highlighting. [ ]
• Codebase improvements:
  • Space out a file a little. [ ]
  • Update various copyright years. [ ]

Mailing list On our mailing list this month:

• Roland Clobus posted his Eleventh status update about reproducible [Debian] live-build ISO images, noting amongst many other things! that all major desktops build reproducibly with bullseye, bookworm and sid.
• Santiago Torres-Arias announced a Call for Papers (CfP) for a new SCORED conference, an academic workshop around software supply chain security . As Santiago highlights, this new conference invites reviewers from industry, open source, governement and academia to review the papers [and] I think that this is super important to tackle the supply chain security task .

Upstream patches The Reproducible Builds project attempts to fix as many currently-unreproducible packages as possible. This month, however, we submitted the following patches:

• Bernhard M. Wiedemann
  • openSUSE monthly report
  • acarsdec (embeds CPU info with march=native)
  • casacore (embeds CPU info with march=native)
  • kubernetes (uses random name of temporary directory)
  • setuptools/python-brotlicffi (toolchain, filesys/readdir)
  • sysstat (FTBFS in single CPU mode)
  • sundials (FTBFS in single CPU mode)
  • nim (FTBFS in single CPU mode)
  • doxygen/libzypp (toolchain readdir)
  • python-pyquil (build failure)
  • openssl-1_0_0 (build failure)
  • jsonrpc-glib (FTBFS in single CPU mode)
  • slurm (Link-Time Optimisation and .tar issues)
  • wasi-libc (sort the output from find)
• Chris Lamb:
  • #1015245 filed against libshumate.
  • #1015246 filed against zeal.
  • #1016186 filed against gappa.
• Philip Rinn:
  • #1014877 filed against cxref.
• Vagrant Cascadian:
  • #1014426 filed against cldump.
  • #1014428 filed against xmacro.
  • #1014559 filed against libloki.
  • #1014560 filed against ygl.
  • #1014561 filed against clp.
  • #1014564 filed against tvtime.
  • #1014789 filed against rdiff-backup-fs.

Reprotest reprotest is the Reproducible Builds project s end-user tool to build the same source code twice in widely and deliberate different environments, and checking whether the binaries produced by the builds have any differences. This month, the following changes were made:

• Holger Levsen:
  • Uploaded version 0.7.21 to Debian unstable as well as mark 0.7.22 development in the repository [ ].
  • Make diffoscope dependency unversioned as the required version is met even in Debian buster. [ ]
  • Revert an accidentally committed hunk. [ ]
• Mattia Rizzolo:
  • Apply a patch from Nick Rosbrook to not force the tests to run only against Python 3.9. [ ]
  • Run the tests through pybuild in order to run them against all supported Python 3.x versions. [ ]
  • Fix a deprecation warning in the setup.cfg file. [ ]
  • Close a new Debian bug. [ ]

Reproducible builds website A number of changes were made to the Reproducible Builds website and documentation this month, including:

• Arnout Engelen:
  • Add a link to recent May Contain Hackers 2022 conference talk slides. [ ]
• Chris Lamb:
  • Correct some grammar. [ ]
• Holger Levsen:
  • Add talk from FOSDEM 2015 presented by Holger and Lunar. [ ]
  • Show date of presentations if we have them. [ ][ ]
  • Add my presentation from DebConf22 [ ] and from Debian Reunion Hamburg 2022 [ ].
  • Add dhole to the speakers of the DebConf15 talk. [ ]
  • Add raboof s talk Reproducible Builds for Trustworthy Binaries from May Contain Hackers. [ ]
  • Drop some Debian-related suggested ideas which are not really relevant anymore. [ ]
  • Add a link to list of packages with patches ready to be NMUed. [ ]
• Mattia Rizzolo:
  • Add information about our upcoming event in Venice. [ ][ ][ ][ ]

Testing framework The Reproducible Builds project runs a significant testing framework at tests.reproducible-builds.org, to check packages and other artifacts for reproducibility. This month, Holger Levsen made the following changes:

• Debian-related changes:
  • Create graphs displaying existing .buildinfo files per each Debian suite/arch. [ ][ ]
  • Fix a typo in the Debian dashboard. [ ][ ]
  • Fix some issues in the pkg-r package set definition. [ ][ ][ ]
  • Improve the builtin-pho HTML output. [ ][ ][ ][ ]
  • Temporarily disable all live builds as our snapshot mirror is offline. [ ]
• Automated node health checks:
  • Detect dpkg failures. [ ]
  • Detect files with bad UNIX permissions. [ ]
  • Relax a regular expression in order to detect Debian Live image build failures. [ ]
• Misc changes:
  • Test that FreeBSD virtual machine has been updated to version 13.1. [ ]
  • Add a reminder about powercycling the armhf-architecture mst0X node. [ ]
  • Fix a number of typos. [ ][ ]
  • Update documentation. [ ][ ]
  • Fix Munin monitoring configuration for some nodes. [ ]
  • Fix the static IP address for a node. [ ]

In addition, Vagrant Cascadian updated host keys for the cbxi4pro0 and wbq0 nodes [ ] and, finally, node maintenance was also performed by Mattia Rizzolo [ ] and Holger Levsen [ ][ ][ ].

Contact As ever, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.
• Twitter: @ReproBuilds
• Mailing list: rb-general@lists.reproducible-builds.org

What happened in the Reproducible Builds effort between Sunday November 27 and Saturday December 3 2016: Reproducible work in other projects

• Ducible is a new tool to make Windows builds reproducible.
• Manish Goregaokar wrote about Reflections on Rusting Trust.

Media coverage, etc.

• There was a Reproducible Builds hackathon in Boston with contributions from Dafydd, Valerie, Clint, Harlen, Anders, Robbie and Ben. (See the "Bugs filed" section below for the results).
• Distrowatch mentioned Webconverger's reproducible status.

Bugs filed Chris Lamb:

• #846588 filed against minicoredumper.
• #846647 filed against tinyeartrainer.
• #846842 filed against nethogs.

Clint Adams:

• #846892 filed against pkg-mozilla-archive-keyring.

Dafydd Harries:

• #846893 filed against flac.

Daniel Shahaf:

• #846832 filed against patat.

Reiner Herrmann:

• #845991 filed against pathogen.

Valerie R Young:

• #846878 filed against taggrepper.
• #846890 filed against ipsvd.
• #846891 filed against integrit.

Reviews of unreproducible packages 15 package reviews have been added, 4 have been updated and 26 have been removed in this week, adding to our knowledge about identified issues. 2 issue types have been added:

• nondeterminstic_ordering_in_casacore_tables
• nondeterminstic_output_from_uglifyjs

Weekly QA work During our reproducibility testing, some FTBFS bugs have been detected and reported by:

• Chris Lamb (5)
• Lucas Nussbaum (8)
• Santiago Vila (1)

diffoscope development

• diffoscope 63 was uploaded to unstable by Ximin Luo:
  • Greatly improve speed for large archives by fixing O(n^2) complexity for archive member lookup.
  • add +/- buttons to toggle visibility of parts of the diff
  • Output coloured diff using colordiff(1) via --text-color= never,auto,always

Is is available now in Debian, Archlinux and on PyPI. strip-nondeterminism development

• At the Reproducible Builds Boston hackathon Anders Kaseorg filed #846895 treat .par files as Zip archives, including a patch which was merged into master.

reprotest development

• reprotest 0.4 was uploaded to unstable by Ximin Luo:
  • disorderfs variation: don't query the testbed, put that in the script instead
  • Add a build_path_same variation to run builds from the same path
  • Fix auto-presets in the case of a file in the current directory
  • Fix d/control so reprotesting reprotest in sbuild works (6 reproductions)
  • Add util-linux to Recommends since we use it to vary some things

tests.reproducible-builds.org

• Holger made a couple of changes:
  • Group all "done" and all "open" usertagged bugs together in the bugs graphs and move the "done bugs" from the bottom of these gaps.
  • Update list of packages installed on .debian.org machines.
  • Made the maintenance jobs run every 2h instead of 3h.
  • Various bug fixes and minor improvements.
• After thorough review by Mattia, some patches by Valerie were merged in preparation of the switch from sqlite to Postgresql, most notably a conversion to the sqlalchemy expression language.
• Holger gave a talk at Profitbricks about how Debian is using 168 cores, 503 GB RAM and 5 TB storage to make jenkins.debian.net and tests.reproducible-builds.org run. Many thanks to Profitbricks for supporting jenkins.debian.net since August 2012!
• Holger created a Jenkins job to build reprotest from git master branch.
• Finally, the Jenkins Naginator plugin was installed to retry git cloning in case of Alioth/network failures, this will benefit all jobs using Git on jenkins.debian.net.

Misc. This week's edition was written by Chris Lamb, Valerie Young, Vagrant Cascadian, Holger Levsen and reviewed by a bunch of Reproducible Builds folks on IRC.

Abstract I introduce TrieHash an algorithm for constructing perfect hash functions from tries. The generated hash functions are pure C code, minimal, order-preserving and outperform existing alternatives. Together with the generated header files,they can also be used as a generic string to enumeration mapper (enums are created by the tool). Introduction APT (and dpkg) spend a lot of time in parsing various files, especially Packages files. APT currently uses a function called AlphaHash which hashes the last 8 bytes of a word in a case-insensitive manner to hash fields in those files (dpkg just compares strings in an array of structs). There is one obvious drawback to using a normal hash function: When we want to access the data in the hash table, we have to hash the key again, causing us to hash every accessed key at least twice. It turned out that this affects something like 5 to 10% of the cache generation performance. Enter perfect hash functions: A perfect hash function matches a set of words to constant values without collisions. You can thus just use the index to index into your hash table directly, and do not have to hash again (if you generate the function at compile time and store key constants) or handle collision resolution. As #debian-apt people know, I happened to play a bit around with tries this week before guillem suggested perfect hashing. Let me tell you one thing: My trie implementation was very naive, that did not really improve things a lot Enter TrieHash Now, how is this related to hashing? The answer is simple: I wrote a perfect hash function generator that is based on tries. You give it a list of words, it puts them in a trie, and generates C code out of it, using recursive switch statements (see code generation below). The function achieves competitive performance with other hash functions, it even usually outperforms them. Given a dictionary, it generates an enumeration (a C enum or C++ enum class) of all words in the dictionary, with the values corresponding to the order in the dictionary (the order-preserving property), and a function mapping strings to members of that enumeration. By default, the first word is considered to be 0 and each word increases a counter by one (that is, it generates a minimal hash function). You can tweak that however:

= 0
WordLabel ~ Word
OtherWord = 9

will return 0 for an unknown value, map Word to the enum member WordLabel and map OtherWord to 9. That is, the input list functions like the body of a C enumeration. If no label is specified for a word, it will be generated from the word. For more details see the documentation C code generation

switch(string[0]   32)  
case 't':
    switch(string[1]   32)  
    case 'a':
        switch(string[2]   32)  
        case 'g':
            return Tag;
         
     
 
return Unknown;

Yes, really recursive switches they directly represent the trie. Now, we did not really do a straightforward translation, there are some optimisations to make the whole thing faster and easier to look at: First of all, the 32 you see is used to make the check case insensitive in case all cases of the switch body are alphabetical characters. If there are non-alphabetical characters, it will generate two cases per character, one upper case and one lowercase (with one break in it). I did not know that lowercase and uppercase characters differed by only one bit before, thanks to the clang compiler for pointing that out in its generated assembler code! Secondly, we only insert breaks only between cases. Initially, each case ended with a return Unknown, but guillem (the dpkg developer) suggested it might be faster to let them fallthrough where possible. Turns out it was not faster on a good compiler, but it s still more readable anywhere. Finally, we build one trie per word length, and switch by the word length first. Like the 32 trick, his gives a huge improvement in performance. Digging into the assembler code The whole code translates to roughly 4 instructions per byte:

1. A memory load,
2. an or with 32
3. a comparison, and
4. a conditional jump.

(On x86, the case sensitive version actually only has a cmp-with-memory and a conditional jump). Due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729 this may be one instruction more: On some architectures an unneeded zero-extend-byte instruction is inserted this causes a 20% performance loss. Performance evaluation I run the hash against all 82 words understood by APT in Packages and Sources files, 1,000,000 times for each word, and summed up the average run-time:

host	arch	Trie	TrieCase	GPerfCase	GPerf	DJB
plummer	ppc64el	540	601	1914	2000	1345
eller	mipsel	4728	5255	12018	7837	4087
asachi	arm64	1000	1603	4333	2401	1625
asachi	armhf	1230	1350	5593	5002	1784
barriere	amd64	689	950	3218	1982	1776
x230	amd64	465	504	1200	837	693

Suffice to say, GPerf does not really come close. All hosts except the x230 are Debian porterboxes. The x230 is my laptop with a a Core i5-3320M, barriere has an Opteron 23xx. I included the DJB hash function for another reference. Source code The generator is written in Perl, licensed under the MIT license and available from https://github.com/julian-klode/triehash I initially prototyped it in Python, but guillem complained that this would add new build dependencies to dpkg, so I rewrote it in Perl. Benchmark is available from https://github.com/julian-klode/hashbench Usage See the script for POD documentation.
Filed under: General

ntrack 011 heading for experimental: I added a ntrack-libnl binary package, for the libnl backend so it s in NEW queue for now.

... finally I got my blog up again and I start with yet another lame post My latest security backports to the upstream abandoned mozilla 1.8.0 branch are now available at http://people.ubuntu.com/~asac/mozilla-security/moz-1.8.1.12a-backports.tar.gz. Those patches should cover all security related fixes that landed on the 1.8 branch (firefox 2) as of 2.0.0.12 RC3. I noticed that I didn’t really release any of the post-mortem security patches released in debian and ubuntu. So, here the patchsets for the 1.8.0 branch that contains them all:

• firefox – http://people.ubuntu.com/~asac/mozilla-security/moz-backports-ffox-all-1.8.1.12.tar.gz


• thunderbird – http://people.ubuntu.com/~asac/mozilla-security/moz-backports-tbird-all-1.8.1.12.tar.gz


• xulrunner – http://people.ubuntu.com/~asac/mozilla-security/moz-backports-xul-all-1.8.1.12.tar.gz

Those tarballs ship quilt patch directories. This means that the sequence to apply them cleanly can be found in the contained series file. To apply them to MOZILLA_1_8_0_BRANCH checkout, just copy the directory contained to your checkout (name the directory patches if you like) and run Have fun!

Original post can be found here. Interview: Today we are interviewing Andrea Veri, fresh MOTU and eager Ubuntu volunteer. Age: 18
Location: Udine, Italy
IRC Nick: bluekuja How long have you used Linux and what was your first distro?
I started using Linux at the end of 2005 using Red Hat and Fedora distros, contributing on writing several pages for Fedora documentation (mostly server docs) but mainly working on some packaging-related activities (introducing ctorrent, gtorrent-viewer and v2strip packages inside Fedora) for more than 3 months until the beginning of March 2006 when I decided to move definitely to Ubuntu after discovering it at a friend s party. Was love at first sight that made me leaving every Fedora plan and project creating my first personal wiki page on wiki.ubuntu.com some days later. How long have you been using Ubuntu?
In fact, I started using Ubuntu at the beginning of 2006, firstly getting involved inside the Edubuntu family making real the possibility to have an Edubuntu Italian support and website area inside the current Italian LoCo Team. When did you get involved with the MOTU team and how?
Right after joining the Ubuntu brigade I started checking out MOTU documentation, mainly packaging guide plus debian new maintainer s guide, trying to understand every single new word and applying directly to a source package every lesson learned during developer s world travel . After getting introduced and fascinated from an active community, I had to left the project for a while for some small problems, restarting everything on May 2007 with my first sponsored upload inside the archive. My packaging passion increased right after meeting Alexander Sack inside #ubuntu-mozillateam irc channel some days later, deciding to work directly with him as my mentor for both Debian and Ubuntu distributions. What helped you learning packaging and learning how the Ubuntu teams work?
I started with Debian New Maintainer s guide and Ubuntu s packaging guide moving then to package my first applications learning from already-packaged software and asking if needed to Alexander improving and learning every time from him or from other developers a new Ubuntu Team lesson. Favorite part of working with MOTU?
Introducing a fix making tons of users happy is one of the best things I appreciate of being a MOTU. Mentoring, sponsoring, helping out new contributors or students is something special as well. Any advice for people wanting to help with MOTU?
I always suggest to start with a package a new contributor cares about personally, that s useful to improve/fix the package itself during its maintenance.
Reading MOTU and Debian documentation is a great starting point as well to avoid any strange question on our MOTU irc channel. What packages/areas of Universe are you most interested in?
I m currently working on a vast area of packages, but I ll try to focus on p2p (Peer-2-Peer) applications both for Universe and Main. I planned to create a MOTU-p2p team really soon including it inside the existing motu-torrent team, but it will take some months to organize everything up; contributors (testers/packagers) are currently missing. Any Plans for Hardy Heron?
I ll keep working on a large number of packages but as I said before I would like to focus on having an updated situation of p2p applications, introducing libtorrent-rasterbar and its related clients like btg or linkage. Creating a working team with interested contributors and developers will be the first step to work on. Favorite quote?

As for me, all I know is that I know nothing. Socrates

What do you do in your other spare time?
I love going around with my motorbike, listening good music, playing basketball and meeting up with friends around the city centre. Pic of you, your work area, and/or your screen?

... are available for testing. firefox will be available soon. use my security preview archive to help testing this release:

• mozilla: 1.7.8-1sarge9
• mozilla-thunderbird: 1.0.2-2.sarge1.0.8e.1

For reference: The raw patches are http://people.debian.org/~asac/backports-1.5.0.9.tar.gz

I noticed some [vitavonni] comments [raw output] about renaming Firefox to various things, to avoid the Mozilla trademark licence bugs. Then ams@gnu told me about Gnuzilla and IceWeasel. Can we use/help them? Update: asac "contacted the gnuzilla project and offered to join them" - great!

As promissed I made available a preview package for the next mozilla-firefox security update. The version of this prospective package is: 1.0.4-2sarge12. If you have a sarge desktop install at hand and want to help, just add my security apt sources from http://www.asoftsite.org/apt-archives.html and upgrade/install mozilla-firefox. Please test and send NEW bugs to me (asac@jwsdot.com) or to pkg-mozilla-maintainers@lists.alioth.debian.org. Thanks!

Hi all, we uploaded preview packages for the next security update of mozilla applications
in debian sarge. This is the second maintenance release after mozilla foundation officially ended
support for the product versions we ship in sarge. The packages are based on the patches I
backported and announced a few days ago [1]. If you are a more or less advanced debian-sarge user (or developer) who wants to contribute and
you are using one of the mozilla apps, then please help by testing
this preview release and provide both, negative and positive feedback to pkg-mozilla-maintainers@lists.alioth.debian.org. To test this release, please upgrade your favorite mozilla app from the sources given below. The repository that contains the new packages can be found at http://people.debian.org/~asac/security. The applications and versions of concern are:

• mozilla-firefox 1.0.4-2sarge10


• mozilla-thunderbird 1.0.2-2.sarge1.0.8b.1


• mozilla 1.7.8-1sarge7.2.1

You can either download the .debs manually or add the following to your apt sources.list:

deb http://people.debian.org/~asac/security ./

If you run into troubles with any of the new packages, chances are high this is due to some
extension that makes use of some corner-case feature. In order to help to track these cases down
you should disable your extensions one by one until you get rid of the problem. If you find the
extension that causes all the troubles, please don’t forget to mention its name and version. Thanks for your support! [1] – http://www.asoftsite.org/s9y/archives/112-Its-mozilla-patch-day!.html

... I have backported security fixes recently announced by mozilla for firefox and thunderbird to the old branch – which we have in debian stable. You can grab the patchset I produced from http://people.debian.org/~asac/patchset_109b.tar.gz. In it you find patches that fix:

• all security flaws whose security advisories had been announced together with firefox/thunderbird 1.5.0.5 – if applicable
• a tricky issue that had not been fixed in the last debian stable-security update for mozilla, mozilla-firefox and mozilla-thunderbird (aka mfsa2006-32, Part 2/7).
• two regressions introduced in our last stable-security update that broke some extensions.

Good news is that a bunch of critical flaws have been identified to not affect debian stable, namely: Another good news is that MFSA2006-45 – which was recently /.ed with a working exploit – is in that list too. So debian stable users are not affected by that issue. In order to get feedback and testing I am now preparing packages. Testing this is critical, because upstream has abandoned 1.0.x development. So please help to test and report regressions … otherwise those might go unseen and finally slip through to our users. I will announce new packages available for testing on my site and on the pkg-mozilla-maintainers mailing-list. Thanks for your support!

mozilla-thunderbird 1.0.2-2.sarge1.0.8a has been uploaded to the security buildds. It addresses the same issues recently fixed in DSA-1118 for mozilla and DSA-1120 for mozilla-firefox. I don’t expect hard regressions, but if you find any, please let me know. Otherwise, this package will enter stable-security soon. You can obtain this build from: http://people.debian.org/~asac/security/

Packages have been built backporting the security fixes from 1.0.8 into sarge's package. This package has gone to the security team and there should be a DSA soon. All the fixes were backported throught the tireless efforts of Alexander Sack. If anyone sees him, buy him a beverage. In other news, the 1.0.8 release is the end of life for the 1.0.x series. With etch at least 8 months away (wouldn't it be great if we released etch in 8 months?) doing security releases for firefox will likely increase in pain.