https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=Build
for a direct link.
On Wed, May 5, 2021 at 9:45 AM Robert Relyea <rrel...@redhat.com> wrote:
>
> 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
> >> "dev-tech-crypto@mozilla.org" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to dev-tech-crypto+unsubscr...@mozilla.org.
> >> 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
> "dev-tech-crypto@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dev-tech-crypto+unsubscr...@mozilla.org.
> 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.
--
You received this message because you are subscribed to the Google Groups
"dev-tech-crypto@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dev-tech-crypto+unsubscr...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/CAPLxc%3DVGwsj0JhFmCMFudYFVGTJv0yhjmrzAWQJy52aPO339bg%40mail.gmail.com.
