Hi,

This is underwhelming and I have several questions inline

https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to
improve mitigation of security issues arising from buffer overflows in
packages in Fedora.

== Owner ==
* Name: [[User:siddhesh| Siddhesh Poyarekar]]
* Email: sipoyare@redhat.com


== Detailed Description ==

Default C and C++ compiler flags to build packages in Fedora currently
includes `-Wp,-D_FORTIFY_SOURCE=2`, which enables fortification of
some functions in glibc, thus providing some mitigation against buffer
overflows.  Since glibc 2.34 and GCC 12, there has been a new
fortification level (`_FORTIFY_SOURCE=3`) which improves the coverage
of this mitigation.

The core change to bring in this mitigation is to change the default
build flags in `redhat-rpm-config` so that packages build by default
with `-Wp,-D_FORTIFY_SOURCE=3`. There are packages (e.g. `systemd`)
that do not interact well with `_FORTIFY_SOURCE` and will also need a
workaround to downgrade fortification to level 2. The change will also
include this override.

How come systemd gets an exception? If it is a security option, it should be enabled everywhere.

I do not see benefit in a security change that ignores PID 1 process,

If the feature, on the GCC side, is not 100% done.
How do I tell a difference of a bug with the _FORTIFY_SOURCE which I will ignore and a bug with my package?

I do not have the knowledge or the time to be able to say that GCC generated the wrong machine code and therefore it is not a bug with my package.
If my program was not complaining before the change and is now complaining with the change, I am opting out of the change, and filing a bug against GCC on Fedora.

I assume that by the package providing the exception, packagers get to choose themselves and we do not need to go through FESCO
to disable a security feature?

== Benefit to Fedora ==

[https://docs.google.com/spreadsheets/d/1nPSmbEf3HVB91zI8yBraMqVry3_ILmlV2Z5K7FZeHZg/edit?usp=sharing
Analysis of packages] in Fedora rawhide indicate that the improvement
of mitigation coverage is on average over 2.4x, in some cases
protecting more than half of the fortified glibc calls in the target
application.

This change will thus harden Fedora to a significant extent, thus
making it a more secure distribution out of the box.

1) Is there some complete source for all these findings? If google sheets cannot handle all the "raw data" as noted in the comment,
maybe it is the wrong medium.

2) What does *anything* on that google sheet mean. I have managed to figure out, from the article, that bos and bdos correspond to level 2 and 3 of _FORTIFY_SOURCE.
However, total of /.*/? Violated accesses? Segfaults? Then followed by "Sum of total". For rubygem-ffi, this reaches into hundreds while "bdos" is 2. That is the only sum I can make, with the data provided.
I am no wiser from looking at it, what do the data mean?

3) I cannot speak to much else than Ruby, I do not see ruby in neither the failures or "All x86_64". Should we attempt to test it ourselves?

Please provide a proper "how to test" section, I cannot fix what I cannot test or compare results when I have no idea what I am seeing.

Actually, last time I heard about number of packages, it was around 50k (not source, build result), and as I stated,
Ruby is missing, and so are quite a few dependent packages that should have GCC involved somewhere:
~~~
$ dnf repoquery --whatrequires "*libruby.so*" --disablerepo="*" --enablerepo="fedora" 2>/dev/null | grep -v "i686" | uniq | wc -l
115
~~~

If we also filter rubygem-* packages that depend on the *libruby.so* (and most probably contain a binary extension written in C/C++ that links to Ruby), I get 68 packages.
When I search "All x86_64" for "ruby" I get 28 packages. That is... not adding up.

== Scope ==
* Proposal owners: Post a merge request to redhat-rpm-config with the
actual change to build flags.

* Other developers:
Resolve bugs filed for build failures, either by fixing the bug
exposed by `_FORTIFY_SOURCE=3` or by disabling `_FORTIFY_SOURCE=3` for
the package if it is a false positive or if the package is unable to
adapt to the change.

* Release engineering: Mass rebuild required
* Policies and guidelines: Guidelines should include workaround for
packages that fail to build with `-Wp,-D_FORTIFY_SOURCE=3` due to a
false positive.

I'll just ask, what is a false positive. How can I tell. What are the steps for this.

* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
No ABI change, so there should be no impact on compatibility in a
mixed environment.

== How To Test ==
* Smoke testing of packages to ensure that they continue to work
correctly. Some packages may have overflows exposed at runtime, which
may need to be fixed.

This does not describe how to test, e.g. ahead of time, just that the packagers are to deal with the fallout...

== User Experience ==
No noticeable change to users.

I beg to differ. From what I am able to tell, from the limited provided sources, packages can have a runtime crash.

A LOT of GUI packages use C or the likes that respond to the flags of "fortify source".
This can have a serious impact to users by the recompiled packages:
* not suddenly working, package's tests passed, but user triggered just the right code branch
* performance impacted due to overhead.

== Dependencies ==
None.

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) If too many
packages are found to be broken at runtime, the default for
fortification will be left at `_FORTIFY_SOURCE=2` for Fedora 38.
Change owner will do this in `redhat-rpm-config`

* Contingency deadline: Beta freeze
* Blocks release? Yes
* Blocks product? No

== Documentation ==

[https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#
More context on `_FORTIFY_SOURCE=3` improvements].

== Release Notes ==

Regards,

Jarek Prokop