Created attachment 438836 [details, diff] nss-3.24-allow-sslkeylogfile.patch To get SSLKEYLOGFIE logging it is necessary to set use flag debug for www-client/firefox-47.0 and to patch ebuild for dev-libs/nss-3.24. It would be more convenient to offer a choice via ad hoc use flags. Detailed report follows. I have recently discovered that the logging of SSL keys does not work as it has for years in firefox, from www-client/firefox-47.0 and/or from dev-libs/nss-3.24 . The reasons and solutions to get that logging back, are of course, on Mozilla pages such as: https://bugzilla.mozilla.org/show_bug.cgi?id=1183318 https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Reference/NSS_environment_variables (only fairly *recently* updated with those reasons and solutions). So setting a line like this in package.use : # grep firefox /etc/portage/package.use www-client/firefox debug # ... and other use flags ... # and reinstalling firefox, and preparing a patch like this: # cat nss-3.24-allow-sslkeylogfile.patch 186a187 > export NSS_ALLOW_SSLKEYLOGFILE=1 # and then: # patch nss-3.24.ebuild < nss-3.24-allow-sslkeylogfile.patch # mv -vi nss-3.24.ebuild nss-3.24-r1.ebuild ( or just adding into the copy of that ebuild another one line, this one: export NSS_ALLOW_SSLKEYLOGFILE=1 into the bunch of "export ..." lines and renaming that ebuild ) and then moving that nss-3.24-r1.ebuild in my local overlay, and reinstalling dev-libs/nss, I now have the SSLKEYLOGFILE functionality back. But it would be great to have an optional use flag to allow ssl key logging in dev-libs/nss, and it would be great to not have to go for the huge debugging installation of firefox to get it to use nss to log SSL keys, by being able to set a use flag for an optimized build (without setting the debug use flag). A fraction of users will certainly need a more convenient solution to this, so I thought I'd post this as a bug report, even though there is nothing wrong in the Mozilla's unshipping of the SSLKEYLOGFILE logging. I don't see how my particular architecture matters in this case, because this story is the same in all architectures, so not posting emerge --info.
From https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.24_release_notes#Notable_changes_in_NSS_3.24: > Disable (by default) NSS support in optimized builds for logging > SSL/TLS key material to a logfile if the SSLKEYLOGFILE environment > variable is set. To enable the functionality in optimized builds, you > must define the symbol NSS_ALLOW_SSLKEYLOGFILE when building NSS.
Created attachment 440042 [details, diff] nss-3.25-allow-sslkeylogfile.patch It is possible to have SSLKEYLOGFILE logging and the optimized Firefox build, and without use of the local overlay. But by use of this small patch (see the attachment): nss-3.25-allow-sslkeylogfile.patch Set the /etc/portage/bashrc exactly as currently on: https://wiki.gentoo.org/wiki//etc/portage/patches ( precisely: https://wiki.gentoo.org/wiki//etc/portage/patches#Enabling_.2Fetc.2Fportage.2Fpatches_for_all_ebuilds but the local link names in that wiki page need fixing) Create dir: mkdir -pv /etc/portage/patches/dev-libs/nss-3.25/ and: mv -iv nss-3.25-allow-sslkeylogfile.patch \ /etc/portage/patches/dev-libs/nss-3.25/ Next, when: emerge -1 nss , there should be a line at the start: * "User patches applied. (only that non-verbose notice, but the patch is applied) And there should be, at the later stretch of compile, the -DNSS_ALLOW_SSLKEYLOGFILE=1 added to lots of lines of the compilation. After nss has compiled, Firefox can be recompiled without the debug useflag, and all the network will have the secrets logs, as set with that env variable. It will be great when we get a useflag for this functionality! Regards! --- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr
If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team
