[Git][reproducible-builds/reproducible-website][master] 2019-07: Misc cosmetic updates

Chris Lamb gitlab at salsa.debian.org
Mon Aug 5 08:52:49 UTC 2019 


Chris Lamb pushed to branch master at Reproducible Builds / reproducible-website


Commits:
ebd716f2 by Chris Lamb at 2019-08-05T08:52:13Z
2019-07: Misc cosmetic updates

- - - - -


5 changed files:

- _reports/2019-07.md
- − images/reports/2019-07/alpinelinux-logo.png
- + images/reports/2019-07/alpinelinux.png
- + images/reports/2019-07/rust.jpg
- + images/reports/2019-07/testframework.png


Changes:

=====================================
_reports/2019-07.md
=====================================
@@ -6,19 +6,21 @@ title: "Reproducible Builds in July 2019"
 draft: true
 ---
 
+**Welcome to the July 2019 report from the [Reproducible Builds](https://reproducible-builds.org) project!**
+
 [![]({{ "/images/reports/2019-07/reproducible-builds.png#right" | prepend: site.baseurl }})](https://reproducible-builds.org/)
 
-**Welcome to the July 2019 report from the [Reproducible Builds](https://reproducible-builds.org) project!** In our reports we outline the most important things that we have been up over the past month.
+In these reports we outline the most important things that we have been up over the past month. As a quick recap, whilst anyone can inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries.
 
-As a quick recap, whilst anyone can inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is to ensure 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.
+The motivation behind the reproducible builds effort is to ensure 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.
 
-In this month's report, we cover:
+In July's report, we cover:
 
-* **Headlines** — *Media coverage and upstream news, etc.*
-* **Distribution work** — *Shenanigans at DebConf19, etc.*
+* **Headlines** — *Media coverage, upstream news, etc.*
+* **Distribution work** — *Shenanigans at DebConf19*
 * **Software development** — *Software transparency, yet more diffoscope work, etc.*
-* **On our mailing list** — *GNU tools, 101s and buildinfo files,, etc.*
-* **Getting in touch** — *How to contribute, etc*
+* **On our mailing list** — *GNU tools, education and buildinfo files*
+* **Getting in touch** — *... and how to contribute*
 
 If you are interested in contributing to our project, we enthusiastically invite you to visit our [*Contribute*]({{ "/contribute/" | prepend: site.baseurl }}) page on our website.
 
@@ -26,7 +28,7 @@ If you are interested in contributing to our project, we enthusiastically invite
 
 ## Headlines
 
-[![]({{ "/images/reports/2019-07/fdroid.png#left" | prepend: site.baseurl }})](https://f-droid.org/)
+[![]({{ "/images/reports/2019-07/fdroid.png#right" | prepend: site.baseurl }})](https://f-droid.org/)
 
 Nico Alt wrote a detailed and well-researched article on his blog titled "[*Trust is good, control is better*](https://nico.dorfbrunnen.eu/posts/2019/reproducibility-fdroid/)" which discusses Reproducible builds in [F-Droid](https://f-droid.org/), alternative application repository for Android mobile phones. In contrast to the bigger commercial app stores F-Droid only offers apps that are free and open source software. The post uses the output of [diffoscope](https://diffoscope.org) and talks more generally about how reproducible builds prevents single developers or other important centralised infrastructure becoming rich targets for toolchain-based attacks.
 
@@ -38,6 +40,8 @@ Morten ("*Foxboron*") Linderud published his academic thesis "[*Reproducible Bui
 
 [Mike Hommey](https://glandium.org) posted to his blog about [*Reproducing the Linux builds of Firefox 68*](https://glandium.org/blog/?p=3923) which leverages that builds shipped by Mozilla should be reproducible from this version onwards. He discusses the problems caused by the builds being optimised with [Profile-guided Optimisation](https://en.wikipedia.org/wiki/Profile-guided_optimization) (PGO) but armed with the now-published profiling data he provides [Docker](https://www.docker.com/)-based instructions how to reproduce the published builds for yourself.
 
+[![]({{ "/images/reports/2019-07/rust.jpg#left" | prepend: site.baseurl }})](https://www.rust-lang.org/)
+
 Joel Galenson has been [making progress on a reproducible Rust compiler](https://github.com/jgalenson/reproducible-rustc) which includes support for a `--remap-path-prefix` related to the concepts and problems involved in the [`BUILD_PATH_PREFIX_MAP`](https://reproducible-builds.org/specs/build-path-prefix-map/) proposal.
 
 Lastly, [Alessio Treglia](http://en.alessiotreglia.com/) posted to their blog about [*Cosmos Hub and Reproducible Builds*](http://en.alessiotreglia.com/articles/cosmos-hub-and-reproducible-builds/) which describes the reproducibility work happening in the [Cosmos Hub](https://hub.cosmos.network), a network of interconnected blockchains. Specifically, Alessio talks about work being done on the [Gaia](https://hub.cosmos.network/docs/what-is-gaia.html) development kit for the Hub.
@@ -66,13 +70,13 @@ There were a number of talks touching on the topic of reproducible builds and se
 * *[Software transparency: improving package manager security](https://debconf19.debconf.org/talks/66-software-transparency-improving-package-manager-security/)* presented by Benjamin Hof.
 * *[Software transparency BoF](https://debconf19.debconf.org/talks/116-software-transparency-bof/)*, an informal "birds of a feather" session to discuss and collect ideas around detecting compromised archives.
 
-There were naturally almost-countless discussions regarding Reproducible Builds in and around the conference on the questions of tooling, infrastructure and our next steps as a project.
+There were naturally countless discussions regarding Reproducible Builds in and around the conference on the questions of tooling, infrastructure and our next steps as a project.
 
 [![]({{ "/images/reports/2019-07/debian.png#center" | prepend: site.baseurl }})](https://debian.org/)
 
 The release of Debian 10 *buster* has also meant the release cycle for the next release (codenamed *bullseye*) has just begun. As part of this, the [Release Team recently announced](https://lists.debian.org/debian-devel-announce/2019/07/msg00002.html) that Debian will no longer allow binaries built and uploaded by maintainers on their own machines to be part of the upcoming release. This is great news not only for toolchain security in general but also in that it will ensure that all binaries that will form part of this release will likely have a `.buildinfo` file and metadata that could be used by others to reproduce the builds.
 
-Holger Levsen [filed a bug against the underlying tool](https://bugs.debian.org/932849) that maintains the Debian archive ("[dak](https://wiki.debian.org/DebianDak)) after he noticed that `.buildinfo` metadata files were not being automatically propagated if packages had to be manually approved or processed in the so-called "[NEW queue](https://ftp-master.debian.org/new.html)". After it was pointed out that the files were being retained in a separate location, Benjamin Hof [proposed a potential patch](https://bugs.debian.org/932849#22) for the issue which is pending review.
+Holger Levsen [filed a bug against the underlying tool](https://bugs.debian.org/932849) that maintains the Debian archive ("[dak](https://wiki.debian.org/DebianDak)) after he noticed that `.buildinfo` metadata files were not being automatically propagated if packages had to be manually approved or processed in the so-called "[`NEW` queue](https://ftp-master.debian.org/new.html)". After it was pointed out that the files were being retained in a separate location, Benjamin Hof [proposed a potential patch](https://bugs.debian.org/932849#22) for the issue which is pending review.
 
 David Bremner posted to his blog post about "[Yet another buildinfo database](https://www.cs.unb.ca/~bremner//blog/posts/builtin-pho/)" that provides a SQL interface for querying `.buildinfo` attestation documents, particularly focusing on identifying packages that were built with a specific — and possibly buggy — build-dependency. Later at DebConf, David [demonstrated his tool live](https://meetings-archive.debian.net/pub/debian-meetings/2019/DebConf19/live-demos.webm) (starting at 36:30).
 
@@ -153,10 +157,12 @@ The Reproducible Builds project detects, dissects and attempts to fix as many cu
 
 Neal Gompa, Michael Schröder & Miro Hrončok responded to [Fedora](https://getfedora.org)'s recent [change to `rpm-config`](https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/57) with some new developments within [rpm](https://github.com/rpm-software-management/rpm/pull/785) to fix an unreproducible "`Build Date`" and [reverted a change to the Python interpreter](https://github.com/fedora-python/cpython/pull/3) to switch back to unreproducible/time-based compile caches.
 
-[![]({{ "/images/reports/2019-07/alpinelinux-logo.png#left" | prepend: site.baseurl }})](https://www.alpinelinux.org)
+[![]({{ "/images/reports/2019-07/alpinelinux.png#left" | prepend: site.baseurl }})](https://www.alpinelinux.org)
 
 Lastly, *kpcyrd* [submitted a pull request](https://github.com/alpinelinux/abuild/pull/93) for [Alpine Linux](https://alpinelinux.org/) to add [`SOURCE_DATE_EPOCH`](https://reproducible-builds.org/docs/source-date-epoch/) support to the [`abuild`](https://github.com/alpinelinux/abuild/) build tool in this operating system.
 
+<br>
+
 #### diffoscope
 
 [![]({{ "/images/reports/2019-07/diffoscope.svg#right" | prepend: site.baseurl }})](https://diffoscope.org)
@@ -223,6 +229,8 @@ In addition, Chris Lamb made the following changes:
 
 #### Test framework
 
+[![]({{ "/images/reports/2019-07/testframework.png#right" | prepend: site.baseurl }})](https://tests.reproducible-builds.org/)
+
 We operate a comprehensive [Jenkins](https://jenkins.io/)-based testing framework that powers [tests.reproducible-builds.org](https://tests.reproducible-builds.org). The following changes were performed in the last month:
 
 * Holger Levsen:


=====================================
images/reports/2019-07/alpinelinux-logo.png deleted
=====================================
Binary files a/images/reports/2019-07/alpinelinux-logo.png and /dev/null differ


=====================================
images/reports/2019-07/alpinelinux.png
=====================================
Binary files /dev/null and b/images/reports/2019-07/alpinelinux.png differ


=====================================
images/reports/2019-07/rust.jpg
=====================================
Binary files /dev/null and b/images/reports/2019-07/rust.jpg differ


=====================================
images/reports/2019-07/testframework.png
=====================================
Binary files /dev/null and b/images/reports/2019-07/testframework.png differ



View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/commit/ebd716f2e815cad7de03ac246088eb41e190abf1

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/commit/ebd716f2e815cad7de03ac246088eb41e190abf1
You're receiving this email because of your account on salsa.debian.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-commits/attachments/20190805/3b995f9c/attachment.html>

More information about the rb-commits mailing list