Aren't there many other specs file already in use for rpm builds? At least that was the case when I was looking at this, there were already 3 others in use iirc

What packages are failing?

Hmm, with afl, I see a bunch of:
clang-14: warning: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' [-Wunused-command-line-argument]
clang-14: warning: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1' [-Wunused-command-line-argument]
clang-14: warning: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' [-Wunused-command-line-argument]
clang-14: warning: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1' [-Wunused-command-line-argument]
clang-14: warning: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-package-notes' [-Wunused-command-line-argument]

Does this means that packages compiled with clang were ignoring hardening flags all along?

Looks like clang has "configuration files" which are essentially the same thing (obviously with a different name and syntax, because who needs cross-toolchain compatibility), can we use those? https://clang.llvm.org/docs/UsersManual.html#configuration-files

There are a different set of CFLAGS for clang and gcc:

https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_298

afl is using the gcc flags, because it doesn't set the toolchain macro in it's spec file (e.g. %global toolchain clang).

clang only accepts one --config option per compile, and clang is already using a config rile for the hardening changes.  Can we just pass the -Wl,--package-metadata= directly to the ldflags instead of using a config file?

> Can we just pass the -Wl,--package-metadata= directly to the ldflags instead of using a config file?

We tried, but it seems impossible to get it to work because of spurious unquoting that occurs
with various build systems. E.g. libtool pushes the flags through one or two levels of shell
interpretation: from '-Wl,--package-metadata={"name":"foo","version":"11"}' to
'-Wl,--package-metadata=name:foo -Wl,--package-metadata=version:11' in the actual program call.
This could be possibly made to work, if we add enough escaping, but then build systems which
don't do the equivalent expansion get the wrong value. It seems that there's no way to get this
to work, and the spec files are a work-around.

> clang only accepts one --config option per compile, and clang is already using a config rile for the hardening changes

I had no idea about this. I regularly use clang for testing, but I never had any package using it ;(

How does it work with annobin and such? For gcc, we already had 3 spec files, and this was the fourth.

Can we append to the config file that is already in use? Or alternatively can clang support multiple config files like gcc supports multiple spec files? Or even better just add support for spec files so that there's command line compatibility?

Config files can include other config files, so you could have the package note config file include /usr/lib/rpm/redhat/redhat-hardened-clang.cfg and then overwrite %_hardening_clang_cflags with /path/to/package-notes/config.  This is a little bit fragile though, because we would have to know not to add any other flags to /usr/lib/rpm/redhat/redhat-hardened-clang.cfg.

There was a proposal to support multiple config files at one point, I don't think it's been implemented though.  spec file support would be a big project.  We could look into that, but it's not going to be implemented any time soon.  The other option would be to disable the package notes when %toolchain == "clang" while we work on one of the solutions.

Yeah we should definitely disable it in the short term. In the medium term, maybe unify into a single clang config that supports all -specs? Then hopefully multi-config supports arrives. Would be good if you could prod upstream about it, as it's clearly quite useful to have.

https://src.fedoraproject.org/rpms/package-notes/pull-request/8

FEDORA-2022-8a43bce16c has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-8a43bce16c

FEDORA-2022-8a43bce16c has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-8a43bce16c`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8a43bce16c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-8a43bce16c has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.