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
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 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:
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 21 Jan 2022, Julian Foad wrote:
Only for commands that need them, but, as mentioned above,
pesimistically for every file that the command *possibly*
pertains to.
I'll follow up on that.
*nod* Will look for that, thanks.
It will not fetch for 'commit' once I commit Evgeny's tiny patch
to
On 21 Jan 2022, Johan Corveleyn wrote:
I like where this is going. Thanks to all involved for pushing it
forward :-).
You're welcome! Thanks for the use-case example, too.
Any chance your company would want to join the consortium that is
funding this work? Please follow up with my privately
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 generally
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 --v
Vincent Lefevre wrote:
> Do you mean that "svn diff" at the root will fetch everything
> even if no files are modified?
No, only the pristines for files that are modified.
On 2022-01-21 11:15:04 +, Julian Foad wrote:
> Premature Hydrating
>
> The present implementation "hydrates" (fetches missing pristines) every
> file within the whole subtree the operation targets. This is done by
> every major client operation calling svn_client__textbase_sync() before
> and
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
>
I have been studying when this implementation fetches pristines. Two
concerns about performance in the current implementation:
1. scanning the whole subtree, calling 'stat' on every file
2. premature hydrating
Scanning with 'stat'
I'm concerned about the implementation scanning the whole subtr
Replying to the last three posts (Nathan, Karl, Johan).
Nathan wrote:
> The pristine for a given file is not fetched until the file is
> modified and an
> operation pertaining to it requires the pristine.
That's basically how the 'pristines-on-demand' branch is working.
However, the present imple
On Fri, Jan 21, 2022 at 5:56 AM Karl Fogel wrote:
>
> 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
15 matches
Mail list logo
