XMLTooling - C++
  1. XMLTooling - C++
  2. CPPXT-9

Fedora 8 et seq, probably RHEL6, have libcurl linked against NSS, not OpenSSL resulting in SP problems

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0
    • Fix Version/s: 1.4
    • Component/s: SOAP
    • Labels:
      None
    • Environment:
      Fedora 8 for sure, almost certainly Fedora 9, probably RHEL 6 and CentOS 6 when they release.
    • Operating System:
      Linux
    • CPU Type:
      Multiple
    • C/C++ Compiler:
      Multiple

      Description

      This results in two problems. The first is that the cipher selection string isn't recognised, resulting in an error message at the SP and rather funky cipher selection.

      The second and more serious issue is that the SP won't present TLS credentials on any back-channel connection. This will result in the IdP treating the SP as unauthenticated and potentially denying it the attributes it needs.

      Scott's comment was that one solution would be to ship with a custom libcurl package which was linked against openssl instead of NSS, and link the Shibboleth packages against that instead of the standard libcurl. The other alternative would be to handle the curl-over-NSS possibility explicitly, but that would probably be more work even if it was possible to do that and retain full functionality.

        Activity

        Hide
        Steve Traylen added a comment -
        I'll do some work on making an alternate library name of curl-openssl, if I can do it are you happy to try and look for it at configure time?
        I'll look at the debian names and try and use the same name space.

        I'm presuming you only need the library and not the curl binary?

        I really am keen to avoid replacing my system curl, as you say dozens of things depend on this.
        Steve.
        Show
        Steve Traylen added a comment - I'll do some work on making an alternate library name of curl-openssl, if I can do it are you happy to try and look for it at configure time? I'll look at the debian names and try and use the same name space. I'm presuming you only need the library and not the curl binary? I really am keen to avoid replacing my system curl, as you say dozens of things depend on this. Steve.
        Hide
        Scott Cantor added a comment -
        I don't assume the curl library name, curl-config has to provide the correct library information. I'm open to an alternative package, but it will be difficult to do that for Red Hat 6, since I've already released one that Provides curl/libcurl/libcurl-devel.
        Show
        Scott Cantor added a comment - I don't assume the curl library name, curl-config has to provide the correct library information. I'm open to an alternative package, but it will be difficult to do that for Red Hat 6, since I've already released one that Provides curl/libcurl/libcurl-devel.
        Hide
        Scott Cantor added a comment -
        Marking fixed with release of new packages. We can create new issues to make improvements or changes.
        Show
        Scott Cantor added a comment - Marking fixed with release of new packages. We can create new issues to make improvements or changes.
        Hide
        Romain Wartel added a comment -
        I am afraid the installation of the shibboleth RPMs remains broken on RHEL6 and variants.

        On a fresh install:

        [root@rw-slc6-64 ~]# yum install shibboleth
        Loaded plugins: changelog, kernel-module, protectbase, refresh-packagekit, security, tsflags, versionlock
        slc6-extras | 2.6 kB 00:00
        slc6-extras/primary_db | 34 kB 00:00
        slc6-os | 3.2 kB 00:00
        slc6-os/primary_db | 4.3 MB 00:00
        slc6-updates | 3.0 kB 00:00
        slc6-updates/primary_db | 3.1 MB 00:00
        0 packages excluded due to repository protections
        Setting up Install Process
        Resolving Dependencies
        --> Running transaction check
        ---> Package shibboleth.x86_64 0:2.4.1-2.1.slc6.1 set to be updated
        --> Processing Dependency: xmltooling-schemas for package: shibboleth-2.4.1-2.1.slc6.1.x86_64
        --> Processing Dependency: libcurl-openssl for package: shibboleth-2.4.1-2.1.slc6.1.x86_64
        --> Processing Dependency: curl-openssl for package: shibboleth-2.4.1-2.1.slc6.1.x86_64
        --> Processing Dependency: opensaml-schemas for package: shibboleth-2.4.1-2.1.slc6.1.x86_64
        --> Processing Dependency: libxmltooling-lite.so.5()(64bit) for package: shibboleth-2.4.1-2.1.slc6.1.x86_64
        --> Processing Dependency: libxerces-c-3.0.so()(64bit) for package: shibboleth-2.4.1-2.1.slc6.1.x86_64
        --> Processing Dependency: libsaml.so.7()(64bit) for package: shibboleth-2.4.1-2.1.slc6.1.x86_64
        --> Processing Dependency: libodbc.so.2()(64bit) for package: shibboleth-2.4.1-2.1.slc6.1.x86_64
        --> Processing Dependency: liblog4shib.so.1()(64bit) for package: shibboleth-2.4.1-2.1.slc6.1.x86_64
        --> Processing Dependency: libxml-security-c.so.16()(64bit) for package: shibboleth-2.4.1-2.1.slc6.1.x86_64
        --> Processing Dependency: libxmltooling.so.5()(64bit) for package: shibboleth-2.4.1-2.1.slc6.1.x86_64
        --> Running transaction check
        ---> Package curl-openssl.x86_64 0:7.19.7-16.slc6 set to be updated
        ---> Package libcurl-openssl.x86_64 0:7.19.7-16.slc6 set to be updated
        ---> Package liblog4shib1.x86_64 0:1.0.4-2.1.slc6 set to be updated
        ---> Package libsaml7.x86_64 0:2.4.1-2.1.slc6 set to be updated
        ---> Package libxml-security-c16.x86_64 0:1.6.0-2.1.slc6 set to be updated
        ---> Package libxmltooling5.x86_64 0:1.4.1-2.1.slc6 set to be updated
        ---> Package opensaml-schemas.x86_64 0:2.4.1-2.1.slc6 set to be updated
        ---> Package unixODBC.x86_64 0:2.2.14-11.el6 set to be updated
        ---> Package xerces-c.x86_64 0:3.0.1-20.el6 set to be updated
        ---> Package xmltooling-schemas.x86_64 0:1.4.1-2.1.slc6 set to be updated
        --> Processing Conflict: curl-openssl-7.19.7-16.slc6.x86_64 conflicts curl
        --> Processing Conflict: libcurl-openssl-7.19.7-16.slc6.x86_64 conflicts libcurl
        --> Finished Dependency Resolution
        Beginning Kernel Module Plugin
        Finished Kernel Module Plugin
        Error: libcurl-openssl conflicts with libcurl
        Error: curl-openssl conflicts with curl
         You could try using --skip-broken to work around the problem
         You could try running: rpm -Va --nofiles --nodigest
        [root@rw-slc6-64 ~]#

        I would be grateful if the discussion could be re-opened.

        I understand alternate packages (i.e. libcurl-openssl/curl-openssl) would be a resonable compromise, but it would be useful if they were made so that they trigger no conflict with libcurl/curl. May not be trivial though.

        Romain.
        Show
        Romain Wartel added a comment - I am afraid the installation of the shibboleth RPMs remains broken on RHEL6 and variants. On a fresh install: [ root@rw-slc6-64 ~]# yum install shibboleth Loaded plugins: changelog, kernel-module, protectbase, refresh-packagekit, security, tsflags, versionlock slc6-extras | 2.6 kB 00:00 slc6-extras/primary_db | 34 kB 00:00 slc6-os | 3.2 kB 00:00 slc6-os/primary_db | 4.3 MB 00:00 slc6-updates | 3.0 kB 00:00 slc6-updates/primary_db | 3.1 MB 00:00 0 packages excluded due to repository protections Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package shibboleth.x86_64 0:2.4.1-2.1.slc6.1 set to be updated --> Processing Dependency: xmltooling-schemas for package: shibboleth-2.4.1-2.1.slc6.1.x86_64 --> Processing Dependency: libcurl-openssl for package: shibboleth-2.4.1-2.1.slc6.1.x86_64 --> Processing Dependency: curl-openssl for package: shibboleth-2.4.1-2.1.slc6.1.x86_64 --> Processing Dependency: opensaml-schemas for package: shibboleth-2.4.1-2.1.slc6.1.x86_64 --> Processing Dependency: libxmltooling-lite.so.5()(64bit) for package: shibboleth-2.4.1-2.1.slc6.1.x86_64 --> Processing Dependency: libxerces-c-3.0.so()(64bit) for package: shibboleth-2.4.1-2.1.slc6.1.x86_64 --> Processing Dependency: libsaml.so.7()(64bit) for package: shibboleth-2.4.1-2.1.slc6.1.x86_64 --> Processing Dependency: libodbc.so.2()(64bit) for package: shibboleth-2.4.1-2.1.slc6.1.x86_64 --> Processing Dependency: liblog4shib.so.1()(64bit) for package: shibboleth-2.4.1-2.1.slc6.1.x86_64 --> Processing Dependency: libxml-security-c.so.16()(64bit) for package: shibboleth-2.4.1-2.1.slc6.1.x86_64 --> Processing Dependency: libxmltooling.so.5()(64bit) for package: shibboleth-2.4.1-2.1.slc6.1.x86_64 --> Running transaction check ---> Package curl-openssl.x86_64 0:7.19.7-16.slc6 set to be updated ---> Package libcurl-openssl.x86_64 0:7.19.7-16.slc6 set to be updated ---> Package liblog4shib1.x86_64 0:1.0.4-2.1.slc6 set to be updated ---> Package libsaml7.x86_64 0:2.4.1-2.1.slc6 set to be updated ---> Package libxml-security-c16.x86_64 0:1.6.0-2.1.slc6 set to be updated ---> Package libxmltooling5.x86_64 0:1.4.1-2.1.slc6 set to be updated ---> Package opensaml-schemas.x86_64 0:2.4.1-2.1.slc6 set to be updated ---> Package unixODBC.x86_64 0:2.2.14-11.el6 set to be updated ---> Package xerces-c.x86_64 0:3.0.1-20.el6 set to be updated ---> Package xmltooling-schemas.x86_64 0:1.4.1-2.1.slc6 set to be updated --> Processing Conflict: curl-openssl-7.19.7-16.slc6.x86_64 conflicts curl --> Processing Conflict: libcurl-openssl-7.19.7-16.slc6.x86_64 conflicts libcurl --> Finished Dependency Resolution Beginning Kernel Module Plugin Finished Kernel Module Plugin Error: libcurl-openssl conflicts with libcurl Error: curl-openssl conflicts with curl  You could try using --skip-broken to work around the problem  You could try running: rpm -Va --nofiles --nodigest [ root@rw-slc6-64 ~]# I would be grateful if the discussion could be re-opened. I understand alternate packages (i.e. libcurl-openssl/curl-openssl) would be a resonable compromise, but it would be useful if they were made so that they trigger no conflict with libcurl/curl. May not be trivial though. Romain.
        Hide
        Scott Cantor added a comment -
        If the installation doesn't work, you can probably just update libcurl and curl first to the corrected packages and then do the install. When and if CentOS 6 ever ships, I'll play with the package sequencing and look into improving the overall experience, but for now, I don't have a Red Hat 6 license, and there's nothing more I can do.

        It's also possible Red Hat updated their curl version. Since they now hide their packages, it's hard for me to tell, but I can do the necessary update to mine if I know where the originals are.

        I have no plans to avoid conflicts. If you can figure out how, feel free to supply the patches.
        Show
        Scott Cantor added a comment - If the installation doesn't work, you can probably just update libcurl and curl first to the corrected packages and then do the install. When and if CentOS 6 ever ships, I'll play with the package sequencing and look into improving the overall experience, but for now, I don't have a Red Hat 6 license, and there's nothing more I can do. It's also possible Red Hat updated their curl version. Since they now hide their packages, it's hard for me to tell, but I can do the necessary update to mine if I know where the originals are. I have no plans to avoid conflicts. If you can figure out how, feel free to supply the patches.

          People

          • Assignee:
            Scott Cantor
            Reporter:
            Ian Young
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: