A major cleanup effort for NSPR, new major release version 5

[Kai Engert]

Hello,

the Firefox team has approached me. They would like to do a major
cleanup of NSPR, removing the majority of NSPR code that is unused by
NSS/Firefox/Thunderbird, and also removing APIs that are no longer
necessary.

To allow time for downstream consumers to adjust, we could use the
following approach.

NSPR version 4.x would continue to be used and maintained until the end
of the (upcoming) FF 153 ESR release cycle, that means (roughly) until
October 2027.

At the time development of FF 154 begins (mid June 2026),
mozilla-central would switch to use NSPR 5.

Because work on the cleanup effort has already started, it's desirable
to be able to commit those changes very soon (and not wait until June).

The suggestion is to create a new branch for version 4 maintenance in
the NSPR repository, based on the current tip, and then change the tip
of https://hg-edge.mozilla.org/projects/nspr to version 5.

Please give feedback.

Thanks and Regards
Kai

[Kai Engert]

Simon has asked me to forward his message to the list, while he's
working on subscribing.

(If anyone of you isn't subscribed yet, feel free to CC me on your
reply, and I'll forward if neccessary. The list might have some strict
anti-spam measures active that we need to figure out.)

Kai


-------- Forwarded Message --------
Subject: Re: A major cleanup effort for NSPR, new major release version 5
Date: Mon, 19 Jan 2026 13:11:04 +0100
From: Simon Josefsson <si...@josefsson.org>
To: Kai Engert <Ka...@kuix.de>
CC: dev-tec...@mozilla.org

Hi

There are other users of NSPR than NSS/Firefox/Thunderbird out there.

Will you review their API usage before removing code?

NSPR in Debian is used by the packages below.

One approach to gain confidence in a v5.x branch is to do incremental
and frequent test releases, and testing building all packages below
against it. Then you would quickly identify if there are some package
that will break by your changes.

Checking reverse dependencies...
# Broken Depends:
389-ds-base: 389-ds-base [amd64 arm64 armhf i386 ppc64el riscv64 s390x]
389-ds-base-dev [amd64 arm64 armhf i386 ppc64el riscv64 s390x]
389-ds-base-libs [amd64 arm64 armhf i386 ppc64el riscv64
s390x]
certmonger: certmonger
chromium: chromium [amd64 arm64 armhf i386 loong64 ppc64el]
chromium-driver [amd64 arm64 armhf i386 loong64 ppc64el]
chromium-headless-shell [amd64 arm64 armhf i386 loong64 ppc64el]
chromium-shell [amd64 arm64 armhf i386 loong64 ppc64el]
cinnamon-settings-daemon: cinnamon-settings-daemon
corosync-qdevice: corosync-qdevice
corosync-qnetd
evolution: libevolution
evolution-data-server: evolution-data-server-dev
libcamel-1.2-64t64
libcamel1.2-dev
libedataserverui-1.2-4t64
libedataserverui4-1.0-0t64
firefox: firefox [amd64 arm64 armhf ppc64el riscv64]
firefox-esr: firefox-esr
jss: libjss-java
kronosnet: libknet1t64
libcacard: libcacard0
libreoffice: libreoffice-core [amd64 arm64 armhf i386 ppc64el riscv64 s390x]
libreoffice-core-nogui [amd64 arm64 armhf i386 ppc64el s390x]
libreswan: libreswan
libsrtp2: libsrtp2-1
libsrtp2-dev
lighttpd: lighttpd-mod-nss
mate-settings-daemon: mate-settings-daemon
network-manager-l2tp: network-manager-l2tp
nordugrid-arc: libarccommon4
nss: libnss3
libnss3-dev
libnss3-tools
nss-passwords: nss-passwords [amd64 arm64 armhf i386 ppc64el riscv64 s390x]
nss-pem: nss-plugin-pem
nut: libupsclient7
nut-server
nvidia-cuda-toolkit/non-free: nsight-compute [amd64 arm64]
nsight-systems [amd64 arm64]
pesign: pesign [amd64 arm64 armhf i386 loong64 ppc64el riscv64]
pidgin: libpurple0t64
poppler: libpoppler147
python-nss: python3-nss [amd64 arm64 armhf i386 ppc64el riscv64 s390x]
qt6-webengine: libqt6webenginecore6 [amd64 arm64 armhf i386]
libqt6webenginecore6-bin [amd64 arm64 armhf i386]
qtwebengine-opensource-src: libqt5webenginecore5 [amd64 arm64 armhf i386]
slapi-nis: slapi-nis [amd64 arm64 armhf i386 ppc64el riscv64 s390x]
systemtap: systemtap
systemtap-runtime
systemtap-server
thunderbird: thunderbird [amd64 arm64 i386 loong64 ppc64el riscv64]
volume-key: libvolume-key1
volume-key
xmlsec1: libxmlsec1-nss1

