Merge pull request #100 from ossf/fix_links

Fix links

Author: david-a-wheeler

.github/linters/.markdown-lint.yml

@@ -10,7 +10,3 @@ MD049: false # MD049/emphasis-style
 MD012: false # MD012/no-multiple-blank
 MD024: false # MD024/no-duplicate-heading/no-duplicate-header
 MD001: false # MD001/heading-increment/header-increment
-# Fix these when you can:
-MD042: false # MD042/no-empty-links
-MD051: false # MD051/link-fragments Link fragments should be valid
-

README.md

@@ -21,6 +21,8 @@ to file [issues](https://github.com/ossf/secure-sw-dev-fundamentals/issues) for
 [secure-sw-dev-fundamentals](https://github.com/ossf/secure-sw-dev-fundamentals)
 project. Changes that are accepted into the Markdown must go through a series of internal steps in coordination with LF Training & Certification so that the changes will be deployed to both the LF Training and edX platforms.
 
+Changes to the markdown must have no errors reported by `markdownlint` using our configuration. This is checked when a pull request is made. You can do this check locally by installing markdownlint (e.g., `brew install markdownlint-cli` or `npm install -g markdownlint-cli`) and running `make`.
+
 This content was originally converted from Google docs format using
 [gdocs2md](http://github.com/mangini/gdocs2md),
 patched to skip inline drawings.

secure_software_development_fundamentals.md

@@ -39,6 +39,8 @@ For more, see [5 Stupid Grammar Rules You Should Never Follow Because They Make
 
 Note that edX requires groupings at 3 levels: Sections, Subsections, and Units. Only Units (level 3) can have content.  We represent this in the material below as follows:  A “Heading 1” represents the beginning of a Section and contains ONLY sequences beginning with “Heading 2” (no text). A “Heading 2” represents the beginning of a Subsection and contains ONLY sequences beginning with “Heading 3”. A “Heading 3” represents the beginning of a Unit and contains all content. A Heading 3 cannot be directly contained within a Heading 1. Heading 4 (and below) are used freely within a Unit.
 
+The primary editable content is in markdown format. There should be no markdownlint errors using our configuration. You can add hyperlinks to internal sections as #<i>section_name</i> where <i>section_name</i> is the title transformed using GitHub's [`gfm_auto_identifiers`](https://pandoc.org/MANUAL.html#extension-gfm_auto_identifiers) algorithm: space becomes `-`, uppercase (ASCII) becomes lowercase, and punctuation (other than `-` and `_`) are removed.
+
 **About this course (Part 1)**
 
 Modern software is under constant attack, but many software developers have never been told how to effectively counter those attacks. This course works to solve that problem, by explaining the fundamentals of developing secure software. Geared towards software developers, DevOps professionals, software engineers, web application developers, and others interested in learning how to develop secure software, this course focuses on practical steps that can be taken, even with limited resources, to improve information security. This course will enable software developers to create and maintain systems that are much harder to successfully attack, reduce the damage when attacks are successful, and speed the response so that any latent vulnerabilities can be rapidly repaired.
@@ -2276,7 +2278,7 @@ One of the simplest ways to ensure an attacker cannot trigger vulnerabilities fr
 
 > 😱 STORY TIME: NetUSB CVE-2021-45608
 
-> An example of an integer overflow leading to a vulnerability is [CVE-2021-45608](), as explained in “[CVE-2021-45608 | NetUSB RCE Flaw in Millions of End User Routers](https://www.sentinelone.com/labs/cve-2021-45608-netusb-rce-flaw-in-millions-of-end-user-routers/)” by Sentinel Labs.  The KCodes NetUSB kernel module, used by a large number of network device vendors, had an integer overflow vulnerability. The module took an untrusted client-provided length, added 0x11, and allocated that amount of memory. If the requested length was large (e.g., all 1s in binary), the addition would wrap around, causing a too-small allocation. After that, data would be dumped into the too-small buffer, leading to a buffer overflow.
+> An example of an integer overflow leading to a vulnerability is [CVE-2021-45608](https://nvd.nist.gov/vuln/detail/CVE-2021-45608), as explained in “[CVE-2021-45608 | NetUSB RCE Flaw in Millions of End User Routers](https://www.sentinelone.com/labs/cve-2021-45608-netusb-rce-flaw-in-millions-of-end-user-routers/)” by Sentinel Labs.  The KCodes NetUSB kernel module, used by a large number of network device vendors, had an integer overflow vulnerability. The module took an untrusted client-provided length, added 0x11, and allocated that amount of memory. If the requested length was large (e.g., all 1s in binary), the addition would wrap around, causing a too-small allocation. After that, data would be dumped into the too-small buffer, leading to a buffer overflow.
 >
 > This shows that it’s important to check for wraparound when using attacker-controlled data, especially if you use it to make size or out-of-range decisions. Other rules can be learned as well. First, always validate data from an untrusted source (e.g., data from the Internet) - there was no reason to allow any allocation request this big. Second, this module listened to requests from the wide-area network (WAN) instead of just the local area network (LAN); software should minimize privilege to only what's needed to reduce the likelihood or impact of damage if there is a vulnerability.
 
@@ -2822,7 +2824,7 @@ Be careful about displaying or storing pathnames, since they can include newline
 
 Once you have a pathname, you often want to do something with it, such as try to open that file.
 
-As discussed in [“Beware of Race Conditions”](#beware_of_race_conditions), open files in ways that prevent time-of-check time-of-use (TOCTOU) race conditions. Open a file directly instead of querying if the access is permitted (since that may change). Include the “exclusive” option (“<tt>x</tt>” or `O_EXCL`) if you want to expressly require that the file be created. If you’re creating temporary files, use interfaces specifically designed to securely create temporary files.
+As discussed in [“Beware of Race Conditions”](#beware-of-race-conditions), open files in ways that prevent time-of-check time-of-use (TOCTOU) race conditions. Open a file directly instead of querying if the access is permitted (since that may change). Include the “exclusive” option (“<tt>x</tt>” or `O_EXCL`) if you want to expressly require that the file be created. If you’re creating temporary files, use interfaces specifically designed to securely create temporary files.
 
 If your software might open a file system object (including a directory) that an attacker might control, be prepared for it. One way this can happen that we have not yet discussed is improper link resolution.
 
@@ -4895,7 +4897,7 @@ Where practical, harden the development environment and distribution environment
 
 The build process should be fully scripted/automated. That way builds will be performed predictably each time. Where possible, the build system should provide provenance information, that is, record what components were included in the build and ideally what components were used to perform the build. Be careful when logging a build process; often you want to avoid recording in log files any secrets like active authentication tokens.
 
-Build, verification, and distribution processes (including CI/CD pipelines) often bring in many other reusable software components. Make sure you apply the good practices discussed in the course sections on (1) [Selecting Reusable Software](#selecting_reusable_software) and (2) [Downloading and Installing Reusable Software](#downloading_and_installing_reusable_software).
+Build, verification, and distribution processes (including CI/CD pipelines) often bring in many other reusable software components. Make sure you apply the good practices discussed in the course sections on (1) [Selecting (Evaluating) Open Source Software](#selecting-evaluating-open-source-software) and (2) [Downloading and Installing Reusable Software](#downloading-and-installing-reusable-software).
 
 Supply chain Levels for Software Artifacts, or SLSA (“salsa”), is a security framework being developed as a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. At the time of this writing it is still in development, but you should consider its recommendations. SLSA is being developed under the Open Source Security Foundation (OpenSSF). To learn more, see the SLSA home page at <https://slsa.dev/>.