It would be particularly beneficial if those with unsual build dependencies tested it as we would increase overall coverage beyond what I get from testing against 1800+ CRAN packages. BioConductor would also be welcome.

install.packages("Rcpp", repos="https://rcppcore.github.io/drat")

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Could I be any more happier?

• During the first three days, I looked for a potential solution to the usage of git ls-files in the gemspec files. This has been the most problematic thing for us.
  • Apart from the option of using Dir or Dir.glob, the best (closest) possible solution (right now) is to use Rake::FileList which tries to respects the .gitignore file.
  • I stumbled upon this interesting gem, fast_ignore. It is the exact thing which we want to use but unfortunately, to use it inside other gemspec files, it should be vendored inside bundler s code.
• We had our first meeting on the fourth day and we decided to hold meetings every Thursday for the next 12 weeks.
• For the next five days, I learned more of Ruby and figured out what to do and how to do it.
  If you d like to know what exactly I did in these 5 days, I d suggest you to read the daily logs for those respective days.
• During the next to two days, the first part of the project, the GemspecGit Cop, was implemented.
  This cop will correctly determine the usage of git in the gemspec files and would tell the developers and the maintainers to replace them with pure Ruby alternatives with giving them a proper reason to do so. Much thanks to Dana for her help she took out time to pair-program with me!
• We had our second weekly meeting where I finally told Antonio and David that the first part is already done (\o/) and we discussed some things and even pair-programmed :D
• I took the weekend off (and something terrible happened) but anyways, I managed to get together some time and energy to document the source code and raised this PR #2.
• And here I am on the 15th day :)

• Ingress admission controller [source code]
• Registry admission controller [source code]

• Privileged policy: used by Kubernetes containers themselves basically a very relaxed set of constraints that are required for the system itself to work.
• Default policy: a bit more restricted than the privileged policy, is intended for admins to deploy services, but it isn t currently in use..
• Toolforge user policies: this applies to user-scheduled containers, and there are some obvious restrictions here: we only allow unprivileged pods, we control which HostPath is available for pods, use only default Linux capabilities, etc.

• metrics-server: used by some utilities like kubectl top.
• kube-state-metrics: provides advanced metrics about the state of the cluster.
• cadvisor: to obtain fine-grained metrics about pods, deployments, nodes, etc.

tar axf qt-everywhere-src-5.15.0.tar.xz
cp -a debian-cross qt-everywhere-src-5.15.0/debian

cp qt-license.txt ~/.qt-license

dpkg --add-architecture armhf
apt install crossbuild-essential-armhf

cd qt-everywhere-src-5.15.0
apt build-dep .
apt -a armhf build-dep .

apt install devscripts
mk-build-deps --host-arch amd64 debian-cross/control
mk-build-deps --host-arch armhf debian-cross/control
apt -f install qt-everywhere-cross-build-deps_5.15.0-1_amd64.deb qt-everywhere-cross-cross-build-deps_5.15.0-1_armhf.deb

cd qt-everywhere-src-5.15.0
fakeroot debian/rules binary

apt install crossbuild-essential-armhf debhelper qtbase5custom-armhf-dev*_amd64.deb qt-everywhere-src-cross-build-deps*_armhf.deb
mkdir runtime
cp -a debian-armhf runtime/debian
cd runtime
dpkg-buildpackage -a armhf

• a libqt5custom package for armhf, installable on the target devices, containing the runtime Qt libraries and depending on the packages that they need to run;
• a libqt5custom-dbgym package for armhf with debugging symbols, to use for debugging on the target hardware.

# apt install qtchooser qt5-qmake qt5-default
$ qtchooser --list-versions
4
5
qt4-x86_64-linux-gnu
qt4
qt5-x86_64-linux-gnu
qt5
qt5custom-x86_64-linux-gnu
qt5custom
qt5custom-armhf-x86_64-linux-gnu
qt5custom-armhf
$ qmake --version
QMake version 3.1
Using Qt version 5.11.3 in /usr/lib/x86_64-linux-gnu
$ export QT_SELECT=qt5custom-armhf
$ qmake --version
QMake version 3.1
Using Qt version 5.15.0 in /opt/qt5custom-armhf/lib

export QT_SELECT=qt5custom-armhf
fakeroot ./debian/rules clean binary

export QT_SELECT=qt5custom-armhf
qmake file.pro

tar axf qt-everywhere-src-5.15.0.tar.xz
cp -a debian-amd64 qt-everywhere-src-5.15.0/debian

cp qt-license.txt ~/.qt-license

cd qt-everywhere-src-5.15.0
apt build-dep .

apt install devscripts
mk-build-deps debian-amd64/control
apt -f install qt-everywhere-src-build-deps_5.15.0-1_amd64.deb

