Hello folks, am I allowed to override -D_FORTIFY_SOURCE=2 with -D_FORTIFY_SOURCE=0 for my Zarafa package until either upstream fixed their code or until glibc is making their protection check more flexible? I already read the Packaging Guidelines, but they still leave open, what's happening, if I am doing it. Our glibc > 2.14.90-8 contains a commit which adds range checking to FD_SET and friends (http://sourceware.org/ml/glibc-cvs/2011-q3/msg00235.html). I also found http://sourceware.org/bugzilla/show_bug.cgi?id=10352 meanwhile, and it's funny to see that Ulrich Drepper implemented what he didn't even want to revisit in the bug report. Finally, that FD_SET range checking causes Zarafa to segfault once it has been built using glibc > 2.14.90-8 (which is Fedora 16+), __fdelt_chk() is simply called as they use more than 1024 file descriptors. https://bugzilla.redhat.com/show_bug.cgi?id=760888 contains whole story, I sat down with Jan Kratochvil to identify the cause, communicated with the Zarafa developers and with Jeff Law, our glibc package maintainer. And also with Adam Jackson on IRC. The feedback from the Zarafa developers was, that the check in glibc is a good idea, but based on wrong assumptions. Together with the upcoming mass- rebuild they think, we could have a lot of fun, because many software will possibly run into __fdelt_chk(). I hope, I summarized them correct. I'm not a developer/programmer, but from what I get > 1024 file descriptors work under certain conditions and if correctly developed and thus the glibc range check is maybe not flexible enough. From the BSD 4.2 FD_SET man page (http://www.manpagez.com/man/2/FD_SET/): > [...] The default size FD_SETSIZE (currently 1024) is somewhat smaller > than the current kernel limit to the number of open files. However, in > order to accommodate programs which might potentially use a larger number > of open files with select, it is possible to increase this size within a > program by providing a larger definition of FD_SETSIZE before the > inclusion of <sys/types.h>. [...] I might be wrong, but that is what Zarafa is doing and what glibc code is not covering. Maybe somebody with proper knowledge can have a look to this once more? Thanks! > # Segmentation faults with glibc > 2.14.90-8, see RHBZ #760888 > export CXXFLAGS="${RPM_OPT_FLAGS/-D_FORTIFY_SOURCE=2/-D_FORTIFY_SOURCE=0}" Above is the snippet, that I would like to introduce into the spec file for the time being and to get the software up and running again. As you can see in the bug report, there are users running into this issue. Greetings, Robert
Attachment:
pgpO7CN5Q_5Ah.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
