-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
build: enable missing OpenSSF-recommended warnings, with fixes
https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C .html as of 2023-11-29 [1]. Enable new recommended warnings (except `-Wsign-conversion`): - enable `-Wformat=2` for clang (in both cmake and autotools). - add `CURL_PRINTF()` internal attribute and mark functions accepting printf arguments with it. This is a copy of existing `CURL_TEMP_PRINTF()` but using `__printf__` to make it compatible with redefinting the `printf` symbol: https://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_5.html#SEC94 - fix `CURL_PRINTF()` and existing `CURL_TEMP_PRINTF()` for mingw-w64 and enable it on this platform. - enable `-Wimplicit-fallthrough`. - enable `-Wtrampolines`. - add `-Wsign-conversion` commented with a FIXME. - cmake: enable `-pedantic-errors` the way we do it with autotools. Follow-up to d5c0351 #2747 - lib/curl_trc.h: use `CURL_FORMAT()`, this also fixes it to enable format checks. Previously it was always disabled due to the internal `printf` macro. Fix them: - fix bug where an `set_ipv6_v6only()` call was missed in builds with `--disable-verbose` / `CURL_DISABLE_VERBOSE_STRINGS=ON`. - add internal `FALLTHROUGH()` macro. - replace obsolete fall-through comments with `FALLTHROUGH()`. - fix fallthrough markups: Delete redundant ones (showing up as warnings in most cases). Add missing ones. Fix indentation. - silence `-Wformat-nonliteral` warnings with llvm/clang. - fix one `-Wformat-nonliteral` warning. - fix new `-Wformat` and `-Wformat-security` warnings. - fix `CURL_FORMAT_SOCKET_T` value for mingw-w64. Also move its definition to `lib/curl_setup.h` allowing use in `tests/server`. - lib: fix two wrongly passed string arguments in log outputs. Co-authored-by: Jay Satiro - fix new `-Wformat` warnings on mingw-w64. [1] https://github.com/ossf/wg-best-practices-os-developers/blob/56c0fde3895bfc55c8a973ef49a2572c507b2ae1/docs/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.md Closes #12489
- Loading branch information
Showing
88 changed files
with
531 additions
and
318 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
3829759
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.
This commit makes the code look like shit IMHO. Why not hide these awful pragmas in a macro:
3829759
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.
I don't think that helps with the "shit" look, but that's entirely subjective.
I prefer the committed version because it's clear at first sight what it
does without having to look up a custom macro, which IMO doesn't add
much. This pattern is used 20 times total, in low-level code that rarely
anybody needs to read.
3829759
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.
I meant no offence, but as you say it's subjective.
But why don't put these one place at the global-level? Or are there other places were these warnings are useful?
3829759
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.
I think the premiss of this warning is useful and may catch real issues
where the mask is coming from an input and thus user controlled, which
is exploitable. Thus, disabling it globally wouldn't be the best solution.
Enabling it was in fact the main point of this commit, to follow the (IMO
sensible) recommendation from OpenSSF.
A better path would be to reduce the code which uses this pattern, or
find any upstream calls that may be passing down format strings to
these internal functions without a matching
CURL_PRINTF()
attribute.I haven't traced back all of them, and may have missed valid issues, so
some of these warning suppressions may be premature or optimistic.
On the upside they are now trivial to spot or look up in the code.
...a quick review revealed a missing
CURL_PRINTF()
forimap_sendf()
,and probably all dbg functions could be fixed the same way as done in
tool_ipfs.c
in this patch, to avoid passing a variable format string.Though it will make the code more verbose.
edit: as for the dbg function, it rather looks like it's just a hack to fixup
the format string for various socket type sizes, but we have a macro
for that. We'll see in a PR.
3829759
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.
PR #12540
3829759
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.
Continuing on this, it turned out that most of the "shit" pragmas were
redundant after all. After #12812, only six of them remain.
3829759
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.
Down to 3 with #12814.