# Broken Build-Depends:
389-ds-base: libnspr4-dev
certmonger: libnspr4-dev
chromium: libnspr4-dev
coolkey: libnspr4-dev
evolution: libnspr4-dev
evolution-data-server: libnspr4-dev
fence-agents: libnspr4-dev
firefox: libnspr4-dev (2:4.32~ >=)
firefox-esr: libnspr4-dev (2:4.32~ >=)
freeipa: libnspr4-dev
kronosnet: libnspr4-dev
libreoffice: libnspr4-dev
libreswan: libnspr4-dev
nss: libnspr4-dev (2:4.34 >=)
nss-passwords: libnspr4-dev
nss-pem: libnspr4-dev (2:4.12 >=)
pesign: libnspr4
libnspr4-dev
slapi-nis: libnspr4-dev
systemtap: libnspr4-dev
thunderbird: libnspr4-dev (2:4.32~ >=)

/Simon

[Kai Engert]

Hi Simon,

thanks for bringing up this list of dependencies.

On 1/19/26 13:11, Simon Josefsson wrote:
> Will you review their API usage before removing code?

We've talked about that briefly.

In my understanding, the intention is to remove code and APIs that it no
longer needs in NSPR 5, regardless of other software depending on it.

If other packages depend on the removed code or APIs, a nspr-version-4
package could be introduced, and those requiring nspr-4 could link to
that package, instead to the most recent version. Or alternatively, they
could make adjustments to avoid the dependencies on the removed code.

I'm the messenger here, so I'd like other FF developers to join the
discussion and post their thoughts here.

Thanks,
Kai

[Lars Eggert]

Hi,

On Jan 19, 2026, at 16:25, Kai Engert <Ka...@kuix.de> wrote:
> In my understanding, the intention is to remove code and APIs that it no longer needs in NSPR 5, regardless of other software depending on it.

this. The plan roughly would be to strip any code from NSPR that Gecko isn't currently using, and support for any platforms that are not currently Gecko tier platforms.

(NSPR hasn't had - IMO - have any meaningful way to test that code and those platforms for a while now anyway, and I'd rather not ship untested code.)

> If other packages depend on the removed code or APIs, a nspr-version-4 package could be introduced, and those requiring nspr-4 could link to that package, instead to the most recent version. Or alternatively, they could make adjustments to avoid the dependencies on the removed code.

This again. I think it would be perfectly reasonable for most current non-Gecko users of NSPR to remain on version 4.

Thanks,
Lars

[Kai Engert]

Forwarding for Paul.

-------- Forwarded Message --------
Subject: Re: [dev-tech-crypto] A major cleanup effort for NSPR, new
major release version 5

Date: Mon, 19 Jan 2026 10:22:00 -0500 (EST)
From: Paul Wouters <pa...@nohats.ca>
To: Lars Eggert <leg...@mozilla.com>
CC: Kai Engert <Ka...@kuix.de>, Simon Josefsson <si...@josefsson.org>,
dev-tec...@mozilla.org

On Mon, 19 Jan 2026, 'Lars Eggert' via dev-tec...@mozilla.org wrote:

> On Jan 19, 2026, at 16:25, Kai Engert <Ka...@kuix.de> wrote:
>> In my understanding, the intention is to remove code and APIs that it no longer needs in NSPR 5, regardless of other software depending on it.
>
> this. The plan roughly would be to strip any code from NSPR that Gecko isn't currently using, and support for any platforms that are not currently Gecko tier platforms.

Note there are other users of NSS/NSPR too, such as libreswan's IKE
stack.

> (NSPR hasn't had - IMO - have any meaningful way to test that code and those platforms for a while now anyway, and I'd rather not ship untested code.)
>
>> If other packages depend on the removed code or APIs, a nspr-version-4 package could be introduced, and those requiring nspr-4 could link to that package, instead to the most recent version. Or alternatively, they could make adjustments to avoid the dependencies on the removed code.
>
> This again. I think it would be perfectly reasonable for most current non-Gecko users of NSPR to remain on version 4.

that's just a bandaid that will fail sometime in the future.

So I am concerned.

Paul

