[Git][reproducible-builds/reproducible-website][master] published as https://reproducible-builds.org/reports/2021-09/

Chris Lamb (@lamby) gitlab at salsa.debian.org
Wed Oct 6 16:56:16 UTC 2021 


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


Commits:
fd1f85d4 by Chris Lamb at 2021-10-06T17:56:05+01:00
published as https://reproducible-builds.org/reports/2021-09/

- - - - -


1 changed file:

- _reports/2021-09.md


Changes:

=====================================
_reports/2021-09.md
=====================================
@@ -3,7 +3,8 @@ layout: report
 year: "2021"
 month: "09"
 title: "Reproducible Builds in September 2021"
-draft: true
+draft: false
+date: 2021-10-06 16:56:05
 ---
 
 [![]({{ "/images/reports/2021-09/reproducible-builds.png#right" | relative_url }})](https://reproducible-builds.org/)
@@ -16,25 +17,23 @@ In these reports we outline the most important things that have been happening i
 
 [![]({{ "/images/reports/2021-09/sigstore.png#right" | relative_url }})](https://www.sigstore.dev/)
 
-First mentioned in our [March 2021 report]({{ "/reports/2021-03/" | relative_url }}), [Martin Heinz](https://martinheinz.dev/) published two blog posts on [**sigstore**](https://www.sigstore.dev/), a project that endeavours to offer software signing as a "public good, [the] software-signing equivalent to [Let's Encrypt](https://letsencrypt.org/)".
+First mentioned in our [March 2021 report]({{ "/reports/2021-03/" | relative_url }}), [Martin Heinz](https://martinheinz.dev/) published two blog posts on [**sigstore**](https://www.sigstore.dev/), a project that endeavours to offer software signing as a "public good, [the] software-signing equivalent to [Let's Encrypt](https://letsencrypt.org/)". The two posts, the first entitled [*Sigstore: A Solution to Software Supply Chain Security*](https://martinheinz.dev/blog/55) outlines more about the project and justifies its existence:
 
-The two posts, the first entitled [*Sigstore: A Solution to Software Supply Chain Security*](https://martinheinz.dev/blog/55) outlines more about the project and justifies its existence:
+> Software signing is not a new problem, so there must be some solution already, right? Yes, but signing software and maintaining keys is very difficult especially for non-security folks and UX of existing tools such as PGP leave much to be desired. That's why we need something like sigstore - an easy to use software/toolset for signing software artifacts.
 
-> software-signing is not a new problem, so there must be some solution already, right? Yes, but signing software and maintaining keys is very difficult especially for non-security folks and UX of existing tools such as PGP leave much to be desired. That's why we need something like sigstore - an easy to use software/toolset for signing software artifacts. [..] Additionally, there are couple of reasons why sigstore's solution is superior to tools like PGP that try to solve the same problem. Unlike with other tools, with sigstore you don't need to manage private keys. You also don't have to understand ins-and-outs of security standards thanks to better UX. sigstore also makes it simpler to manage revocations and with all this it still provides all the required features of software signing, that being integrity, non-repudiation and authentication.
-
-The second post — titled [*Signing Software The Easy Way with Sigstore and Cosign*](https://martinheinz.dev/blog/56) — then goes into the technical details of getting started
+The second post (titled [*Signing Software The Easy Way with Sigstore and Cosign*](https://martinheinz.dev/blog/56)) goes into some technical details of getting started.
 
 <br>
 
-There was an interesting thread on the [/r/Signal](https://www.reddit.com/r/signal/) subreddit based on the observation that [*Signal's apk doesn't match with the source code*](https://www.reddit.com/r/signal/comments/pyj0uv/signals_apk_doesnt_match_with_the_source_code/):
+There was an interesting thread in the [/r/Signal](https://www.reddit.com/r/signal/) subreddit that started from the observation that [*Signal's apk doesn't match with the source code*](https://www.reddit.com/r/signal/comments/pyj0uv/signals_apk_doesnt_match_with_the_source_code/):
 
-> Some time ago I checked Signal's reproducibility and it failed. I asked others to test in case I did something wrong, but nobody made any reports. Since then I tried to test the Google Play Store version of the apk against one I [compiled](https://github.com/signalapp/Signal-Android/tree/master/reproducible-builds) myself, and that doesn't match either. If any of you is willing to test this themselves, please report your findings.
+> Some time ago I checked Signal's reproducibility and it failed. I asked others to test in case I did something wrong, but nobody made any reports. Since then I tried to test the Google Play Store version of the apk against one I [compiled](https://github.com/signalapp/Signal-Android/tree/master/reproducible-builds) myself, and that doesn't match either.
 
 <br>
 
 [![]({{ "/images/reports/2021-09/bitcoinbinary.png#right" | relative_url }})](https://bitcoinbinary.org)
 
-A new website, [**BitcoinBinary.org**](https://bitcoinbinary.org), was announced this month, which aims to be a "repository of Reproducible Build Proofs for Bitcoin Projects". The project explains itself as follows:
+[**BitcoinBinary.org**](https://bitcoinbinary.org) was announced this month, which aims to be a "repository of Reproducible Build Proofs for Bitcoin Projects":
 
 > Most users are not capable of building from source code themselves, but we can at least get them able enough to check signatures and shasums. When reputable people who can tell everyone they were able to reproduce the project's build, others at least have a secondary source of validation.
 
@@ -42,20 +41,20 @@ A new website, [**BitcoinBinary.org**](https://bitcoinbinary.org), was announced
 
 ### Distribution work
 
-Frédéric Pierret [announced](https://lists.reproducible-builds.org/pipermail/rb-general/2021-September/002386.html) a new site at [**beta.tests.reproducible-builds.org**](https://beta.tests.reproducible-builds.org/), showing actual rebuilds of binaries distributed by both the Debian and Qubes distributions.
+Frédéric Pierret [announceda new testing service](https://lists.reproducible-builds.org/pipermail/rb-general/2021-September/002386.html) at [**beta.tests.reproducible-builds.org**](https://beta.tests.reproducible-builds.org/), showing actual rebuilds of binaries distributed by both the Debian and Qubes distributions.
 
 [![]({{ "/images/reports/2021-09/debian.png#right" | relative_url }})](https://debian.org/)
 
 In Debian specifically, however, 51 reviews of Debian packages were added, 31 were updated and 31 were removed this month to [our database of classified issues](https://tests.reproducible-builds.org/debian/index_issues.html). As part of this, Chris Lamb refreshed a number of notes, including the [build_path_in_record_file_generated_by_pybuild_flit_plugin](https://salsa.debian.org/reproducible-builds/reproducible-notes/commit/3f309266) issue.
 
-Elsewhere in Debian, Roland Clobus posted his [*Fourth status update about reproducible live-build ISO images in Jenkins*](https://lists.reproducible-builds.org/pipermail/rb-general/2021-September/002387.html) on our mailing list, which mentions (amongst other things) that:
+Elsewhere in Debian, Roland Clobus posted his [*Fourth status update about reproducible live-build ISO images in Jenkins*](https://lists.reproducible-builds.org/pipermail/rb-general/2021-September/002387.html) to our mailing list, which mentions (amongst other things) that:
 
-> * All major configurations are [still built regularly](https://jenkins.debian.net/view/live/) using live-build and bullseye
-> * All major configurations are reproducible now; Jenkins is green
->     * I've worked around the issue for the Cinnamon image
->     * [The patch](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993444) was accepted and released within a few hours
-> * My main focus for the last month was on the live-build tool itself
->     * It will properly [use the proxy for all HTTP traffic](https://salsa.debian.org/live-team/live-build/-/merge_requests/252)
+> * All major configurations are [still built regularly](https://jenkins.debian.net/view/live/) using live-build and bullseye.
+> * All major configurations are reproducible now; Jenkins is green.
+>     * I've worked around the issue for the Cinnamon image.
+>     * [The patch](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993444) was accepted and released within a few hours.
+> * My main focus for the last month was on the live-build tool itself.
+>     * It will properly [use the proxy for all HTTP traffic](https://salsa.debian.org/live-team/live-build/-/merge_requests/252).
 
 Related to this, there was continuing discussion on how to [embed/encode the build metadata for the Debian "live" images](https://lists.reproducible-builds.org/pipermail/rb-general/2021-September/002359.html) which were being worked on by Roland Clobus.
 
@@ -63,11 +62,9 @@ Related to this, there was continuing discussion on how to [embed/encode the bui
 
 [![]({{ "/images/reports/2021-09/alpine.png#right" | relative_url }})](https://ariadne.space/2021/06/04/a-slightly-delayed-monthly-status-update/)
 
-[Ariadne Conill](https://ariadne.space/) published another [detailed blog post](https://ariadne.space/2021/09/07/bits-relating-to-alpine-security-initiatives-in-august/) this month related to various security initiatives in the [Alpine](https://alpinelinux.org/) Linux distribution. After summarising more-conventional security work being done regarding [sudo](https://www.sudo.ws/) and the release of [OpenSSH](FIXME) version 3.0, Ariadne included another section on reproducible builds: "The main blocker [was] determining what to do about storing the build metadata so that a build environment can be recreated precisely".
-
-<br>
+[Ariadne Conill](https://ariadne.space/) published [another detailed blog post](https://ariadne.space/2021/09/07/bits-relating-to-alpine-security-initiatives-in-august/) related to various security initiatives within the [Alpine](https://alpinelinux.org/) Linux distribution. After summarising some conventional security work being done (eg. with [sudo](https://www.sudo.ws/) and the release of [OpenSSH](https://www.openssh.com/) version 3.0), Ariadne included another section on reproducible builds: "The main blocker [was] determining what to do about storing the build metadata so that a build environment can be recreated precisely".
 
-Finally, Bernhard M. Wiedemann posted his [monthly reproducible builds status report](https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/JGVWCDTZJS2HXTXVADS3ZKO3CIHXZZIN/)
+Finally, Bernhard M. Wiedemann posted his [monthly reproducible builds status report](https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/JGVWCDTZJS2HXTXVADS3ZKO3CIHXZZIN/).
 
 <br>
 
@@ -75,7 +72,7 @@ Finally, Bernhard M. Wiedemann posted his [monthly reproducible builds status re
 
 [![]({{ "/images/reports/2021-09/website.png#right" | relative_url }})](https://reproducible-builds.org/)
 
-On [our website](https://reproducible-builds.org/) this month, Bernhard M. Wiedemann fixed some broken links [[...](https://salsa.debian.org/reproducible-builds/reproducible-website/commit/104a68e)] and Holger Levsen made a number of changes to the [*Who is Involved?*]({{ "/who/" | relative_url }})" page [[...](https://salsa.debian.org/reproducible-builds/reproducible-website/commit/9f43eb7)][[...](https://salsa.debian.org/reproducible-builds/reproducible-website/commit/6b2a913)][[...](https://salsa.debian.org/reproducible-builds/reproducible-website/commit/32b3aba)]. And on our mailing list, Magnus Ihse Bursie started a thread with the subject [*Reproducible builds on Java*](https://lists.reproducible-builds.org/pipermail/rb-general/2021-September/thread.html#2374) which starts as follows:
+On [our website](https://reproducible-builds.org/) this month, Bernhard M. Wiedemann fixed some broken links [[...](https://salsa.debian.org/reproducible-builds/reproducible-website/commit/104a68e)] and Holger Levsen made a number of changes to the [*Who is Involved?*]({{ "/who/" | relative_url }}) page [[...](https://salsa.debian.org/reproducible-builds/reproducible-website/commit/9f43eb7)][[...](https://salsa.debian.org/reproducible-builds/reproducible-website/commit/6b2a913)][[...](https://salsa.debian.org/reproducible-builds/reproducible-website/commit/32b3aba)]. On our mailing list, Magnus Ihse Bursie started a thread with the subject [*Reproducible builds on Java*](https://lists.reproducible-builds.org/pipermail/rb-general/2021-September/thread.html#2374), which begins as follows:
 
 > I'm working for Oracle in the Build Group for [OpenJDK](https://openjdk.java.net/groups/build/) which is primary responsible for creating a built artifact of the OpenJDK source code. [...] For the last few years, we have worked on a low-effort, background-style project to make the build of OpenJDK itself building reproducible. We've come far, but there are still issues I'd like to address. [[...](https://lists.reproducible-builds.org/pipermail/rb-general/2021-September/002374.html)]
 



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

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/fd1f85d460748bec5621dc2388859554efbd7ce0
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/20211006/c1cbba71/attachment.htm>

More information about the rb-commits mailing list