[Git][reproducible-builds/reproducible-website][master] 2022-05: -2 typos

[Bernhard M. Wiedemann (@bmwiedemann-guest)]

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


Commits:
adc0cb90 by Bernhard M. Wiedemann at 2022-06-05T09:46:32+02:00
2022-05: -2 typos

- - - - -


1 changed file:

- _reports/2022-05.md


Changes:

=====================================
_reports/2022-05.md
=====================================
@@ -16,7 +16,7 @@ Welcome to the May 2022 report from the [Reproducible Builds](https://reproducib
 
 [![]({{ "/images/reports/2022-05/repfix.png#right" | relative_url }})](http://oscar-lab.org/paper/icse_22_repfix.pdf)
 
-Zhilei Ren, Shiwei Sun, Jifeng Xuan, Xiaochen Li, Zhide Zhou and He Jiang have published an academic titled *Automated Patching for Unreproducible Builds*:
+Zhilei Ren, Shiwei Sun, Jifeng Xuan, Xiaochen Li, Zhide Zhou and He Jiang have published an academic paper titled *Automated Patching for Unreproducible Builds*:
 
 > [..] fixing unreproducible build issues poses a set of challenges [..], among which we consider the localization granularity and the historical knowledge utilization as the most significant ones. To tackle these challenges, we propose a novel approach [called] RepFix that combines **tracing-based fine-grained localization with history-based patch generation** mechanisms.
 
@@ -79,7 +79,7 @@ The [minutes and logs from our May 2022 IRC meeting](http://meetbot.debian.net/r
 
 #### A new tool to improve supply-chain security in Arch Linux
 
-*kpcyrd* published yet another interesting tool related to reproducibility. Writing about the tool in a recent blog post, *kpcyrd* mentions that although many `PKGBUILDs` provide **authentication** in the context of signed Git tags (ie. the ability to "verify the Git tag was signed by one of the two trusted keys"), they do not support **pinning**, ie. that "upstream could create a new signed Git tag with an identical name, and arbitrarily change the source code without the [maintainer] noticing". Conversely, other `PKGBUILD`s support pinning but not authentication. The new tool, [*auth-tarball-from-git*](https://github.com/kpcyrd/auth-tarball-from-git), fixes both problems, as [nearly outlined in *kpcyrd*'s original blog post](https://vulns.xyz/2022/05/auth-tarball-from-git/).
+*kpcyrd* published yet another interesting tool related to reproducibility. Writing about the tool in a recent blog post, *kpcyrd* mentions that although many `PKGBUILDs` provide **authentication** in the context of signed Git tags (i.e. the ability to "verify the Git tag was signed by one of the two trusted keys"), they do not support **pinning**, ie. that "upstream could create a new signed Git tag with an identical name, and arbitrarily change the source code without the [maintainer] noticing". Conversely, other `PKGBUILD`s support pinning but not authentication. The new tool, [*auth-tarball-from-git*](https://github.com/kpcyrd/auth-tarball-from-git), fixes both problems, as [nearly outlined in *kpcyrd*'s original blog post](https://vulns.xyz/2022/05/auth-tarball-from-git/).
 
 <br>
 



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

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/adc0cb90005a1a4094c04de2ef32d37f829258b0
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/20220605/5a248cb1/attachment.htm>