cd qt-everywhere-src-5.15.0
fakeroot debian/rules binary

• libqt5custom: the runtime environment
• libqt5custom-dbgsym: debugging symbols for the runtime environment
• qtbase5custom-dev: the build environment
• qtbase5custom-dev-dbgsym: debugging symbols for the build environment

# apt install qtchooser qt5-qmake qt5-default
$ qtchooser --list-versions
4
5
qt4-x86_64-linux-gnu
qt4
qt5-x86_64-linux-gnu
qt5
qt5custom-x86_64-linux-gnu
qt5custom
$ qmake --version
QMake version 3.1
Using Qt version 5.11.3 in /usr/lib/x86_64-linux-gnu
$ export QT_SELECT=qt5custom
$ qmake --version
QMake version 3.1
Using Qt version 5.15.0 in /opt/qt5custom/lib

export QT_SELECT=qt5custom
fakeroot ./debian/rules clean binary

export QT_SELECT=qt5custom
qmake file.pro

PSA: don't rely on GnuTLS, please. CVE-2020-13777 Whoops, for the past 10 releases most TLS 1.0 1.2 connection could be passively decrypted and most TLS 1.3 connections intercepted. Trivially. Also, TLS 1.2 1.0 session tickets are awful.

Affected packages Assuming you're running Debian, this will show a list of packages that Depends on GnuTLS:

apt-cache --installed rdepends libgnutls30   grep '^ '   sort -u

This assumes you run this only on hosts running Buster or above. Otherwise you'll need to figure out a way to pick machines running GnuTLS 3.6.4 or later. Note that this list only first level dependencies! It is perfectly possible that another package uses GnuTLS without being listed here. For example, in the above list I have libcurl3-gnutls, so the be really thorough, I would actually need to recurse down the dependency tree. On my desktop, this shows an "interesting" list of targets:

• apt
• cadaver - AKA WebDAV
• curl & wget
• fwupd - another attack on top of this one
• git (through the libcurl3-gnutls dependency)
• mutt - all your emails
• weechat - your precious private chats

Arguably, fetchers like apt, curl, fwupd, and wget rely on HTTPS for "authentication" more than secrecy, although apt has its own OpenPGP-based authentication so that wouldn't matter anyways. Still, this is truly distressing. And I haven't mentioned here things like gobby, network-manager, systemd, and others - the scope of this is broad. Hell, even good old lynx links against GnuTLS. In our infrastructure, the magic command looks something like this:

cumin -o txt -p 0  'F:lsbdistcodename=buster' "apt-cache --installed rdepends libgnutls30   grep '^ '   sort -u"   tee gnutls-rdepds-per-host   awk ' print $NF '   sort   uniq -c   sort -n

There, the result is even more worrisome, as those important packages seem to rely on GnuTLS for their transport security:

• mariadb - all MySQL traffic and passwords
• mandos - full disk encryption
• slapd - LDAP passwords

mandos is especially distressing although it's probably not vulnerable because it seems it doesn't store the cleartext -- it's encrypted with the client's OpenPGP public key -- so the TLS tunnel never sees the cleartext either. Other reports have also mentioned the following servers link against GnuTLS and could be vulnerable:

• exim
• rsyslog
• samba
• various VNC implementations

Not affected Those programs are not affected by this vulnerability:

• apache2
• gnupg
• python
• nginx
• openssh

This list is not exhaustive, naturally, but serves as an example of common software you don't need to worry about. The vulnerability only exists in GnuTLS, as far as we know, so programs linking against other libraries are not vulnerable. Because the vulnerability affects session tickets -- and those are set on the server side of the TLS connection -- only users of GnuTLS as a server are vulnerable. This means, for example, that while weechat uses GnuTLS, it will only suffer from the problem when acting as a server (which it does, in relay mode) or, of course, if the remote IRC server also uses GnuTLS. Same with apt, curl, wget, or git: it is unlikely to be a problem because it is only used as a client; the remote server is usually a webserver -- not git itself -- when using TLS.

Caveats Keep in mind that it's not because a package links against GnuTLS that it uses it. For example, I have been told that, on Arch Linux, if both GnuTLS and OpenSSL are available, the mutt package will use the latter, so it's not affected. I haven't confirmed that myself nor have I checked on Debian. Also, because it relies on session tickets, there's a time window after which the ticket gets cycled and properly initialized. But that is apparently 6 hours by default so it is going to protect only really long-lasting TLS sessions, which are uncommon, I would argue. My audit is limited. For example, it might have been better to walk the shared library dependencies directly, instead of relying on Debian package dependencies.

