[Git][reproducible-builds/reproducible-website][master] Make a few more smaller changes to Kees' post.

[Chris Lamb (@lamby)]

Chris Lamb pushed to branch master at Reproducible Builds / reproducible-website


Commits:
f13914e5 by Chris Lamb at 2024-09-23T12:37:12-07:00
Make a few more smaller changes to Kees' post.

- - - - -


1 changed file:

- _posts/2024-08-01-supporter-spotlight-kees-cook.md


Changes:

=====================================
_posts/2024-08-01-supporter-spotlight-kees-cook.md
=====================================
@@ -44,14 +44,16 @@ easy it is to subvert bugs. I wanted to improve that fragility.  In 2006, I
 started working at Canonical on Ubuntu and was mainly focusing on bringing
 Debian and Ubuntu up to what was the state of the art for Fedora and Gentoo's
 security hardening efforts. Both had really pioneered a lot of userspace
-hardening with compiler flags and ELF stuff and many other things for hardened
+hardening with compiler flags and [ELF](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format)
+stuff and many other things for hardened
 binaries. On the whole, Debian had not really paid attention to it. Debian's
 packaging building process at the time was sort of a chaotic free-for-all as
 there wasn't centralized build methodology for defining things. Luckily that
 did slowly change over the years. In Ubuntu we had the opportunity to apply top
 down build rules for hardening all the packages. In 2011 Chrome OS was
 following along and took advantage of a bunch of the security hardening work as
-they were based on `ebuild` out of Gentoo and when they looked for someone to
+they were based on [`ebuild`](https://wiki.gentoo.org/wiki/Ebuild) out of Gentoo
+and when they looked for someone to
 help out they reached out to me. We recognized the Linux kernel was pretty much
 the weakest link in the Chrome OS security posture and I joined them to help
 solve that.  Their userspace was pretty well handled but the kernel had a lot
@@ -75,7 +77,7 @@ when it wasn't already their job.
 [![](https://placehold.co/185x140#right)](FIXME)
 
 **Vagrant: So my understanding of some of your recent work is basically
-defining undefined behavior in the language or compiler?**
+defining [undefined behavior](https://en.wikipedia.org/wiki/Undefined_behavior) in the language or compiler?**
 
 **Kees:** I've found the term "undefined behavior" to have a really strict
 meaning within the compiler community, so I have tried to redefine my goal as
@@ -173,7 +175,7 @@ class of flaws in C.
 in which that might affect your work?**
 
 **Kees:** One of the questions I frequently get is, "What version of the Linux
-kernel has feature $foo?" If I know how things are built, I can answer with
+kernel has feature *$foo*?" If I know how things are built, I can answer with
 just a version number. In a Reproducible Builds scenario I can count on the
 compiler version, compiler flags, kernel configuration, etc. all those things
 are known, so I can actually answer definitively that a certain feature exists.
@@ -184,7 +186,7 @@ testing.
 
 <br>
 
-**Vagrant: Have you used *diffoscope*?**
+**Vagrant: Have you used [*diffoscope*](https://diffoscope.org/)?**
 
 **Kees:** I have! One subset of tree-wide refactoring that we do when getting
 rid of ambiguous language usage in the kernel is when we have to make source
@@ -216,7 +218,7 @@ diffoscope is definitely the default. Diffoscope is awesome!
 **Vagrant: Where has reproducible builds affected you?**
 
 **Kees:** One of the notable wins of reproducible builds lately was
-dealing with the fallout of the XZ backdoor and just being able to ask
+dealing with the fallout of the [XZ backdoor](https://en.wikipedia.org/wiki/XZ_Utils_backdoor) and just being able to ask
 the question "is my build environment running the expected
 code?" and to be able to compare the output generated from one
 install that never had a vulnerable XZ and one that did have a



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

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/f13914e55fcf7de0eae8dc0e987bca08bf28b9fe
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/20240923/ab2e87f9/attachment.htm>