Bug 1284089 - Need libfreebl3.a to link statically with libcrypt.a.
Need libfreebl3.a to link statically with libcrypt.a.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: nss-softokn (Show other bugs)
23
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Elio Maldonado Batiz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-20 14:29 EST by August Schwerdfeger
Modified: 2016-11-02 10:37 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-29 18:37:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test program to demonstrate linking failure. (57 bytes, text/plain)
2015-11-20 14:29 EST, August Schwerdfeger
no flags Details
Errors raised when attempting to link with 'libcrypt.a'. (20.49 KB, text/plain)
2015-11-20 14:30 EST, August Schwerdfeger
no flags Details

  None (edit)
Description August Schwerdfeger 2015-11-20 14:29:48 EST
Created attachment 1097284 [details]
Test program to demonstrate linking failure.

Description of problem:

It is impossible to link with the static version of 'libcrypt' provided in Fedora 23.


Version-Release number of selected component (if applicable):

glibc-static-2.22-5.fc23.x86_64


How reproducible:

Attempt to compile the attached C file with the command

$ gcc -static libcrypt-test.c -lcrypt


Actual results:

The attached series of errors.


Expected results:

No errors and a binary output.


Additional info:

The corresponding 'libcrypt.a' from Ubuntu 14.04, copied into the place of the default version, behaves as expected.
Comment 1 August Schwerdfeger 2015-11-20 14:30 EST
Created attachment 1097285 [details]
Errors raised when attempting to link with 'libcrypt.a'.
Comment 2 Carlos O'Donell 2015-11-20 16:36:23 EST
(In reply to August Schwerdfeger from comment #0)
> $ gcc -static libcrypt-test.c -lcrypt

For Fedora glibc the Crypt functionality relies upon the additional NSS crypto routines. Therefore in order to compile a static program that uses -lcrypt you must also provide all the requirements that libcrypt.a has, which is a static copy of the NSS crypto routines. At present the Fedora nss-softokn-freebl package does not provide a static copy of /usr/lib64/libfreebl3.so to link against.

In summary:
- You can't link with `-static` and `-lcrypt` on Fedora.
- You could if nss-softokn-freebl provided libfreebl3.a.

If we had a libfreebl3.a then we might change libcryp.so into a wrapper linker script to make this transparent to the user.

Passing this to nss-softokn to see what they say.

Let me reiterate that it is very very dangerous to link statically with crypto routines and that you really want to link dynamically unless you have a very compelling reason not to.

On Ubuntu I expec they don't provide the additional crypto routines from NSS and thus `static` + `-lcrypt` works. It is completely unsupported to copy Ubuntu's libcrypt.a into your system and link with it.
Comment 3 Elio Maldonado Batiz 2015-12-07 10:50:52 EST
(In reply to Carlos O'Donell from comment #2)
> (In reply to August Schwerdfeger from comment #0)
> > $ gcc -static libcrypt-test.c -lcrypt
> 
> For Fedora glibc the Crypt functionality relies upon the additional NSS
> crypto routines. Therefore in order to compile a static program that uses
> -lcrypt you must also provide all the requirements that libcrypt.a has,
> which is a static copy of the NSS crypto routines. At present the Fedora
> nss-softokn-freebl package does not provide a static copy of
> /usr/lib64/libfreebl3.so to link against.
> 
> In summary:
> - You can't link with `-static` and `-lcrypt` on Fedora.
> - You could if nss-softokn-freebl provided libfreebl3.a.
> 
> If we had a libfreebl3.a then we might change libcryp.so into a wrapper
> linker script to make this transparent to the user.

Years ago it was decided to package libfreebl.a in order to meet the needs of the glibc-provided small hash library. 

$ rpm -ql nss-softokn-freebl-devel
/usr/include/nss3/alghmac.h
/usr/include/nss3/blapi.h
/usr/include/nss3/blapit.h
/usr/lib64/libfreebl.a <---------------

From nss-softokn.spec I quote

<begin quote/>
%description freebl-devel
NSS Softoken Cryptographic Module Freebl Library Development Tools
This package supports special needs of some PKCS #11 module developers and
is otherwise considered private to NSS. As such, the programming interfaces
may change and the usual NSS binary compatibility commitments do not apply.
Developers should rely only on the officially supported NSS public API.
</end quote>

PKCS #11 module developers are the other set of privilege clients that we support and no one else should be calling freebl directly. Even the higher layers of NSS avoid calling freebl and get their needs met via the PKCS #11 service API layer.


> 
> Passing this to nss-softokn to see what they say.
See the comments above.

> 
> Let me reiterate that it is very very dangerous to link statically with
> crypto routines and that you really want to link dynamically unless you have
> a very compelling reason not to.

We fully agree with Carlo's statement.

> 
> On Ubuntu I expec they don't provide the additional crypto routines from NSS
> and thus `static` + `-lcrypt` works. It is completely unsupported to copy
> Ubuntu's libcrypt.a into your system and link with it.

For the reasons exposed above libfreebl3.a should not be made tolink statically with libcrypt.a.
Comment 4 Elio Maldonado Batiz 2016-05-29 18:37:49 EDT
Closing as WONTIX but I will gladly change it to NOTABUG for the reasons exposed earlier.
Comment 5 Florian Weimer 2016-11-02 10:37:50 EDT
(In reply to Elio Maldonado Batiz from comment #3)
> Years ago it was decided to package libfreebl.a in order to meet the needs
> of the glibc-provided small hash library. 
> 
> $ rpm -ql nss-softokn-freebl-devel
> /usr/include/nss3/alghmac.h
> /usr/include/nss3/blapi.h
> /usr/include/nss3/blapit.h
> /usr/lib64/libfreebl.a <---------------

But glibc does not use the interfaces provided by libfreebl.a, it uses NSSLOW* functions:

  /* Initialize libfreebl3.  */
  NSSLOWInitContext *nss_ictx = NSSLOW_Init ();
  if (nss_ictx == NULL)
    {
      free (free_key);
      return NULL;
    }
  NSSLOWHASHContext *nss_ctx = NULL;
  NSSLOWHASHContext *nss_alt_ctx = NULL;

I think it's always been this way since NSS was added.  This means that from a glibc perspective, you can drop libfreebl.a.

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