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

Reply via email to