| Newsgroups |
gmane.comp.mozilla.crypto |
| Message-ID |
<[email protected]> |
On 4/14/26 5:06 AM, Kai Engert wrote:
> Hi all,
>
> after more discussions with the Firefox and NSS teams, I'd like to=20
> present a different plan.
>
> We'd like to stop maintaining and stop releasing NSPR as an individual=20
> project.
>
> Once Firefox starts developing Firefox 154, the classic NSPR=20
> repository would (likely) no longer get maintained by Mozilla, except=20
> for security fixes required for the earlier Firefox and NSS versions=20
> (probably ending late 2027 at the time Firefox ESR 153 and Thunderbird=20
> 153 reach end-of-life).
>
> Rather, we'd like to move all the NSPR code into the NSS repository.
>
> That means external projects that depend on NSS would continue to=20
> work, because the required NSPR APIs are bundled with it.
This=C2=A0 sounds fine.
>
> We'd like to add symbol versioning to all exported NSPR functions, and=20
> rename all exported NSPR functions at the same time.
This will also be fine. We already have symbol versioning in NSS.
> =C2=A0For example, PR_Init would get renamed to MPR_Init.
>
> (NSPR =3D NetScape Portable Runtime, MPR =3D Mozilla Portable Runtime)
>
> We should consolidate and build only one shared library going forward,=20
> libmpr5.so / mpr5.dll.
This would be a nightmare for us. Any kind of rollout for us will need=20
to maintain both symbols and library sets.
We require maintaining ABI compatibility over the life of our OS=20
releases. That means RHEL-8, RHEL-9 and RHEL-10 will all need to be=20
maintain the old nspr symbols. But the also require updates to the=20
latest version of Firefox because Firefox ESR has a shorter support=20
cycle than RHEL-10, so we need to pick up the latest NSS and NSPR into=20
our older OSes. This is why we have ABI and API guarantees for NSS and NSPR=
.
Basically to make this work, we would have to maintain both and the=20
ability for Firefox and NSS to use both, or we need to create=20
compatibilty layers (old nspr libraries with the old names calling the=20
new nspr library).
An example of the time lines we are looking at, track the conversion of=20
the NSS database from dbm to sql: The sqldb code as added to NSS in=20
about 2006 (pre-mecurial). It was made the default in Nov 2017. Ability=20
to build without dbm (NSS_DISABLE_DBM added) 2020. When we can remove=20
dbm completely (2029 - RHEL-8 goes out of support).
>
> MPR code that isn't required by either NSS or Firefox would then get=20
> removed over time.
This is probabably doable. There are other users of NSPR in our OS, but=20
those can get transitioned over time, as long as the phase out is a=20
compile time option.
>
> This means APIs can get removed from the MPR library between releases.=20
> We haven't discussed this detail yet, but if this is a problem for=20
> external consumers, maybe we could define that the MPR major library=20
> version is increased whenever functions are removed?
Err, only if the API can be compiled out over releases. As long as both=20
Firefox and NSS depend on NSPR (or MPR), then we have the long term=20
support issues. Dropping NSPR as a separate project doesn't stop it from=20
being a separate library, and it would be difficult to not export the=20
NSPR interface because that's is how applications use NSS to do thing=20
like SSL, so even applications that aren't using NSPR per se, still uses=20
NSPR if they are doing NSS.
>
> Regards
> Kai
>
--=20
You received this message because you are subscribed to the Google Groups "=
[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to [email protected].
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msg=
id/dev-tech-crypto/5484d084-7689-4606-a285-7c967416dd08%40redhat.com.