On Sat, Jun 12, 2010 at 02:11:14PM -0700, Nelson B Bolyard wrote: > You have a problem with a distribution of NSS that is not identical to the > NSS as built from the upstream NSS source repository. Mozilla's NSS team > supports NSS as it comes from the builds from the upstream NSS source > repository. Mozilla's NSS team does not attempt to keep track of all the > changes made to NSS by every downstream Linux distro. If the upstream NSS > works, but some downstream distribution does not, then the differences are > due to changes outside of the control of Mozilla's NSS team, and primary > support for those problems (that are unique to a downstream distribution) > must come from the suppliers of that downstream distribution. LOOK at the links I provided, there are ZERO changes to the actual source code.
There is an additional file packaged for pkgconfig support, and we compile with -fno-strict-aliasing. > > It is true that virtually every Linux distribution modifies NSS sources > significantly and distributes a downstream flavor of NSS that differs from > the upstream version in a number of ways. > > For some distros, the differences are so minor that you can simply download > the upstream NSS sources, build them yourself, and use the resultant > binaries as a replacement for the binaries that came with the distribution, > and it all works fine. > > For other distros, they've made changes on such a large scale, such as > renaming the functions, renaming the shared libraries and splitting up the > shared libraries so that they no longer all live in the same directory, that > a vanilla build of NSS from upstream sources simply will not work with > programs that were built to work with that distro's NSS libraries. If your > distro is one of those, then you'll have no choice but to get help from the > maintainers of that distro. NONE of the above is the case, as I noted in previous emails. The C source is absolutely stock. > It may be that, in your case, the problem is as simple as this: the distro > did not include the ".chk" files that are generated during the NSS build > process, or it put them in the wrong directory or gave them the wrong file > names, so that NSS cannot find them. Or they may have changed the shared > libraries, but not regenerated the .chk files. If that is the case, and the > distro HAS distributed NSS's shlibsign program, then you may be able > to remedy this yourself by generating replacements for the missing (or old) > .chk files using shlibsign. Instructions on how to use shlibsign may be > found at > http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn6.html Ok, this helped tremendously. The root of the problem is that the shared libraries can change POST-install, as needed for ELF signing, split-debug and prelinking. The ELF signing is a catch-22. Either I have to run shlibsign afterwards, or I have to not sign those files, and leave them open to potential compromise. Running shlibsign does remedy the problem. However, this entire matter could be remedied if some more useful error had been returned instead of 'Invalid Arguments'. Something to indicate that the library checksums no longer matched. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgp2rACleeKNf.pgp
Description: PGP signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
