Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

eventlet worker: ALREADY_HANDLED -> WSGI_LOCAL #2581

Merged
merged 1 commit into from Jul 2, 2021
Merged

eventlet worker: ALREADY_HANDLED -> WSGI_LOCAL #2581

merged 1 commit into from Jul 2, 2021

Conversation

temoto
Copy link
Contributor

@temoto temoto commented May 6, 2021

Eventlet 0.30.3+ removed wsgi.ALREADY_HANDLED breaking public API in just a patch version increase. Sorry.

Issue with ALREADY_HANDLED: eventlet/eventlet#543
Solution with WSGI_LOCAL: eventlet/eventlet#544

It's recommended to use eventlet>=0.31.0 if one uses websockets, because older versions are vulnerable to DoS attack. GHSA-9p9m-jm8w-94p2

CI failed in pylint checks on lines I didn't touch.

@temoto temoto marked this pull request as ready for review May 6, 2021 10:16
HenriWahl pushed a commit to HenriWahl/doko3000 that referenced this pull request May 7, 2021
Boring-Mind added a commit to Boring-Mind/gunicorn that referenced this pull request May 10, 2021
Fix issue with import error while using latest eventlet (>=0.30.3).

Changes made in eventlet: benoitc#2581
demoyuw added a commit to iii-org/devops-system that referenced this pull request May 11, 2021
ffafara-tw added a commit to department-of-veterans-affairs/notification-api that referenced this pull request May 11, 2021
demoyuw added a commit to iii-org/devops-system that referenced this pull request May 12, 2021
* develope: (69 commits)
  eventlet 0.31.0 still has bug. return to 0.30.2 benoitc/gunicorn#2581
  Remove pip package gunicorn version
  project_members_detail response add pm_user_login
  * Update project.py apiError.py 1. check patterns exist in project description 2. add invalid_project_description
  add return data: ' ' when the socket return
  bug fixed. delete multi role binding (user, project) when delete user.
  Don't keep git-count-commits and job by edit cronjob yaml
  Unify project.repository_ids to array type
  Don't keep sync-redmine and job by edit cronjob yaml
  * Update sync_redmine.py 1. set default admin_account 2. insert_project add pm_user_login 3. insert_all_issues add assigned_to_login 4. get_redmine_issue_rank add user_login
  *Update model.py 1. RedmineIssue add assigned_to_login 2. RedmineProject add pm_user_login
  Bump eventlet from 0.30.2 to 0.31.0
  fix bug and format for PE8
  fix page_search number
  fix ad search citeria
  Fix bug
  Can change role of users from ad
  Fix correct location timeout to avoid timeout while creating database
  Change SocketIO timeout to 60s
  Change SocketIO timeout to 60s
  ...
@onlinejudge95
Copy link

Can we have at least a basic agreement of not doing such breaking changes as part of a patch version upgrade at least

@marcus233
Copy link

Can we have at least a basic agreement of not doing such breaking changes as part of a patch version upgrade at least

Agreed, however a major version change would have had the same result:

'eventlet': ['eventlet>=0.24.1'],
https://github.com/benoitc/gunicorn/blob/master/setup.py#L81

Smirl added a commit to Smirl/fake-realtor-api that referenced this pull request May 18, 2021
Smirl added a commit to Smirl/fake-realtor-api that referenced this pull request May 18, 2021
@onlinejudge95
Copy link

Agreed, however a major version change would have had the same result:

Then what is the use of semver?
had it been a major version bump, it would have been pretty clear just by seeing the version info that something needs to be checked. I expect a patch version to be always backward compatible and hence don't see issues in merging a patch upgrade that too in the case when I am not using this package directly but as a dependency for gunicorn.

@marcus233
Copy link

marcus233 commented May 19, 2021

Then what is the use of semver?

In theory you would pin the version using something like package>=1.0.0,<2.0.0 (which is what I tend to do for my projects). With a "non-stable" version I like to pin it to the minor version so in this case eventlet>=0.24.1,<0.25. Depending on how you read the packaging suggestions you can end up with different ways of managing the dependencies.

You might consider opening a pull request suggesting your way of managing the versions to see if the project will accept it or consider moving to a dependency manager that uses a lock file (poetry?) but what's more concerning to me is the delay on reviewing and merging this PR.

@tomthorogood
Copy link

what's more concerning to me is the delay on reviewing and merging this PR.

💯, it would be great to see some follow-up from the gunicorn folks about this.

@onlinejudge95
Copy link

In theory you would pin the version using something like package>=1.0.0,<2.0.0 (which is what I tend to do for my projects). With a "non-stable" version I like to pin it to the minor version so in this case eventlet>=0.24.1,<0.25. Depending on how you read the packaging suggestions you can end up with different ways of managing the dependencies.

