On Tue, Apr 25, 2023 at 5:00 AM Nathan Hartman <hartman.nat...@gmail.com> wrote: > > On Mon, Apr 24, 2023 at 12:38 PM Daniel Sahlberg > <daniel.l.sahlb...@gmail.com> wrote: > > > > Den mån 24 apr. 2023 kl 18:11 skrev Nathan Hartman > > <hartman.nat...@gmail.com>: > (snip) > >> Sometime in the next few days, I'll draft some text for the 1.15.x > >> release notes about this change (unless you or someone else wants to > >> do it or has already started; in that case, just let me know)... Also > >> the FAQ entry might need an update; I'll look at that at the same > >> time. > > > > > > Great! Thanks for taking the time to do this! > > Here's a first draft, obviously without HTML markup... > > Whatever this ultimately morphs into will go in the 1.15 release notes. > > Normally, I would not recommend to write a dissertation in the release > notes, but I think there is a lot of room for confusion and > misunderstandings, so perhaps it is better to be a little verbose here > and present the brief history of how we got here and why we're making > this change. > > Feedback welcome! > > [[[ > > # Plaintext credential cache is supported by default on Unix-like systems > > Subversion supports several credential caches to prevent re-typing > usernames and passwords repeatedly. Which credential cache(s) are used > depends on the operating system, compile-time options, and the user's > runtime configuration. On Windows and macOS, Subversion uses OS > facilities to save passwords in encrypted form. Unix-like operating > systems do not have a single standard facility to do this; on these > systems, Subversion supports up to four credential caches: GNOME > Keyring, KWallet, GPG Agent, and (as a fallback) the Plaintext cache. > > The rest of this section discusses the Plaintext cache and is > applicable only to Subversion clients running on Unix-like operating > systems. > > In Subversion 1.12 through 1.14, write access to the Plaintext cache > was disabled by default at _compile-time_. Binaries compiled in the > default configuration could not store new plaintext credentials, but > would continue to use any that were already stored. Users and binary > packagers could explicitly enable write access to the Plaintext cache > by compiling Subversion with the --enable-plaintext-password-storage > option to configure. (See r1845377.) > > Unfortunately, this has caused a variety of problems for users, > especially when using the svn client in unattended processes such as > CI systems, or on remote machines through ssh (a GUI password prompt > would display on the remote machine, inaccessible to the ssh user). > Users reported that they had to employ workarounds that caused > passwords to be stored in plaintext anyway, or refused to upgrade > their Subversion installations to these releases. Some binary > packagers built with --enable-plaintext-password-storage while others > didn't, creating inconsistent experiences within the same release > lines. > > Based on the feedback received, Subversion 1.15 inverts the default. > (See r1909351.) Binaries compiled in the default configuration can > once again store new plaintext credentials (after warning and asking > the user). Sites that wish to eliminate this possibility can do one or > both of the following: > > * Compile Subversion with the --disable-plaintext-password-storage > option to configure or install a binary package that was compiled this > way. Be aware that users can circumvent this by compiling or > installing their own Subversion binaries and/or by creating a > plaintext cache manually. > > * Allow encrypted stores like GNOME Keyring and KWallet, but not the > Plaintext cache, by setting store-plaintext-passwords = no in > Subversion's run-time config settings. See the per user files at > ~/.subversion/config and ~/.subversion/servers, and the systemwide > files at /etc/subversion/config and /etc/subversion/servers. > > For more on plaintext credentials, see the FAQ entry: > https://subversion.apache.org/faq.html#plaintext-passwords > > ]]]
Great. Well written, looks good to me. -- Johan