Here are some informal guidelines on what kind of patches that are likely to be accepted or rejected, based on policies and/or the history of rejection/acceptance in the past.
Non-Erlang/OTP team members: Feel free to add items to this page, as long as you cite a reference to an email written by an Erlang/OTP team member. We (Erlang/OTP) may edit the item if we feel that you have quoted us out of context, or if a policy has been changed since the email was written.
No. It is our policy not to add any new environment variables for configuring the emulator. Implement a new command line option to configure the behavior (see this example of an accepted patch). Any command line option can be passed in the environment variable
Source: Björn Gustavsson (Erlang/OTP team member)
The Erlang distribution was not designed to support various levels of trust. A node that knows the shared cookie is assumed to be trusted completely. There is no way to restrict what a connected node can do to another node.
We will not accept patches that add mechanisms that allows a node to restrict what other connected nodes can do, for the following reasons:
If you still want to improve the security, please write an EEP first. It would probably be more fruitful to design an entire new protocol (independent of the current Erlang distribution), designed with security in mind from the ground up.
Source: The Erlang/OTP Technical Board