hi there, folks:
I'd really like to release 0.7.0 but I would like it to be at least a
little bit tested before I do so. Could those of you with CVS trees check
everything out and see if it performs as advertised? Deeper bugs than
that will have to wait for the next release, but I'd at least like to know
if it works for someone other than me.
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
I'm getting a "maximum recursion depth exceeded" error that appears to be coming from flatten(). The odd thing is that it only happens sometimes. The HTML that's being flattened does have a few Deferreds in it. Those come from function calls, which cache the results, which might explain why I only see the error on the first visit to the page (as far as I can tell).
The system recursion limit is the standard 1000. My HTML is only nested a few tags deep, two orders of magnitude short of that. Is there anything about the way flatten() works that might cause this behaviour?
TLDR: Twisted appears broken on PyPy 7.3.4 (aka "3.7.10")?
I don't have time right now to set up a PyPy-capable environment and try
to reproduce this, but perhaps someone does?
Trunk has been broken since the last merge a week or so ago, but I
don't think the breakage is due to that merge. As an experiment I made
a PR based off the last successful version of trunk, with a whitespace
change, and it now fails CI as well. So I think the failure must be due
to some change that isn't in Twisted or controlled-for by tox.
The failure in all cases is in the pypy-3.7-alldeps-nocov-posix task.
Unlike our usual CI problems it doesn't seem to be a random failure: it
fails all the time in the same place. But the place doesn't make sense
to me. It's in the IRC CTCP tests, and they fail in the same ways each
time (an expected response is not received).
The pair of CI runs closest to the change are these:
run 5793: https://github.com/twisted/twisted/runs/2328450554
run 5809: https://github.com/twisted/twisted/runs/2360415474
There are a lot of differences, but sys.version went from 3.7.9 to
3.7.10 between those runs, so that seems like the most likely culprit.
> sys.version : 3.7.9 (7e6e2bb30ac5, Nov 18 2020, 10:55:52)
> [PyPy 7.3.3-beta0 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]
> sys.prefix : /opt/hostedtoolcache/PyPy/3.7.9/x64
> sys.exec_prefix : /opt/hostedtoolcache/PyPy/3.7.9/x64
> sys.executable : /opt/hostedtoolcache/PyPy/3.7.9/x64/bin/python
> sys.version : 3.7.10 (51efa818fd9b, Apr 04 2021, 11:22:34)
> [PyPy 7.3.4 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]
> sys.prefix : /opt/hostedtoolcache/PyPy/3.7.10/x64
> sys.exec_prefix : /opt/hostedtoolcache/PyPy/3.7.10/x64
> sys.executable : /opt/hostedtoolcache/PyPy/3.7.10/x64/bin/python
PyPy's release notes for 7.3.4 don't list anything that jumps out at me:
My guess would be some latent timing bug in Twisted that was uncovered
by pypy execution time changes (I don't imagine that the CTCP code gets
exercised very heavily these days) or perhaps PyPy got a bug.
I've been investigating
https://github.com/matrix-org/synapse/issues/9566, which amounts to:
"when there is a TLS error connecting to the SMTP server, the resultant
exception is unreadable".
I think I've traced the problem to the fact that
SMTPSenderFactory.clientConnectionFailed is being called with an
unhelpful ConnectionAborted rather than anything more descriptive.
I've then reproduced that with a simpler test case: see
https://gist.github.com/richvdh/909761ff5dab23f0873eeddd7936a740. As you
can see, the output is: "Factory lost connection. Reason: Connection was
aborted locally using ITCPTransport.abortConnection."
This seems to be thanks to TLSMemoryBIOProtocol.failVerification, which
stashes the error and calls abortConnection():
At this point I'm struggling. Is the SMTP code holding the Factory
wrong? Or is it reasonable to expect the verification error to propagate
into clientConnectionFailed - in which case, how could this work?
Thanks for your thoughts!
We just added a patch to our twisted to prevent twisted from doing idna validation.
_idnaBytes and _idnaText not convert from bytes to unicode based on the type of
the provided arg.
We had to do this because there are domain names that youtube.com uses that are
not valid under IDNA-2008 https://tools.ietf.org/html/rfc5891#section-220.127.116.11
For example this URL: https://r2---sn-aigzrn7e.googlevideo.com/generate_204
Firefox is happy to visit this URL and does not change it when its enter
in the address bar.
The comment in the _idna.py code that say this:
"Convert some text typed by a human into some ASCII bytes." and
"Convert some IDNA-encoded octets into some human-readable text"
The key idea here is that its human input that will be converted.
But the code is used deep in the _sslverify.py where no human
input is entered.
I can see why a UI would need to do IDNA-2008 converts and validation
but I'm not clear why its of value deep in the guts of twisted.
Why is this code needed at all in twisted?
If its for a high level API then why isn't it being called at the
edge of the high level API calls?
This is a follow up for https://about.codecov.io/security-update/ that was
raised by Maarten
The security breach is from January 31, 2021,
Here you can see the list of Twisted org projects using Codecov.io
The projects that might be affected are:
twisted Latest commit 3 hours ago - using Bash
pydoctor Latest commit a day ago - using Python
towncrier Latest commit a day ago - using Python
axiom Latest commit 2 days ago - using bash via codecov/codecov-action@v1
klein Latest commit 7 days ago - using bash via codecov/codecov-action@v1
incremental Latest commit 25 days ago - using codecov in Travis
ldaptor 2 months ago - using Python
So the only targets are: twisted , axiom and klein
For twisted/twisted we start using the bash uploaded 19 days ago as part of
Before that we were using the python uploader.
Here is my understanding of what the codecov bash uploader can do:
* Read all the env variables present at the time the bash codecov.io script
is executed. The env might contain secrets
* Use the GitHub Token that is automatically generated for each GitHub
The GitHub token is valid while the action is executed and is kind of a
For twisted/twisted and I think that other repos the main secret available
for GitHub Action is the PYPY upload token.
This is not used as a general env variable, but is only available to the
specific step in which twine is used to upload the files.
The GitHub Org audit page can be used to check org administratie changes
I took a quick look and didn't notice anything suspicious.
I don't know how we can prevent these types of security issues.
We are a public project with limited resources and are always exposed when
we are pulling dependencies from codecov or pypy that we don't fully
I guess that what we can do is stop using the codecov.io bash uploaded and
switch back to python uploader.
Any other ideas ?