https://bugzilla.redhat.com/show_bug.cgi?id=1987298 Ben Beasley <code@xxxxxxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(code@musicinmybra | |in.net) | --- Comment #6 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- I have added a build conditional to cease packaging the stb_include library: > # We choose not to package the “stb_include” library (stb_include.h) because it > # is so rife with old-school blithe C behavior—wanton use of strcat/strcpy into > # a fixed-length buffer that is assumed (but not proven) to be large enough for > # all possible uses, ignoring possible I/O errors (possibly leading to > # undefined behavior from reading uninitialized memory), and so on. Making it > # safe to use would mean a substantial rewrite. > # > # If a request for this library arises, this decision may be revisited, or the > # necessary rewrite may be done and offered upstream. For now, we omit the > # library and expect it will not be missed. > %bcond_with stb_include I also filed https://github.com/nothings/stb/issues/1193. I have patched some of the most serious and/or most easily fixed issues highlighted by the compiler warnings: https://github.com/nothings/stb/pull/1194 https://github.com/nothings/stb/pull/1195 https://github.com/nothings/stb/pull/1196 There are still some compiler warnings. Most are unused functions or variables—most of those related to preprocessor conditionals. Those warnings that still hint at real issues are difficult to evaluate. I filed one additional issue, https://github.com/nothings/stb/issues/1197. I am leaving this alone: > In file included from /usr/include/string.h:519, > from ../stb_ds.h:395, > from test_cpp_compilation.cpp:13: > In function 'memcpy', > inlined from 'stbi__getn(stbi__context*, unsigned char*, int)' at ../stb_image.h:1653:16, > inlined from 'stbi__parse_png_file(stbi__png*, int, int) [clone .constprop.0]' at ../stb_image.h:5123:28: > /usr/include/bits/string_fortified.h:29:33: warning: 'memcpy' specified bound between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] > 29 | return __builtin___memcpy_chk (__dest, __src, __len, > | ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~ > 30 | __glibc_objsize0 (__dest)); > | ~~~~~~~~~~~~~~~~~~~~~~~~~~ which I *think* is pointing out that a sufficiently large 32-bit unsigned chunk length may be cast to a negative int, which is then interpreted as a huge positive number of bytes to memcpy; but whether this can actually happen in practice is much harder to tell. (I ignore here the possibility that int could be shorter than 32 bits on some platform…) In any case, I’m sure that looking closely and turning over a few rocks (i.e., compiling with clang-analyzer/scan-build, or trying to fuzz some of the libraries) could reveal dozens of similar issues in short order. Still, let me know if you think there’s anything else I should deal with before proceeding with the package. Updated spec URL: https://music.fedorapeople.org/20210819/stb.spec Updated SRPM URL: https://music.fedorapeople.org/20210819/stb-0-0.1.20210728git3a11740.fc34.src.rpm -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