Other technical details It seems the vulnerability might have been introduced in this merge request, itself following a (entirely reasonable) feature request to make it easier to rotate session tickets. The merge request was open for a few months and was thoroughly reviewed by a peer before being merged. Interestingly, the vulnerable function (_gnutls_initialize_session_ticket_key_rotation), explicitly says:

 * This function will not enable session ticket keys on the server side. That is done
 * with the gnutls_session_ticket_enable_server() function. This function just initializes
 * the internal state to support periodical rotation of the session ticket encryption key.

In other words, it thinks it is not responsible for session ticket initialization, yet it is. Indeed, the merge request fixing the problem unconditionally does this:

memcpy(session->key.initial_stek, key->data, key->size);

I haven't reviewed the code and the vulnerability in detail, so take the above with a grain of salt. The full patch is available here. See also the upstream issue 1011, the upstream advisory, the Debian security tracker, and the Redhat Bugzilla.

Moving forward The impact of this vulnerability depends on the affected packages and how they are used. It can range from "meh, someone knows I downloaded that Debian package yesterday" to "holy crap my full disk encryption passwords are compromised, I need to re-encrypt all my drives", including "I need to change all LDAP and MySQL passwords". It promises to be a fun week for some people at least. Looking ahead, however, one has to wonder whether we should follow @FiloSottile's advice and stop using GnuTLS altogether. There are at least a few programs that link against GnuTLS because of the OpenSSL licensing oddities but that has been first announced in 2015, then definitely and clearly resolved in 2017 -- or maybe that was in 2018? Anyways it's fixed, pinky-promise-I-swear, except if you're one of those weirdos still using GPL-2, of course. Even though OpenSSL isn't the simplest and secure TLS implementation out there, it could preferable to GnuTLS and maybe we should consider changing Debian packages to use it in the future. But then again, the last time something like this happened, it was Heartbleed and GnuTLS wasn't affected, so who knows... It is likely that people don't have OpenSSL in mind when they suggest moving away from GnuTLS and instead think of other TLS libraries like mbedtls (previously known as PolarSSL), NSS, BoringSSL, LibreSSL and so on. Not that those are totally sinless either... "This is fine", as they say...

[  \x -> x + 1  ]

LamE [VarP x_1]
    (InfixE (Just (VarE x_1))
            (VarE GHC.Num.+)
            (Just (LitE (IntegerL 1))))

 > 1 + $( litE (IntegerL 1) )
2

genfst n = do
    xs <- replicateM n (newName "x")
    let ntup = tupP (map varP xs)
    [  \ $(ntup) ->  $(varE (head xs))  ]

 > $(genfst 2) (1,2)
1
 > $(genfst 3) ('a','b','c')
'a'
 > :t $(genfst 10)
$(genfst 10) :: (a, b, c, d, e, f, g, h, i, j) -> a

 > :t [  1  ]
[  1  ] :: ExpQ

 > runQ [  \x -> x  ]
LamE [VarP x_1] (VarE x_1)
 > runQ [  \x -> x  ]
LamE [VarP x_2] (VarE x_2)

Changes in RcppArmadillo version 0.9.900.1.0 (2020-06-08)

• Upgraded to Armadillo release 9.900.1 (Nocturnal Misbehaviour)
  • faster solve() for under/over-determined systems
  • faster eig_gen() and eig_pair() for large matrices
  • expanded eig_gen() and eig_pair() to optionally provide left and right eigenvectors
• Switch Travis CI testing to R 4.0.0, use bionic as base distro and test R 3.6.3 and 4.0.0 in a matrix (Dirk in #298).
• Add two badges to README for indirect use and the CSDA paper.
• Adapt RcppArmadillo.package.skeleton() to a change in R 4.0.0 affecting what it exports in NAMESPACE.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

This comic was based on this essay from Augusten Burroughs: How to live unhappily ever after. In addition to the essay, I highly recommend reading his books. It's also been described in psychology as flow.

With full English subtitles

Confict where it comes from and how to deal with it

Communication skills

Other languages

Distributed teams are where people you work with aren t physically co-located, ie. they re at another office building, home or an outsourced company abroad. They re becoming increasingly popular, for DevOps and other teams, due to recruitment, diversity, flexibility and cost savings. Challenges arise due to timezones, language barriers, cultures and ways of working. People actively participating in Open Source communities tend to be effective in distributed teams. This session looks at how to apply core Open Source principles to distributed teams in Enterprise organisations, and the importance of shared purposes/goals, (mis)communication, leading vs managing teams, sharing and learning. We'll also look at practical aspects of what's worked well for others, such as alternatives to daily standups, promoting video conferencing, time management and virtual coffee breaks. This session is relevant for those leading or working in distributed teams, wanting to know how to cultivate an inclusive culture of increased trust and collaboration that leads to increased productivity and performance.

int socket = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);

int socket = socket(PF_INET, SOCK_STREAM, IPPROTO_TLS);

