@spacekitteh, thanks for your PR! By analyzing the history of the files in this pull request, we identified @gilligan, @cko and @vcunat to be potential reviewers.

I actually don't see much use in having an option to disable openssl. So cjdns does not need openssl per se. Why would you need to use it with a nodejs built without ssl support though?

I don't see a good reason for that. Can you explain? Otherwise i would be rather 👎 on this.

1. Minimise attack surface
2. Until nodejs can be built with LibreSSL, I'd rather not pretend to be secure

I'm also not really sold on the idea.

Re: attack surface, when the attack surface embeds a sizable part of a browser, I'm not sure disabling openssl is really a helpful move. Can you provide specifics on why this is a big improvement?

FWIW OpenSSL is useful for much more than just networking. For example, nodejs's random number generator (while not perfect) depends upon OpenSSL. Removing this functionality will certainly be surprising.

Re: libressl, using LibreSSL doesn't change you from pretending to be secure vs. being actually secure. Secure isn't a binary thing, it is a spectrum and usually you need a threat matrix to really understand what is worth protecting against.

Re: attack surface, when the attack surface embeds a sizable part of a browser, I'm not sure disabling openssl is really a helpful move. Can you provide specifics on why this is a big improvement?

It's not too big, but every little bit helps.

FWIW OpenSSL is useful for much more than just networking. For example, nodejs's random number generator (while not perfect) depends upon OpenSSL. Removing this functionality will certainly be surprising.

Indeed, and some node applications need neither SSL nor CPRNGs. :)

Re: libressl, using LibreSSL doesn't change you from pretending to be secure vs. being actually secure. Secure isn't a binary thing, it is a spectrum and usually you need a threat matrix to really understand what is worth protecting against.

Yeah, of course. It does, however, significantly reduce the number of CVEs applicable, which is pretty much always a good thing.

Reguardless, nodejs itself ships with the option to disable SSL (if you look at the changes in the PR, you'll see that I'm merely adding the "--without-ssl" build flag). Likewise, a huge part of the usefulness of nodejs is npm, and there is a enableNpm flag. For something as heavyweight as nodejs, I think having some ability to configure it to your needs is always a good thing.

Disabling npm has a huge benefit for whenever you are creating runtime production environments which will mostly just invoke some service via node directly. It reduces the closure size considerably.

I do not see the same benefits with the ssl flag. I also do not think that anything that can be configured should also be configured.

If a configuration option isn't helpful for you, then leave it at the default. However, there are cases where it option IS useful. I don't understand the objection.

I think the reason this PR hasn't been merged is while it perhaps adds a useful option flag, it also adds extra edge cases that future maintainers need to watch and test for. These edge cases, plus the very likely small user base interested in this feature make it tough for me to justify merging, personally. This seems to me like a patch more appropriate for using local overrides, instead of an in-tree option.

Ok.