Skip to content

Commit

Permalink
Fix wording of commit messages
Browse files Browse the repository at this point in the history
Co-authored-by: Jonah Aragon <[email protected]>
  • Loading branch information
dngray and jonaharagon committed Apr 11, 2024
1 parent 2bc01b1 commit bef1766
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion docs/basics/common-threats.md
Original file line number Diff line number Diff line change
Expand Up @@ -80,7 +80,7 @@ These sorts of attacks can require a lot of time and preparation to perform and
1. Only adopting popular software that has been around for a while. The more interest in a project the greater likelihood that external parties will notice malicious changes. A malicious actor will also need to spend more time gaining community trust with meaningful contributions.
2. Finding software which releases binaries with widely-used, trusted build infrastructure platforms, as opposed to developer workstations or self-hosted servers. Some systems like GitHub Actions let you inspect the build script that runs publicly for extra confidence. This lessens the likelihood that malware on a developer's machine could infect their packages, and gives confidence that the binaries produced are in fact produced correctly.
3. Looking for code signing on individual source code commits and releases, which creates an auditable trail of who did what. For example: Was the malicious code in the software repository? Which developer added it? Was it added during the build process?
4. In open source projects the code should have meaningful commit messages (such as [conventional commits](https://conventionalcommits.org)) which explain what the change is supposed accomplish. Clear messages make it easier for outsiders to the project to verify, audit and find bugs.
4. Checking whether the source code has meaningful commit messages (such as [conventional commits](https://conventionalcommits.org)) which explain what the change is supposed to accomplish. Clear messages can make it easier for outsiders to the project to verify, audit, and find bugs.
5. Noting the number of contributors or maintainers a program has. A lone developer may be more susceptible to being coerced into adding malicious code by an external party, or to negligently enable undesirable behavior. This may very well mean software developed by "Big Tech" has more scrutiny than a lone developer who doesn't answer to anyone.

## Privacy From Service Providers
Expand Down

0 comments on commit bef1766

Please sign in to comment.