[Andrew Cagney]

On Mon, 19 Jan 2026 at 10:43, Kai Engert <Ka...@kuix.de> wrote:
>
> Forwarding for Paul.
>
>
> -------- Forwarded Message --------
> Subject: Re: [dev-tech-crypto] A major cleanup effort for NSPR, new
> major release version 5
> Date: Mon, 19 Jan 2026 10:22:00 -0500 (EST)
> From: Paul Wouters <pa...@nohats.ca>
> To: Lars Eggert <leg...@mozilla.com>
> CC: Kai Engert <Ka...@kuix.de>, Simon Josefsson <si...@josefsson.org>,
> dev-tec...@mozilla.org
>
> On Mon, 19 Jan 2026, 'Lars Eggert' via dev-tec...@mozilla.org wrote:
>
> > On Jan 19, 2026, at 16:25, Kai Engert <Ka...@kuix.de> wrote:
> >> In my understanding, the intention is to remove code and APIs that it no longer needs in NSPR 5, regardless of other software depending on it.
> >
> > this. The plan roughly would be to strip any code from NSPR that Gecko isn't currently using, and support for any platforms that are not currently Gecko tier platforms.
>
> Note there are other users of NSS/NSPR too, such as libreswan's IKE
> stack.

Libreswan uses NSS, and NSS then uses NSPR, which should keep the
project insulated from these changes.
Where NSPR is being called directly (Arena, memory, error) because it
is part of the NSS API, so I don't see it being a problem.

The only thing that perhaps lives on the edge is libreswan's EAP code.
It uses things like PR_CreateIOLayerStub() when calling
SSL_BadCertHook() et.al. but, again, that's for the NSS interface (a
nice to have item is to revisit the code to see if it can work with
libevent, but I digress).

Taking a step back. Is the intent to cleave off specific NSPR
functionality, or to just pick away at the various APIs removing
functions that don't seem to be used?

> > (NSPR hasn't had - IMO - have any meaningful way to test that code and those platforms for a while now anyway, and I'd rather not ship untested code.)
> >
> >> If other packages depend on the removed code or APIs, a nspr-version-4 package could be introduced, and those requiring nspr-4 could link to that package, instead to the most recent version. Or alternatively, they could make adjustments to avoid the dependencies on the removed code.
> >
> > This again. I think it would be perfectly reasonable for most current non-Gecko users of NSPR to remain on version 4.
>
> that's just a bandaid that will fail sometime in the future.
>
> So I am concerned.
>
> Paul
>

> --
> You received this message because you are subscribed to the Google Groups "dev-tec...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dev-tech-cryp...@mozilla.org.
> To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/5162ee1a-2a7f-46d9-9d4f-d0ca940ef946%40kuix.de.

[Lars Eggert]

Hi,

On Jan 19, 2026, at 18:47, Andrew Cagney <andrew...@gmail.com> wrote:
> Taking a step back. Is the intent to cleave off specific NSPR
> functionality, or to just pick away at the various APIs removing
> functions that don't seem to be used?

the latter.

Full disclosure: I'm treating NSPR as a bit of a trial balloon in this space. I think longer-term we'll want to discuss a similar effort for NSS. I understand that this will be a much more complicated discussion (also within Mozilla), because there are more direct users of NSS than of NSPR (which as you say is mostly consumed as a dependency of NSS.) But let's cross that bridge when we got to it, which definitely won't be for months and likely not even in 2026.

Thanks,
Lars

[Kai Engert]

Hi all,

after more discussions with the Firefox and NSS teams, I'd like to
present a different plan.

We'd like to stop maintaining and stop releasing NSPR as an individual
project.

