Another stupid hackaround could be to setup a local old proxy/man in the
middle https server that still accepts old tls connection, but also
provides newer protocols and switch your working copy to this server
instead.
But a much cleaner solution is to confront IT with the fact that they
need to do something with the server as it is basically broken.
Am 15/06/2020 um 09:43 schrieb Michael Back:
Hello Subversion folks,
When I upgraded to the latest version of my Linux OS (Ubuntu 20.04)
and installed Subversion 1.13.0 client, svn could no longer connect to
our company's old subversion server via https.
$ svn --version
svn, version 1.13.0 (r1867053)
compiled Mar 24 2020, 12:33:36 on x86_64-pc-linux-gnu
Copyright (C) 2019 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository access (RA) modules are available:
* ra_svn : Module for accessing a repository using the svn network
protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol
using serf.
- using serf 1.3.9 (compiled with 1.3.9)
- handles 'http' scheme
- handles 'https' scheme
The following authentication credential caches are available:
* Gnome Keyring
* GPG-Agent
* KWallet (KDE)
$ svn update
Updating '.':
svn: E170013: Unable to connect to a repository at URL
'https://something.something.com/repos/something/trunk'
svn: E120171: Error running context: An error occurred during SSL
communication
Doing a checkout results in the same error.
The server (I am told) is running RHEL 6.10 with OpenSSL 1.0.1.
I understand that the old server is limited to using the old insecure
TLSv1... I'm not IT though with no power to upgrade the server... and
I just want to use our internal system. How do I configure the new
svn to connect to the old server?
Michael
*Qualcomm Confidential and Proprietary material.*
/Please delete if you receive this email and or attachment by
accident. All rights reserved. Qualcomm Technologies Incorporated./