I am pinning the eventlet version in my requirement file and dependency management is not the point I am talking about, my issue is that since it is a security vulnerability(which again by definition should have warranted a MAJOR or MINOR version bump) so I expected gunicorn would also patch it up from their end given that eventlet is an optional dependency for gunicorn.

You might consider opening a pull request suggesting your way of managing the versions to see if the project will accept it or consider moving to a dependency manager that uses a lock file (poetry?) but what's more concerning to me is the delay on reviewing and merging this PR.

Even I am puzzled that there had been no acknowledgement from their end on this PR.

@@ -125,6 +130,10 @@ def patch(self):
patch_sendfile()

def is_already_handled(self, respiter):
# eventlet >= 0.30.3
if EVENTLET_WSGI_LOCAL and EVENTLET_WSGI_LOCAL.already_handled:
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need an « and » there ? can’t we simply check if one or the other is present and set to true?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I don't understand.

We need first check because there may be older version of eventlet and module level getattr would set it to None. Arguably should explicitly compare to None like so.

if EVENTLET_WSGI_LOCAL is not None: # eventlet >= 0.30.3

And then if we know it's eventlet with WSGI_LOCAL, we can check its already_handled and avoid resolving None.already_handled.

Surely you got all this and I'm just confused about what other option is possible here. Sorry. If you show a more concrete example, I will change code as you wish.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think another way of expressing this would be to write if getattr(EVENTLET_WSGI_LOCAL, 'already_handled', None):.

I am not saying this is better, I am just stating @temoto's case another way, to help illustrate the intent. (Or at least, that's how I undersatnd it.)

Edit: I re-considered and realized that my initial take was wrong, so updated my snippet.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@benoitc did you want getattr like that?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually believe it needs to be: if EVENTLET_WSGI_LOCAL and getattr(EVENTLET_WSGI_LOCAL, 'already_handled', False):
without that I get AttributeError: 'local' object has no attribute 'already_handled'

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to single getattr, it would work in earlier versions of eventlet.

@benoitc
Copy link
Owner

benoitc commented May 21, 2021

In theory you would pin the version using something like package>=1.0.0,<2.0.0 (which is what I tend to do for my projects). With a "non-stable" version I like to pin it to the minor version so in this case eventlet>=0.24.1,<0.25. Depending on how you read the packaging suggestions you can end up with different ways of managing the dependencies.

I am pinning the eventlet version in my requirement file and dependency management is not the point I am talking about, my issue is that since it is a security vulnerability(which again by definition should have warranted a MAJOR or MINOR version bump) so I expected gunicorn would also patch it up from their end given that eventlet is an optional dependency for gunicorn.

You might consider opening a pull request suggesting your way of managing the versions to see if the project will accept it or consider moving to a dependency manager that uses a lock file (poetry?) but what's more concerning to me is the delay on reviewing and merging this PR.

Even I am puzzled that there had been no acknowledgement from their end on this PR.

i commented about the PR (thanks for it). Please have a look

About semver or not I do think we shouldn’t as a project rely too much on it. Sometimes an author is just wanting to ensure an hotfix is going out. We should rather improve our testing to ensure the teste pass when a new dependency is out. It would be cool if we can do that automatically. Possibly without relying on a proprietary service. Any idea/hint is welcome :)

@temoto temoto requested a review from benoitc May 21, 2021 10:22
@temoto
Copy link
Contributor Author

temoto commented May 21, 2021

We should rather improve our testing to ensure the teste pass when a new dependency is out. It would be cool if we can do that automatically. Possibly without relying on a proprietary service. Any idea/hint is welcome :)

Yes, I will setup Eventlet CI with gunicorn.

philherbert added a commit to department-of-veterans-affairs/notification-api that referenced this pull request Jun 1, 2021
because
a) we're not doing stuff with websockets, so we're not very vulnerable
b) the fixed version of eventlet does not work with gunicorn yet: benoitc/gunicorn#2581

also fixes typo in requirements regarding this point

Co-authored-by: Saman Moshafi <saman.moshafi@thoughtworks.com>
Co-authored-by: Vikram Kohli <vikram.kohli@thoughtworks.com>
@gregersn
Copy link

gregersn commented Jun 9, 2021

Why is there no movement on this?

@bt
Copy link

bt commented Sep 8, 2022

@naktinis yes it's maintained. A release is planned soon, once the CI is fixed. Users of Gunicorn can help by testing master and provide feedback about it. That would be really helpful. I will come back on on the release topic really soon.

The fact that this has not been released after several months of waiting makes me doubt this claim.

The only way an open source project is maintained is if people find some time to help. I've been waiting for this fix for a very long time, but haven't found any time to help, so i really can't complain.

But the thing is, a lot of people depend on this project and I’m sure there’s many people would would be open to help where it is needed. Heck, even I am happy to help get a new release out and tagged.

