Bug 1204646 - krb5-config returns wrong -specs path
Summary: krb5-config returns wrong -specs path
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: krb5
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Robbie Harwood
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1247751
TreeView+ depends on / blocked
 
Reported: 2015-03-23 09:46 UTC by Jakub Jelen
Modified: 2016-01-20 20:27 UTC (History)
10 users (show)

Fixed In Version: krb5-1.13.1-3.fc23
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1247751 (view as bug list)
Environment:
Last Closed: 2016-01-20 20:27:58 UTC
Type: Bug


Attachments (Terms of Use)

Description Jakub Jelen 2015-03-23 09:46:50 UTC
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.

Comment 1 Jakub Jelen 2015-03-23 09:48:07 UTC
or do not return -specs like in f21:
-lkrb5 -lk5crypto -lcom_err

Comment 2 Lukas Slebodnik 2015-03-23 13:40:09 UTC
(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

Comment 3 Jakub Jelen 2015-03-23 16:18:24 UTC
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.

Comment 4 Lukas Slebodnik 2015-03-23 17:00:40 UTC
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

Comment 5 Simo Sorce 2015-03-24 22:31:51 UTC
One way to fix it is to make dependent packages use pkg-config instead ...

Comment 6 Simo Sorce 2015-03-25 00:14:45 UTC
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.

Comment 7 Henrik Nordström 2015-03-25 08:24:30 UTC
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?

Comment 8 Lukas Slebodnik 2015-03-25 08:45:13 UTC
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.

Comment 9 Henrik Nordström 2015-03-25 15:15:23 UTC
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.

Comment 10 Roland Mainz 2015-03-25 16:10:51 UTC
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... :-)

Comment 11 Lukas Slebodnik 2015-03-27 14:44:26 UTC
I can see in change log it's just a workaround:
* Wed Mar 25 2015 Roland Mainz <rmainz@redhat.com> - 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.

Comment 12 Roland Mainz 2015-03-27 15:09:28 UTC
(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@redhat.com> - 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).

Comment 13 Henrik Nordström 2015-03-29 02:07:39 UTC
Thanks for the workaround. Squid can now build successfully again in rawhide.

Comment 14 Jakub Jelen 2015-03-30 06:55:03 UTC
Thanks for update. Tested scratch build seems to be working for now.

Comment 15 Jan Kurik 2015-07-15 14:22:24 UTC
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

Comment 16 Roland Mainz 2015-07-28 18:05:32 UTC
(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@redhat.com> - 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...

Comment 17 Roland Mainz 2015-07-28 18:07:53 UTC
Marking bug as MODIFIED.

Comment 18 Fedora Admin XMLRPC Client 2015-09-01 21:36:16 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 19 Robbie Harwood 2016-01-20 20:27:58 UTC
It looks to me like this was fixed and just accidentally not tagged in an update.  Please reopen if that's not the case.


Note You need to log in before you can comment on or make changes to this bug.