Bug#995781: [Debian-med-packaging] Bug#995781: python-sqlsoup autopkgtest fails with SQLAlchemy 1.4.23+ds1-2
On Sun, Nov 14, 2021, at 12:19 AM, Paul Wise wrote: > On Fri, 08 Oct 2021 16:51:06 -0400 Mike Bayer wrote: > > > SQLSoup's repository is currently at > > https://github.com/zzzeek/sqlsoup > > > > However it has not been maintained for many years and would not be > > expected to work with modern versions of SQLAlchemy. > > I suggest that you make this official by either mentioning that SQLSoup > is no longer maintained in the README.md, or using the "archived" > feature on GitHub, which marks the repository as read-only and adds a > banner about the repository no longer being maintained. I've done both as well as taken down the readthedocs page. > > https://docs.github.com/en/repositories/archiving-a-github-repository/archiving-repositories > > FTR, I've filed a bug upstream against Python plac, which is the only > other thing in Debian that uses SQLSoup (for its build-time tests). > > https://github.com/ialbert/plac/issues/62 > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise > > > *Attachments:* > * signature.asc
Bug#995781: [Debian-med-packaging] Bug#995781: python-sqlsoup autopkgtest fails with SQLAlchemy 1.4.23+ds1-2
you woujld have better luck changing epigrass to use automap instead: https://docs.sqlalchemy.org/en/14/orm/extensions/automap.html On Fri, Oct 8, 2021, at 5:08 PM, Étienne Mollier wrote: > Control: tag -1 upstream help > Control: forwarded -1 https://github.com/zzzeek/sqlsoup/issues/1 > > Hi Mike, > > I flag the bug so it eventually draws more attention from people > still interested in sqlsoup. Your program is still in use by at > least one other package: epigrass, so a removal from Debian > would be inconvenient. > > Many thanks for your status! > > Have a nice day, :) > -- > Étienne Mollier > Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da > Sent from /dev/pts/2, please excuse my verbosity. > > > *Attachments:* > * signature.asc
Bug#995781: [Debian-med-packaging] Bug#995781: python-sqlsoup autopkgtest fails with SQLAlchemy 1.4.23+ds1-2
Hi Étienne - SQLSoup's repository is currently at https://github.com/zzzeek/sqlsoup However it has not been maintained for many years and would not be expected to work with modern versions of SQLAlchemy. Feel free to remove it from your distributions. - mike On Fri, Oct 8, 2021, at 4:22 PM, Étienne Mollier wrote: > Hi Michael, > > Sorry to contact you like this, but since the forge disappeared > from bitbucket, we were keeping track of the pypi repository > instead, but it hasn't much moved since 2016 [0], and we don't > know where else to pull upgrades, report issues, etc. Per > chance, do you still happen to work on sqlsoup on some public > location? > > [0]: https://pypi.org/project/sqlsoup/ > > There is an impending upgrade of SQLAlchemy from version 1.3 to > 1.4 in Debian Testing, but there are a couple of issues which > hold the process in Unstable. One of them is that it introduces > regressions in our current version of sqlsoup, per Thomas' bug > report [1]. > > [1]: http://bugs.debian.org/995781 > > Excerpt from the migration test log [2], which basically consist > in running `python3 -c "import sqlsoup; print(sqlsoup)"`: > > Testing with python3.9: > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3/dist-packages/sqlsoup.py", line 11, in > from sqlalchemy.orm.interfaces import MapperExtension, EXT_CONTINUE > ImportError: cannot import name 'MapperExtension' from > 'sqlalchemy.orm.interfaces' > (/usr/lib/python3/dist-packages/sqlalchemy/orm/interfaces.py) > > [2]: > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-sqlsoup/15788076/log.gz > > I begun to have a peek at the issue and rapidly found changelogs > for SQLAchemy [3], but once the first symptom is worked around, > I begin pull more hairy issues with relation to functions which > were apparently not documented on sqlalchemy side, while running > the unit test suite: > > == > ERROR: test_bad_names (tests.test_sqlsoup.SQLSoupTest) > -- > Traceback (most recent call last): > File > "/<>/.pybuild/cpython3_3.9_sqlsoup/build/tests/test_sqlsoup.py", > line 105, in tes > t_bad_names > str(db.bad_names.c.query) > File "/<>/.pybuild/cpython3_3.9_sqlsoup/build/sqlsoup.py", > line 463, in __getattr__ > return self.entity(attr) > File "/<>/.pybuild/cpython3_3.9_sqlsoup/build/sqlsoup.py", > line 460, in entity > return self.map_to(attr, tablename=attr, schema=schema) > File "/<>/.pybuild/cpython3_3.9_sqlsoup/build/sqlsoup.py", > line 366, in map_to > mapped_cls = _class_for_table( > File "/<>/.pybuild/cpython3_3.9_sqlsoup/build/sqlsoup.py", > line 133, in _class_for_table > selectable = expression._clause_element_as_expr(selectable) > AttributeError: module 'sqlalchemy.sql.expression' has no attribute > '_clause_element_as_expr' > > [3]: > https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html#change-6daf2f59ac2438ef9c8213e9ebeac157 > > (I wrote a patch, in attachment, to get there, but I am not too > happy about it, feels like just a crude workaround to hide the > first symptom.) > > Please let us know if you have time to investigate this, > otherwise the sqlsoup package is at risk of being removed from > Debian Testing to avoid blocking further the SQLAlchemy upgrade. > > Kind Regards, > -- > Étienne Mollier > Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da > Sent from /dev/pts/2, please excuse my verbosity. > > > *Attachments:* > * migrate-to-mapper-events.patch > * signature.asc
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)
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) >
