Re: nss symbols vs openssl symbols

On 5/1/21 2:57 PM, Thomas Klausner wrote:
> Hi Bob!
>
> Thanks again for the detailed explanation of the nss build system.
>
> With it, it was quite easy to see that the whole symbol hiding stuff
> was just missing in the NetBSD configuration coming with nss.  For
> nss' purposes, you can handle NetBSD, FreeBSD, and OpenBSD nearly the
> same. I reduced the differences between the OpenBSD and NetBSD
> configurations and came up with the attached patch.
>
> (I also removed code for supporting the a.out file format, which is
> not used in NetBSD for ten years or more. And it improves arm and
> arm64 support.)
>
> Please merge this (or something similar) into the next nss release.
>
> Thanks,
>   Thomas


If you create a bug here:

bugzilla.mozilla.org

Assign the bug to me and attach this patch, I will review it and include 
it in NSS then following release of NSS. If you are maintaining NSS for 
BSD systems, you probably should sign up for a phabricator account. That 
would make subitting new patches to NSS easier. Your current patch is 
small enough, I can handle reviewing it with the mozilla tools. and 
since your patch is in the NetBSD.mk file, it shouldn't be a problem 
bringing it upstream.


bob

>
> On Fri, Apr 16, 2021 at 03:25:07PM -0700, Robert Relyea wrote:
>> NSS hides the symbols with shared libraries that only export a curated set
>> of public symbols. Each nss shared library has it's own symbol list found in
>> {sharedlibname}.def so lib/nss/nss.def lib/util/nssutil.def lib/ssl/ssl.def
>> etc.
>>
>> The NSS build system massages this file to whatever system the OS uses to
>> create an use an explicit export list for your shared library.
>>
>> When you link with NSS, you need to link with the NSS shared library, namley
>> libnss3.so libnssutil3.so libssl3.so and libsmime3.so (depending on how much
>> of NSS you need). libsoftken3 will be automatically loaded by libnss3.so and
>> it in term will automatically load libfreebl* as needed. So only the last
>> two are dlopened. You should not link with any libnss*.a files, or all bets
>> are off on working with something like openssl.
>>
>> If you are doing all this and still running into issues, it's likely the
>> build system (either your own or the NSS build system) isn't correctly
>> processing the .def file for your platform. The command to process the .def
>> file is set with the symbol PROCESS_MAP_FILE and is set in your {OS}.mk file
>> in nss/coreconf.
>>
>> Linux, for instance, sets the command as follows:
>>
>> PROCESS_MAP_FILE = grep -v ';-' $< | \
>>          sed -e 's,;+,,' -e 's; DATA ;;' -e 's,;;,,' -e 's,;.*,;,' > $@
>> This removes all the lines with ;- , then removes all occurrences of ';+','
>> DATA ',';;', and then all commands '; to the end of the line'
>>
>> Linux later adds the directive -Wl,-c,$(MAPFILE) to it's shared library
>> linking command.
>>
>> It looks like openBSD has the same processing line as linux, and adds
>> -Wl,--version-script,$(MAPFILE) which sounds right to me.
>>
>> (Some unsupported OSs ignore the MAPFILE, and they could be subject to
>> symbol collisions).
>>
>> bob
>>
>>
>>> I looked at the code a bit and see that HASH_Update calls a function
>>> indirectly, which in pk11cxt.c is forwarded and finally used in
>>> pkcs11c.c - which however, then uses the wrong function, the one from
>>> openssl.
>>>
>>> Can you please explain in more detail how the function table works?
>>> In my case, it seems the wrong MD5_Update function is used when
>>> openssl is linked into the binary.
>>>
>>> Perhaps it's a difference in linker behavior on NetBSD?
>>>
>>> As for pkgsrc - I cited the patches in my original email. The whole
>>> package information is [1], the Makefile contains the flags used when
>>> compiling and the patches directory the patches used.  If you see what
>>> the problem is, that'd be very helpful, but I don't think it's
>>> something that's something obvious any longer.
>>>
>>> [1] https://github.com/NetBSD/pkgsrc/tree/trunk/devel/nss
>>>
>>> Thanks,
>>>    Thomas
>>>
>> -- 
>> 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 email to [email protected].
>> To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/8c271011-93c3-529f-6e08-deff68d9bb32%40redhat.com.


-- 
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 email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/e6b61d8d-ab92-835b-16d5-0cffe31ea5e0%40redhat.com.