The real problem, is the community perception of how 'safe' their content is, using the existing system. User John believes that by setting quest, and cheat passwords, he is doing something meaningful, and doesn't realise that it takes all of five seconds to bypass it, as it stands. Thus, they stand up on a soap box, and rant against removing this feature. I doubt there are many people here, on AGN, that we need to convince, but rather, the PZC crowd, is the bigger culprit. I suggested the library module as a quick-and-dirty way to skirt the issue, not as a valid method of security. If a user wants special levels of security, and encryption, clearly they would need to devise their own module for it; and the terms of GPL take a somewhat dim view on that, in general.
If all forward-changes to a source set, must be made available, a security method, would also need to be made available. A randomly generated key file, would therefore be the most secure, but it's something that users of the open-source code should be making, not the present project leaders, who rightfully feel that all of this is just a sheer waste of time. I concur. I suggested making the encryption itself, a module, that allows one of three inputs: User-defined, precompiled lib (using the stock method), or, best of all, none.
The real question, is whether the community at large can grow beyond the need for this false sense of protection.
Honestly, if the core devs opened up to the PZC community how the idea of not releasing the password and encryption routines as part of the source, was crippling future development, the perception of it would change in favour actual progress. I do not believe that the point has ever been nailed in to the heads of all the members, that this is more than simple logistics issue, and that it is indeed stalling exactly what they've wanted for years.
Hell, a developer strike would shake things up too.
Really though, the core devs posting a clear, concise, and explanatory topic on PZC may do the trick.
Reply With Quote