| Newsgroups |
gmane.comp.mozilla.crypto |
| Message-ID |
<[email protected]> |
On 4/16/26 7:36 AM, Kai Engert wrote:
> Note my previous message was an attempt to help in thinking about=20
> options for your needs.
>
> From our perspective, I think the intention is to no longer make=20
> promises about NSPR/MPR APIs remaining available.
This is a foolhardy goal. That ship has sailed, and any way to get back=20
to it will require a lot of work an patience. I better way is to simply=20
integrate it back into NSS and keep that ABI requirements. If you need=20
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=20
that may be marked as 'not public' and can eventually be phased out. I=20
know that the IO system is the system that needs to be managed the most=20
carefully, but suspect it's the one you want to change the most.
>
> Brainstorming again about your needs, maybe it would be more practical=20
> for you if you took to opposite approach?
>
> You could decide that you keep maintaining the old NSPR libraries, as=20
> long as you need them, and backport upstream MPR fixes to it, if=20
> necessary.
The integration of NSS and NSPR is *very tight* shim libraries on a new=20
API could work, but only if the new API is *stable*. I also think the=20
shim libraries existence would be a prereq for your plan. It would even=20
help the transition. You can create the new library with the shims and=20
then you can transition the base libraries to call the new API directly=20
in a piece meal way rather than all at once. I doubt we would want make=20
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=20
> other way round?
That might be easier. It provides the same character as the other shims,=20
but you only add MPR calls as you need them.
>
> Don't use MPR as distributed with NSS, but rather use a shim MPR=20
> 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=20
this would mean that everything (including firefox) lives on top of the=20
shim. Firefox must have the same view as NSPR. This means it needs to=20
run on the shim, which means NSPR will need to have at least the same=20
functionality and stability as MPR, which means MPR +MPR shim probably=20
is a non-starter because it you will end up maintaining two libraries=20
(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=20
> more flexible and make changes more easily, which isn't easy to align=20
> with your needs for long term stability.
Yup, though, ironically it's Firefox's 'move' fast plan that has caused=20
the requirements of freezing the lowest level of the system. The normal=20
way we handle these things is we just freeze all the code when we ship.=20
The problem is that we can't freeze a version of Firefox itself, and=20
thus we need to drop new versions of NSS and NSPR into old versions of=20
our OS.
Maybe If I knew what it was you wanted to change moving forward. NSPR=20
has been extremely stable, with only minimal changes to the code base=20
for a couple of decades. Is it just removing functionality? That can be=20
done the way we do in NSS. We isolate the functionality and=20
conditionally compile it. Often (initially) we just conditionally=20
disable the functionality, but eventually we drop out the actual code.
I think getting to they "wild west" of "let's just rewrite everything=20
when we feel like it" is really, in the long run, more expensive than=20
you realize. Moving to a 'here's where we want to go long term, and it's=20
stable within these=C2=A0 parameters'=C2=A0 is something we could work with=
.
bob
>
> 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/1f4d739f-b8d2-483a-a520-48ffb922bd91%40redhat.com.