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