The problem: 1. Insecure defaults are, well, insecure. 2. Secure defaults cause confusion and support overhead esp. in dev/testing environments. 3. We need fine-grained security settings (e.g. "allow-plain-with-ssl") because security is complicated.
Here's what I would suggest: Provide a top-level setting: "secure", default true. If true, all the fine-grained security settings have secure defaults. If false, all fine-grained security settings have permissive defaults. This addresses the problems as follows: 1. We are secure by default. 2. User in a safe environment must set secure=off but that beats making them hit "allow-plain-with-ssl", "require-sasl-if-no-ssl", "no-ssl-verison-3-on-full-moon" ... one by one. It is also very clear that this is flat-out insecure. When the user is ready for security they will set secure=true and be less surprised if they have to tweak other security settings. 3. We have fine-grained settings to selectively permit special things in secure mode for people with special needs. Cheers, Alan. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