The problem is none of us currently know what the hold up is nor do we have any access to release a new tag unless we were to fork the project.

Repository owner deleted a comment from SuryaSrikanthsml Oct 14, 2022
@benoitc
Copy link
Owner

benoitc commented Oct 14, 2022

This issue is closed and merged in master.

@joanise
Copy link

joanise commented Oct 14, 2022

Yes, it's merged in master, but without a release published to PyPI, it's still an outstanding issue for all projects in the world that use gunicorn. The release is what we're all waiting for and nagging about.

@mball-agathos
Copy link

I've referenced this issue from #2828, which appears to be the most up-to-date open issue on the topic of creating a new release.

vagechirkov pushed a commit to vagechirkov/RN-III-Task-Explorer that referenced this pull request Nov 29, 2022
@ReimarBauer
Copy link

Had the same problem - this seems to work

this requires a patched eventlet, see

https://adv-archiv.dfn-cert.de/adv/2021-1047/

plockaby added a commit to paullockaby/enphase-proxy that referenced this pull request Apr 9, 2023
I'm tired of waiting for this fix to be released and the I'm tired of the gunicorn author saying "oh yeah any day now" for nearly two years. benoitc/gunicorn#2581
@blacklight
Copy link

blacklight commented May 7, 2023

New release, please.

We can't afford to use in production a project that takes more than two years to fix an obvious bug and release a new version, especially when the workaround involves using a previous vulnerable version of eventlet. And using a Github link for a dependency is a dirty workaround that nobody should be forced to do in production.

If maintainers can't maintain this anymore, please make room to somebody else. Nobody deserves to beg for a new release for two years.

Is it safe to assume that this project is no longer maintained, so we can move on to alternatives?

blacklight added a commit to blacklight/platypush that referenced this pull request May 7, 2023
Reason: gunicorn maintainers no longer give a fuck about their project
and they aren't letting anybody take over either - see
benoitc/gunicorn#2581

This is not how a FOSS project should be run. A project with 9k stars
and countless usages shouldn't end up in a situation where users beg for
two years for a new release that fixes a bad regression and a bad
security vulnerability. The way gunicorn is maintained and run is an
insult to the whole FOSS community.
@benoitc
Copy link
Owner

benoitc commented May 7, 2023

@blacklight did you test master. Does this change works for you? Next time please come with a more constructive comment.

@bt
Copy link

bt commented May 7, 2023

@blacklight did you test master. Does this change works for you? Next time please come with a more constructive comment.

@benoitc, if you have the time to reply this comment, at least action #2828 and release a new tagged release WITH this PR in it.

You'll notice magically everyone will stop pestering you about this issue over and over again...

@benoitc
Copy link
Owner

benoitc commented May 7, 2023

@bt this issue is closed.

@blacklight
Copy link

@blacklight did you test master. Does this change works for you?

For some reason everything works out of the box on Arch Linux using the provided pacman packages - I'm not sure if the maintainers of the eventlet or gunicorn packages already provided a patch.

It also works on a fresh virtual environment with the latest pip versions of eventlet and everything else.

I still haven't found a way of getting things to work on Debian Bullseye, but I guess it may be due to some of the ancient python3-* packages shipped with Debian.

@lgnashold
Copy link

lgnashold commented May 12, 2023

Any resolution to this? Still appears to be an issue in the latest eventlet version.

@CurtisLeeBolin
Copy link

@benoitc, I tested master, and it does resolve the problem for me with no apparent ill effects. Are you waiting for more people to test before making a release?

$ pip install git+https://github.com/benoitc/gunicorn.git

Maybe if it is easy to copy and paste a few more will test. ;)

@imalobster
Copy link

Confirmed working for me when directly referencing the github link (thanks CurtisLeeBolin) in my requirements file. Had to add 'apt-get -y git' in my Dockerfile for it to build, but at least the issue found in the PyPI release is no longer occurring.

@devopstales
Copy link

@imalobster you didn't need git. You can add by it's zip like this: https://github.com/benoitc/gunicorn/archive/refs/heads/master.zip

hw1621 pushed a commit to hw1621/AskCareer that referenced this pull request Dec 21, 2023
openiobot pushed a commit to open-io/oio-sds that referenced this pull request Jan 11, 2024
Gunicorn 21.x includes this
benoitc/gunicorn#2581
which allow us to use recent eventlet versions.
openiobot pushed a commit to open-io/oio-sds that referenced this pull request Jan 11, 2024
Gunicorn 21.x includes this
benoitc/gunicorn#2581
which allow us to use recent eventlet versions.
openiobot pushed a commit to open-io/oio-sds that referenced this pull request Jan 16, 2024
Gunicorn 21.x includes this
benoitc/gunicorn#2581
which allow us to use recent eventlet versions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet