Distros' Default C/C++ Complier Options

[ran-dall]

As discussed on today's (3/1/23) phone call, I'm putting together a paper with the default compiler options used by each independent Linux distro.

https://docs.google.com/document/d/1QGyDVgu0bGdKkdSIIJMHW35R044vGLa6-9tVs86A4_8/edit?usp=sharing

[ran-dall]

@david-a-wheeler So far, I've added Debian and Ubuntu. I plan on adding Red Hat and Gentoo next (sometimes before our next meeting, hopefully, if possible).

[david-a-wheeler]

I recommend that we identify for each option flag the list of distros that use it, as that can help people gain confidence that it's okay or necessary to use/test with that option.

[david-a-wheeler]

Below are clarifications about what's happening on the compiler options draft work. Hopefully that clarifies some things (and if I got something wrong, please let me know).

--- David A. Wheeler

=======

The current draft of the "Compiler Options Hardening Guide for C and C++" is here: https://github.com/ossf/wg-best-practices-os-developers/blob/main/docs/Compiler_Hardening_Guides/Compiler-Options-Hardening-Guide-for-C-and-C%2B%2B.md

This is work originally developed & donated by Ericsson - thank you! The plan is for the community to build on it to have the "best available information".

@ran-dall is working to identify the default compiler options used by each independent Linux distro, with the goal of then comparing them. Indeed, I recommend that we identify for each option flag the list of distros that use it, as that can help people gain confidence that it's okay or necessary to use/test with that option. Issue: https://github.com/ossf/wg-best-practices-os-developers/issues/119 Identified list: https://docs.google.com/document/d/1QGyDVgu0bGdKkdSIIJMHW35R044vGLa6-9tVs86A4_8/edit?usp=sharing

We had started work on an earlier draft. The plan now is to take the more-complete contributed work, and merge in the information from our earlier work. This is tracked in this issue: https://github.com/ossf/wg-best-practices-os-developers/issues/97 The earlier work is here: https://docs.google.com/document/d/1SslnJuqbFUyTFnhzkhC_Q3PPGZ1zrG89COrS6LV6pz4/edit#

On Mar 1, 2023, at 2:57 PM, Randall @.***> wrote:

@david-a-wheeler So far, I've added Debian and Ubuntu. I plan on adding Red Hat and Gentoo next (sometimes before our next meeting, hopefully, if possible).

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[ran-dall]

I recommend that we identify for each option flag the list of distros that use it, as that can help people gain confidence that it's okay or necessary to use/test with that option.

@david-a-wheeler That's a good idea. I'll move things around.

[ran-dall]

@david-a-wheeler Also, FWIW, I've noticed that most distros will default GCC for all other binaries (i.e., not compiled by the Distro's Build process) to the GCC Built-In Specification by default. Perhaps identifying what that default is would be useful.

[david-a-wheeler]

All, FYI:

The OpenSSF Best Practices badge (formerly known as the CII Best Practices badge) has officially moved its production website from: https://bestpractices.coreinfrastructure.org https://bestpractices.coreinfrastructure.org/ to: https://www.bestpractices.dev https://www.bestpractices.dev/

People using the old URLs will be automatically redirected to the new ones. People who use "bestpractices.dev" instead of "www.bestpractices.dev http://www.bestpractices.dev/" will also be automatically redirected to the new domain name. So, for many people, this will be a relatively transparent chagne.

This process had more bumps than I expected, but I believe it's all working. If something is NOT working properly, PLEASE let me know. A big thank-you to the LF IT team, who helped me track down & debug some mysteries.

--- David A. WHeeler

P.S.: A few details if you're curious:

• I had to recreate the GitHub token to move the site. Therefore, the first time you login using GitHub (if you do), you'll need to re-authorize logging in with the GitHub. Text next to Sign in / Log in explains this.
• Email from the site will temporarily continue to use the old domain. We have to change the email system anyway, but I'm making that a separate change to minimize the risk of problems (and minimize debugging if there is a problem).
• Currently the redirects are 302 "Found" (temporary redirect). Once we're confident this all works well, we'll make the redirects a 301 (permanent redirect). We didn't want to use 301 at first, in case there was an unexpected problem.
• Once we have confidence in this, we'll want to update Scorecard and LFX so they immediately go to the correct domain name. That will immediately eliminate many redirects.
• We need to update the logo, again that'll be handled separately.