How does Smokeping work Leaving those two aside for now, I'm left with Smokeping, which I used in my previous job to diagnose routing issues, using Smokeping as a decentralized looking glass, which was handy to debug long term issues. Smokeping is a strange animal: it's fundamentally similar to Munin, except it's harder to write plugins for it, so most people just use it for Ping, something for which it excels at. Its trick is this: instead of doing a single ping and returning this metrics, it does multiple ones and returns multiple metrics. Specifically, smokeping will send multiple ICMP packets (20 by default), with a low interval (500ms by default) and a single retry. It also pings multiple hosts at once which means it can quickly scan multiple hosts simultaneously. You therefore see network conditions affecting one host reflected in further hosts down (or up) the chain. The multiple metrics also mean you can draw graphs with "error bars" which Smokeping shows as "smoke" (hence the name). You also get per-metric packet loss. Basically, smokeping runs this command and collects the output in a RRD database:

fping -c $count -q -b $backoff -r $retry -4 -b $packetsize -t $timeout -i $mininterval -p $hostinterval $host [ $host ...]

... where those parameters are, by default:

• $count is 20 (packets)
• $backoff is 1 (avoid exponential backoff)
• $timeout is 1.5s
• $mininterval is 0.01s (minimum wait interval between any target)
• $hostinterval is 1.5s (minimum wait between probes on a single target)

It can also override stuff like the source address and TOS fields. This probe will complete between 30 and 60 seconds, if my math is right (0% and 100% packet loss).

How do draw Smokeping graphs in Grafana A naive implementation of Smokeping in Prometheus/Grafana would be to use the blackbox exporter and create a dashboard displaying those metrics. I've done this at home, and then I realized that I was missing something. Here's what I did.

1. install the blackbox exporter:

   apt install prometheus-blackbox-exporter
   

2. make sure to allow capabilities so it can ping:

   dpkg-reconfigure prometheus-blackbox-exporter
   

3. hook monitoring targets into prometheus.yml (the default blackbox exporter configuration is fine):

   scrape_configs:
     - job_name: blackbox
         metrics_path: /probe
         params:
           module: [icmp]
         scrape_interval: 5s
         static_configs:
           - targets:
             - octavia.anarc.at
             # hardcoded in DNS
             - nexthop.anarc.at
             - koumbit.net
             - dns.google
         relabel_configs:
           - source_labels: [__address__]
             target_label: __param_target
           - source_labels: [__param_target]
             target_label: instance
           - target_label: __address__
             replacement: 127.0.0.1:9115  # The blackbox exporter's real hostname:port.
   

   Notice how we lower the scrape_interval to 5 seconds to get more samples. nexthop.anarc.at was added into DNS to avoid hardcoding my upstream ISP's IP in my configuration.
4. use this Grafana panel to graph the results. It was created with this query:

   sum(probe_icmp_duration_seconds phase="rtt" ) by (instance)
   

   • Set the Legend field to instance RTT
   • Set Draw modes to lines and Mode options to staircase
   • Set the Left Y axis Unit to duration(s)
   • Show the Legend As table, with Min, Avg, Max and Current enabled
   Then this query, for packet loss:

   1-avg_over_time(probe_success[$__interval])!=0 or null
   

   • Set the Legend field to instance packet loss
   • Set a Add series override to Lines: false, Null point mode: null, Points: true, Points Radius: 1, Color: deep red, and, most importantly, Y-axis: 2
   • Set the Right Y axis Unit to percent (0.0-1.0) and set Y-max to 1
   Then set the entire thing to Repeat, on target, vertically. And you need to add a target variable like label_values(probe_success, instance).

The result looks something like this:

Not bad, but not Smokeping

This actually looks pretty good! The resulting dashboard is available in the Grafana dashboard repository.

What is missing? Now, that doesn't exactly look like Smokeping, does it. It's pretty good, but it's not quite what we want. What is missing is variance, the "smoke" in Smokeping. There's a good article about replacing Smokeping with Grafana. They wrote a custom script to write samples into InfluxDB so unfortunately we can't use it in this case, since we don't have InfluxDB's query language. I couldn't quite figure out how to do the same in PromQL. I tried:

stddev(probe_icmp_duration_seconds phase="rtt",instance=~"$instance" )
stddev_over_time(probe_icmp_duration_seconds phase="rtt",instance=~"$instance" [$__interval])
stddev_over_time(probe_icmp_duration_seconds phase="rtt",instance=~"$instance" [1m])

The first two give zero for all samples. The latter works, but doesn't look as good as Smokeping. So there might be something I'm missing. SuperQ wrote a special exporter for this called smokeping_prober that came out of this discussion in the blackbox exporter. Instead of delegating scheduling and target definition to Prometheus, the targets are set in the exporter. They also take a different approach than Smokeping: instead of recording the individual variations, they delegate that to Prometheus, through the use of "buckets". Then they use a query like this:

