Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Provide recommendation to counter xz utils style attack #560

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Provide recommendation to counter xz utils style attack #560

Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
e065ab2
Provide recommendation to counter xz utils style attack
david-a-wheeler Jul 5, 2024
01d5e05
Fix grammar nit in xz utils response
david-a-wheeler Jul 5, 2024
64f4159
Clarify text
david-a-wheeler Nov 5, 2024
093b41f
Merge branch 'main' into xz_utils_counter
david-a-wheeler Nov 5, 2024
c38c1b9
Fix emphasis for markdownlint
david-a-wheeler Nov 5, 2024
f8f0507
Fix emphasis for markdownlint
david-a-wheeler Nov 5, 2024
f0a63e4
Update docs/Concise-Guide-for-Developing-More-Secure-Software.md
david-a-wheeler Nov 7, 2024
3354518
Clarify source package should only include VCS materials
david-a-wheeler Nov 7, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion docs/Concise-Guide-for-Developing-More-Secure-Software.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,7 @@ Here is a concise guide for all software developers for secure software developm
24. **Continuously improve**. Improve scores, look for tips, & apply as appropriate.
25. **Manage succession**. Have clear governance & work to add active, trustworthy maintainer(s).
26. **Prefer memory-safe languages**. Many vulnerabilities involve memory safety. Where practical, use memory-safe programming languages (most are) and keep memory safety enabled. Otherwise, use mechanisms like extra tools and peer review to reduce risk.
27. **Ensure production websites only load assets from your own domains**. _Linking_ to other domains is fine, but where practical, don't directly load assets such as JavaScript, CSS, and media (including images) from domains you do not control. If you do, your site might be subverted if that other domain is subverted, so investigate the risks before doing so. See the [subverted polyfill.io revelation in 2024](https://blog.qualys.com/vulnerabilities-threat-research/2024/06/28/polyfill-io-supply-chain-attack).
27. **If a source code (unbuilt) package is released, it should only include content from the version control system (VCS), and source package users should rebuild to create production (built) package(s)**. E.g., if autotools is used, if a source package is released it should _not_ include a generated `configure` file, while recipients should ignore pre-generated files like `configure` and instead rebuild from source (e.g., with `autoreconf`). This eliminates a malware-hiding mechanism, as illustrated by an attack on [xz utils](https://access.redhat.com/security/cve/CVE-2024-3094).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unbuilt packages are also production packages, for scripting languages - is there another way to phrase this?

Suggested change
27. **If a source code (unbuilt) package is released, it should only include content from the version control system (VCS), and source package users should rebuild to create production (built) package(s)**. E.g., if autotools is used, if a source package is released it should _not_ include a generated `configure` file, while recipients should ignore pre-generated files like `configure` and instead rebuild from source (e.g., with `autoreconf`). This eliminates a malware-hiding mechanism, as illustrated by an attack on [xz utils](https://access.redhat.com/security/cve/CVE-2024-3094).
27. **If a source code (unbuilt) package is released, it should only include content from the version control system (VCS), and source package users should rebuild, if needed, to create production (built) package(s)**. E.g., if autotools is used, if a source package is released it should _not_ include a generated `configure` file, while recipients should ignore pre-generated files like `configure` and instead rebuild from source (e.g., with `autoreconf`). This eliminates a malware-hiding mechanism, as illustrated by an attack on [xz utils](https://access.redhat.com/security/cve/CVE-2024-3094).

28. **Ensure production websites only load assets from your own domains**. _Linking_ to other domains is fine, but where practical, don't directly load assets such as JavaScript, CSS, and media (including images) from domains you do not control. If you do, your site might be subverted if that other domain is subverted, so investigate the risks before doing so. See the [subverted polyfill.io revelation in 2024](https://blog.qualys.com/vulnerabilities-threat-research/2024/06/28/polyfill-io-supply-chain-attack).

We welcome suggestions and updates! Please open an [issue](https://github.com/ossf/wg-best-practices-os-developers/issues/) or post a [pull request](https://github.com/ossf/wg-best-practices-os-developers/pulls).
Loading