FAQ: What kind of patches will be approved?
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 ERL_FLAGS.
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:
- “Almost secure” is not any better than “definitely not secure”. You still cannot allow untrusted nodes to connect. (To reach the level of complete security is very hard for a protocol that was not designed for that in the beginning.)
- We don’t want code bloat and code that makes the Erlang distribution slower even for applications that don’t use the new features.
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
change footers copy tags