-
Notifications
You must be signed in to change notification settings - Fork 157
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
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: David A. Wheeler <[email protected]>
There was a problem hiding this 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). |
There was a problem hiding this comment.
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).
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. |
There was a problem hiding this 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.
No description provided.