[Git][reproducible-builds/reproducible-website][master] 2020-08: -2 typos

[Bernhard M. Wiedemann]

Bernhard M. Wiedemann pushed to branch master at Reproducible Builds / reproducible-website


Commits:
aacc9e8d by Bernhard M. Wiedemann at 2020-09-09T12:29:09+02:00
2020-08: -2 typos

- - - - -


1 changed file:

- _reports/2020-08.md


Changes:

=====================================
_reports/2020-08.md
=====================================
@@ -18,7 +18,7 @@ This month, [Jennifer Helsby](https://redshiftzero.github.io/) launched a new [*
 
 > One hiccup we've encountered in [SecureDrop](https://securedrop.org/) development is that not all Python wheels can be built reproducibly. We ship multiple (Python) projects in Debian packages, with Python dependencies included in those packages as wheels. In order for our Debian packages to be reproducible, we need that wheel build process to also be reproducible
 
-Parallel to this, [*transparencylog.com*](https://www.transparencylog.com/) was also launched, a service that verifies the contents of URLs against a publicly recorded cryptographic log. It keeps an [append-only log](https://en.wikipedia.org/wiki/Append-only) of the cryptographic digests of all URLs it has seen. ([Github repo](https://github.com/transparencylog/tl))
+Parallel to this, [*transparencylog.com*](https://www.transparencylog.com/) was also launched, a service that verifies the contents of URLs against a publicly recorded cryptographic log. It keeps an [append-only log](https://en.wikipedia.org/wiki/Append-only) of the cryptographic digests of all URLs it has seen. ([GitHub repo](https://github.com/transparencylog/tl))
 
 [![]({{ "/images/reports/2020-08/isdd2020.png#right" | relative_url }})](https://www.eco.de/events/internet-security-days-2020/isdd-2020-agenda/#best_practises__aus_erfahrungen_lernen)
 
@@ -150,7 +150,7 @@ The Reproducible Builds project detects, dissects and attempts to fix as many cu
 
     * Don't raise an exception when we encounter XML files with `<!ENTITY>` declarations inside the [Document Type Definition](https://en.wikipedia.org/wiki/Document_type_definition) (DTD), or when a DTD or entity references an external resource. ([#212](https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/212))
     * `pgpdump(1)` can successfully parse some binary files, so check that the parsed output contains something sensible before accepting it. [[...](https://salsa.debian.org/reproducible-builds/diffoscope/commit/156f239)]
-    * Temporarily drop `gnumeric` from the Debian build-dependies as it has been removed from the *testing* distribution. ([#968742](https://bugs.debian.org/968742))
+    * Temporarily drop `gnumeric` from the Debian build-dependencies as it has been removed from the *testing* distribution. ([#968742](https://bugs.debian.org/968742))
     * Correctly use `fallback_recognises` to prevent matching `.xsb` binary XML files.
     * Correct identify signed PGP files as `file(1)` returns "`data`". ([#211](https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/211))
 
@@ -259,7 +259,7 @@ On [our mailing list](https://lists.reproducible-builds.org/listinfo/rb-general/
 
 > If you think you know how to spread the word about reproducibility in the context of Bitcoin wallets through WalletScrutiny, your contributions are highly welcome on [this PR](https://gitlab.com/walletscrutiny/walletScrutinyCom/-/merge_requests/68) [[...](https://lists.reproducible-builds.org/pipermail/rb-general/2020-August/002004.html)]
 
-Julien Lepiller posted to the list linking to a blog post by Tavis Ormandy titled [*You don't need reproducible builds*](https://lists.reproducible-builds.org/pipermail/rb-general/2020-August/002007.html). Morten Linderud (*foxboron*) responded with a clear rebuttal that Tavis was only considering the narrow use-case of proprietary vendors and closed-source software. He additionally notied that the criticism that reproducible builds cannot prevent against backdoors being deliberately introduced into the upstream source ("bugdoors") are decidedly (and deliberately) outside the scope of reproducible builds to begin with.
+Julien Lepiller posted to the list linking to a blog post by Tavis Ormandy titled [*You don't need reproducible builds*](https://lists.reproducible-builds.org/pipermail/rb-general/2020-August/002007.html). Morten Linderud (*foxboron*) responded with a clear rebuttal that Tavis was only considering the narrow use-case of proprietary vendors and closed-source software. He additionally noted that the criticism that reproducible builds cannot prevent against backdoors being deliberately introduced into the upstream source ("bugdoors") are decidedly (and deliberately) outside the scope of reproducible builds to begin with.
 
 Chris Lamb included the Reproducible Builds mailing list in a wider discussion regarding a tentative [proposal to include `.buildinfo` files in `.deb` packages](https://wiki.debian.org/Teams/Dpkg/Spec/BundledBuildinfo), adding his remarks regarding requiring a custom tool in order to determine whether generated build artifacts are 'identical' in a reproducible context. [[...](https://lists.reproducible-builds.org/pipermail/rb-general/2020-August/002030.html)]
 



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

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/aacc9e8def61b2a83e158a04bdb3a63cce3344fa
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/20200909/3fd32c82/attachment.htm>