NSS_ALLOW_SSLKEYLOGFILE=1 is enabled at compile time

[colo-des]

I was looking at the options passed at compile time of the dev-libs/nss package and I see that in the ebuilds of both the stable and testing versions
3.79.2 and 3.88.1 the export variable NSS_ALLOW_SSLKEYLOGFILE=1 is passed
I searched and apparently it is used for debugging and from the dev-libs/nss-3.42 version they say that it is disabled, my question is why it is enabled
and what function does it fulfill that it is enabled since if it is a release it is not being debugged.

http://udn.realityripple.com/docs/Mozilla/Projects/NSS/Reference/NSS_environment_variables

NSS_ALLOW_SSLKEYLOGFILE Boolean (1 to enable)
Enable NSS support in optimized builds for logging SSL/TLS key material to a logfile if the SSLKEYLOGFILE environment variable.
As of NSS 3.24 this is disabled by default.

https://bugzilla.mozilla.org/show_bug.cgi?id=1515236#c4

Regards.

[colo-des]

The help from build.sh script says that it can be disabled, that is, it is enabled by default, but there is no use for it disable it to handle --disable-keylog...or I don't see it.

~/adm/work/nss/src/nss-3.88.1/nss $ ./build.sh --help

--disable-keylog disable support for logging key data to a file specified by the SSLKEYLOGFILE environment variable

Regards.

[colo-des]

This is very interesting.

https://markusgraf.net/2021-07-04-FreeBSD-SSLKEYLOGFILE.html

For my taste it should be disabled by default, and be a use in the ebuild, so if someone wants to see what happens with wireshark
rebuild nss with active use and you can sniff the traffic... but not by default as it is now, although I started to test and I don't get nothing with firefox.

Regards.

[colo-des]

Now it works, I was running firefox from a sandbox so it didn't work, when running it from a console, it does send the log.

[Hu]

A simple review of git log shows this was first added in bb2d6491fd7b64675fd0ccf1007b40f87b99f674. That commit credits https://github.com/gentoo/gentoo/pull/13990. The request does not describe the rationale for the change.

[colo-des]

It seems to me that it is not necessary to give the reason, it is in plain sight, on top of that it says it openly... to date it makes one think but of course, then one is paranoid.

[sam_]

If you think a change should be made, please file a bug. Posting on the forums doesn't get things anywhere.

With regard to the function: it allows directing NSS to log to a file at runtime. If NSS isn't built with this support, that isn't possible.

Now, as for the change itself: while I generally think that environment variables can't be trusted anyway (this is well-accepted), given this is off by default upstream, it probably makes sense to make it toggleable via a USE flag, if nothing else to avoid confusion or concern.

Note that for NSS, it's a bit different to other ebuilds in a way, because it doesn't use autotools, so users can't use EXTRA_ECONF to pass additional configure arguments. They might be able to pass a variable via /etc/portage/env to enable the logging capability if they want, but I haven't checked if the build system allows that or not.

[colo-des]

Don't want to clash with the ebuilds developers, they have their reasons for to do things the way they to make,
I respect them, but if don't I like their recipes, modify them or don't use them directly.

Well, I edited it in my local tree by setting the option NSS_ALLOW_SSLKEYLOGFILE=0

[sam_]

My point is that if you think something is wrong as a default, you can tell us using the proper venue (Bugzilla) and we'll consider it.

That's not clashing, but you and others in this thread feel the same, and I think it's worth changing as well (if nothing else to avoid scaring people).

If everybody just implemented local workarounds for problems, we would be in big trouble. We need bug reports.

[colo-des]

Without intending to generate controversy, users are the owners of editing the ebuilds and building their own ebuilds in their local trees
,or in external repositories, and if it doesn't give them the ability to handle eclass they can compile from source and install in /usr/local/,
but then no come and complain through the forums or IRC.
This is not a bug, it is a feature wanted by the maintainer of the ebuild, since he liked it so much, he soldered it fixed, so nobody
change it so everyone can enjoy that functionality that will always be available.
I could not have created this thread and not say anything, but I do it so that many see how the choice of a few people determines what everyone uses.
The reality is that there should be no one between the source code and the end user...mens in middle.

Regards.

[pietinger]

[colo-des]

[pietinger]

[colo-des]

I don't have that luck...where I live as governments change, they tend to change the names of the streets...that says it all.

The development system is based on tests and reports as feedback, it is humanly impossible to determine all the states
of the state machine... that is understandable.
To err is human, only those who have never done anything do not err... although thinking about it, never doing anything is the worst mistake that exists.
For me nothing is completely safe or completely insecure, there are no extremes.

Many years ago around 2005 I made some guides on how to defend ourselves from the tyranny that were the mandriva repositories, I don't know who could have done it.
read or how much it was read, I had no reports, I only did it as the only defense measure, perhaps a reaction to unjustified treatment.
So if the things you do are only used by yourself, you don't have to answer to anyone, but when you know that what you do
many people can use it, you have to be more careful, although as open licenses say... nobody is responsible for anything.

Regards.

[Juippisi]

[pietinger]