[Git][reproducible-builds/reproducible-website][master] 3 commits: add skeleton for new supporter interview

[Holger Levsen (@holger)]

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


Commits:
8eb31a79 by Holger Levsen at 2022-11-30T14:06:29+01:00
add skeleton for new supporter interview

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

- - - - -
2f21ec6b by Holger Levsen at 2022-11-30T14:13:27+01:00
new supporter interview: add draft content and FIXMEs as needed

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

- - - - -
82266993 by Holger Levsen at 2022-11-30T14:17:17+01:00
2022 11: += https://link.springer.com/article/10.1007/s11219-022-09607-z

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

- - - - -


2 changed files:

- + _posts/2022-11-30-supporter-spotlight.md
- _reports/2022-11.md


Changes:

=====================================
_posts/2022-11-30-supporter-spotlight.md
=====================================
@@ -0,0 +1,300 @@
+---
+layout: post
+title: "Supporter spotlight: David A. Wheeler"
+date: 2022-11-30 10:00:00
+categories: org
+draft: true
+---
+
+[![]({{ "/images/news/supporter-spotlight-hans/FIXME.jpg?#right" | relative_url }})](https://FIXME.org/)
+
+<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)](https://security.googleblog.com/), [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** from the **FIXME** project</big>.
+
+<br>
+<br>
+
+[![]({{ "/images/news/supporter-spotlight-hans/FIXME.jpg?#right" | relative_url }})](https://FIXME/)
+
+**Holger: Welcome, David! Could you briefly tell me about yourself?**
+
+Hans: Sure...
+
+<br>
+
+
+Holger: Hi David, thanks for taking the time to talk with us today. First, could you briefly tell me about yourself?
+
+Sure! I'm David A. Wheeler.
+I work for the Linux Foundation 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,
+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.
+
+My PhD dissertation is connected to reproducible builds.
+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 (<https://dwheeler.com/trusting-trust>) I showed that the process
+"Diverse Double-Compiling" (DDC), which I named, 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
+more common. Reproducible builds enable detection of
+build-time subversions.
+Most attackers wouldn't bother with a trusting trust attack if they could just
+directly use a build-tie subversion of the software they actually want to subvert.
+
+
+
+Holger: thanks for taking the time to introduce yourself to us, David! 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
+  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.
+* Lack of enough developers able to develop the software that people & organizations need.
+  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
+  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.
+  Even small embedded systems are often supported by huge back-end systems.
+* Ending tail of Moore's law & rise of smartphones. Historically people would just wait a few years for their
+  software to speed up, but Moore's law is petering out, and smartphones are necessarily
+  limited by power & size limits. As a result, software developers
+  can't wait for the hardware to save their slow systems; they must redesign.
+  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.
+  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.
+  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.
+  Yet many developers aren't told how to develop software that resists attacks, nor
+  how to protect their supply chains. Operations try to monitor and recover from
+  attacks, but their job is difficult due to inadequately secure software that doesn't
+  support those monitoring & recovery efforts well either. The results are terrible security.
+
+
+
+Holger: Do you think reproducible builds are an important part in secure computing today already?
+
+Yes, but 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:
+* 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/>
+* 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
+  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
+  vulnerabilities in Chrome and in Microsoft are from memory safety problems; using a memory-safe
+  language eliminates most of them.
+
+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).
+
+The software supply chain hasn't historically gotten much attention, making it the easy target.
+
+----------------------begin-holger-comment------
+maybe cut something from the next 50 lines
+------------------------end-holger--------------
+
+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.
+  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
+  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
+  caused by stolen passwords. Using a multi-factor authentication (MFA) token eliminates
+  stolen password attacks, which is why several
+  repositories are starting to require MFA tokens in some cases.
+
+Unfortunately, attackers know there are other lines of attack.
+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.
+
+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".
+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.
+A build is reproducible if given the same source code, build environment and build instructions,
+any party can recreate bit-by-bit identical copies of all specified artifacts.
+A build is *verified* if multiple different parties verify that they get the same result for that situation.
+When you have a verified reproducible build, either all the parties colluded
+(and you could always double-check it yourself), or the build process isn't subverted.
+
+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.
+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.
+
+
+(David said above)
+>> The software supply chain hasn't historically gotten much attention, making it the easy target.
+
+Holger: thankfully this slowly started to change, as evident by efforts like 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.  in there, r-b 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'? :)
+
+
+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
+good reasons for that.
+
+Today the most common kinds of attacks based on software
+vulnerabilities still involve unintentional vulnerabilities in operational systems.
+Attackers are starting to apply supply chain attacks, but the top such attacks
+today are typosquatting (creating packages with similar names) and
+dependency confusion) (convincing projects to download packages from the wrong
+repositories).
+
+Reproducible builds don't counter those kinds of attacks, they
+counter subverted builds. It's important to eventually have verified
+reproducible builds, but understandably other issues are currently getting
+prioritized first.
+
+That said, reproducible builds are important long term.
+Many people are working on countering unintentional vulnerabilities
+and the most common kinds of supply chain attacks.
+As these other threats are countered, attackers will increasingly target
+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.
+
+
+
+Holger: what are your suggestions to accellerate things here?
+
+Reproducible builds need to be:
+
+* Easy (ideally automatic). Tools need to be modified so that reproducible builds
+  are the default or at least easier to do.
+* Transparent to projects & potential users. Many projects have no idea that their results aren't
+  reproducible, and many potential users of the project don't know either.
+  That information needs to be obvious. I've proposed that the OpenSSF
+  Dashboard SIG try to reproduce builds, for at least some packages, to make it
+  more obvious to everyone when a project isn't reproducible. I don't know if that
+  will happen in that particular case, but the point is to help people learn that information
+  as soon as possible.
+* Deployed.
+  Experiments are great, but experiments showing that a project *could* be reproducible
+  are inadequate. We need the projects that people *use* to be reproducible.
+
+I think there's a snowball effect. Once many projects' packages are reproducible,
+it will be easier to convince other projects to make their packages reproducible.
+
+I also think there should be some prioritization. If a package is in wide use
+(e.g., part of minimum set of packages for a widely-used Linux distribution or
+framework), its reproducibility should be a special focus. If a package is vital for
+supporting some societally important critical infrastructure (e.g., running dams),
+it should also be considered important. You can then work on the
+ones that are less important over time.
+
+
+
+Holger: on another topic, you're involved in, how is https://github.com/coreinfrastructure/best-practices-badge/ going? I mean, how many projects are participating, and how many are missing?
+
+It's going very well. You can see some automatically-generated statistics here:
+https://bestpractices.coreinfrastructure.org/project_stats
+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.
+
+Holger: And how many of the participing ones are doing reproducible builds?
+
+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.
+
+Currently we've been strategically focused on getting projects to at least earn a passing badge,
+and less on earning silver or gold badges.
+We would *love* for all projects to get earn a silver or gold badge, of course, but
+our theory is that projects that can't even earn a passing badge present the most risk to their users.
+
+That said, there are some projects we especially want to see implementing higher badge levels.
+Those include projects that are very widely used, so that
+vulnerabilities in them can impact many systems.
+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.
+We definitely encourage any of those kinds of projects to earn higher badge levels.
+
+
+Holger: David, thanks a lot for taking the time for having this discussion and giving us much food for thought!
+
+
+
+
+
+
+<br>
+
+**Holger: Many thanks for this interview, David, and for all of your work on FIXME and elsewhere. If someone wanted to get in touch or learn more about the project, where might someone go?**
+
+[![]({{ "/images/news/supporter-spotlight-hans/FIXME.jpg?#right" | relative_url }})](https://FIXME.org/)
+
+David: FIXME: The best way to find out about F-Droid is, of course, the [main F-Droid homepage](https://f-droid.org/), but we are also on Twitter [@fdroidorg](https://twitter.com/fdroidorg). We have many avenues to participate and to learn more! We have an [About](https://f-droid.org/en/about/) page on our website and a [thriving forum](https://forum.f-droid.org/). We also have part of our documentation [specifically dedicated to reproducible builds](https://f-droid.org/en/docs/Reproducible_Builds/).
+
+<br>
+
+---
+
+<br>
+*For more information about the Reproducible Builds project, please see our website at
+[reproducible-builds.org]({{ "/" | relative_url }}). If you are interested in
+ensuring the ongoing security of the software that underpins our civilisation
+and wish to sponsor the Reproducible Builds project, please reach out to the
+project by emailing
+[contact at reproducible-builds.org](mailto:contact at reproducible-builds.org).*


=====================================
_reports/2022-11.md
=====================================
@@ -27,3 +27,7 @@ draft: true
 * [FIXME](https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606205.html)
 
 * [FIXME:FESCo is the Fedora Engineering Steering Committee: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH](https://pagure.io/fesco/issue/2899)
+
+* [FIXME: Simon Butler announced on the rb-general list](https://lists.reproducible-builds.org/pipermail/rb-general/2022-November/002761.html) that Software Quality Journal have published an
+article under open access called [On business adoption and use of reproducible builds for open and closed source software
+](https://link.springer.com/article/10.1007/s11219-022-09607-z). The article describes an interview study that focuses on the adoption and uses of of R-Bs in industry - with examples, and some pros and cons.



View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/compare/8f08f07f076aa872714693b4dd92d69058aae61e...822669938df2e9442ad8c4ffc4699c5bc723dec7

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/compare/8f08f07f076aa872714693b4dd92d69058aae61e...822669938df2e9442ad8c4ffc4699c5bc723dec7
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/20221130/271b8767/attachment.htm>