On 21 Jan 2022, Bernard Boudet wrote:
- There should be a single option in the repository config to
define
whether that repo permits client-side plaintext password
storage (or
perhaps define which are the permitted/denied caching methods).
Hmm. A design principle that I think is
Hi all,
The current situation makes certain work-flows, unworkable. It also
encourages the use of a modified or out-dated client, to "get the job
done", which then itself becomes a security risk more generally.
Reverting to the "old way" and adding a compile-time option is viable,
IMHO, only as
On Fri, Jan 21, 2022 at 7:35 AM Mark Phippard wrote:
> On Thu, Jan 20, 2022 at 11:50 PM Karl Fogel wrote:
> >
> Putting the hat on of someone that wants to turn off plaintext passwords
> ...
>
> 1) I think there should be an easy way to know if the support exists
> or not. I am thinking "svn
On Thu, Jan 20, 2022 at 11:50 PM Karl Fogel wrote:
>
> 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
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
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
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
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
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):
>
>
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
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'
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
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.
On Sun, Oct 3, 2021 at 7:17 PM Johan Corveleyn wrote:
>
> On Sun, Oct 3, 2021 at 12:39 PM Daniel Sahlberg
> wrote:
> >
> > Hi,
> >
> > I would like to reboot this thread once again. I have read through all
> > messages and I have tried to make a summary of the important points. The
> >
On Sun, Oct 3, 2021 at 12:39 PM Daniel Sahlberg
wrote:
>
> Hi,
>
> I would like to reboot this thread once again. I have read through all
messages and I have tried to make a summary of the important points. The
date/time references are as seen in
Thanks for taking the time to summarize the thread as well as the
additional research you added.
On Sun, Oct 3, 2021 at 6:39 AM Daniel Sahlberg
wrote:
> The decision to change the compile time default was made in 2018-10-31 within
> less than 12 hours and without much debate. It was committed
On Sun, Oct 03, 2021 at 12:38:48PM +0200, Daniel Sahlberg wrote:
> * Create an svn auth add command. This option has the advantage that
> one person has expressed interest to invest time to write the code.
> Based on the reasoning above I'm proposing:
> - Adding an svn auth add command
Hi,
I would like to reboot this thread once again. I have read through all
messages and I have tried to make a summary of the important points. The
date/time references are as seen in
https://mail-archives.apache.org/mod_mbox/subversion-dev/.
There are numerous descriptions of problems with the
On Thu, Sep 2, 2021 at 7:29 AM Daniel Sahlberg
wrote:
>
> Den mån 23 aug. 2021 kl 12:15 skrev Johan Corveleyn :
>>
>> Anyway, concerning package maintainers, for Solaris, I'm getting even
>> more depressed ...
>> * We were using Collab.net's distro, but apparently their Solaris
>> build is no
Den mån 23 aug. 2021 kl 12:15 skrev Johan Corveleyn :
> Anyway, concerning package maintainers, for Solaris, I'm getting even
> more depressed ...
> * We were using Collab.net's distro, but apparently their Solaris
> build is no longer maintained:
> https://www.collab.net/downloads/subversion
> *
On 30.08.21 03:38, Barry wrote:
On 26 Aug 2021, at 11:30, Stefan Sperling wrote:
I think this may still be better than the alternative where configuration
files can be tweaked to trick Alice into unknowingly saving her password
in plaintext while running regular SVN operations. Having
> On 26 Aug 2021, at 11:30, Stefan Sperling wrote:
>
> I think this may still be better than the alternative where configuration
> files can be tweaked to trick Alice into unknowingly saving her password
> in plaintext while running regular SVN operations. Having 'svn auth' be
> the only
On Fri, Aug 27, 2021 at 9:26 AM Johan Corveleyn wrote:
>
> On Fri, Aug 27, 2021 at 2:03 PM Daniel Shahaf wrote:
> >
> > Consensus can only result from an open discussion. That's a standard
> > ASF operating principle.
> >
> > The rhetoric in this thread effects chill on anyone who has an
On Fri, Aug 27, 2021 at 2:03 PM Daniel Shahaf wrote:
>
> Consensus can only result from an open discussion. That's a standard
> ASF operating principle.
>
> The rhetoric in this thread effects chill on anyone who has an opinion
> different from the opinion of certain speakers.
I must say I have
Consensus can only result from an open discussion. That's a standard
ASF operating principle.
The rhetoric in this thread effects chill on anyone who has an opinion
different from the opinion of certain speakers.
Therefore, this thread _cannot_ consense at this time.
I think we should
On Fri, Aug 27, 2021 at 11:38:57AM +, Daniel Shahaf wrote:
> The solution to "credentials can't be used to commit with" is not
> *necessarily* "cache a password for a different username". It could
> also be that the authz file has a business logic error («r» rather than
> «rw»), or that the
Johan Corveleyn wrote on Thu, Aug 26, 2021 at 17:26:50 +0200:
> I.e. shouldn't the more general problem statement be "Replace cached
> username+passwords that can't be used to commit with"?
+1
> (hence my first response with "huh, shouldn't a --username make that
> problem moot"? I.e. the user
Den fre 27 aug. 2021 kl 09:15 skrev Johan Corveleyn :
> On Thu, Aug 26, 2021 at 3:44 PM Mark Phippard wrote:
> >
> > On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling wrote:
> >
> > > The answer might be that 'svn authz add' should simply not contact the
> > > server to check credentials. Which
On Thu, Aug 26, 2021 at 3:44 PM Mark Phippard wrote:
>
> On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling wrote:
>
> > The answer might be that 'svn authz add' should simply not contact the
> > server to check credentials. Which means we cannot check upfront whether
> > the user running 'svn auth
On Thu, Aug 26, 2021 at 04:08:34PM -0400, Nathan Hartman wrote:
> On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling wrote:
> > One consequence is that when Alice mistypes the --username option, or
> > mistypes the username or password at the prompt, invalid credentials will
> > be cached. Which
On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling wrote:
> One consequence is that when Alice mistypes the --username option, or
> mistypes the username or password at the prompt, invalid credentials will
> be cached. Which should make any regular SVN operation fail and ask for
> credentials again.
On Thu, Aug 26, 2021 at 4:31 PM Daniel Shahaf wrote:
>
> Johan Corveleyn wrote on Thu, 26 Aug 2021 12:41 +00:00:
> > On Wed, Aug 25, 2021 at 8:52 PM Daniel Shahaf
> > wrote:
> > > This thread is on dev@ as opposed to users@, so I'm trying to solve the
> > > problem generically, rather than just
Johan Corveleyn wrote on Thu, 26 Aug 2021 12:41 +00:00:
> On Wed, Aug 25, 2021 at 8:52 PM Daniel Shahaf wrote:
> > This thread is on dev@ as opposed to users@, so I'm trying to solve the
> > problem generically, rather than just your specific $WORK scenario.
>
> I get the feeling I'm missing
Branko Čibej wrote on Thu, 26 Aug 2021 12:49 +00:00:
> On 26.08.2021 14:10, Daniel Shahaf wrote:
> > Branko Čibej wrote on Thu, 26 Aug 2021 08:11 +00:00:
> >> On 25.08.2021 21:01, Mark Phippard wrote:
> >>> Solving with svn auth is a nice idea but I do not see it working
> >>> unless we have a way
On Thu, Aug 26, 2021 at 04:17:16PM +0200, Daniel Sahlberg wrote:
> Den tors 26 aug. 2021 kl 16:10 skrev Stefan Sperling :
>
> > On Thu, Aug 26, 2021 at 02:41:44PM +0200, Johan Corveleyn wrote:
> > > I get the feeling I'm missing something, but I still don't understand
> > > what authz has to do
Den tors 26 aug. 2021 kl 16:10 skrev Stefan Sperling :
> On Thu, Aug 26, 2021 at 02:41:44PM +0200, Johan Corveleyn wrote:
> > I get the feeling I'm missing something, but I still don't understand
> > what authz has to do with the problem at hand here (i.e. detecting
> > expired passwords so we
On Thu, Aug 26, 2021 at 12:15:39PM +, Daniel Shahaf wrote:
> Stefan Sperling wrote on Thu, 26 Aug 2021 10:30 +00:00:
> > And while we are considering read-only vs. read-write access:
> > Plaintext passwords or not, in my contrived scenario Eve could always
> > trick Alice into using a
On Thu, Aug 26, 2021 at 02:41:44PM +0200, Johan Corveleyn wrote:
> I get the feeling I'm missing something, but I still don't understand
> what authz has to do with the problem at hand here (i.e. detecting
> expired passwords so we can ask the user for the new one).
The problem is that some
On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling wrote:
> The answer might be that 'svn authz add' should simply not contact the
> server to check credentials. Which means we cannot check upfront whether
> the user running 'svn auth add' knows valid credentials.
Yeah that seems reasonable.
On 26.08.2021 14:10, Daniel Shahaf wrote:
Branko Čibej wrote on Thu, 26 Aug 2021 08:11 +00:00:
On 25.08.2021 21:01, Mark Phippard wrote:
Solving with svn auth is a nice idea but I do not see it working
unless we have a way to authenticate for write access without writing
something.
There
On Wed, Aug 25, 2021 at 8:52 PM Daniel Shahaf wrote:
> Johan Corveleyn wrote on Wed, 25 Aug 2021 07:16 +00:00:
> > On Tue, Aug 24, 2021 at 7:03 PM Daniel Shahaf
> > wrote:
> > > Johan Corveleyn wrote on Tue, 24 Aug 2021 15:22 +00:00:
> > > > On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf
> > >
Stefan Sperling wrote on Thu, 26 Aug 2021 10:30 +00:00:
> And while we are considering read-only vs. read-write access:
> Plaintext passwords or not, in my contrived scenario Eve could always
> trick Alice into using a different user account by caching a set of
> valid credentials which Eve knows.
Branko Čibej wrote on Thu, 26 Aug 2021 08:11 +00:00:
> On 25.08.2021 21:01, Mark Phippard wrote:
> > Solving with svn auth is a nice idea but I do not see it working
> > unless we have a way to authenticate for write access without writing
> > something.
>
> There isn't in general, since authz
On Thu, Aug 26, 2021 at 10:11:44AM +0200, Branko Čibej wrote:
> On 25.08.2021 21:01, Mark Phippard wrote:
> > On Wed, Aug 25, 2021 at 3:16 AM Johan Corveleyn wrote:
> >
> > > > Is there a way to test whether one has rw access without actually doing
> > > > a commit or a revprop edit? It's
On 25.08.2021 21:01, Mark Phippard wrote:
On Wed, Aug 25, 2021 at 3:16 AM Johan Corveleyn wrote:
Is there a way to test whether one has rw access without actually doing
a commit or a revprop edit? It's possible with hooks, of course, but is
it also possible without hooks?
I'm not sure I
On Wed, Aug 25, 2021 at 3:16 AM Johan Corveleyn wrote:
> > Is there a way to test whether one has rw access without actually doing
> > a commit or a revprop edit? It's possible with hooks, of course, but is
> > it also possible without hooks?
>
> I'm not sure I understand: why would I need to
Johan Corveleyn wrote on Wed, 25 Aug 2021 07:16 +00:00:
> On Tue, Aug 24, 2021 at 7:03 PM Daniel Shahaf wrote:
> > Johan Corveleyn wrote on Tue, 24 Aug 2021 15:22 +00:00:
> > > On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf
> > > wrote:
> > > > Johan Corveleyn wrote on Tue, 24 Aug 2021 14:25
On Tue, Aug 24, 2021 at 7:03 PM Daniel Shahaf wrote:
> Johan Corveleyn wrote on Tue, 24 Aug 2021 15:22 +00:00:
> > On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf
> > wrote:
> > > Johan Corveleyn wrote on Tue, 24 Aug 2021 14:25 +00:00:
> > > > OTOH, if this kind of behaviour is too far-fetched
Johan Corveleyn wrote on Tue, 24 Aug 2021 15:22 +00:00:
> On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf wrote:
> > Johan Corveleyn wrote on Tue, 24 Aug 2021 14:25 +00:00:
> > > OTOH, if this kind of behaviour is too far-fetched for a single
> > > subcommand, I might be able to do it by invoking
On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf wrote:
>
> Johan Corveleyn wrote on Tue, 24 Aug 2021 14:25 +00:00:
> > OTOH, if this kind of behaviour is too far-fetched for a single
> > subcommand, I might be able to do it by invoking two commands, if I
> > could succesfully (and invisibly) detect
Johan Corveleyn wrote on Tue, 24 Aug 2021 14:25 +00:00:
> OTOH, if this kind of behaviour is too far-fetched for a single
> subcommand, I might be able to do it by invoking two commands, if I
> could succesfully (and invisibly) detect that a cached password is no
> longer correct. As in:
>
>
On Tue, Aug 24, 2021 at 1:24 PM Stefan Sperling wrote:
>
> On Tue, Aug 24, 2021 at 12:16:48PM +0200, Johan Corveleyn wrote:
> > But: obviously I have disabled, in the runtime config area, the
> > warning prompt that "Your password will be stored in plaintext" (I
> > have disabled it system-wide,
On Tue, Aug 24, 2021 at 02:37:57AM -0700, Robby Zinchak wrote:
> Oh, hello all :)
>
> Yeah, between this cli obstacle, problems with rapidsvn corrupting local
> repo during file moves, and svn Apache frequently corrupting server repo
> unrecoverably in large check-ins (>200mb) and requiring a
On Tue, Aug 24, 2021 at 12:16:48PM +0200, Johan Corveleyn wrote:
> But: obviously I have disabled, in the runtime config area, the
> warning prompt that "Your password will be stored in plaintext" (I
> have disabled it system-wide, in /etc/subversion). Yes, we know this
> and we accept it. I would
Oh, hello all :)
Yeah, between this cli obstacle, problems with rapidsvn corrupting local
repo during file moves, and svn Apache frequently corrupting server repo
unrecoverably in large check-ins (>200mb) and requiring a nuke and reload
from backup... it's been pretty rough year for my use cases
[ sorry Robby, I left you out of a previous reply -- looping you back
in in case you're interested in this tangent ... ]
On Tue, Aug 24, 2021 at 10:34 AM Stefan Sperling wrote:
>
> On Mon, Aug 23, 2021 at 02:45:44PM +0200, Johan Corveleyn wrote:
> > Thanks, those are good efforts (and thanks to
On Mon, Aug 23, 2021 at 02:45:44PM +0200, Johan Corveleyn wrote:
> Thanks, those are good efforts (and thanks to both Daniels for writing
> them), but I'm afraid those workarounds are not good enough. The thing
> is: this is not for me alone. This needs to be handled in buildscripts
> that can be
On Mon, Aug 23, 2021 at 09:05:33PM +0200, Daniel Sahlberg wrote:
> Has there been any complaints about Subversion's ability to store passwords
> in plaintext?
Of course :) Years ago, before any encrypted storage was available
on Unix systems, this was a common complaint.
The FAQ entry which you
Den mån 23 aug. 2021 kl 12:15 skrev Johan Corveleyn :
> Anyway, concerning package maintainers, for Solaris, I'm getting even
> more depressed ...
> * We were using Collab.net's distro, but apparently their Solaris
> build is no longer maintained:
> https://www.collab.net/downloads/subversion
> *
Den mån 23 aug. 2021 kl 13:50 skrev Nathan Hartman :
> On Mon, Aug 23, 2021 at 6:15 AM Johan Corveleyn wrote:
>
>> I know the decision to disable plaintext pwd storage by default was
>> briefly discussed on this very list [1], but sadly I didn't pay
>> attention back then. I have a lot of
Johan Corveleyn wrote on Mon, 23 Aug 2021 10:15 +00:00:
> So I guess my best shot is contacting the maintainer of the openCSW
> package, and asking him to add the --enable-plaintext-password-storage
> configure flag and make a new build then.
>
> Building it ourselves is not an option.
Write a
On Mon, Aug 23, 2021 at 1:50 PM Nathan Hartman wrote:
>
> On Mon, Aug 23, 2021 at 6:15 AM Johan Corveleyn wrote:
>>
>> On Fri, Aug 7, 2020 at 7:01 AM Robby Zinchak wrote:
>> >
>> > Small rant here from a very long time subversion user, regarding
>> > subversion project's decision to compile
On Mon, Aug 23, 2021 at 6:15 AM Johan Corveleyn wrote:
> On Fri, Aug 7, 2020 at 7:01 AM Robby Zinchak
> wrote:
> >
> > Small rant here from a very long time subversion user, regarding
> subversion project's decision to compile out plaintext password storage by
> default
On Fri, Aug 7, 2020 at 7:01 AM Robby Zinchak wrote:
>
> Small rant here from a very long time subversion user, regarding subversion
> project's decision to compile out plaintext password storage by default
> (https://marc.info/?l=subversion-commits=154101482302608=2).
>
> There are a tremendous
Daniel Sahlberg wrote on Sat, 15 Aug 2020 11:28 +0200:
> Den fre 14 aug. 2020 23:44Daniel Shahaf skrev:
>
> > Daniel Sahlberg wrote on Fri, 14 Aug 2020 23:01 +0200:
> > > Den fre 7 aug. 2020 kl 11:34 skrev Daniel Shahaf > >:
> > >
> > > > It successfully adds a password to the storage, in
Den fre 14 aug. 2020 23:44Daniel Shahaf skrev:
> Daniel Sahlberg wrote on Fri, 14 Aug 2020 23:01 +0200:
> > Den fre 7 aug. 2020 kl 11:34 skrev Daniel Shahaf >:
> >
> > > It successfully adds a password to the storage, in the sense that
> > > after running it, a subsequent `svn auth
Daniel Sahlberg wrote on Fri, 14 Aug 2020 23:01 +0200:
> Den fre 7 aug. 2020 kl 11:34 skrev Daniel Shahaf :
>
> > It successfully adds a password to the storage, in the sense that
> > after running it, a subsequent `svn auth --show-passwords` shows the
> > password. Still, a subsequent `svn
Den fre 7 aug. 2020 kl 11:34 skrev Daniel Shahaf :
> It successfully adds a password to the storage, in the sense that
> after running it, a subsequent `svn auth --show-passwords` shows the
> password. Still, a subsequent `svn info` doesn't use the password.
> Why? By source inspection,
Dr. Thomas Orgis wrote on Fri, 07 Aug 2020 09:41 +0200:
> Am Fri, 7 Aug 2020 05:53:24 +
> schrieb Daniel Shahaf :
>
> > > > should work: the compile-time knob prevents passwords from being
> > > > _written_, but doesn't prevent passwords already there from being
> > > > read.
>
> Then
Am Fri, 7 Aug 2020 05:53:24 +
schrieb Daniel Shahaf :
> > > should work: the compile-time knob prevents passwords from being
> > > _written_, but doesn't prevent passwords already there from being
> > > read.
Then it might be a nice idea to allow users to intentionally trigger
that write
Robby Zinchak wrote on Thu, 06 Aug 2020 18:56 -0700:
> I would love to hear what the expected workaround is for users running
> automated subversion clients on server VMs [...].
>
As I wrote on SVN-4861 recently:
> > Also, if I'm reading the code correctly, simply adding the password
> > to the
71 matches
Mail list logo
