Skip to content

Add links from Compiler Options Hardening guide to Concise guides #851

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.

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

david-a-wheeler
Copy link
Contributor

No description provided.

Copy link
Contributor

@thomasnyman thomasnyman left a comment

Choose a reason for hiding this comment

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

lgtm

@@ -54,6 +54,8 @@ In this guide, we use the term *production code* for executable code intended fo

Developers should ensure that both their production code and their instrumented test code pass their automated test suite with all their relevant options. We encourage developers to consider it a bug if the program cannot be compiled with these options. Those who build production code may choose to omit some hardening options that hurt performance if the program only processes trusted data, but remember that it's not helpful to deploy programs that that are insecure and rapidly do the wrong thing. Existing programs may need to be modified over time to work with some of these options.

Flags can help counter some attacks, but not all. For more information on how to develop secure software, see the OpenSSF [Concise Guide for Developing More Secure Software](../Concise-Guide-for-Developing-More-Secure-Software). For more information on how to select secure open source software, see the OpenSSF [Concise Guide for Evaluating Open Source Software](../Concise-Guide-for-Evaluating-Open-Source-Software).
Copy link
Contributor

@thomasnyman thomasnyman Apr 17, 2025

Choose a reason for hiding this comment

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

Raised during the n C/C++ Compiler BP Guide Call 2025-04-17: If these were turned into absolute links they would also work for someone reading the guide on GitHub (and be future proof if we e.g., render a PDF version of the guide at some point).

@david-a-wheeler
Copy link
Contributor Author

I think internal links should be relative (just start with "#"). But that's not what this proposal is about.

Ideally references in the same repo should be relative, so that you can see the results of a PR that changes multiple files. However, I don't see a reasonable way to do that. If you link to the ".md" file, you get a not-pretty result. If you link to the ".html" file or a filename without extension, it won't exist unless you're regenerating the files locally (which most people won't do). So I reluctantly agree, if it's a different document, typically use an absolute reference so it works everywhere. One exception: if the original document in the repo is in .html format, you can use the relative link (and you should), as that will always work. We do that for labs, but not usually for anything else.

Copy link
Contributor

@gkunz gkunz left a comment

Choose a reason for hiding this comment

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

Agreed. Getting the links right is difficult... to impossible. I'd vote for keeping relative link for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants