[Git][reproducible-builds/reproducible-website][master] supporter interviews: several small fixes as pointed out by David

Wed Dec 14 20:06:58 UTC 2022


Holger Levsen pushed to branch master at Reproducible Builds / reproducible-website


Commits:
645e62ba by Holger Levsen at 2022-12-14T21:06:46+01:00
supporter interviews: several small fixes as pointed out by David

Signed-off-by: Holger Levsen <holger at layer-acht.org>

- - - - -


1 changed file:

- _posts/2022-11-30-supporter-spotlight-davidawheeler-supply-chain-security.md


Changes:

=====================================
_posts/2022-11-30-supporter-spotlight-davidawheeler-supply-chain-security.md
=====================================
@@ -35,10 +35,10 @@ My PhD dissertation was on countering the 'Trusting Trust' attack, an attack
 that subverts fundamental build system tools such as compilers.
 The attack was discovered by Karger & Schell in the 1970s, and later
 demonstrated & popularized by Ken Thompson.
-In [my dissertation 'trusting trust'](https://dwheeler.com/trusting-trust) I showed that a process
+In [my dissertation on 'trusting trust'](https://dwheeler.com/trusting-trust) I showed that a process
 called 'Diverse Double-Compiling' (DDC) could detect trusting trust attacks.
 That process is a specialized kind of reproducible build specifically designed
-to detect trusting trust style attacks. In addition, the countering the trusting trust
+to detect trusting trust style attacks. In addition, countering the trusting trust
 attack primarily becomes more important only when reproducible builds become
 more common. Reproducible builds enable detection of
 build-time subversions.
@@ -75,7 +75,7 @@ There are many big challenges in computing today. For example:
   Switching to faster languages, or using multiple processors, is much more difficult than
   waiting for performance problems to disappear.
 * Continuous change in interfaces. Developers continuously find reasons to change
-  component interfaces: perhaps they're too inflexible, too hard to use and so on.
+  component interfaces: perhaps they're too inflexible, too hard to use, and so on.
   But now that developers are reusing hundreds, thousands, or tens of thousands of components,
   managing the continuous change of the reused components is challenging..
   Package managers make updating easy — but don't automatically handle interface changes.
@@ -118,7 +118,7 @@ developers. There are a lot of efforts to counter this:
 We're just starting to get better at this, which is good. However, attackers always
 try to attack the easiest target. As our deployed software has started to be hardened
 against attack, attackers have dramatically increased their attacks
-on the software supply chain ([Sonatype found a 650% increase in one year](https://www.sonatype.com/resources/state-of-the-software-supply-chain-2021)).
+on the software supply chain ([Sonatype found in 2022 that there's been a 742% increase year-over-year](https://www.sonatype.com/state-of-the-software-supply-chain/open-source-supply-demand-security)).
 
 The software supply chain hasn't historically gotten much attention, making it the easy target.
 
@@ -156,24 +156,24 @@ When you have a verified reproducible build, either all the parties colluded
 
 There is one last turtle: What if the build system tools or machines are subverted themselves?
 This is not a common attack today, but it's important to know if we *can* address them
-when the time times. The good news is that we *can* address this.
+when the time comes. The good news is that we *can* address this.
 For some situations reproducible builds can also counter such attacks.
 If there's a loop (that is, a compiler is used to generate itself), that's called the 'trusting trust' attack,
 and that is more challenging. Thankfully, the 'trusting trust' attack has been known about for
 decades and there are known solutions. The 'diverse double-compiling' (DDC) process that
-I explained in my PhD dissertation (as well as the 'bootstrappable builds' process) can
+I explained in my PhD dissertation, as well as the 'bootstrappable builds' process, can
 both counter trusting trust attacks in the software space. So there is no reason to lose hope:
 there is a 'bottom turtle', as it were.
 
 <br>
 
 **Holger: Thankfully, this has all slowly started to change and supply chain issues are now widely discussed, as evident by efforts like 
-[https://www.cisa.gov/uscert/sites/default/files/publications/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF](https://www.cisa.gov/uscert/sites/default/files/publications/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF)
+[Securing the Software Supply Chain: Recommended Practices Guide for Developers](https://www.cisa.gov/uscert/sites/default/files/publications/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF)
 which you shared [on our mailing list](https://lists.reproducible-builds.org/listinfo/rb-general). In there, Reproducible Builds are mentioned as recommended advanced practice, which is both pretty cool (we've come a long way!), but to me it also sounds like this will take another decade until it's become standard normal procedure. Do you agree on that timeline?
 
 David: I don't think there will be any particular timeframe. Different projects and
 ecosystems will move at different speeds. I wouldn't be surprised if it
-took a decade of so for them to become relatively common — there are
+took a decade or so for them to become relatively common — there are
 good reasons for that.
 
 Today the most common kinds of attacks based on software
@@ -232,13 +232,13 @@ ones that are less important over time.
 **Holger: How is the [Best Practices Badge](https://github.com/coreinfrastructure/best-practices-badge/) going? How many projects are participating and how many are missing?**
 
 David: It's going very well. You can [see some automatically-generated statistics](https://bestpractices.coreinfrastructure.org/project_stats), showing we have over 5,000 projects, adding more than 1/day on average.
-We have more than 800 projects that have earned at least the 'passing' badge level.
+We have more than 900 projects that have earned at least the 'passing' badge level.
 
 <br>
 
 **Holger: How many of the projects participating in the Best Practices badge engaging with reproducible builds?**
 
-David: As of writing there are 168 projects that report meeting the reproducible builds criterion.
+David: As of this writing there are 168 projects that report meeting the reproducible builds criterion.
 That's a relatively small percentage of projects. However, note that this criterion (labelled *build_reproducible*)
 is only required for the 'gold' badge. It's not required for the passing or silver level badge.
 



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

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/645e62badb8800c92d220ebb3ca78c9d485694f7
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/20221214/f1b2031e/attachment.htm>
