[Git][reproducible-builds/reproducible-website][master] Many misc changes to 2022-11-30 post.
Chris Lamb (@lamby)
gitlab at salsa.debian.org
Fri Dec 2 08:42:38 UTC 2022
Chris Lamb pushed to branch master at Reproducible Builds / reproducible-website
Commits:
d8d9ddbc by Chris Lamb at 2022-12-02T08:42:02+00:00
Many misc changes to 2022-11-30 post.
- - - - -
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
=====================================
@@ -8,9 +8,9 @@ draft: true
<big>The Reproducible Builds project [relies on several projects, supporters and sponsors]({{ "/who/" | relative_url }}) for financial support, but they are also valued as ambassadors who spread the word about our project and the work that we do.</big>
-This is the *six* instalment in a series featuring the projects, companies and individuals who support the Reproducible Builds project. We started this series by [featuring the Civil Infrastructure Platform]({{ "/news/2020/10/21/supporter-spotlight-cip-project/" | relative_url }}) project and followed this up with a [post about the Ford Foundation]({{ "/news/2021/04/06/supporter-spotlight-ford-foundation/" | relative_url }}) as well as a recent ones about [ARDC]({{ "/news/2022/04/14/supporter-spotlight-ardc/" | relative_url }}), the [Google Open Source Security Team (GOSST)]({{ "/news/2022/04/26/supporter-spotlight-google-open-source-security-team/" | relative_url }}), [Jan Nieuwenhuizen on Bootstrappable Builds, GNU Mes and GNU Guix]({{ "/news/2022/05/18/jan-nieuwenhuizen-on-bootrappable-builds-gnu-mes-and-gnu-guix/" | relative_url }}) and .[Hans-Christoph Steiner of the F-Droid project]({{ "/news/2022/06/24/supporter-spotlight-hans-christoph-steiner-f-droid-project/" | relative_url }})
+This is the *sixth* instalment in a series featuring the projects, companies and individuals who support the Reproducible Builds project. We started this series by [featuring the Civil Infrastructure Platform]({{ "/news/2020/10/21/supporter-spotlight-cip-project/" | relative_url }}) project and followed this up with a [post about the Ford Foundation]({{ "/news/2021/04/06/supporter-spotlight-ford-foundation/" | relative_url }}) as well as a recent ones about [ARDC]({{ "/news/2022/04/14/supporter-spotlight-ardc/" | relative_url }}), the [Google Open Source Security Team (GOSST)]({{ "/news/2022/04/26/supporter-spotlight-google-open-source-security-team/" | relative_url }}), [Jan Nieuwenhuizen on Bootstrappable Builds, GNU Mes and GNU Guix]({{ "/news/2022/05/18/jan-nieuwenhuizen-on-bootrappable-builds-gnu-mes-and-gnu-guix/" | relative_url }}) and [Hans-Christoph Steiner of the F-Droid project]({{ "/news/2022/06/24/supporter-spotlight-hans-christoph-steiner-f-droid-project/" | relative_url }}).
-Today, however, we will be talking with <big>**David A. Wheeler**, the Director of Open Source Supply Chain Security at the Linux Foundation</big>.
+Today, however, we will be talking with <big>**David A. Wheeler**</big>, the Director of Open Source Supply Chain Security at the [Linux Foundation](https://www.linuxfoundation.org/).
<br>
<br>
@@ -19,24 +19,24 @@ Today, however, we will be talking with <big>**David A. Wheeler**, the Director
**Holger Levsen: Welcome, David, thanks for taking the time to talk with us today. First, could you briefly tell me about yourself?**
-David: Sure! I'm David A. Wheeler.
-I work for the [Linux Foundation](https://https://www.linuxfoundation.org/) as the "Director of Open Source Supply Chain Security".
+David: Sure! I'm David A. Wheeler and
+I work for the [Linux Foundation](https://www.linuxfoundation.org/) as the Director of Open Source Supply Chain Security.
That just means that my job is to help open source software projects
improve their security, including its development, build, distribution,
and incorporation in larger works, all the way out to its eventual use by end-users.
-In my copious free time I also teach at George Mason University (GMU), in particular,
+In my copious free time I also teach at [George Mason University](https://www.gmu.edu/) (GMU); in particular,
I teach a graduate course on how to design and implement secure software..
My background is technical. I have a Bachelor's in Electronics Engineering,
-a Master's in Computer Science, and a PhD in Information Technology.
+a Master's in Computer Science and a PhD in Information Technology.
My PhD dissertation is connected to reproducible builds.
-My PhD dissertation was on countering the "Trusting Trust" attack, an attack
+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 the process
-"Diverse Double-Compiling" (DDC), which I named, could detect trusting trust attacks.
+In [my dissertation '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
attack primarily becomes more important only when reproducible builds become
@@ -47,14 +47,14 @@ directly use a build-time subversion of the software they actually want to subve
<br>
-**Holger: thanks for taking the time to introduce yourself to us, David! What do you think are the biggest challenges today in computing?**
+**Holger: Thanks for taking the time to introduce yourself to us. What do you think are the biggest challenges today in computing?**
There are many big challenges in computing today. For example:
* Lack of resilience & capacity in chip fabrication. Fabs are extraordinarily expensive,
and at the high end continue to have technological advancement.
- As a result, supply is failing to meet demand, and geopolitical issues raise more concerns.
- We've seen cars, gaming consoles, and many other devices
+ As a result, supply is failing to meet demand, and geopolitical issues raise further concerns.
+ We've seen cars, gaming consoles and many other devices
unable to be delivered due to chip shortages. More fabs are
being built, and some politicians are raising concerns, but it's unclear
that current efforts will be enough.
@@ -62,8 +62,8 @@ There are many big challenges in computing today. For example:
Computers are far faster, and open source software has made software reuse
incredibly easy. However, organizations still struggle to automate
many tasks. The bottleneck is the lack of enough talented developers able to convert
- ideas into working software. "Low-code" and "no-code" approaches help in specialized areas,
- just like all previous "automate the programmer" efforts of the last 60 years, but
+ ideas into working software. 'Low-code' and 'no-code' approaches help in specialized areas,
+ just like all previous 'automate the programmer' efforts of the last 60 years, but
there's no reason to believe they will help enough.
* Large scale of software. Small systems are easier to develop & maintain, but today's
systems increasingly get bigger to meet users' needs & are much harder to manage.
@@ -75,13 +75,13 @@ 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.
- I think this is mostly a self-inflicted problem - most components *could* support old interfaces
- (like the Linux kernel does) - but because it's often not acknowledged as a problem, it's often not addressed.
-* Security & privacy. Decades ago there were fewer computers, and most computers weren't connected to a network.
+ Package managers make updating easy — but don't automatically handle interface changes.
+ I think this is mostly a self-inflicted problem — most components *could* support old interfaces
+ (like the Linux kernel does) — but because it's often not acknowledged as a problem, it's often not addressed.
+* Security & privacy. Decades ago there were fewer computers and most computers weren't connected to a network.
Today things are different. Criminals have found many ways to attack computer systems to
make money, and nation-states have found many ways to attack computer systems for their own reasons.
Attackers now have very strong motivations to perform attacks.
@@ -94,20 +94,21 @@ There are many big challenges in computing today. For example:
**Holger: Do you think reproducible builds are an important part in secure computing today already?**
-David: Yes, but let's put things in context.
+David: Yes, but first let's put things in context.
+
+Today, when attackers exploit software vulnerabilities, they're primarily
+exploiting unintentional vulnerabilities that were created by the software
+developers. There are a lot of efforts to counter this:
-Today, when attackers exploit software vulnerabilities, they're primarily exploiting
-unintentional vulnerabilities that were created by the software developers.
-There are a lot of efforts to counter this:
* Train & education developers in how to develop secure software.
- The OpenSSF provides a free course on how to do that (full disclosure: I'm the author).
- Take that course or something like it! More info: <https://openssf.org/training/courses/>
+ The OpenSSF provides a [free course on how to do that](https://openssf.org/training/courses/) (full disclosure: I'm the author).
+ Take that course or something like it!
* Add tools to your CI pipeline to detect potential vulnerabilities. Yes, they have false
positives and false negatives, so you have to also use your brain... but that just means you
need to be smart about using tools, instead of not using them.
* Get projects & organizations to update the components they use,
since often the vulnerabilities are well-known publicly
- (e.g., Equifax in 2017). Add some tools to your development process to warn you about
+ (e.g., [Equifax in 2017](https://en.wikipedia.org/wiki/2017_Equifax_data_breach)). Add some tools to your development process to warn you about
components with known vulnerabilities! GitHub & GitLab both provide tools to do this,
and there are many other tools.
* When starting new projects, try to use memory-safe languages. On average 70% of the
@@ -117,17 +118,17 @@ 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).
+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)).
The software supply chain hasn't historically gotten much attention, making it the easy target.
There are simple supply chain attacks with simple solutions:
* In almost every year the top attack has been typosquatting. In typo squatting,
an attacker creates packages with *almost* the right name. This is an easy attack to
- counter - developers just need to double-check the name of a package before adding it.
+ counter — developers just need to double-check the name of a package before adding it.
But we aren't warning developers enough about it!
- For more information, see papers such as the "Backstabber's Knife Collection".
-* Last year the top software supply chain attack was "dependency confusion" - convincing
+ For more information, see papers such as the [Backstabber's Knife Collection](https://dasfreak.github.io/Backstabbers-Knife-Collection/).
+* Last year the top software supply chain attack was 'dependency confusion' — convincing
projects to use the wrong repo for a given package. There are simple solutions to this, such as
specifying the package source and/or requiring a cryptographic hash to match.
* Some attacks involve takeovers of developer accounts. In almost all cases, these are
@@ -140,10 +141,10 @@ One of the most dangerous is subverted build systems, as demonstrated by
the subversion of SolarWinds' Orion system. In a subverted build system,
developers can review the software source code all day and see no problem,
because there *is* no problem there. Instead, the process to convert source code
-into the code people run, called the "build system", is subverted by an attacker.
+into the code people run, called the 'build system', is subverted by an attacker.
One solution for countering subverted build systems is to make the build systems harder
-to attack. That's a good thing to do, but you can never be confident that it was "good enough".
+to attack. That's a good thing to do, but you can never be confident that it was 'good enough'.
How can you be sure it's not subverted, if there's no way to know?
A stronger defense against subverted build systems is the idea of verified reproducible builds.
@@ -157,20 +158,20 @@ There is one last turtle: What if the build system tools or machines are subvert
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.
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 named and explained in my PhD dissertation, and 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.
+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
+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 slowly started to change and supply chain issues are now widely discussed, as evident by efforts like [FIXME:404 document](https://media.defense.gov/2022/Sep/01/2003068942/-1/-1/0/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF) which you shared on the [r-b general 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 also sounds like this will take another decade until it's become standard normal procedure. Do you agree on 'a decade'?**
+**Holger: Thankfully, this has all slowly started to change and supply chain issues are now widely discussed, as evident by efforts like [FIXME:404 document](https://media.defense.gov/2022/Sep/01/2003068942/-1/-1/0/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, and there are
+took a decade of so for them to become relatively common — there are
good reasons for that.
Today the most common kinds of attacks based on software
@@ -193,11 +194,11 @@ build systems. Attackers always go for the weakest link.
We will eventually need verified reproducible builds, and
it'll take a while to get build systems able to widely perform reproducible builds,
so we need to start that work now. That's true for anything where you know
-you'll need it but it will take a long time to get ready - you need to start now.
+you'll need it but it will take a long time to get ready — you need to start now.
<br>
-**Holger: what are your suggestions to accellerate things here?**
+**Holger: What are your suggestions to accelerate adoption?**
David: Reproducible builds need to be:
@@ -226,18 +227,18 @@ ones that are less important over time.
<br>
-**Holger: on another topic, you're involved in, how is the [Best practices badge](https://github.com/coreinfrastructure/best-practices-badge/) going? I mean, how many projects are participating, and how many are missing?**
+**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.
+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.
<br>
-**Holger: And how many of the participing ones are doing reproducible builds?**
+**Holger: How many of the projects participating in the Best Practices badge engaging with reproducible builds?**
-David: As of 2022-09-28 there are 168 projects that report meeting the reproducible builds criterion.
-That's a relatively small percentage of projects. However, note that this criterion (named "build_reproducible")
-is only required for the "gold" badge. It's not required for the passing or silver level badge.
+David: As of 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.
Currently we've been strategically focused on getting projects to at least earn a passing badge,
and less on earning silver or gold badges.
@@ -251,13 +252,9 @@ Examples of such projects include the Linux kernel and curl.
In addition, some projects are used within
systems where it's important to society that they not have serious security vulnerabilities.
Examples include projects used by
-chemical manufacturers, financial systems, and weapons.
+chemical manufacturers, financial systems and weapons.
We definitely encourage any of those kinds of projects to earn higher badge levels.
-
-
-
-
<br>
**Holger: Many thanks for this interview, David, and for all of your work at the Linux Foundation and elsewhere!**
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/d8d9ddbca7ec2b8c5c76f8960f55c3bde7e4491f
--
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/d8d9ddbca7ec2b8c5c76f8960f55c3bde7e4491f
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/20221202/4eb64ee0/attachment.htm>
More information about the rb-commits
mailing list