[postgis-devel] Can we put back GEOS 3.5 support in 3.0?

Tue Feb 12 07:47:25 PST 2019

Experiment results so far: it's a way to patch endless loops and segfaults
into old Debian :)

PostGIS 2.1.4 backpatched by Debian Security team in Debian 8, so you can't
crash it that way.
https://lists.debian.org/debian-lts-announce/2019/01/msg00030.html

Assigned severity is "HIGH" :)
https://nvd.nist.gov/vuln/detail/CVE-2017-18359

Ubuntu is still vulnerable. Pinged them with bug report, let's see where it
goes.
https://bugs.launchpad.net/bugs/cve/2017-18359

Red Hat created a tracking bug but seemingly did nothing:
https://bugzilla.redhat.com/show_bug.cgi?id=1669660

Some service crafted a script to check whether your Debian 8 has unpatched
packages:
https://vulners.com/openvas/OPENVAS:1361412562310891653

Someone got issue translated into Spanish:
https://www.incibe-cert.es/alerta-temprana/vulnerabilidades/cve-2017-18359

And into Russian:
https://ovaldb.altx-soft.ru/Definition.aspx?id=oval:ru.altx-soft.win:def:59483

Cisco wrote an analysis on this avoiding the exact way to crash but
recommending to isolate the database in network using their solutions:
https://tools.cisco.com/security/center/viewAlert.x?alertId=59519

Someone may be selling exploit to this for $5k:
https://vuldb.com/?id.130256

On Fri, Jan 25, 2019 at 6:14 PM Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

> A worthy experiment!
>
> On Jan 24, 2019, at 9:50 PM, Darafei Komяpa Praliaskouski <me at komzpa.net>
> wrote:
>
> PostGIS 2.0..2.3.2 now has a CVE, let's see how quick vendors will pick it
> up:
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-18359
>
>
> On Thu, Jan 24, 2019 at 2:20 AM Darafei "Komяpa" Praliaskouski <
> me at komzpa.net> wrote:
>
>> To push libraries to get update, either:
>>  - make downstream packages dependencies tighter (with each PostGIS
>> release depend on current minor of GEOS);
>>  - report a CVE / security bug, so that it's handled by security team
>> (can become just a three-line backpatch though).
>>
>> On Thu, Jan 24, 2019 at 2:14 AM Paul Ramsey <pramsey at cleverelephant.ca>
>> wrote:
>>
>>> Well, there’s going to be some exciting news on the GEOS front next
>>> week, and hopefully it will bring everyone back to the table :) I don’t
>>> know how to break the packaging logjam though, as there’s something about
>>> system libraries that defies makes everyone “go slow”. Which isn’t really
>>> fair, since we’ve done everything necessary to make things easy: the ABI
>>> never changes, there’s never a reason to not just dump the latest GEOS into
>>> place. What can we do to convince packagers we are sincere?
>>>
>>> P
>>>
>>> > On Jan 23, 2019, at 3:05 PM, Nyall Dawson <nyall.dawson at gmail.com>
>>> wrote:
>>> >
>>> > On Wed, 23 Jan 2019 at 23:45, Darafei "Komяpa" Praliaskouski
>>> > <me at komzpa.net> wrote:
>>> >>
>>> >> I believe that not upgrading GEOS is self supporting problem.
>>> >>
>>> >> Nobody cares about GEOS, as nobody uses GEOS directly. They use
>>> PostGIS, QGIS, or whatevergis that uses GEOS. The only reason to pull a new
>>> version is if something can't work with older.
>>> >>
>>> >> If we, PostGIS developers, are affected by the same plague, we
>>> basically can't ever close a ticket in PostGIS GEOS milestone - we're
>>> supporting old versions, so you can still get your PostGIS with the bug
>>> manifesting itself. A recent case is someone showing on PostGIS IRC asking
>>> why ST_Subdivide won't work as expected in their 2.4.latest and the issue
>>> was they used unpatched GEOS.
>>> >
>>> > I'm watching this thread with interest! From a QGIS developer's
>>> > perspective, we're consistently running into this same issue. We've
>>> > got a choice between:
>>> >
>>> > 1. Fixing bugs and implementing features in GEOS, and then waiting...
>>> > 2? 3? more? years before we can actually rely on users HAVING those
>>> > fixes/features when they install QGIS
>>> > or
>>> > 2. Being "bad" open source citizens and implementing workarounds and
>>> > features downstream, so that users get these changes within (at most)
>>> > 4 months.
>>> >
>>> > Guess which option we usually pick? ;)
>>> >
>>> > I'm really happy to see the recent increase in activity on the GEOS
>>> > repo, and the performance boosts and optimizations which are landing
>>> > there. I'd love to see GEOS regain it's rightful place as the
>>> > "standard" geometry processing library used by PostGIS/QGIS/GDAL/R/...
>>> > but... I can't see this happening with the combination of GEOS' slow
>>> > release cycle and (more importantly) the constant demand from users to
>>> > see the latest versions of applications (PostGIS, QGIS, etc) available
>>> > on these ultra-slow distributions, with outdated library versions.
>>> >
>>> > One of these days I'm going to propose that QGIS just bundles the
>>> > whole of the latest GEOS stable release inside the QGIS repo (maybe as
>>> > a git submodule) so that we're guaranteed to have the very latest GEOS
>>> > release alongside QGIS. It's honestly the only way forward that I can
>>> > see working. Maybe PostGIS should consider the same...
>>> >
>>> > Nyall
>>> > _______________________________________________
>>> > postgis-devel mailing list
>>> > postgis-devel at lists.osgeo.org
>>> > https://lists.osgeo.org/mailman/listinfo/postgis-devel
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>>
>>
>>
>> --
>> Darafei Praliaskouski
>> Support me: http://patreon.com/komzpa
>>
>
>
> --
> Darafei Praliaskouski
> Support me: http://patreon.com/komzpa
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel

-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20190212/7b9becb5/attachment.html>