Allow to override the library/libraries linked to sub libraries and tools

NEW
Unassigned

Status

NSS
Build
5 years ago
4 years ago

People

(Reporter: glandium, Unassigned)

Tracking

(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
In a world where nss3, ssl3, smime3 and nssutil3 are all folded in a single library, possibly libxul, we need a way for the nss build system to allow an override for the libraries it links to softokn, nssckbi, etc.
(Reporter)

Updated

5 years ago
Depends on: 844884

Comment 1

5 years ago
Mike, this suggests a desire for a static build, but I believe that's not desired for NSS (in part, it breaks FIPS mode and system-wide NSS deployments). See bug #534471

Otherwise, I'm not sure what you mean by "folded in a single library"
(Reporter)

Comment 2

5 years ago
(In reply to Ryan Sleevi from comment #1)
> Mike, this suggests a desire for a static build, but I believe that's not
> desired for NSS (in part, it breaks FIPS mode and system-wide NSS
> deployments). See bug #534471
> 
> Otherwise, I'm not sure what you mean by "folded in a single library"

See bug 648407 (and it works)
(In reply to Ryan Sleevi from comment #1)
> Mike, this suggests a desire for a static build, but I believe that's not
> desired for NSS (in part, it breaks FIPS mode and system-wide NSS
> deployments). See bug #534471
> 
> Otherwise, I'm not sure what you mean by "folded in a single library"

Not really a single library. Instead, fold everything except freebl and softoken into one library, and possibly later fold freebl and softoken together library. That would still preserve the FIPS-iness, right?

I think it is good to do this as the default configuration of NSS on non-Unix, non-Linux platforms. It should make applications that use NSS faster and smaller (because NSS will be smaller due to better inter-source-file optimization).

Comment 4

5 years ago
Ah, yes, absolutely for that. As long as softoken is still kept outside, you shouldn't have any issues with FIPS, and I agree, that'd lead to more flexibility in  other aspects of NSS (such as libssl or libpkix).

This should not negatively affect Red Hat deployments either, since the system expressions of trust-et-al are handled by system PKCS#11 modules.
You need to log in before you can comment on or make changes to this bug.