RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1247751 - krb5-config returns wrong -specs path
Summary: krb5-config returns wrong -specs path
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: krb5
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Robbie Harwood
QA Contact: Patrik Kis
URL:
Whiteboard:
Depends On: 1204646
Blocks: 1203889
TreeView+ depends on / blocked
 
Reported: 2015-07-28 18:36 UTC by Roland Mainz
Modified: 2015-11-19 05:14 UTC (History)
14 users (show)

Fixed In Version: krb5-1.13.2-4.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 1204646
: 1263721 (view as bug list)
Environment:
Last Closed: 2015-11-19 05:14:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1263721 0 low CLOSED krb5-config returns wrong -specs path - follow up bug 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHSA-2015:2154 0 normal SHIPPED_LIVE Moderate: krb5 security, bug fix, and enhancement update 2015-11-19 08:16:22 UTC

Internal Links: 1263721

Description Roland Mainz 2015-07-28 18:36:23 UTC
+++ This bug was initially created as a clone of Bug #1204646 +++

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.

--- Additional comment from Jakub Jelen on 2015-03-23 05:48:07 EDT ---

or do not return -specs like in f21:
-lkrb5 -lk5crypto -lcom_err

--- Additional comment from Lukas Slebodnik on 2015-03-23 09:40:09 EDT ---

(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

--- Additional comment from Jakub Jelen on 2015-03-23 12:18:24 EDT ---

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.

--- Additional comment from Lukas Slebodnik on 2015-03-23 13:00:40 EDT ---

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

--- Additional comment from Simo Sorce on 2015-03-24 18:31:51 EDT ---

One way to fix it is to make dependent packages use pkg-config instead ...

--- Additional comment from Simo Sorce on 2015-03-24 20:14:45 EDT ---

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.

--- Additional comment from Henrik Nordström on 2015-03-25 04:24:30 EDT ---

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?

--- Additional comment from Lukas Slebodnik on 2015-03-25 04:45:13 EDT ---

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.

--- Additional comment from Henrik Nordström on 2015-03-25 11:15:23 EDT ---

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.

--- Additional comment from Roland Mainz on 2015-03-25 12:10:51 EDT ---

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... :-)

--- Additional comment from Lukas Slebodnik on 2015-03-27 10:44:26 EDT ---

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.

--- Additional comment from Roland Mainz on 2015-03-27 11:09:28 EDT ---

(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).

--- Additional comment from Henrik Nordström on 2015-03-28 22:07:39 EDT ---

Thanks for the workaround. Squid can now build successfully again in rawhide.

--- Additional comment from Jakub Jelen on 2015-03-30 02:55:03 EDT ---

Thanks for update. Tested scratch build seems to be working for now.

--- Additional comment from Jan Kurik on 2015-07-15 10:22:24 EDT ---

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

--- Additional comment from Roland Mainz on 2015-07-28 14:05:32 EDT ---

(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...

--- Additional comment from Roland Mainz on 2015-07-28 14:07:53 EDT ---

Marking bug as MODIFIED.

Comment 2 Roland Mainz 2015-07-29 02:59:49 UTC
QA not needed... the commit contains an assert-style safeguard which causes the RPM build to abort/fail if we return wrong data.

Comment 3 Roland Mainz 2015-07-29 15:02:57 UTC
Fix checked in (krb5-1.13.2-4.el7) ...

... marking bug as MODIFIED.

Comment 9 errata-xmlrpc 2015-11-19 05:14:00 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-2154.html


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