E120171: Error running context: An error occurred during SSL communication

[martinl]

Dear SAC,

since today I am unable to update GRASS SVN repo:

Updating '.':
svn: E170013: Unable to connect to a repository at URL 'https://svn.osgeo.org/grass/grass/trunk'
svn: E120171: Error running context: An error occurred during SSL communication

Could be related to recent changes in Debian regarding OpenSSL (1). Is there anything related to OSGeo server or just my issue? Thanks for clarification. Martin

(1) ​https://lists.debian.org/debian-devel-announce/2017/08/msg00004.html

[neteler]

Your assumption could be right:

​https://www.ssllabs.com/ssltest/analyze.html?d=svn.osgeo.org&latest

--> " The server supports only older protocols, but not the current best TLS 1.2. Grade capped to C.

[...]

• TLS 1.3 No
• TLS 1.2 No
• TLS 1.1 No
• TLS 1.0 Yes"

An upgrade of the server configuration would be a good idea.

[martinl]

Replying to neteler:

An upgrade of the server configuration would be a good idea.

So I am taking liberty to increase priority. For now I will try to downgrade openssl package on my PC.

[strk]

It looks like it'd take manually compiling libssl and mod_ssl. Or upgrade to a still supported Debian version (even backports repository has been obsoleted)

[strk]

Or switch to ​https://mod.gnutls.org/ ...

[strk]

It looks like The version of gnutls on that server already supports TLS1.2

$ gnutls-cli -l | grep TLS1.2 Protocols: SSL3.0, TLS1.0, TLS1.1, TLS1.2

And the apache module is available, so could be a viable path to switch to that. Only it might taking tweaking some apache configurations (/etc/apache is under a local git repository though, which should help)

[strk]

For the record: Ubuntu 17.04 does not ship mod_ssl anymore, but it does ship mod_gnutls.

[mlennert]

Just a ping, confirming the same issue for me. And yes, this happens after the Debian OpenSSL upgrade.

[jef]

quick workaround on an affected client:

apt-get build-dep openssl
apt-get source openssl
cd openssl-1.1.0f
sed -i -e "s/disable-tls1 disable-tls1_1/# &/" debian/rules
DEB_BUILD_OPTIONS="nocheck parallel" dpkg-buildpackage -us -uc -b
sudo dpkg -i ../libssl1.1_1.1.0f-4_amd64.deb

[strk]

For those like me who receive comments by mail: the suggested workaround is for clients, not server (post-submit edit of trac comments are not notified by mail, the info was added later)

[mlennert]

Thanks for the workaround. Are there any plans of upgrading the server so it supports 1.2+ ?

[martinl]

Any chance to get svn server fixed to support 1.2+?

[strk]

I don't have time to work on it, but if anyone else does I suggest to look at GNU-lts module (is avalable as packaged for the version of OS on that system).

[rduivenvoorde]

