On Thu, Mar 30, 2023 at 12:15 AM Nathan Hartman <hartman.nat...@gmail.com> wrote: > > On Wed, Mar 29, 2023 at 6:02 PM Evgeny Kotkov > <evgeny.kot...@visualsvn.com> wrote: > > > > Nathan Hartman <hartman.nat...@gmail.com> writes: > > > > > I think a good middle ground is: > > > > > > * Build with --enable-plaintext-password-storage by default; users who > > > want to harden their system can do so, but will need to build their > > > own client. > > > > +1.
+1 > > > * Set the default run-time config to store-plaintext-passwords = no > > > (if it isn't already; haven't checked) and instruct users on how to > > > change it. This makes the decision to store in plaintext an explicit > > > one that the user can opt into. (I appreciate that this could be > > > changed without the user's knowledge; perhaps the systemwide config > > > should always take precedence over the user-controlled one for this > > > setting?) > > > > So, apparently, the current default is "ask". > > > > I haven't checked all the details, but I think that defaulting to "ask" > > already makes the user decision explicit and allows it to happen naturally, > > without requiring any additional instructions or knowledge. > > > > If we change the default to "no", this part of the experience could be > > worse, > > because for the end users it might look like the credentials aren't being > > stored for unknown reasons / a bug in the software. > > Ah, this makes sense. In that case, I'm +1 to leave it as "ask" (no change). +1 Basically this would correspond to kfogel's proposal earlier in this thread [1] (and the one most participants agreed with): "I think it's just a matter of reverting r1845377, right? (And updating CHANGES, etc.)" For completeness, I want to quickly summarize two additional suggestions made by Mark Phippard [2][3]: - If plaintext-pwd-caching support is compiled out (by explicitly giving the compile-time flag for this), also stop reading already cached ones. This would render Daniel's python script useless in these environments. It might satisfy some security sensitive people who would regard the script as a way to "circumvent" the plaintext-disablement. It would make the "plaintext-disabling" more of a complete feature. Additionally, it was suggested that svn could warn or erase such legacy plaintext-cached passwords (instead of just ignoring them), as yet another mitigation improvement. - Apply some obfuscation or encryption with a key hidden in the code (or even supplied by a compile time option) to the plaintext passwords. This helps against non-malicious exposure, and makes it a tad harder for simple scripts to extract the password (which might appease some part of our user base). This might break legitimate scripts that explicitly (mis-)use the cached password for other purposes, though we could regard such uses as hacks that we are allowed to break. IMHO these additional "mitigations" are not absolutely required (I mainly would like to see r1845377 reverted), but if some people feel strongly about them ... sure, why not (though in that case we'd need someone to put in the work too). [1] https://lists.apache.org/thread/shzxh04l493qnj8pdt8vl0x4gkjrkvcy [2] https://lists.apache.org/thread/1tfny40nokqf6p6nll30p06t8or2c8hm [3] https://lists.apache.org/thread/p2vn6foj8qz3lfvdl70bs62vg5krcgr7 -- Johan