histogram_quantile(0.9 rate(smokeping_response_duration_seconds_bucket[$__interval]))

This is the rationale to SuperQ's implementation:

Yes, I know about smokeping's bursts of pings. IMO, smokeping's data model is flawed that way. This is where I intentionally deviated from the smokeping exact way of doing things. This prober sends a smooth, regular series of packets in order to be measuring at regular controlled intervals. Instead of 20 packets, over 10 seconds, every minute. You send one packet per second and scrape every 15. This has the same overall effect, but the measurement is, IMO, more accurate, as it's a continuous stream. There's no 50 second gap of no metrics about the ICMP stream. Also, you don't get back one metric for those 20 packets, you get several. Min, Max, Avg, StdDev. With the histogram data, you can calculate much more than just that using the raw data. For example, IMO, avg and max are not all that useful for continuous stream monitoring. What I really want to know is the 90th percentile or 99th percentile. This smokeping prober is not intended to be a one-to-one replacement for exactly smokeping's real implementation. But simply provide similar functionality, using the power of Prometheus and PromQL to make it better. [...] one of the reason I prefer the histogram datatype, is you can use the heatmap panel type in Grafana, which is superior to the individual min/max/avg/stddev metrics that come from smokeping. Say you had two routes, one slow and one fast. And some pings are sent over one and not the other. Rather than see a wide min/max equaling a wide stddev, the heatmap would show a "line" for both routes.

That's an interesting point. I have also ended up adding a heatmap graph to my dashboard, independently. And it is true it shows those "lines" much better... So maybe that, if we ignore legacy, we're actually happy with what we get, even with the plain blackbox exporter. So yes, we're missing pretty "fuzz" lines around the main lines, but maybe that's alright. It would be possible to do the equivalent to the InfluxDB hack, with queries like:

min_over_time(probe_icmp_duration_seconds phase="rtt",instance=~"$instance" [30s])
avg_over_time(probe_icmp_duration_seconds phase="rtt",instance=~"$instance" [5m])
max_over_time(probe_icmp_duration_seconds phase="rtt",instance=~"$instance" [30s])

The output looks something like this:

Looks more like Smokeping!

But there's a problem there: see how the middle graph "dips" sometimes below 20ms? That's the min_over_time function (incorrectly, IMHO) returning zero. I haven't quite figured out how to fix that, and I'm not sure it is better. But it does look more like Smokeping than the previous graph. Update: I forgot to mention one big thing that this setup is missing. Smokeping has this nice feature that you can order and group probe targets in a "folder"-like hierarchy. It is often used to group probes by location, which makes it easier to scan a lot of targets. This is harder to do in this setup. It might be possible to setup location-specific "jobs" and select based on that, but it's not exactly the same.

Credits Credits to Chris Siebenmann for his article about Prometheus and pings which gave me the avg_over_time query idea.

Welcome to the May 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. Nonetheless, 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 seemingly secure software during the various compilation and distribution processes. In these reports we outline the most important things that we and the rest of the community have been up to over the past month.

News The Corona-Warn app that helps trace infection chains of SARS-CoV-2/COVID-19 in Germany had a feature request filed against it that it build reproducibly. A number of academics from Cornell University have published a paper titled Backstabber s Knife Collection which reviews various open source software supply chain attacks:

Recent years saw a number of supply chain attacks that leverage the increasing use of open source during software development, which is facilitated by dependency managers that automatically resolve, download and install hundreds of open source packages throughout the software life cycle.

In related news, the LineageOS Android distribution announced that a hacker had access to the infrastructure of their servers after exploiting an unpatched vulnerability. Marcin Jachymiak of the Sia decentralised cloud storage platform posted on their blog that their siac and siad utilities can now be built reproducibly:

This means that anyone can recreate the same binaries produced from our official release process. Now anyone can verify that the release binaries were created using the source code we say they were created from. No single person or computer needs to be trusted when producing the binaries now, which greatly reduces the attack surface for Sia users.

Synchronicity is a distributed build system for Rust build artifacts which have been published to crates.io. The goal of Synchronicity is to provide a distributed binary transparency system which is independent of any central operator. The Comparison of Linux distributions article on Wikipedia now features a Reproducible Builds column indicating whether distributions approach and progress towards achieving reproducible builds.

Distribution work In Debian this month:

• Paul Wise continued a discussion that was started in February regarding the storing and distribution of build logs and other related artifacts and their relationship to reproducible builds. For example, the binutils package ships its own, unreproducible, log files in its binary packages. It was followed-up by replies from Chris Lamb and Matthias Klose.
• 34 reviews of Debian packages were added, 20 were updated and 122 were removed this month adding to our knowledge about identified issues. Chris Lamb added and categorised a new ocaml_cmti_files toolchain issue.

