1247358 - Implement a mechanism that enforces a minimum runtime version of NSS/NSPR, based on the version an application was built against

Status: NEW

(NSS :: Libraries, enhancement, P3)

Description

[Kai Engert [:KaiE:]]

Let's assume that between an NSS version A, and an NSS version B, no new symbols were introduced, but the size of a function parameter changed.

(For an example you might look at bug 1247021.)

If an application was built against version B, but at runtime the application environment provides the older version A, the application might fail in unpredictable ways.

As of today, this scenario is defined as "unsupported".

It would be nice to research how to improve this situation.

It would be an improvement if the above unsupported situation, if the above scenario were immediately detected at runtime and the application startup were prevented, or if the application terminated during initialization of the NSS library.

Hubert suggested to introduce versioned library symbols. I'm not sure if we can. I remember that there have been discussions on this topic in the past, but I don't remember why the idea was rejected by the NSS developers in the past.

Ideally, it would be great to have a solution that could be automated, and that didn't require manual work when working on new releases.

I suggest to use this bug to track ideas for potential solutions to this problem, and the arguments, why rejected solutions don't work for NSPR/NSS.

Comment 1

[Alicja Kario]

Note that if a new independent symbol was introduced between NSS version but the application does not use it, it should NOT be prevented from being run with an old library version.