On 21 Jan 2022, Mark Phippard wrote:
In terms of what needs to be done, maybe I am wrong, but I did
not
think we had any mechanism in place where someone could choose
not to
compile in support for this feature. So that is new code that
would
need to be added.
Well:
On Fri, Jan 21, 2022 at 6:39 PM Karl Fogel wrote:
> >2) If we have to add a new compile option, then I suggest we go
> >all
> >the way and also close the backdoor that exists. IOW, if svn is
> >compiled without plaintext support then it also should not be
> >able to
> >read an existing stored pla
On 21 Jan 2022, Mark Phippard wrote:
One aspect of the previous thread that came up is that someone
demonstrated a simple script to create a cached password (as a
workaround for current users). That is what led to the idea of
formalizing this using the svn auth command to create this file.
I am
On Fri, Jan 21, 2022 at 7:22 PM Karl Fogel wrote:
>
> On 21 Jan 2022, Mark Phippard wrote:
> >One aspect of the previous thread that came up is that someone
> >demonstrated a simple script to create a cached password (as a
> >workaround for current users). That is what led to the idea of
> >formal
Mark Phippard wrote on Fri, Jan 21, 2022 at 20:29:21 -0500:
> On Fri, Jan 21, 2022 at 7:22 PM Karl Fogel wrote:
> >
> > On 21 Jan 2022, Mark Phippard wrote:
> > >One aspect of the previous thread that came up is that someone
> > >demonstrated a simple script to create a cached password (as a
> > >
On Mon, Jan 24, 2022 at 10:44 AM Daniel Shahaf wrote:
> > > >I return to my "two camps" argument. The people that do not want
> > > >plaintext passwords to be cached ... do not want them being
> > > >cached.
> > >
> > > I see what you mean.
> > >
> > > If svn is compiled to not cache passwords, b
On Mon, Jan 24, 2022 at 5:02 PM Mark Phippard wrote:
>
> On Mon, Jan 24, 2022 at 10:44 AM Daniel Shahaf
> wrote:
>
> > > > >I return to my "two camps" argument. The people that do not want
> > > > >plaintext passwords to be cached ... do not want them being
> > > > >cached.
> > > >
> > > > I see
Den tis 28 mars 2023 kl 14:41 skrev Johan Corveleyn :
> On Mon, Jan 24, 2022 at 5:02 PM Mark Phippard wrote:
> >
> > On Mon, Jan 24, 2022 at 10:44 AM Daniel Shahaf
> wrote:
> >
> > > > > >I return to my "two camps" argument. The people that do not want
> > > > > >plaintext passwords to be cached
On Tue, Mar 28, 2023 at 10:35 AM Daniel Sahlberg
wrote:
>
> Den tis 28 mars 2023 kl 14:41 skrev Johan Corveleyn :
>>
>> On Mon, Jan 24, 2022 at 5:02 PM Mark Phippard wrote:
>> >
>> > On Mon, Jan 24, 2022 at 10:44 AM Daniel Shahaf
>> > wrote:
>> >
>> > > > > >I return to my "two camps" argument.
Den tis 28 mars 2023 kl 18:56 skrev Nathan Hartman :
> On Tue, Mar 28, 2023 at 10:35 AM Daniel Sahlberg
> wrote:
> > [...] reverting the previous change and changing the default config. I
> don't know (didn't check, no time) what the default config is right now and
> if it can be interpreted as "
Nathan Hartman 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.
> * Set the default run-time config to store-plaintext-passwords = no
On Wed, Mar 29, 2023 at 6:02 PM Evgeny Kotkov
wrote:
>
> Nathan Hartman 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.
On Thu, Mar 30, 2023 at 12:15 AM Nathan Hartman
wrote:
>
> On Wed, Mar 29, 2023 at 6:02 PM Evgeny Kotkov
> wrote:
> >
> > Nathan Hartman writes:
> >
> > > I think a good middle ground is:
> > >
> > > * Build with --enable-plaintext-password-storage by default; users who
> > > want to harden th
On Thu, Mar 30, 2023 at 8:39 AM Johan Corveleyn wrote:
> 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 completenes
The dicussion died again, but this time I intend make sure we complete it
once and for all. I've marked the subject as VOTE to hopefully get some
attention, although I believe votes have already been cast.
In my mind, it seems we have consensus to revert r1845377 (+1 from Nathan
Hartman, Evgeny K
On Sun, Apr 16, 2023 at 11:19 PM Daniel Sahlberg
wrote:
>
> The dicussion died again, but this time I intend make sure we complete it
> once and for all. I've marked the subject as VOTE to hopefully get some
> attention, although I believe votes have already been cast.
Thanks for picking it up
On 21.04.2023 16:43, Johan Corveleyn wrote:
My plan is to revert r1845377 during next weekend. For the first bulletpoint
nothing has to be done, but if consensus changes during the week, I can do the
work to to implement option 1. For the second bullet point I'd like to reach
consensus (on t
On 22.04.2023 10:27, Branko Čibej wrote:
On 21.04.2023 16:43, Johan Corveleyn wrote:
My plan is to revert r1845377 during next weekend. For the first bulletpoint
nothing has to be done, but if consensus changes during the week, I can do the
work to to implement option 1. For the second bulle
On Sat, Apr 22, 2023 at 4:30 AM Branko Čibej wrote:
>
> On 22.04.2023 10:27, Branko Čibej wrote:
>
> On 21.04.2023 16:43, Johan Corveleyn wrote:
>
>
> My plan is to revert r1845377 during next weekend. For the first bulletpoint
> nothing has to be done, but if consensus changes during the week, I
Den lör 22 apr. 2023 kl 10:30 skrev Branko Čibej :
> On 22.04.2023 10:27, Branko Čibej wrote:
>
> On 21.04.2023 16:43, Johan Corveleyn wrote:
>
>
> My plan is to revert r1845377 during next weekend. For the first bulletpoint
> nothing has to be done, but if consensus changes during the week, I ca
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 t
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 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 --v
23 matches
Mail list logo