In Alpine Linux, an issue was filed and closed regarding the reproducibility of .apk packages. Allan McRae of the ArchLinux project posted their third Reproducible builds progress report to the arch-dev-public mailing list which includes the following call for help:

We also need help to investigate and fix the packages that fail to reproduce that we have not investigated as of yet.

In openSUSE, Bernhard M. Wiedemann published his monthly Reproducible Builds status update.

Software development

diffoscope Chris Lamb made the changes listed below to diffoscope, our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. He also prepared and uploaded versions 142, 143, 144, 145 and 146 to Debian, PyPI, etc.

• Comparison improvements:
  • Improve fuzzy matching of JSON files as file now supports recognising JSON data. (#106)
  • Refactor .changes and .buildinfo handling to show all details (including the GnuPG header and footer components) even when referenced files are not present. (#122)
  • Use our BuildinfoFile comparator (etc.) regardless of whether the associated files (such as the orig.tar.gz and the .deb) are present. [ ]
  • Include GnuPG signature data when comparing .buildinfo, .changes, etc. [ ]
  • Add support for printing Android APK signatures via apksigner(1). (#121)
  • Identify iOS App Zip archive data as .zip files. (#116)
  • Add support for Apple Xcode .mobilepovision files. (#113)
• Bug fixes:
  • Don t print a traceback if we pass a single, missing argument to diffoscope (eg. a JSON diff to re-load). [ ]
  • Correct differences typo in the ApkFile handler. (#127)
• Output improvements:
  • Never emit the same id="foo" anchor reference twice in the HTML output, otherwise identically-named parts will not be able to linked to via a #foo anchor. (#120)
  • Never emit an empty id anchor either; it is not possible to link to #. [ ]
  • Don t pretty-print the output when using the --json presenter; it will usually be too complicated to be readable by the human anyway. [ ]
  • Use the SHA256 over MD5 hash when generating page names for the HTML directory-style presenter. (#124)
• Reporting improvements:
  • Clarify the message when we truncate the number of lines to standard error [ ] and reduce the number of maximum lines printed to 25 as usually the error is obvious by then [ ].
  • Print the amount of free space that we have available in our temporary directory as a debugging message. [ ]
  • Clarify Command [ ] failed with exit code messages to remove duplicate exited with exit but also to note that diffoscope is interpreting this as an error. [ ]
  • Don t leak the full path of the temporary directory in Command [ ] exited with 1 messages. (#126)
  • Clarify the warning message when we cannot import the debian Python module. [ ]
  • Don t repeat stderr from if both commands emit the same output. [ ]
  • Clarify that an external command emits for both files, otherwise it can look like we are repeating itself when, in reality, it is being run twice. [ ]
• Testsuite improvements:
  • Prevent apksigner test failures due to lack of binfmt_misc, eg. on Salsa CI and elsewhere. [ ]
  • Drop .travis.yml as we use Salsa instead. [ ]
• Dockerfile improvements:
  • Add a .dockerignore file to whitelist files we actually need in our container. (#105)
  • Use ARG instead of ENV when setting up the DEBIAN_FRONTEND environment variable at runtime. (#103)
  • Run as a non-root user in container. (#102)
  • Install/remove the build-essential during build so we can install the recommended packages from Git. [ ]
• Codebase improvements:
  • Bump the officially required version of Python from 3.5 to 3.6. (#117)
  • Drop the (default) shell=False keyword argument to subprocess.Popen so that the potentially-unsafe shell=True is more obvious. [ ]
  • Perform string normalisation in Black [ ] and include the Black output in the assertion failure too [ ].
  • Inline MissingFile s special handling of deb822 to prevent leaking through abstract layers. [ ][ ]
  • Allow a bare try/except block when cleaning up temporary files with respect to the flake8 quality assurance tool. [ ]
  • Rename in_dsc_path to dsc_in_same_dir to clarify the use of this variable. [ ]
  • Abstract out the duplicated parts of the debian_fallback class [ ] and add descriptions for the file types. [ ]
  • Various commenting and internal documentation improvements. [ ][ ]
  • Rename the Openssl command class to OpenSSLPKCS7 to accommodate other command names with this prefix. [ ]
• Misc:
  • Rename the --debugger command-line argument to --pdb. [ ]
  • Normalise filesystem stat(2) birth times (ie. st_birthtime) in the same way we do with the stat(1) command s Access: and Change: times to fix a nondeterministic build failure in GNU Guix. (#74)
  • Ignore case when ordering our file format descriptions. [ ]
  • Drop, add and tidy various module imports. [ ][ ][ ][ ]

In addition:

• Jean-Romain Garnier fixed a general issue where, for example, LibarchiveMember s has_same_content method was called regardless of the underlying type of file. [ ]
• Daniel Fullmer fixed an issue where some filesystems could only be mounted read-only. (!49)
• Emanuel Bronshtein provided a patch to prevent a build of the Docker image containing parts of the build s. (#123)
• Mattia Rizzolo added an entry to debian/py3dist-overrides to ensure the rpm-python module is used in package dependencies (#89) and moved to using the new execute_after_* and execute_before_* Debhelper rules [ ].

Chris Lamb also performed a huge overhaul of diffoscope s website:

• Add a completely new design. [ ][ ]
• Dynamically generate our contributor list [ ] and supported file formats [ ] from the main Git repository.
• Add a separate, canonical page for every new release. [ ][ ][ ]
• Generate a latest release section and display that with the corresponding date on the homepage. [ ]
• Add an RSS feed of our releases [ ][ ][ ][ ][ ] and add to Planet Debian [ ].
• Use Jekyll s absolute_url and relative_url where possible [ ][ ] and move a number of configuration variables to _config.yml [ ][ ].

Upstream patches The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:
  • golang-packaging (toolchain issue, affecting times in minikube)
  • jboss-logging-tools (toolchain issue, affecting date for resteasy)
  • linux_logo (sort find output to avoid inheriting filesystem order)
  • moonjit (generate reproducible output by default if SOURCE_DATE_EPOCH is set)
  • vala (report ASLR nondeterminism)
• Jelle van der Waa:
  • earlyoom (timestamps in Gzip files)
  • fmt (Don t install sphinx-build cached files as they are unneeded & unreproducible)
  • nvidia-settings (timestamp in Gzip files)
• Chris Lamb:
  • #959714 filed against ataqv.
  • #960313 filed against elinks.
  • #960386 filed against briquolo.
  • #960388 filed against cryptominisat.
  • #960590 filed against wolfssl.
  • #960591 filed against mistral.
  • #960607 filed against python-watcherclient.
  • #960669 filed against tree-puzzle.
  • #961009 filed against nulib2.
  • #961202 filed against process-cpp.
  • #961494 filed against bowtie2.
  • #961495 filed against properties-cpp.
  • #961582 filed against wand (forwarded upstream)
  • #961657 filed against vows.
• Vagrant Cascadian:
  • #961747 filed against libstatgrab.
  • #961764 filed against texi2html.
  • #961766 filed against grub.
  • #961830 filed against systemtap.
  • #961942 filed against mono.
  • mescc-tools: Inherit CFLAGS in a Makefile, allowing -ffile-prefix-map/-fdebug-prefix-map to sanitise build paths (merged upstream).

Other tools Elsewhere in our tooling: strip-nondeterminism is our tool to remove specific non-deterministic results from a completed build. In May, Chris Lamb uploaded version 1.8.1-1 to Debian unstable and Bernhard M. Wiedemann fixed an off-by-one error when parsing PNG image modification times. (#16) In disorderfs, our FUSE-based filesystem that deliberately introduces non-determinism into directory system calls in order to flush out reproducibility issues, Chris Lamb replaced the term dirents in place of directory entries in human-readable output/log messages [ ] and used the astyle source code formatter with the default settings to the main disorderfs.cpp source file [ ]. Holger Levsen bumped the debhelper-compat level to 13 in disorderfs [ ] and reprotest [ ], and for the GNU Guix distribution Vagrant Cascadian updated the versions of disorderfs to version 0.5.10 [ ] and diffoscope to version 145 [ ].

Project documentation & website

• Carl Dong:
  • Clarify some potential confusion around GCC libtool. [ ]
• Chris Lamb:
  • Rename the Who page to Projects . [ ]
  • Ensure that Jekyll enters the _docs subdirectory to find the _docs/index.md file after an internal move. (#27)
  • Wrap ltmain.sh etc. in preformatted quotes. [ ]
  • Wrap the SOURCE_DATE_EPOCH Python examples onto more lines to prevent visual overflow on the page. [ ]
  • Correct a preferred spelling error. [ ]
• Holger Levsen:
  • Sort our Academic publications page by publication year [ ] and add Trusting Trust and Fully Countering Trusting Trust through Diverse Double-Compiling [ ].
• Juri Dispan:
  • Update the URL for faketime to the project s Github page. (!57)

Testing framework We operate a large and many-featured Jenkins-based testing framework that powers tests.reproducible-builds.org that, amongst many other tasks, tracks the status of our reproducibility efforts as well as identifies any regressions that have been introduced. Holger Levsen made the following changes:

• System health status:
  • Improve page description. [ ]
  • Add more weight to proxy failures. [ ]
  • More verbose debug/failure messages. [ ][ ][ ]
  • Work around strangeness in the Bash shell let VARIABLE=0 exits with an error. [ ]
• Debian:
  • Fail loudly if there are more than three .buildinfo files with the same name. [ ]
  • Fix a typo which prevented /usr merge variation on Debian unstable. [ ]
  • Temporarily ignore PHP s horde](https://www.horde.org/) packages in Debian bullseye. [ ]
  • Document how to reboot all nodes in parallel, working around molly-guard. [ ]
• Further work on a Debian package rebuilder:
  • Workaround and document various issues in the debrebuild script. [ ][ ][ ][ ]
  • Improve output in the case of errors. [ ][ ][ ][ ]
  • Improve documentation and future goals [ ][ ][ ][ ], in particular documentiing two real world tests case for an impossible to recreate build environment [ ].
  • Find the right source package to rebuild. [ ]
  • Increase the frequency we run the script. [ ][ ][ ][ ]
  • Improve downloading and selection of the sources to build. [ ][ ][ ]
  • Improve version string handling.. [ ]
  • Handle build failures better. [ ]. [ ]. [ ]
  • Also consider architecture all .buildinfo files. [ ][ ]

In addition:

• kpcyrd, for Alpine Linux, updated the alpine_schroot.sh script now that a patch for abuild had been released upstream. [ ]
• Alexander Couzens of the OpenWrt project renamed the brcm47xx target to bcm47xx. [ ]
• Mattia Rizzolo fixed the printing of the build environment during the second build [ ][ ][ ] and made a number of improvements to the script that deploys Jenkins across our infrastructure [ ][ ][ ].

Lastly, Vagrant Cascadian clarified in the documentation that you need to be user jenkins to run the blacklist command [ ] and the usual build node maintenance was performed was performed by Holger Levsen [ ][ ][ ], Mattia Rizzolo [ ][ ] and Vagrant Cascadian [ ][ ][ ].

Mailing list: There were a number of discussions on our mailing list this month: Paul Spooren started a thread titled Reproducible Builds Verification Format which reopens the discussion around a schema for sharing the results from distributed rebuilders:

To make the results accessible, storable and create tools around them, they should all follow the same schema, a reproducible builds verification format. The format tries to be as generic as possible to cover all open source projects offering precompiled source code. It stores the rebuilder results of what is reproducible and what not.

Hans-Christoph Steiner of the Guardian Project also continued his previous discussion regarding making our website translatable. Lastly, Leo Wandersleb posted a detailed request for feedback on a question of supply chain security and other issues of software review; Leo is the founder of the Wallet Scrutiny project which aims to prove the security of Android Bitcoin Wallets:

Do you own your Bitcoins or do you trust that your app allows you to use your coins while they are actually controlled by them ? Do you have a backup? Do they have a copy they didn t tell you about? Did anybody check the wallet for deliberate backdoors or vulnerabilities? Could anybody check the wallet for those?

Elsewhere, Leo had posted instructions on his attempts to reproduce the binaries for the BlueWallet Bitcoin wallet for iOS and Android platforms.

---

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
• Reddit: /r/ReproducibleBuilds
• Mailing list: rb-general@lists.reproducible-builds.org

This month s report was written by Bernhard M. Wiedemann, Chris Lamb, Holger Levsen, Jelle van der Waa and Vagrant Cascadian. It was subsequently reviewed by a bunch of Reproducible Builds folks on IRC and the mailing list.

P.step :: Int -> Int -> Context -> Context

S.step :: Int -> Int -> State Context ()
S.step x y = modify (P.step x y)

mkWrap fn = do
     
    let name = mkName (nameBase fn)
    return $ FunD name [ Clause (map VarP args) (NormalB rhs) [] ]

info    <- reify fn
let ty   = (\(VarI _ t _ ) -> t) info
let n    = arity ty - 1
args    <- replicateM n (newName "arg")

-- mkFnApp f [a,b,c] => ((f a) b) c => f a b c
mkFnApp = foldl (\e -> appE e . varE)
rhs     <- [  modify $(mkFnApp (varE fn) args) :: State Context ()  ]

import Liquorice.Pure
wrapPureFunctions = mapM mkWrap pureFns

P.place :: Int -> Int -> (Context -> Context) -> Context -> Context

wget http://snapshot.debian.org/archive/debian/20180412T100152Z/pool/main/g/gcc-5/libasan2_5.5.0-12_amd64.deb

wget http://snapshot.debian.org/archive/debian/20180412T100152Z/pool/main/g/gcc-5/gcc-5-base_5.5.0-12_amd64.deb

dpkg -i ./gcc-5-base_5.5.0-12_amd64.deb ./libasan2_5.5.0-12_amd64.deb

apt-get install python3-protobuf