Description of problem: krb5-config returns wrong hardening paths (missing /usr/lib/) Version-Release number of selected component (if applicable): krb5-devel-1.13.1-2.fc23 How reproducible: deterministic Steps to Reproduce: # /usr/bin/krb5-config --libs Actual results: -specs=/rpm/redhat/redhat-hardened-ld -lkrb5 -lk5crypto -lcom_err Expected results: -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lkrb5 -lk5crypto -lcom_err Additional info: Please fix ASAP. Openssh package configure (maybe others) depends on this.
or do not return -specs like in f21: -lkrb5 -lk5crypto -lcom_err
(In reply to Jakub Jelen from comment #0) > Description of problem: > krb5-config returns wrong hardening paths (missing /usr/lib/) > > Version-Release number of selected component (if applicable): > krb5-devel-1.13.1-2.fc23 > > How reproducible: > deterministic > > Steps to Reproduce: > # /usr/bin/krb5-config --libs > > > Actual results: > -specs=/rpm/redhat/redhat-hardened-ld -lkrb5 -lk5crypto -lcom_err > > Expected results: > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lkrb5 -lk5crypto -lcom_err > > Additional info: > Please fix ASAP. Openssh package configure (maybe others) depends on this. I do not agree with expected result. The hardened build flags should be in cflags and ldflags in the same time or they should not be present at all. Actual result on fedora rawhide: [root@rawhide /]# krb5-config --cflags krb5 [root@rawhide /]# krb5-config --libs krb5 -specs=/rpm/redhat/redhat-hardened-ld -lkrb5 -lk5crypto -lcom_err I would prefer to remove it and each application should decide whether it want hardened build or don't want and behaviour of krb5-config will be the same as on fedora 22: Actual result on fedora 22 (expected the same result on fedora rawhide) [root@f22 ~]# krb5-config --cflags krb5 [root@f22 ~]# krb5-config --libs krb5 -lkrb5 -lk5crypto -lcom_err
Yes. You are right. I am also for your proposed result as stated in comment #1. But I was writing too fast and referring to results from rawhide.
It would be good to fix this BZ very fast because fedora rawhide has 89 packages which build requirement to krb5-devel. I's very likely most of them use krb5-config for detecting *flags. [root@host ~]# repoquery --enablerepo=fedora-source --archlist=src --whatrequires krb5-devel | wc -l 89
One way to fix it is to make dependent packages use pkg-config instead ...
I opened http://krbdev.mit.edu/rt/Ticket/Display.html?id=8159 (not visibile yet), and had a chat with MIT after having a discussion on #fedora-devel On #fedora-devel the consensus is that although the hack to harden is a hask it is krb5-config thast is wonky in the way it munged LDFLAGS. Howeever MIT disagrees as krb5-config always did it. For 1.13 we have only 2 options: 1) Disable hardening in krb5: I tried a scratch build with %global _configure_libtool_hardening_hack 0 2) Downstream patch the krb5 vuild to strip -spec=<whatever> from krb5-config output I currently "resolved" the problem of building gssproxy 0.4.0 (which made me look into this problem) by simply ditching krb5-config and using pkg-config instead.
I think the -spec option should be stripped out, leaving it to the application to decide how to be built. It's also consistent with pkg-config results. I can understand that upstream do not fully understand the problem. It is not a regression in krb5, but a change in what LDFLAGS are specified during the build and embedded in krb5-config triggering new problems with old code in krb5-config. There is actually two problems with krb5-config here a) It munges any build time LDFLAGS/CFLAGS which includes /usr/lib, regardless of where this is. The line causing this is: lib_flags=`echo $lib_flags | sed -e "s#-L$libdir##" -e "s#$RPATH_FLAG$libdir##"` where RPATH_FLAG is empty in the Fedora build. Likely upstream do not expect RPATH_FLAG to be empty. b) The "new" -spec= option added by Fedora is not stripped out. It is stripped out from pkg-config template, giving inconsistent result between pkg-config and krb5-config. The simplest way to fix 'b' is to edit it out from the spec file after compilation, together with any other (if any) Fedora packaging build time option that should not be automatically inherited by user applications using krb5. How is the pkg-config template defined to not have -spec= flag?
pkg-config uses predefined files with all necessary compiler/linker flags: @see templates in git: https://github.com/krb5/krb5/tree/master/src/build-tools krb5-config probably used real LDFLAGS which were used at compile time. That might be reason why there are hardening flags in output.
The variable values that were used at compiletime gets embedded as-is into krb5-config, and then it attempts to clean them up into more usable form on every invocation of krb5-config.
Just for the log: I've deployed a workaround in krb5-1.13.1-3.fc23 for RH bug #1204646 (https://bugzilla.redhat.com/show_bug.cgi?id=1204646 - "krb5-config returns wrong -specs path) and also added a small safeguard which aborts the build when *redhat-hardened-ld* tries to sneak back into krb5-config to bite Lukas again... :-)
I can see in change log it's just a workaround: * Wed Mar 25 2015 Roland Mainz <rmainz> - 1.13.1-3 - Add temporay workaround for RH bug #1204646 ("krb5-config returns wrong -specs path") which modifies krb5-config post build so that development of krb5 dependicies gets unstuck. This MUST be removed before rawhide becomes F23 ... So what is the right solution? Do we want to file tickets to all components to convert detecting flags from krb5-config to pkgconfig? Or is there any other plan? Would it be acceptable for upstream to use pkg-config inside krb5-config? It would reduce duplication of the same information.
(In reply to Lukas Slebodnik from comment #11) > I can see in change log it's just a workaround: > * Wed Mar 25 2015 Roland Mainz <rmainz> - 1.13.1-3 - Add temporay > workaround for RH bug #1204646 ("krb5-config returns wrong -specs path") > which modifies krb5-config post build so that development of krb5 > dependicies gets unstuck. This MUST be removed before rawhide becomes F23 ... > > So what is the right solution? > Do we want to file tickets to all components to convert detecting flags from > krb5-config to pkgconfig? > Or is there any other plan? Plan is to wait for upstream to come up with a patch, backport it and then remove the kludge... > Would it be acceptable for upstream to use pkg-config inside krb5-config? > It would reduce duplication of the same information. Erm... that won't work for platforms which do not have pkg-config OR where pkg-config is too old (Fedora 20 for example has this issue).
Thanks for the workaround. Squid can now build successfully again in rawhide.
Thanks for update. Tested scratch build seems to be working for now.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
(In reply to Lukas Slebodnik from comment #11) > I can see in change log it's just a workaround: > * Wed Mar 25 2015 Roland Mainz <rmainz> - 1.13.1-3 - Add temporay > workaround for RH bug #1204646 ("krb5-config returns wrong -specs path") > which modifies krb5-config post build so that development of krb5 > dependicies gets unstuck. This MUST be removed before rawhide becomes F23 ... > > So what is the right solution? > Do we want to file tickets to all components to convert detecting flags from > krb5-config to pkgconfig? That won't work for upstream projects which wish to work for platforms which do not have pkg-config (yet) ... I asked around and the more or less uniform response was that they are unhappy about such a change. > Or is there any other plan? After consulting with pkis&&co. I'd say I close this bug as FIXED and remove the workaround with the rebase bug which fixes krb5-config. In the meantime there is a safeguard in the rpm spec file which will prevent this kind of bug from creeping in again...
Marking bug as MODIFIED.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
It looks to me like this was fixed and just accidentally not tagged in an update. Please reopen if that's not the case.