I've read this, version 3.15.4 is slightly different, nspr is shipped with nss, no more as a standalone source, the slackbuild needs a little changes

and now something complet... and now a question:

i've seen nspr is linked with the running kernel, i've compiled it on the desktop pc with 3.10 (standard 14.1 kernel), but my laptop, who share the packages has 3.13, there will be some kind of problems?

o_O

Uh, no. (The "kernel headers" in /usr/include/linux don't count - those are platform-specific headers for linking with glibc, *not* for linking with the running kernel. The kernel does not ship any .so libraries.)

I have linux-3.13.0 running with slackware-14.1 here, and libnspr4.so from seamonkey-solibs-2.23-x86_64-1_slack14.1 works fine for me -- presumably Patrick compiled that on 3.10.17, so it's exactly the same situation.

In general, the only stuff that links with the kernel (and needs recompiling for a new kernel) is stuff that installs its own kernel modules in /lib/modules/<version> (eg. nvidia, virtualbox).

Patrick is usually quite assiduous about security updates for openssl and seamonkey-solibs, so it's possible that this will see an official Slackware patch soon.

Firefox, SeaMonkey, and Thunderbird, as currently shipped in Slackware 14.1, are unaffected as long as security.ssl.enable_false_start is not changed from its default value of false.

Those interested/worried can verify this setting in about:config (Firefox & SeaMonkey) or the config editor (Thunderbird).

I believe the only other stock Slackware application that uses libssl3 for SSL/TLS transport is Pidgin. It's also unaffected because it doesn't make use of abbreviated handshakes. If there is another stock Slackware program I've missed let me know.

Nonetheless, it would be good to upgrade to NSS 3.15.4 in case other clients link libssl3 with false start enabled.

--mancha

For those wondering why OP marked this solved:

Tue Jan 28 21:07:13 UTC 2014
l/mozilla-nss-3.15.4-i486-1.txz: Upgraded.
Upgraded to nss-3.15.4 and nspr-4.10.3.
Fixes a possible man-in-the-middle issue.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename...=CVE-2013-1740
(* Security fix *)