Re: A two-part vision for Subversion and large binary objects.
On 20 Jan 2022, Julian Foad wrote: The more I think about this, the more I think we are prematurely complicating the requirements in this respect. I'm going to back-track and posit that a simple per-WC switch should suffice for the vast majority of cases, and has the benefit of simplicity. (The user might wish to set this based on the repository location -- local/fast versus remote/slow.) Personally I'd be very happy to start with this. We can always improve the client-side UI for the feature more in the future. I will note that I previously misunderstood the current 'pristines-on-demand' implementation as fetching the pristine before a diff (for example) and discarding it afterwards. In fact it keeps the pristine as long as the file in question remains in a locally modified state, and only discards the pristine when (before or after some client operation) the file is no longer in a modified state. That is to say, it fetches pristines less often than I had thought. And it only fetches pristine for commands that absolutely need pristine, I assume? (I think you said earlier that it does not fetch for 'commit'.) I like the trick of keeping the pristine, once fetched, for as long as the file is locally modified. The only case in which a simple per-WC setting might be unsatisfactory is the following combination: - the repository is "slow" (and/or offline working is required); - and, in a single WC: - the WC data set is "huge" (relative to local disk space) in total; and - there is a subset of files on which the user needs to work (requiring diffs, etc.) often enough that fetching their pristines "on demand" is a problem; and - that subset of files is not "huge" in total; and - that subset of files can be distinguished from the rest by metadata. That is certainly a possible case, but we have no suggestion that it is at all common. It is not one of the cases driving this feature. So I think it is not something to design for at this stage. Well, that case is almost exactly our use case at my company :-), except that I think fetching pristines on demand will be fine. Thus, we can live with a per-WC setting. I'm going to work on getting something more basic (per-WC yes/no) closer to production-ready and then we can re-assess it. Sounds good! Best regards, -Karl
[PROPOSAL] Allow plaintext passwords again. (was: Re: A strong WTF on compiling out plaintext password support by default?!)
On 20 Jan 2022, Mark Phippard wrote: I have made the suggestion before and I want to say there was agreement from anyone that responded. So if nothing else anyone that objects to this is not speaking up. I think the main issue is that no one has wanted to step forward and make the change. I think we all know there are people who legitimately want the additional security. They are either not reading any of this or have decided they can accept having a compile time option and just want to wait and see what happens. Most likely it is the former. Making the change can at least make them come forward again. I've changed the Subject line to reflect that I'm concretely proposing now that we do this. I'll volunteer to do it, though am happy for anyone else to as well. I think it's just a matter of reverting r1845377, right? (And updating CHANGES, etc.) If someone knows a reason why it's more complex than what I've described above, please speak up. Best regards, -Karl
Re: A two-part vision for Subversion and large binary objects.
On Thu, Jan 20, 2022 at 4:03 PM Julian Foad wrote: > > Karl Fogel wrote: > >>> So if we have client-side configuration that can specify "no > >>> pristine" based on some combination of one or more of... > > [... size, properties, etc. ...] > > with a general mechanism for combining conditions, then things > > will be in a good position for future improvement. > > The more I think about this, the more I think we are prematurely > complicating the requirements in this respect. I'm going to back-track > and posit that a simple per-WC switch should suffice for the vast > majority of cases, and has the benefit of simplicity. (The user might > wish to set this based on the repository location -- local/fast versus > remote/slow.) > > I will note that I previously misunderstood the current > 'pristines-on-demand' implementation as fetching the pristine before a > diff (for example) and discarding it afterwards. In fact it keeps the > pristine as long as the file in question remains in a locally modified > state, and only discards the pristine when (before or after some client > operation) the file is no longer in a modified state. That is to say, it > fetches pristines less often than I had thought. Thanks for explaining this. If I understand correctly, when pristines are turned off: The pristine for a given file is not fetched until the file is modified and an operation pertaining to it requires the pristine. Once fetched, the pristine remains present until the file becomes unmodified through either 'commit' or 'revert'. +1 to this. This seems more logical than immediate removal: if the file becomes modified and its pristine is fetched, then the user may (is likely to?) run additional operations requiring the pristine. No sense in re-fetching it several times in rapid succession. If users complain, 'svn cleanup --vacuum-pristines' could be made to just delete all pristines when the pristines-on-demand feature is active. While writing the above, it occurred to me that if the file is deleted, the pristine (if present) should be deleted as well. (Potential caveat: if the file is modified, subsequently marked for deletion with '--keep-local', and subsequently the user runs 'svn revert', the expected result is to restore the original contents as they appear in BASE.) More below... > The only case in which a simple per-WC setting might be unsatisfactory > is the following combination: > > - the repository is "slow" (and/or offline working is required); > > - and, in a single WC: > - the WC data set is "huge" (relative to local disk space) in total; and > - there is a subset of files on which the user needs to work > (requiring diffs, etc.) often enough that fetching their pristines "on > demand" is a problem; and > - that subset of files is not "huge" in total; and > - that subset of files can be distinguished from the rest by metadata. > > That is certainly a possible case, but we have no suggestion that it is > at all common. It is not one of the cases driving this feature. So I > think it is not something to design for at this stage. > > I'm going to work on getting something more basic (per-WC yes/no) closer > to production-ready and then we can re-assess it. +1 to this also. A production-ready per-wc on/off switch for pristines sounds reasonable to me for the initial feature and is arguably better than not-production-ready and full of bells and whistles. Cheers, Nathan
Re: A strong WTF on compiling out plaintext password support by default?!
On Thu, Jan 20, 2022 at 4:06 PM Karl Fogel wrote: > So: shall we just go back to the old way, but with a compile-time option > to remove support for it? I have made the suggestion before and I want to say there was agreement from anyone that responded. So if nothing else anyone that objects to this is not speaking up. I think the main issue is that no one has wanted to step forward and make the change. I think we all know there are people who legitimately want the additional security. They are either not reading any of this or have decided they can accept having a compile time option and just want to wait and see what happens. Most likely it is the former. Making the change can at least make them come forward again. Mark
Re: A strong WTF on compiling out plaintext password support by default?!
On 20 Jan 2022, Mark Phippard wrote: ... my main idea has always been that we put things back the way they were. I would be completely in favor of that. The old status quo was fine: it presented warnings to users at the appropriate moments, and otherwise let them decide their own threat model, which they know best. For those who consider *any* support of plain text passwords to be a major security problem, you are right: they will not like any of these solutions, and that's not going to change. I think the way we already managed the warnings was the right way to handle this for camp 2. It was just enough warning to make a user aware without making it too difficult to use. What we then need to do is also add some new compile time option to disable plain text passwords. This would give the people in camp 1 an option. +1 to that plan. This problem only exists on *nix and the people in camp 1 are capable of solving this problem if we give them the tools to do so. Whereas the people in camp 2 are less able to solve it themselves. So I think our defaults should cater more to camp 2 and we should provide options that can be leveraged by camp 1 if they must go that route. Agreed. So: shall we just go back to the old way, but with a compile-time option to remove support for it? Best regards, -Karl
Re: A two-part vision for Subversion and large binary objects.
Karl Fogel wrote: >>> So if we have client-side configuration that can specify "no >>> pristine" based on some combination of one or more of... > [... size, properties, etc. ...] > with a general mechanism for combining conditions, then things > will be in a good position for future improvement. The more I think about this, the more I think we are prematurely complicating the requirements in this respect. I'm going to back-track and posit that a simple per-WC switch should suffice for the vast majority of cases, and has the benefit of simplicity. (The user might wish to set this based on the repository location -- local/fast versus remote/slow.) I will note that I previously misunderstood the current 'pristines-on-demand' implementation as fetching the pristine before a diff (for example) and discarding it afterwards. In fact it keeps the pristine as long as the file in question remains in a locally modified state, and only discards the pristine when (before or after some client operation) the file is no longer in a modified state. That is to say, it fetches pristines less often than I had thought. The only case in which a simple per-WC setting might be unsatisfactory is the following combination: - the repository is "slow" (and/or offline working is required); - and, in a single WC: - the WC data set is "huge" (relative to local disk space) in total; and - there is a subset of files on which the user needs to work (requiring diffs, etc.) often enough that fetching their pristines "on demand" is a problem; and - that subset of files is not "huge" in total; and - that subset of files can be distinguished from the rest by metadata. That is certainly a possible case, but we have no suggestion that it is at all common. It is not one of the cases driving this feature. So I think it is not something to design for at this stage. I'm going to work on getting something more basic (per-WC yes/no) closer to production-ready and then we can re-assess it.
Re: RFC: Create new obfuscated password storage module
On Thu, Jan 20, 2022 at 1:01 PM Daniel Sahlberg wrote: > > Den tors 20 jan. 2022 kl 14:57 skrev Mark Phippard : >> >> I was in the process of replying to Karl's email and why I do not >> think his approach is the way to go when I had the following idea. >> >> What if we add a new password storage module in the spirit of the >> gnome-keyring, gpg modules that stores the password in some kind of >> obfuscated format in the auth folder? >> >> This module could be built by default on *nix but also support a >> configure option to disable building it. Also if the library itself is >> just not present at runtime then it would also not be available. >> >> It would become a new password-stores option in the config file so we >> already have a mechanism for enabling or disabling it via that file as >> well. >> >> For purposes of all of the other warnings we still support this would >> NOT be considered a plain text password. >> >> How we obfuscate would be up to whoever writes the code. I think >> Base64 would be fine but we could also use something like AES where we >> use the realm-string or some other value we know as the key. This >> would not be truly secure but it does help protect against trivial >> observation and discovery. >> >> This would make password storage available by default on Linux, but >> still give Disto maintainers and anyone else maintaining a system >> options to completely disable it if that is their desire. >> >> I will also still reply to Karl's email >> >> Thanks >> >> Mark > > > Is this something that can be added to / merged with issue 4145[1]: Master > passphrase and encrypted credentials cache /shrug I really do not know. That issue is another idea for solving the same fundamental problem I suppose but other than that it is a different idea and approach. I think the reason that idea did not work out is that it would require some kind of daemon like ssh-agent to hold your passphrase in memory, otherwise our CLI would just have to constantly prompt you for your passphrase so it could decrypt the data. This approach would be secure but it does not solve the usability problems we have. Mark
Re: RFC: Create new obfuscated password storage module
Den tors 20 jan. 2022 kl 14:57 skrev Mark Phippard : > I was in the process of replying to Karl's email and why I do not > think his approach is the way to go when I had the following idea. > > What if we add a new password storage module in the spirit of the > gnome-keyring, gpg modules that stores the password in some kind of > obfuscated format in the auth folder? > > This module could be built by default on *nix but also support a > configure option to disable building it. Also if the library itself is > just not present at runtime then it would also not be available. > > It would become a new password-stores option in the config file so we > already have a mechanism for enabling or disabling it via that file as > well. > > For purposes of all of the other warnings we still support this would > NOT be considered a plain text password. > > How we obfuscate would be up to whoever writes the code. I think > Base64 would be fine but we could also use something like AES where we > use the realm-string or some other value we know as the key. This > would not be truly secure but it does help protect against trivial > observation and discovery. > > This would make password storage available by default on Linux, but > still give Disto maintainers and anyone else maintaining a system > options to completely disable it if that is their desire. > > I will also still reply to Karl's email > > Thanks > > Mark > Is this something that can be added to / merged with issue 4145[1]: Master passphrase and encrypted credentials cache /Daniel Sahlberg [1] https://issues.apache.org/jira/browse/SVN-4145
Re: A strong WTF on compiling out plaintext password support by default?!
On 20 Jan 2022, Stefan Sperling wrote: You may have missed that we have added the 'svn auth' command while you were not looking :) I totally did miss that :-). Removing cached creds can already be done with 'svn auth --remove'. Hah! Now that you mention it, I even remember learning about that (a while ago) and actually using it. What I don't remember is forgetting about it afterwards... Having both 'svn authn' and 'svn auth' commands would be confusing. The names are too close and the proposed functionalty overlaps. So I would prefer if the existing 'svn auth' command was extended. 100% agree. I like your proposal. Great! Best regards, -Karl
Re: A strong WTF on compiling out plaintext password support by default?!
On Wed, Jan 19, 2022 at 9:08 PM Karl Fogel wrote:
>
> This thread has been dormant for a while, but the question hasn't
> gone away. It would be great if we could reach a consensus. Here
> is a combined proposal (based on proposals quoted below from
> Daniel Sahlberg and Stefan Sperling):
>
> 1) Re-enable plaintext passwords in compile time defaults.
>
> 2) Disable plaintext passwords in default runtime configuration.
>Users can re-enable it in their configuration when they want
>it.
>
> 3) When running a regular Subversion command like 'update' or
> 'commit',
>if authentication is required and there is a "safe"
>password-storage mechanism available (such as kwallet or
>gpg-agent or whatever), then that safe mechanism would be used
>automatically, as it is today.
>
>But if no safe mechanism is available, *then* the user would be
>told to run 'svn authn' (see below).
>
> 4) There is a new 'svn authn' command to authenticate to any
>repository. E.g., 'svn authn [ --username jrandom ]
>REPOS_URL'.
>See detailed description of it below.
>
> The new 'svn authn' command is a generic entry point to
> authentication-related functionality.
>
> If you run 'svn authn' and a "safe" password-storage mechanism is
> available, then it'll just store the password using that mechanism
> -- the same way 'update' or 'commit' would have done.
>
> But when no safe mechanism is available, then 'svn authn' will
> print the big warning message that svn traditionally printed when
> about to store a plaintext password, and then, if the user
> indicates "yes", caches the password in plaintext in the same way
> we did before.
>
> Notice that, in practice, users will only be steered to 'svn
> authn' when there is no safe mechanism available, becuase
> otherwise whatever regular svn command they were running would
> have simply used the safe mechanism.
>
> Thus, users will not become habituated to using the 'authn'
> command. It'll be a rare event, and the user will be aware of
> what she's doing and be likely to read and understand the warning
> about plaintext password storage, instead of skimming or ignoring
> that warning because she's right in the middle of a common
> end-goal operation like 'update' or 'commit' and just wants to
> complete it as fast as possible.
>
> ('svn authn' could also support a '--remove' flag to clear out the
> authn cache for a given repository. It could also support
> wildcards / offer a way to clear auth for all repositories / offer
> a --remove-plaintext-passwords option to clear all plaintexts,
> etc. The point is, with this new subcommand, we would now have a
> UI entry point to a number of cleanup / change-one's-mind
> features.)
>
> I suggest the command name 'authn' rather than 'auth' in order to
> keep "authentication" (authn) distinct from "authorization"
> (authz). Although though we don't have an "authz" subcommand,
> Subversion does have server-side authz features, so keeping this
> distinction clear seems worthwhile. However, I don't feel
> strongly about it -- if everyone prefers "auth", I'm not going to
> argue too hard :-).
>
> Thoughts?
Before I say why I do not think this is the right approach, I want to
emphasize that I do think something needs to be done. So if this is
the proposal everyone agrees with then consider me a +1 as well.
That said ... I do not think this is the way to go.
Practically speaking, there are two camps here.
1. Those who consider any support of plain text passwords a major
security vulnerability. Potentially a deal breaker to their usage of
Subversion.
2. Everyone else (realizing that this camp is split across a wide
spectrum of levels of concern)
The current versions of SVN have swung the pendulum completely in
favor of the first camp. The problem I have with Karl's proposal is
that I do not think it really satisfies either camp.
The fact that the user can jump through a bunch of hoops and store a
password in plain text is still a deal breaker to camp 1.
The fact that the user has to jump through a bunch of hoops is not
very helpful to a lot of the users in camp 2.
In composing this reply I had an idea how we might satisfy both camps
and I have sent it to dev@ as a new thread. That said, aside from that
idea my main idea has always been that we put things back the way they
were. I think the way we already managed the warnings was the right
way to handle this for camp 2. It was just enough warning to make a
user aware without making it too difficult to use. What we then need
to do is also add some new compile time option to disable plain text
passwords. This would give the people in camp 1 an option.
This problem only exists on *nix and the people in camp 1 are capable
of solving this problem if we give them the tools to do so. Whereas
the people in camp 2 are less able to solve it themselves. So I think
our defaults should cater more to camp 2 and we should provide options
that can be leveraged by camp
RFC: Create new obfuscated password storage module
I was in the process of replying to Karl's email and why I do not think his approach is the way to go when I had the following idea. What if we add a new password storage module in the spirit of the gnome-keyring, gpg modules that stores the password in some kind of obfuscated format in the auth folder? This module could be built by default on *nix but also support a configure option to disable building it. Also if the library itself is just not present at runtime then it would also not be available. It would become a new password-stores option in the config file so we already have a mechanism for enabling or disabling it via that file as well. For purposes of all of the other warnings we still support this would NOT be considered a plain text password. How we obfuscate would be up to whoever writes the code. I think Base64 would be fine but we could also use something like AES where we use the realm-string or some other value we know as the key. This would not be truly secure but it does help protect against trivial observation and discovery. This would make password storage available by default on Linux, but still give Disto maintainers and anyone else maintaining a system options to completely disable it if that is their desire. I will also still reply to Karl's email Thanks Mark
Re: A strong WTF on compiling out plaintext password support by default?!
On Wed, Jan 19, 2022 at 08:08:06PM -0600, Karl Fogel wrote:
> ('svn authn' could also support a '--remove' flag to clear out the authn
> cache for a given repository.)
You may have missed that we have added the 'svn auth' command while
you were not looking :)
Removing cached creds can already be done with 'svn auth --remove'.
> I suggest the command name 'authn' rather than 'auth' in order to keep
> "authentication" (authn) distinct from "authorization" (authz).
Having both 'svn authn' and 'svn auth' commands would be confusing.
The names are too close and the proposed functionalty overlaps.
So I would prefer if the existing 'svn auth' command was extended.
I like your proposal.
Cheers,
Stefan
Re: A strong WTF on compiling out plaintext password support by default?!
On 20 Jan 2022, Dr. Thomas Orgis wrote: Am Wed, 19 Jan 2022 20:08:06 -0600 schrieb Karl Fogel : 2) Disable plaintext passwords in default runtime configuration. Users can re-enable it in their configuration when they want it. But when no safe mechanism is available, then 'svn authn' will print the big warning message The latter would happen with the default config, right? And the config setting would just disable the warning? I think it would be useless/overbearing nagging otherwise. No, actually I was thinking one would have to *also* enable plaintext-passwords in the config. If it's not enabled in run-time config, then 'svn authn' would first let the user know that she would have to enable it in run-time config. Once she has done so, 'svn authn' would then actually be able to store plaintext passwords. The regular svn command that led to 'svn authn' could also make the same point -- when recommending 'svn authn', it could also point out that run-time config would need to change before plaintext passwords are possible. (Open to discussion on all the above; I'm just clarifying what I meant in my original post.) But back on topic: Yes, please make use of simple password storage usable for everyone again. The use cases are real. Glad you agree! Best regards, -Karl
