On Sat, Apr 22, 2023 at 4:30 AM Branko Čibej <br...@apache.org> wrote: > > On 22.04.2023 10:27, Branko Čibej wrote: > > On 21.04.2023 16:43, Johan Corveleyn wrote: > > > My plan is to revert r1845377 during next weekend. For the first bulletpoint > nothing has to be done, but if consensus changes during the week, I can do > the work to to implement option 1. For the second bullet point I'd like to > reach consensus (on the short- and long term plan) by the same time, then if > we decide on 2/3 we will put it on the wish list for a future release. > > Great!
+1. great to see progress on this. Getting the change reverted should be the priority. If someone volunteers to take up some of the additional ideas even better but we do not need to block on them. > There was one additional suggestion: obfuscate plaintext passwords, or > encrypt them with a key embedded in the code (or even with a key > supplied at compile-time). > > > There's actually a branch for that, but the feature never made it to trunk. > > > I'll just add that the intent of that branch is to properly encrypt passwords > at least on Linux, not to obfuscate them or embed a key in the code. The > latter is worse than storing in plain text, because the effect is the same > but it adds a veneer of false sense of security. Feedback we had from users did not agree with this. They would have seen something as simple as Base64 encoding the string as an improvement. I believe there is a way to implement this without creating the impression that the string is cryptographically secure. For starters, you could just name the property in the file something like "obfuscatedPassword" or "base64Password" to make it clear. Kubernetes has used the term "Opaque" for its Base64 encoded but otherwise plaintext "secrets". Even if we did use encryption and stored the key in the same file it would still be better than having a plain text string. I would agree that we should not suggest that the password is "secure" if we do this but we have let this argument be the enemy of making progress for nearly 2 decades when lots of users have said this would be an improvement for them. Mark