During OSGeo-NL GRASS-intro, we were hit with this one too :-(

[goatbar]

Sigh. Hit the same on a debian testing based distro. :(

svn --version
svn, version 1.9.7 (r1800392)
   compiled Aug 17 2017, 02:50:12 on x86_64-pc-linux-gnu

svn co https://svn.osgeo.org/gdal/trunk/gdal
svn: E170013: Unable to connect to a repository at URL 'https://svn.osgeo.org/gdal/trunk/gdal'
svn: E120171: Error running context: An error occurred during SSL communication

apt-cache show subversion
Depends: libsvn1 (= 1.9.7-2), libapr1 (>= 1.5.0), libaprutil1 (>= 1.3.2+dfsg), libc6 (>= 2.4), libldap-2.4-2 (>= 2.4.7), libsasl2-2

apt-cache show openssl | egrep 'Version'
Version: 1.1.0f-4

[robe]

I have run into similar issues when using Caddy (for proxying). This just highlights the fact we are desperately in need of upgrading the trac server. The OS is just too old. It's running Debian 6 which at this point is ancient.

[martin]

In order to resolve this issue I'm planning to upgrade the TracSVN VM this Friday (2018-02-16) to a more recent version of Debian Linux. Outages will occur at some point in the process, reboot will be synced with OSL staff.

Currently the following VM's still run an outdated distro, some of which I'd prepare to upgrade as well:

secure / projects / web / download / tracsvn / wiki

[strk]

Great news, thank you ! Please make sure to update the VM information on the wiki at the end of the upgrade process.

[martin]

Upgrade to Debian7 on TracSVN VM is almost complete, please report features which might have gone lost.

[martin]

Upgrade to Debian7 on Download VM is almost complete, please report features which might have gone lost.

[robe]

martin,

Not sure if the TracSVN upgrade and ssl changes is related, but I noticed I'm not seeing our bot badges on PostGIS anymore. As I recall I think I saw all of them the day before.

I have a related ticket in our postgis tracker. ​https://trac.osgeo.org/postgis/ticket/4019

I still see the bot badges on github and gitea and confirm the images are there if called directly.

The net calls for the badges shows they are being cancelled and I get this notice

Request URL:https://debbie.postgis.net/buildStatus/icon?job=PostGIS_trunk
Referrer Policy:no-referrer-when-downgrade
Provisional headers are shown
Origin:https://trac.osgeo.org
Referer:https://trac.osgeo.org/postgis
User-Agent:Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Mobile Safari/537.36
job:PostGIS_trunk

[robe]

Forgot to mention page badges show. Dronie badges are currently showing for me but not any of the others

​https://trac.osgeo.org/postgis

[martin]

EDIT: I think I figured what you mean and I confirm more badges are available from their respective sources than shown on the "postgis" Trac page. I also confirm the visible result is different depending on which browser you use.

Looking at the page source delivered to the browser I'm unable to identify any syntax or related differences which might be making the difference, will look again later today using a larger screen.

[strk]

Problem page is: ​https://trac.osgeo.org/postgis

Drone badges come from drone.osgeo.org, others come from non-osgeo domains (in case that matters).

[martin]

Firefox on Linux renders only the alternate text for non-OSGeo-domains, with a quick chat about TLS handshake in the status bar shortly before the Dronie badges show up.

Chromium on Linux renders broken image URLs in every field for non-OSGeo-domains plus the alternate text, but if you open the underlying image in a new tab, it renders correctly.

Therefore I'd go with Sandro's idea, to me this smells like modern browsers refuse to reach out for badges from external sites - but currently I don't know how to "do it right" in this (Trac) context. Assistance is appreciated.

During the Debian update on the TracSVN machine the Trac software saw a minor update as well, because reinstall in Python2.7 was required. In order not to introduce any feature changes, I took the latest release from the same line, which is 1.2.2, together with the plugins listed in ​https://wiki.osgeo.org/wiki/Trac#Plugins

Now I wonder wether the update from the preceding 1.2.1-dev is making the difference ....

[strk]

I'd look at the suggested CORS header, maybe it was previously done by Trac, maybe by Apache. We know browsers did not change so the change must be on the server side (we can't get back to check and compare the headers now...)

Do new headers say anything about allowed-origins ?

[strk]

BTW, this discussion about badges should go in a separate ticket, this ticket was just about SSL

[strk]

I filed the badges discussion as #2122

[strk]

Martin Landa: can we close this as fixed now ?

[martin]

I think one or two VM's (Secure, maybe the Wiki) still require updating, before they or their respective services finally get migrated elsewhere.

May I assume the Web VM is now obsolete ?

[martin]

Ok, I see, it's still being used.

[martin]

​https://wiki.osgeo.org/wiki/SAC:Debian_System_Administration

[martin]

The Wiki VM has been upgraded to Debian7 as well, this makes overall maintenance a little bit easier.

I *think* the secret to get a working GRUB on OSGeo's VM's is to install the "grub-legacy" package. Surprisingly there wasn't such thing on the Adhoc VM - maybe it's been upgraded again after the last successful reboot.

[martin]

The Wweb VM has now been upgraded to Debian7.

For the sake of backwards compatibility with the old Drupal setup I took care of keeping the old PHP5 packages. Thus, the old web site should behave as it did before. If it doesn't, please report.

[martin]

Now there are two Debian6 VM's left:

• Projects: I think the remaining projects should get migrated over to Osgeo6. The VM might subsequently turn into a reboot-testbed.
• Secure: Upgrading this one is rather simple, because SLAPD is its only service and it's already in config directory format. Can OSGeo afford a little LDAP hiccup during upgrade ?

[strk]

How long would such hiccup be ?

[martin]

From my experience with other VM migrations, I'd say the hiccup would last less than 5 minutes, because there's so little to upgrade on this VM.
Alternatively, we could make the current LDAP directory read-only, set up a read-only clone on Osgeo6, switch the "ldap.osgeo.org" DNS to Osgeo6, upgrade the secure VM, switch the DNS back to the secure VM.

Ideas, votes ?

[strk]

I find the idea of setting up a read only clone useful in general, we could keep it ready and document how to do it again next time it will be needed, for any reason.

[robe]

is this still an issue or can we close?