Bug#929321: unblock: sqlalchemy/1.2.18+ds1-2 (CVE-2019-7164 CVE-2019-7548)
On 5/30/19 5:23 AM, Paul Gevers wrote: Hi Mike, zigo, Thanks for your replies, I very much think it's safer to just allow SQLAchemy to migrate right now, to fix the potential SQL insertion vulnerability, rather than waiting for any (potential, but likely rare) issue in the above reverse dependencies. I do think a gentle ping to the maintainers of the above packages would be nice, but probably mass-filling of bugs isn't needed. How can I easily gather the list of maintainer? Is there a script somewhere to do this, or should I write it myself (which shouldn't be hard with some apt-cache show in a loop...)? Piotr, Mike, is what I wrote above accurate? I can confirm Openstack is likely OK, most packages are likely OK, and if a package is not OK, it's a trivial fix for them. But as long as they are not fixed, how severe do you expect those issues to be? I suggest to proceed with contacting them, just so maintainers can check their package if they care. severe because they will have queries that won't run. @zigo, if you have the package name, you can contact the maintainers by sending to @packages.debian.org. I'm not 100% sure if this only works for source package names. Paul
Bug#929321: unblock: sqlalchemy/1.2.18+ds1-2 (CVE-2019-7164 CVE-2019-7548)
Hi Mike, zigo, Thanks for your replies, >> I very much think it's safer to just allow SQLAchemy to migrate right >> now, to fix the potential SQL insertion vulnerability, rather than >> waiting for any (potential, but likely rare) issue in the above reverse >> dependencies. >> >> I do think a gentle ping to the maintainers of the above packages would >> be nice, but probably mass-filling of bugs isn't needed. How can I >> easily gather the list of maintainer? Is there a script somewhere to do >> this, or should I write it myself (which shouldn't be hard with some >> apt-cache show in a loop...)? >> >> Piotr, Mike, is what I wrote above accurate? > > I can confirm Openstack is likely OK, most packages are likely OK, and > if a package is not OK, it's a trivial fix for them. But as long as they are not fixed, how severe do you expect those issues to be? I suggest to proceed with contacting them, just so maintainers can check their package if they care. @zigo, if you have the package name, you can contact the maintainers by sending to @packages.debian.org. I'm not 100% sure if this only works for source package names. Paul signature.asc Description: OpenPGP digital signature
Bug#929321: unblock: sqlalchemy/1.2.18+ds1-2 (CVE-2019-7164 CVE-2019-7548)
On Wed, May 29, 2019, at 5:28 PM, Thomas Goirand wrote: > > Dear Debian release team, > > Please note that, even though I was the person who updated SQLAlchemy to > apply the upstream CVE fix, I am not the official maintainer of the > package, and that this is probably up to Piotr to do the work. I'm > happily replying though. :) > > I'm CC-ing Piotr and Mike Bayer (upstream for SQLAlchemy). > > On 5/28/19 8:59 PM, Paul Gevers wrote: > > Control: tags -1 moreinfo confirmed > > > > Hi Zigo, > > > > On Tue, 21 May 2019 17:50:28 +0200 Thomas Goirand wrote: > >> Note that it may (or not) break some reverse dependencies, though according > >> to upstream, OpenStack (the biggest SQLAlchemy consumer in Debian) behaves > >> correctly with it. If this happens, then these reverse dependencies will > >> have to be fixed. > > > > Do you already have indications that this may be the case? > > For all things OpenStack, I'm pretty sure that everything is ok, because > the upstream author of SQLAlchemy has been hired by Red Hat to make sure > OpenStack uses SQLAlchemy the proper way. > > For other dependencies, it's harder to know. > > > How you > > already warned the reverse dependencies to check? I would appreciate it > > if you do such that we can also have those fixed reverse dependencies in > > buster. > > > > Paul > > Here's the list of reverse dependencies for python3-sqlalchemy: > > * buildbot > * changeme > * db2twitter > * dms-core [amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x] > * mailman3 > * openlp > * python3-agatesql > * python3-geoalchemy2 > * python3-osmalchemy > * python3-pybel > * python3-sadisplay > * python3-sqlsoup > * retweet > * sqlacodegen > * yokadi > > Here are those for python-sqlalchemy: > > * archipel-core > * bauble > * blogofile-converters > * childsplay > * epigrass [amd64 arm64 armel armhf i386 kfreebsd-amd64 mips mips64el > mipsel ppc64el s390x] > * gnukhata-core > * gourmet > * griffith > * kamcli > * pegasus-wms > * pycsw-wsgi > * python-elixir > * python-pywps > * python-sprox > * python-sqlkit > * python-sqlsoup > * python-zope.sqlalchemy > * pytrainer > * vistrails > * yhsm-yubikey-ksm > > I removed all-things-openstack and libraries who are very unlikely to > have issues, such as sqlalchemy-utils and others. > > I don't know any of the above package. It would be hard to tell who's > affected by a related problem, though the miss-use of SQLAlchemy > (because that's really what we're talking about here... a miss-use that > should have been considered a bug to begin with, even without the > applied patch to SQLAlchemy) is quite rare. > > I very much think it's safer to just allow SQLAchemy to migrate right > now, to fix the potential SQL insertion vulnerability, rather than > waiting for any (potential, but likely rare) issue in the above reverse > dependencies. > > I do think a gentle ping to the maintainers of the above packages would > be nice, but probably mass-filling of bugs isn't needed. How can I > easily gather the list of maintainer? Is there a script somewhere to do > this, or should I write it myself (which shouldn't be hard with some > apt-cache show in a loop...)? > > Piotr, Mike, is what I wrote above accurate? I can confirm Openstack is likely OK, most packages are likely OK, and if a package is not OK, it's a trivial fix for them. > > Cheers, > > Thomas Goirand (zigo) >
Bug#929321: unblock: sqlalchemy/1.2.18+ds1-2 (CVE-2019-7164 CVE-2019-7548)
Dear Debian release team, Please note that, even though I was the person who updated SQLAlchemy to apply the upstream CVE fix, I am not the official maintainer of the package, and that this is probably up to Piotr to do the work. I'm happily replying though. :) I'm CC-ing Piotr and Mike Bayer (upstream for SQLAlchemy). On 5/28/19 8:59 PM, Paul Gevers wrote: > Control: tags -1 moreinfo confirmed > > Hi Zigo, > > On Tue, 21 May 2019 17:50:28 +0200 Thomas Goirand wrote: >> Note that it may (or not) break some reverse dependencies, though according >> to upstream, OpenStack (the biggest SQLAlchemy consumer in Debian) behaves >> correctly with it. If this happens, then these reverse dependencies will >> have to be fixed. > > Do you already have indications that this may be the case? For all things OpenStack, I'm pretty sure that everything is ok, because the upstream author of SQLAlchemy has been hired by Red Hat to make sure OpenStack uses SQLAlchemy the proper way. For other dependencies, it's harder to know. > How you > already warned the reverse dependencies to check? I would appreciate it > if you do such that we can also have those fixed reverse dependencies in > buster. > > Paul Here's the list of reverse dependencies for python3-sqlalchemy: * buildbot * changeme * db2twitter * dms-core [amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x] * mailman3 * openlp * python3-agatesql * python3-geoalchemy2 * python3-osmalchemy * python3-pybel * python3-sadisplay * python3-sqlsoup * retweet * sqlacodegen * yokadi Here are those for python-sqlalchemy: * archipel-core * bauble * blogofile-converters * childsplay * epigrass [amd64 arm64 armel armhf i386 kfreebsd-amd64 mips mips64el mipsel ppc64el s390x] * gnukhata-core * gourmet * griffith * kamcli * pegasus-wms * pycsw-wsgi * python-elixir * python-pywps * python-sprox * python-sqlkit * python-sqlsoup * python-zope.sqlalchemy * pytrainer * vistrails * yhsm-yubikey-ksm I removed all-things-openstack and libraries who are very unlikely to have issues, such as sqlalchemy-utils and others. I don't know any of the above package. It would be hard to tell who's affected by a related problem, though the miss-use of SQLAlchemy (because that's really what we're talking about here... a miss-use that should have been considered a bug to begin with, even without the applied patch to SQLAlchemy) is quite rare. I very much think it's safer to just allow SQLAchemy to migrate right now, to fix the potential SQL insertion vulnerability, rather than waiting for any (potential, but likely rare) issue in the above reverse dependencies. I do think a gentle ping to the maintainers of the above packages would be nice, but probably mass-filling of bugs isn't needed. How can I easily gather the list of maintainer? Is there a script somewhere to do this, or should I write it myself (which shouldn't be hard with some apt-cache show in a loop...)? Piotr, Mike, is what I wrote above accurate? Cheers, Thomas Goirand (zigo)
Bug#929321: unblock: sqlalchemy/1.2.18+ds1-2 (CVE-2019-7164 CVE-2019-7548)
Control: tags -1 moreinfo confirmed Hi Zigo, On Tue, 21 May 2019 17:50:28 +0200 Thomas Goirand wrote: > Note that it may (or not) break some reverse dependencies, though according > to upstream, OpenStack (the biggest SQLAlchemy consumer in Debian) behaves > correctly with it. If this happens, then these reverse dependencies will > have to be fixed. Do you already have indications that this may be the case? How you already warned the reverse dependencies to check? I would appreciate it if you do such that we can also have those fixed reverse dependencies in buster. Paul signature.asc Description: OpenPGP digital signature
Bug#929321: unblock: sqlalchemy/1.2.18+ds1-2 (CVE-2019-7164 CVE-2019-7548)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package sqlalchemy, My last (team-)upload for version 1.2.18+ds1-2 adds a patch from upstream for CVE-2019-7164 CVE-2019-7548, which is an SQL vulnerability problem. Note that it may (or not) break some reverse dependencies, though according to upstream, OpenStack (the biggest SQLAlchemy consumer in Debian) behaves correctly with it. If this happens, then these reverse dependencies will have to be fixed. Debdiff attached. unblock sqlalchemy/1.2.18+ds1-2 Cheers, Thomas Goirand (zigo) diff -Nru sqlalchemy-1.2.18+ds1/debian/changelog sqlalchemy-1.2.18+ds1/debian/changelog --- sqlalchemy-1.2.18+ds1/debian/changelog 2019-02-25 00:01:50.0 +0100 +++ sqlalchemy-1.2.18+ds1/debian/changelog 2019-05-21 16:23:35.0 +0200 @@ -1,3 +1,11 @@ +sqlalchemy (1.2.18+ds1-2) unstable; urgency=high + + * Team upload. + * CVE-2019-7164 CVE-2019-7548: SQL injection. Apply upstream backported patch +for this. Note: This potentially impacts applications (Closes: #922669). + + -- Thomas Goirand Tue, 21 May 2019 16:23:35 +0200 + sqlalchemy (1.2.18+ds1-1) unstable; urgency=medium * New upstream release diff -Nru sqlalchemy-1.2.18+ds1/debian/patches/CVE-2019-7164_and_7548_Illustrate_fix_for_4481_in_terms_of_a_1.2_patch.patch sqlalchemy-1.2.18+ds1/debian/patches/CVE-2019-7164_and_7548_Illustrate_fix_for_4481_in_terms_of_a_1.2_patch.patch --- sqlalchemy-1.2.18+ds1/debian/patches/CVE-2019-7164_and_7548_Illustrate_fix_for_4481_in_terms_of_a_1.2_patch.patch 1970-01-01 01:00:00.0 +0100 +++ sqlalchemy-1.2.18+ds1/debian/patches/CVE-2019-7164_and_7548_Illustrate_fix_for_4481_in_terms_of_a_1.2_patch.patch 2019-05-21 16:23:35.0 +0200 @@ -0,0 +1,331 @@ +Description: CVE-2019-7164 / CVE-2019-7548: Illustrate fix for #4481 in terms of a 1.2 patch + Release 1.2 has decided (so far) not to backport 1.3's fix for #4481 as it is + backwards-incompatible with code that relied upon the feature of automatic text + coercion in SQL statements. However, for the specific case of order_by() and + group_by(), we present a patch that backports the specific change in compiler + to have 1.3's behavior for order_by/group_by specifically. This is much more + targeted than the 0.9 version of the patch as it takes advantage 1.0's + architecture which runs all order_by() / group_by() through a label lookup that + only warns if the label can't be matched. + . + For an example of an application that was actually impacted by 1.3's change + and how they had to change it, see: + . + https://github.com/ctxis/CAPE/commit/be0482294f5eb30026fe97a967ee5a768d032278 + . + Basically, in the uncommon case an application is actually using the text + coercion feature which was generally little-known, within the order_by() + and group_by() an error is now raised instead of a warning; the application + must instead ensure the SQL fragment is passed within a text() construct. + The above application has also been seeing a warning about this since 1.0 + which apparently remained unattended. + . + The patch includes adjustments to the tests that were testing for the + warning to now test that an exception is raised. Any distro that wants + to patch the specific CVE issue resolved in #4481 to SQLAlchemy 1.0, 1.1 + or 1.2 can use this patch. +Author: Mike Bayer +Date: Mon, 08 Apr 2019 22:07:35 -0400 +Change-Id: I3363b21428f1ad8797394b63197375a2e56a0bd7 +References: #4481 +Bug-Debian: https://bugs.debian.org/922669 +Origin: upstream, https://gerrit.sqlalchemy.org/#/c/sqlalchemy/sqlalchemy/+/1184/ +Last-Update: 2019-05-21 + +diff --git a/lib/sqlalchemy/sql/compiler.py b/lib/sqlalchemy/sql/compiler.py +index 5a11ed1..4780bab 100644 +--- a/lib/sqlalchemy/sql/compiler.py b/lib/sqlalchemy/sql/compiler.py +@@ -757,12 +757,11 @@ + else: + col = with_cols[element.element] + except KeyError: +-# treat it like text() +-util.warn_limited( +-"Can't resolve label reference %r; converting to text()", +-util.ellipses_string(element.element), ++elements._no_text_coercion( ++element.element, ++exc.CompileError, ++"Can't resolve label reference for ORDER BY / GROUP BY.", + ) +-return self.process(element._text_clause) + else: + kwargs["render_label_as_label"] = col + return self.process( +diff --git a/lib/sqlalchemy/sql/elements.py b/lib/sqlalchemy/sql/elements.py +index 299fcad..ff86deb 100644 +--- a/lib/sqlalchemy/sql/elements.py b/lib/sqlalchemy/sql/elements.py +@@ -4432,6 +4432,17 @@ + ) + + ++def _no_text_coercion(element, exc_cls=exc.ArgumentError, extra=None): ++raise exc_cls( ++"%(extra)sTextual SQL expression %(expr)r should be " ++"explicitly declared as
