Opened 7 years ago

Closed 5 years ago

#1981 closed defect (worksforme)

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

Reported by: martinl Owned by: martin
Priority: blocker Milestone: Sysadmin Contract 2018-I
Component: SysAdmin Keywords: svn, openssl
Cc:

Description

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

Change History (42)

comment:1 by neteler, 7 years ago

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.

in reply to:  1 comment:2 by martinl, 7 years ago

Priority: normalcritical

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.

comment:3 by strk, 7 years ago

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)

comment:5 by strk, 7 years ago

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)

comment:6 by strk, 7 years ago

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

comment:7 by mlennert, 7 years ago

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

comment:8 by jef, 7 years ago

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
Last edited 7 years ago by jef (previous) (diff)

comment:9 by strk, 7 years ago

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)

comment:10 by mlennert, 7 years ago

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

comment:11 by martinl, 6 years ago

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

comment:12 by strk, 6 years ago

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).

comment:13 by rduivenvoorde, 6 years ago

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

comment:14 by strk, 6 years ago

Priority: criticalblocker

comment:15 by goatbar, 6 years ago

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

comment:16 by robe, 6 years ago

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.

comment:17 by martin, 6 years ago

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

comment:18 by strk, 6 years ago

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

comment:19 by martin, 6 years ago

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

comment:20 by martin, 6 years ago

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

comment:21 by robe, 6 years ago

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

comment:22 by robe, 6 years ago

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

https://trac.osgeo.org/postgis

comment:23 by martin, 6 years ago

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.

Last edited 6 years ago by martin (previous) (diff)

comment:24 by strk, 6 years ago

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).

comment:25 by martin, 6 years ago

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 ....

comment:26 by strk, 6 years ago

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 ?

comment:27 by strk, 6 years ago

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

comment:28 by strk, 6 years ago

I filed the badges discussion as #2122

comment:29 by strk, 6 years ago

Martin Landa: can we close this as fixed now ?

comment:30 by martin, 6 years ago

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 ?

comment:31 by martin, 6 years ago

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

comment:32 by martin, 6 years ago

Owner: changed from sac@… to martin
Status: newassigned

comment:33 by martin, 6 years ago

Milestone: Sysadmin Contract 2018-I

comment:35 by martin, 6 years ago

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.

comment:36 by martin, 6 years ago

The Web 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.

Last edited 6 years ago by martin (previous) (diff)

comment:37 by martin, 6 years ago

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 ?

comment:38 by strk, 6 years ago

How long would such hiccup be ?

comment:39 by martin, 6 years ago

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 ?

comment:40 by strk, 6 years ago

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.

comment:41 by robe, 5 years ago

is this still an issue or can we close?

comment:42 by robe, 5 years ago

Resolution: worksforme
Status: assignedclosed
Note: See TracTickets for help on using tickets.