Nils-Johan Andreasson wrote on Fri, May 07, 2021 at 15:41:47 +0200:
> On Thu, May 6, 2021 at 3:24 PM Daniel Shahaf wrote:
>
> > Nils-Johan Andreasson wrote on Thu, May 06, 2021 at 14:48:01 +0200:
> > > I have indeed considered svn+ssh but there are other details involved
> > which
> > > makes me
Clever!
The library does indeed only consider svn:// insecure and it does not
validate the scheme other than that. So, this would work (although it of
course requires some configuration in the places I want to use it, but I
can live with that).
It took me some reading and fiddling though to get th
On Thu, May 06, 2021 at 09:15:44AM -0400, Mark Phippard wrote:
> I am not familiar with the SASL options in the client config
Neither was I, and after some investigation of the code I concluded
that there are none. They're only available in svnserve/libsvn_repos.
Client-side support for these opti
Nils-Johan Andreasson wrote on Thu, May 06, 2021 at 13:03:28 +0200:
> Thanks Stefan for your response and pointers!
>
> There is no doubt my connections are already encrypted.
> The issue is that the external library I'm referring to supports specifying
> paths to source code using multiple protoc
Nils-Johan Andreasson wrote on Thu, May 06, 2021 at 14:48:01 +0200:
> Is there a way (command) to remotely determine if the svn server behind
> 'hostname' has sasl enabled/uses encryption/enforces a min_ssf >= 128?
> Preferably without having to send any authentication credentials (to not
> risk se
Nils-Johan Andreasson wrote on Thu, May 06, 2021 at 14:48:01 +0200:
> I have indeed considered svn+ssh but there are other details involved which
> makes me prefer to stay with svnserve and svn:// if possible.
Does your library consider svn+foo:// secure? If so, you can define an
svn+foo:// schem
On Thu, May 6, 2021 at 8:57 AM Nils-Johan Andreasson
wrote:
>
> Thanks for excellent input!
>
> Unfortunately this external library is being very widely used and is not
> shipped with svn included. Rather it relies on being able to use svn if
> detected as installed on the system, so simply wait
Thanks for excellent input!
Unfortunately this external library is being very widely used and is not
shipped with svn included. Rather it relies on being able to use svn if
detected as installed on the system, so simply waiting for a new release
wouldn't be an option to make a library-wide change.
On Thu, May 06, 2021 at 01:03:28PM +0200, Nils-Johan Andreasson wrote:
> Thanks Stefan for your response and pointers!
>
> There is no doubt my connections are already encrypted.
> The issue is that the external library I'm referring to supports specifying
> paths to source code using multiple pro
Thanks Stefan for your response and pointers!
There is no doubt my connections are already encrypted.
The issue is that the external library I'm referring to supports specifying
paths to source code using multiple protocols, e.g. svn:// (but also
https://, http://, git://, ftp:// etc) and any svn:
On Thu, May 06, 2021 at 11:21:57AM +0200, Nils-Johan Andreasson wrote:
> Hi there!
>
> I'm serving a repository using svnserve with SASL to make sure
> communication is always encrypted (config has use-sasl = true,
> min-encryption = 128 and max-encryption = 256).
> I know this enforces encryption
Hi there!
I'm serving a repository using svnserve with SASL to make sure
communication is always encrypted (config has use-sasl = true,
min-encryption = 128 and max-encryption = 256).
I know this enforces encryption server-side but is there any way to in
addition also "require" encryption client-s
12 matches
Mail list logo