Once Firefox starts developing Firefox 154, the classic NSPR repository
would (likely) no longer get maintained by Mozilla, except for security
fixes required for the earlier Firefox and NSS versions (probably ending
late 2027 at the time Firefox ESR 153 and Thunderbird 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 work,
because the required NSPR APIs are bundled with it.

We'd like to add symbol versioning to all exported NSPR functions, and
rename all exported NSPR functions at the same time. For example,
PR_Init would get renamed to MPR_Init.

(NSPR = NetScape Portable Runtime, MPR = Mozilla Portable Runtime)

We should consolidate and build only one shared library going forward,
libmpr5.so / mpr5.dll.

MPR code that isn't required by either NSS or Firefox would then get
removed over time.

This means APIs can get removed from the MPR library between releases.
We haven't discussed this detail yet, but if this is a problem for
external consumers, maybe we could define that the MPR major library
version is increased whenever functions are removed?

Regards
Kai

[Robert Relyea]

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
> present a different plan.
>
> We'd like to stop maintaining and stop releasing NSPR as an individual
> project.
>
> Once Firefox starts developing Firefox 154, the classic NSPR
> repository would (likely) no longer get maintained by Mozilla, except
> for security fixes required for the earlier Firefox and NSS versions
> (probably ending late 2027 at the time Firefox ESR 153 and Thunderbird
> 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
> work, because the required NSPR APIs are bundled with it.

This  sounds fine.

>
> We'd like to add symbol versioning to all exported NSPR functions, and
> rename all exported NSPR functions at the same time.

This will also be fine. We already have symbol versioning in NSS.

>  For example, PR_Init would get renamed to MPR_Init.
>
> (NSPR = NetScape Portable Runtime, MPR = Mozilla Portable Runtime)
>
> We should consolidate and build only one shared library going forward,
> libmpr5.so / mpr5.dll.

This would be a nightmare for us. Any kind of rollout for us will need
to maintain both symbols and library sets.

We require maintaining ABI compatibility over the life of our OS
releases. That means RHEL-8, RHEL-9 and RHEL-10 will all need to be
maintain the old nspr symbols. But the also require updates to the
latest version of Firefox because Firefox ESR has a shorter support
cycle than RHEL-10, so we need to pick up the latest NSS and NSPR into
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
ability for Firefox and NSS to use both, or we need to create
compatibilty layers (old nspr libraries with the old names calling the
new nspr library).

An example of the time lines we are looking at, track the conversion of
the NSS database from dbm to sql: The sqldb code as added to NSS in
about 2006 (pre-mecurial). It was made the default in Nov 2017. Ability
to build without dbm (NSS_DISABLE_DBM added) 2020. When we can remove
dbm completely (2029 - RHEL-8 goes out of support).

>
> MPR code that isn't required by either NSS or Firefox would then get
> removed over time.

This is probabably doable. There are other users of NSPR in our OS, but
those can get transitioned over time, as long as the phase out is a
compile time option.

>
> This means APIs can get removed from the MPR library between releases.
> We haven't discussed this detail yet, but if this is a problem for
> external consumers, maybe we could define that the MPR major library
> version is increased whenever functions are removed?

Err, only if the API can be compiled out over releases. As long as both
Firefox and NSS depend on NSPR (or MPR), then we have the long term
support issues. Dropping NSPR as a separate project doesn't stop it from
being a separate library, and it would be difficult to not export the
NSPR interface because that's is how applications use NSS to do thing
like SSL, so even applications that aren't using NSPR per se, still uses
NSPR if they are doing NSS.


>
> Regards
> Kai
>

[Kai Engert]

On 4/15/26 19:35, 'Robert Relyea' via dev-tec...@mozilla.org wrote:
> This would be a nightmare for us. Any kind of rollout for us will need
> to maintain both symbols and library sets.

As I understand it, renaming is necessary to ensure that accidentally
loading an old NSPR library into the same process will not result in the
wrong symbols being used - on systems that have multiple copies of the
NSPR libraries.

> Basically to make this work, we would have to maintain both and the
> ability for Firefox and NSS to use both, or we need to create
> compatibilty layers (old nspr libraries with the old names calling the
> new nspr library).

Introducing shim libraries (named like the old NSPR libraries) that
export the old symbols, which forward calls to the new functions in the
new library, might be doable on your side?

Over time, when functionality gets removed, the shim could be changed to
return a failure for the removed APIs.

>> MPR code that isn't required by either NSS or Firefox would then get
>> removed over time.
> This is probabably doable. There are other users of NSPR in our OS, but
> those can get transitioned over time, as long as the phase out is a
> compile time option.

I think it wouldn't be a compile time option of MPR. The intention is
that the feature set of MPR is no longer promised to remain stable.

If a consumer needs old NSPR code that newest NSS no longer requires and
is removed from MPR, and I think you'd have to find another way to
provide that old API. Potentially by tweaking the NSPR shim library to
provide it.

>> This means APIs can get removed from the MPR library between releases.
>> We haven't discussed this detail yet, but if this is a problem for
>> external consumers, maybe we could define that the MPR major library
>> version is increased whenever functions are removed?
>
> Err, only if the API can be compiled out over releases. As long as both
> Firefox and NSS depend on NSPR (or MPR), then we have the long term
> support issues. Dropping NSPR as a separate project doesn't stop it from
> being a separate library, and it would be difficult to not export the
> NSPR interface because that's is how applications use NSS to do thing
> like SSL, so even applications that aren't using NSPR per se, still uses
> NSPR if they are doing NSS.

The shim library would provide the interfaces with the old name. I guess
you'd have to replace the single copy of the NSPR libraries on the
system with the replacement shim libraries (nspr4 + plc4 + plds4).

So applications that aren't relinked/rebuilt, and don't depend on the
removed APIs should continue to work?

Regards,
Kai

[Kai Engert]

Note my previous message was an attempt to help in thinking about
options for your needs.

From our perspective, I think the intention is to no longer make
promises about NSPR/MPR APIs remaining available.

Brainstorming again about your needs, maybe it would be more practical
for you if you took to opposite approach?

You could decide that you keep maintaining the old NSPR libraries, as
long as you need them, and backport upstream MPR fixes to it, if necessary.

And instead of having a shim from NSPR to MPR, maybe you need it the
other way round?

Don't use MPR as distributed with NSS, but rather use a shim MPR library
that maps the new symbol names to the old NSPR symbols?

I think the dilemma here is that the Firefox team would like to be more
flexible and make changes more easily, which isn't easy to align with
your needs for long term stability.

Kai

[Robert Relyea]

On 4/16/26 7:36 AM, Kai Engert wrote:
> Note my previous message was an attempt to help in thinking about
> options for your needs.
>
> From our perspective, I think the intention is to no longer make
> promises about NSPR/MPR APIs remaining available.

This is a foolhardy goal. That ship has sailed, and any way to get back
to it will require a lot of work an patience. I better way is to simply
integrate it back into NSS and keep that ABI requirements. If you need
some additional work you can start a new library that neither depends on.

Now that being said, we can probably look at NSPR and figure what parts
that may be marked as 'not public' and can eventually be phased out. I
know that the IO system is the system that needs to be managed the most
carefully, but suspect it's the one you want to change the most.

>
> Brainstorming again about your needs, maybe it would be more practical
> for you if you took to opposite approach?
>
> You could decide that you keep maintaining the old NSPR libraries, as
> long as you need them, and backport upstream MPR fixes to it, if
> necessary.

The integration of NSS and NSPR is *very tight* shim libraries on a new
API could work, but only if the new API is *stable*. I also think the
shim libraries existence would be a prereq for your plan. It would even
help the transition. You can create the new library with the shims and
then you can transition the base libraries to call the new API directly
in a piece meal way rather than all at once. I doubt we would want make
a huge patch that moves NSS to the new MPR in one go...

>
> And instead of having a shim from NSPR to MPR, maybe you need it the
> other way round?

That might be easier. It provides the same character as the other shims,
but you only add MPR calls as you need them.

>
> Don't use MPR as distributed with NSS, but rather use a shim MPR
> library that maps the new symbol names to the old NSPR symbols?

The shim only works if there isn't another library. NOTE: In our system
this would mean that everything (including firefox) lives on top of the
shim. Firefox must have the same view as NSPR. This means it needs to
run on the shim, which means NSPR will need to have at least the same
functionality and stability as MPR, which means MPR +MPR shim probably
is a non-starter because it you will end up maintaining two libraries
(MPR and NSPR). So I guess long term it isn't easier.

>
> I think the dilemma here is that the Firefox team would like to be
> more flexible and make changes more easily, which isn't easy to align
> with your needs for long term stability.

Yup, though, ironically it's Firefox's 'move' fast plan that has caused
the requirements of freezing the lowest level of the system. The normal
way we handle these things is we just freeze all the code when we ship.
The problem is that we can't freeze a version of Firefox itself, and
thus we need to drop new versions of NSS and NSPR into old versions of
our OS.

Maybe If I knew what it was you wanted to change moving forward. NSPR
has been extremely stable, with only minimal changes to the code base
for a couple of decades. Is it just removing functionality? That can be
done the way we do in NSS. We isolate the functionality and
conditionally compile it. Often (initially) we just conditionally
disable the functionality, but eventually we drop out the actual code.

I think getting to they "wild west" of "let's just rewrite everything
when we feel like it" is really, in the long run, more expensive than
you realize. Moving to a 'here's where we want to go long term, and it's
stable within these  parameters'  is something we could work with.


bob

>
> Kai
>

[Kai Engert]

Hi Bob,

thank you for the feedback, we appreciate the concern and will take some
time to consider the best path forwards.

Regards
Kai