[issue46114] OpenSSL 3.0 uses different version scheme
Charalampos Stratakis added the comment: Case in point: https://buildbot.python.org/all/#/builders/355/builds/338 -- ___ Python tracker <https://bugs.python.org/issue46114> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46114] OpenSSL 3.0 uses different version scheme
Charalampos Stratakis added the comment: 3.8 builds are still running on the buildbots so not fixing 3.8 will cause them to fail. -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue46114> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46542] test_json and test_lib2to3 crash on s390x Fedora Clang 3.x buildbot
Charalampos Stratakis added the comment: The issue seems to be affecting also the PPC64LE Fedora Rawhide Clang 3.x and PPC64LE Fedora Stable Clang 3.x -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue46542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45067] Failed to build _curses on CentOS 7
Charalampos Stratakis added the comment: You should use -lpaneltw instead of -lpanelw. See also: https://bugs.python.org/issue41981 -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue45067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44285] Coverity scan: Modules/getpath.c. "calculate_open_pyenv" allocates memory that is stored into "env_file".
Change by Charalampos Stratakis : -- keywords: +patch pull_requests: +25082 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26486 ___ Python tracker <https://bugs.python.org/issue44285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44285] Coverity scan: Modules/getpath.c. "calculate_open_pyenv" allocates memory that is stored into "env_file".
New submission from Charalampos Stratakis :
This is an issue as it seems with coverity as it's an error case where the file
was not actually opened. This warning can be silenced and the code be made more
explicit by adding an assertion.
Python-3.9.1/Modules/getpath.c:1264: alloc_arg: "calculate_open_pyenv"
allocates memory that is stored into "env_file".
Python-3.9.1/Modules/getpath.c:1266: leaked_storage: Variable "env_file" going
out of scope leaks the storage it points to.
# 1264| status = calculate_open_pyenv(calculate, _file);
# 1265| if (_PyStatus_EXCEPTION(status)) {
# 1266|-> return status;
# 1267| }
# 1268| if (env_file == NULL) {
--
messages: 394906
nosy: cstratak
priority: normal
severity: normal
status: open
title: Coverity scan: Modules/getpath.c. "calculate_open_pyenv" allocates
memory that is stored into "env_file".
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44285>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44048] test_hashlib failure for "AMD64 RHEL8 FIPS Only Blake2 Builtin Hash" buildbot
Change by Charalampos Stratakis : -- keywords: +patch pull_requests: +25065 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26470 ___ Python tracker <https://bugs.python.org/issue44048> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44048] test_hashlib failure for "AMD64 RHEL8 FIPS Only Blake2 Builtin Hash" buildbot
New submission from Charalampos Stratakis :
The buildbot started experiencing some failures. First after
https://github.com/python/cpython/commit/ddbef71a2c166a5d5dd168e26493973053a953d6
this test started failing with:
==
ERROR: test_disallow_instantiation (test.test_hashlib.HashLibTestCase)
--
Traceback (most recent call last):
File
"/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/hashlib.py",
line 160, in __hash_new
return _hashlib.new(name, data, **kwargs)
ValueError: [digital envelope routines: EVP_DigestInit_ex] disabled for FIPS
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/test/test_hashlib.py",
line 912, in test_disallow_instantiation
h = constructor()
File
"/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/test/test_hashlib.py",
line 133, in _test_algorithm_via_hashlib_new
return hashlib.new(_alg, **kwargs)
File
"/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/hashlib.py",
line 166, in __hash_new
return __get_builtin_constructor(name)(data)
File
"/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/hashlib.py",
line 123, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
And then after
https://github.com/python/cpython/commit/91554e4c5ca3c762998296522f854a7166ba84f0
there is another failure:
==
ERROR: test_readonly_types (test.test_hashlib.HashLibTestCase)
--
Traceback (most recent call last):
File
"/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/hashlib.py",
line 160, in __hash_new
return _hashlib.new(name, data, **kwargs)
ValueError: [digital envelope routines: EVP_DigestInit_ex] disabled for FIPS
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/test/test_hashlib.py",
line 933, in test_readonly_types
hash_type = type(constructor())
File
"/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/test/test_hashlib.py",
line 133, in _test_algorithm_via_hashlib_new
return hashlib.new(_alg, **kwargs)
File
"/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/hashlib.py",
line 166, in __hash_new
return __get_builtin_constructor(name)(data)
File
"/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/hashlib.py",
line 123, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
--
assignee: christian.heimes
components: SSL
messages: 393003
nosy: christian.heimes, cstratak
priority: normal
severity: normal
status: open
title: test_hashlib failure for "AMD64 RHEL8 FIPS Only Blake2 Builtin Hash"
buildbot
versions: Python 3.10, Python 3.11
___
Python tracker
<https://bugs.python.org/issue44048>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38820] Make Python compatible with OpenSSL 3.0.0
Change by Charalampos Stratakis : -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue38820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43164] test_nntplib.NetworkedNNTP_SSLTests fails on "AMD64 RHEL8 FIPS Only Blake2 Builtin Hash" buildbot
Charalampos Stratakis added the comment: The issue seems to be resolved and the buildbot is green. -- resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43164> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
Charalampos Stratakis added the comment: > You do not need to support every platform. Just allow your users to use them. This is kinda missing the point though. For example I've dealt a lot with the CPython codebase (and I'm also one of the Red Hat maintainers for RHEL and Fedora) and although I'm not a core developer, the codebase can be quite intimidating. I agree that some lines of code do not seem like much but they add up. If noone actually has a use case here, removing them would be the best option overall just from a cognitive perspective. Now I agree there are hobbyist's and so forth but you present an example, which is irrelevant to this case (m68k is not s390, right?). Do you actually know someone who is actively interested in the usecase of building a 32 bit python on an s390x system? Or do you know someone who owns an s390 system? Maybe someone who sends related fixes to another project? You claim to speak for other maintainers, yet I'd like to actually hear their position on that. Feel free to add them to the nosy list. If the latest kernel is not even booting, I don't think many people actually care about this arch to at least keep it running. On the other hand I do think though here that David would be the best person to speak about those use cases, as he is the most experienced here with the s390(x) architecture. Now from my personal point of view, I don't mind actually keeping the support there, but it will never come up downstream for me, hence it won't affect me as Fedora doesn't build anymore for s390 (and already posted before the case for RHEL). So again, do you know of this specific usecase, of someone either owning an s390 machine and compiling python, or actually utilizing an s390x machine and using the multilib packages to build a 32 bit python? If so, would you (or they) step up to fix related issues when they come up and assuming a buildbot would be set? Or would you know someone who would? While your arguments make sense up to a point, claiming that others will step up or saying what others have done for different architectures, doesn't really help your arguments to hold. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 32-bit s390 Linux support (s390-linux-gnu triplet)
Charalampos Stratakis added the comment: > s390 is being built for SLE-12, for example, on the internal SUSE build > system and SLE-12 is still supported. So if a customer wants to use Python > 3.10 in a SLE-12 s390 environment, why keep them from doing so? Are you sure about that? It seems SLE-12 support s390x not s390. Maybe it's multilib support in a similar manner that I've mentioned about RHEL7? -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 32-bit s390 Linux support (s390-linux-gnu triplet)
Charalampos Stratakis added the comment: And to dig a bit further with a semi-official answer. RHEL4 had standalone support for s390, while since RHEL5+ we've had only multilib support (64 bits kernel and possibility of s390 userspace packages). RHEL7 that is the oldest currently supported RHEL OS, does have multilib support, meaning that 32 bit (s390) userspace packages are available for s390x booting on 64 bit kernel. Although a later base python version for RHEL7 will not be shipped as we already have python2.7.5 and python3.8.6 supported there, which already builds for s390 for the aforementioned multilib support. On Software Collections where we actually sometimes ship later Python versions, we compile only for 64 bits so the removal of the s390 pieces wouldn't pose an issue here. Hence the only problem I can figure out from my analysis would be for users on s390x who would download the necessary 32bit libraries and dependencies from the repos and use the -m32 CFLAGS and LDFLAGS to get a 32 bits build. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 32-bit s390 Linux support (s390-linux-gnu triplet)
Charalampos Stratakis added the comment: For RHEL7 which is the older OS that buildbots are still running, only the System Z architecture is supported. From the release notes [0]: Note that Red Hat Enterprise Linux 7 supports IBM zEnterprise 196 hardware or later; IBM System z10 mainframe systems are no longer supported and will not boot Red Hat Enterprise Linux 7. Also 32 (31 bits) in this case are only supported through virtualization with older OS's. So IMO it's fine to remove the support. [0] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.0_release_notes/chap-red_hat_enterprise_linux-7.0_release_notes-architectures -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43164] test_nntplib.NetworkedNNTP_SSLTests fails on "AMD64 RHEL8 FIPS Only Blake2 Builtin Hash" buildbot
New submission from Charalampos Stratakis : This is one of the unstable buildbots, running under FIPS mode. One of the tests is failing at the moment. == ERROR: setUpClass (test.test_nntplib.NetworkedNNTP_SSLTests) -- Traceback (most recent call last): File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/test/test_nntplib.py", line 321, in setUpClass cls.server = cls.NNTP_CLASS(cls.NNTP_HOST, File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/nntplib.py", line 1025, in __init__ super().__init__(host, port, user, password, readermode, File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/nntplib.py", line 334, in __init__ self.sock = self._create_socket(timeout) File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/nntplib.py", line 1031, in _create_socket sock = _encrypt_on(sock, self.ssl_context, self.host) File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/nntplib.py", line 292, in _encrypt_on return context.wrap_socket(sock, server_hostname=hostname) File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/ssl.py", line 500, in wrap_socket return self.sslsocket_class._create( File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/ssl.py", line 1040, in _create self.do_handshake() File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/ssl.py", line 1309, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: BAD_DH_VALUE] bad dh value (_ssl.c:1122) -- -- assignee: christian.heimes components: SSL, Tests messages: 386631 nosy: christian.heimes, cstratak priority: normal severity: normal status: open title: test_nntplib.NetworkedNNTP_SSLTests fails on "AMD64 RHEL8 FIPS Only Blake2 Builtin Hash" buildbot versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43164> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41981] Errors building python 3.9.0 from source on Centos 7 with GCC 10
Charalampos Stratakis added the comment: The RHEL7 buildbots test on the default system compiler (GCC 4.8). The combination of RHEL7 + GCC10 + Python 3.9 could do very weird stuff, and I don't think it would easy to support. Generally the build environment of an OS is tied to the default compiler toolchain and that involves also the various compiler and linker flags which might be obsoleted in newer versions. -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue41981> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41648] edelsohn-* buildbot worker failing with: No space left on device
Charalampos Stratakis added the comment: Note: I found that all my Fedora and RHEL8 buildbots have issues with connecting to the master buildbot server. Not sure if a related package got updated and prompts the disconnects (as the RHEL7 ones are fine), or if it's relevant to the master buildbot server migration. -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue41648> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41642] RHEL and fedora buildbots fail due to disk space error
Charalampos Stratakis added the comment: There were almost 10GB of remnant cc* files in /tmp from the compilers used, which I presume were also the temporary artifacts which remained there after the disconnects. Cleaned those up and rebooted the RHEL8 x86_64 buildbot. -- ___ Python tracker <https://bugs.python.org/issue41642> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41642] RHEL and fedora buildbots fail due to disk space error
Charalampos Stratakis added the comment: There is an issue which I discovered after I returned from holidays, basically the buildbot-worker keeps getting disconnected from master, so builds start and end abruptly, retaining some artifacts. The next second it tried again with the same results, eventually filling the hard disk with the artifacts. Might be due to an updated package, but I've yet to discover what the issue is. -- ___ Python tracker <https://bugs.python.org/issue41642> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41175] Static analysis issues reported by GCC 10
Change by Charalampos Stratakis : -- keywords: +patch pull_requests: +20392 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21240 ___ Python tracker <https://bugs.python.org/issue41175> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41175] Static analysis issues reported by GCC 10
Charalampos Stratakis added the comment: First issue in Objects/bytearrayobject.c [0]. warning: use of NULL ‘’ where non-null expected [CWE-690] [-Wanalyzer-null-argument] 277 | memcpy(result->ob_bytes, va.buf, va.len); [0] https://github.com/python/cpython/blob/master/Objects/bytearrayobject.c#L277 -- ___ Python tracker <https://bugs.python.org/issue41175> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41175] Static analysis issues reported by GCC 10
New submission from Charalampos Stratakis : GCC added a static analysis tool recently [0]. Running it under for CPython code base produces some interesting results. Reproducer: ./configure --with-pydebug && CFLAGS='-fanalyzer' make Attaching the log. [0] https://developers.redhat.com/blog/2020/03/26/static-analysis-in-gcc-10/ -- files: debugstaticanalysis.txt messages: 372711 nosy: cstratak priority: normal severity: normal status: open title: Static analysis issues reported by GCC 10 versions: Python 3.10, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file49281/debugstaticanalysis.txt ___ Python tracker <https://bugs.python.org/issue41175> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37630] Investigate replacing SHA3 code with OpenSSL
Change by Charalampos Stratakis : -- pull_requests: +20160 pull_request: https://github.com/python/cpython/pull/20986 ___ Python tracker <https://bugs.python.org/issue37630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40637] Allow users to disable builtin hash modules on compile time
Change by Charalampos Stratakis : -- pull_requests: +20131 pull_request: https://github.com/python/cpython/pull/20951 ___ Python tracker <https://bugs.python.org/issue40637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40637] Allow users to disable builtin hash modules on compile time
Change by Charalampos Stratakis : -- nosy: +cstratak nosy_count: 2.0 -> 3.0 pull_requests: +20116 pull_request: https://github.com/python/cpython/pull/20937 ___ Python tracker <https://bugs.python.org/issue40637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40698] distutils.command.upload md5_digest
Charalampos Stratakis added the comment: There is also https://github.com/pypa/warehouse/pull/888 So I would assume it's safe it change the digest to sha256. -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue40698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40334] PEP 617: new PEG-based parser
Change by Charalampos Stratakis : -- nosy: -cstratak ___ Python tracker <https://bugs.python.org/issue40334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40334] PEP 617: new PEG-based parser
Charalampos Stratakis added the comment: > Is this related to this issue? We didn't change that line I can provide you access to the buildbot if you'd like to debug the issue. -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue40334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40018] test_ssl fails with OpenSSL 1.1.1e
Charalampos Stratakis added the comment: And there is already a meta-issue created by cheimes for 3.0.0: https://bugs.python.org/issue38820 -- ___ Python tracker <https://bugs.python.org/issue40018> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40018] test_ssl fails with OpenSSL 1.1.1e
Charalampos Stratakis added the comment: The change has been reverted upstream. Also on the rawhide buildbots, we have an updated build with the commit reverted, so they returned back to green. Now the revertion will be included at a new release of the 1.1.1 branch, however it will still be on the 3.0.0 branch when it will be released, so at that point a possible rewrite of the ssl module will be required, as is the case with every major openssl update. I'd suggest to close this issue and open a new one for compatibility with openssl 3.0.0. -- ___ Python tracker <https://bugs.python.org/issue40018> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40018] test_ssl fails with OpenSSL 1.1.1e
Charalampos Stratakis added the comment: This behavior change is considered being reverted upstream. PR: https://github.com/openssl/openssl/pull/11400 -- ___ Python tracker <https://bugs.python.org/issue40018> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40018] test_ssl fails with OpenSSL 1.1.1e
Charalampos Stratakis added the comment: Still searching the issue and created a first draft PR. With it, tesT_ssl and test_imaplib pass now, urllib2_localnet still has issues. -- ___ Python tracker <https://bugs.python.org/issue40018> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40018] test_ssl fails with OpenSSL 1.1.1e
Change by Charalampos Stratakis : -- keywords: +patch pull_requests: +18491 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19129 ___ Python tracker <https://bugs.python.org/issue40018> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40018] test_ssl fails with OpenSSL 1.1.1e
Charalampos Stratakis added the comment: The relevant info which seems to make the tests fail: Properly detect EOF while reading in libssl. Previously if we hit an EOF while reading in libssl then we would report an error back to the application (SSL_ERROR_SYSCALL) but errno would be 0. We now add an error to the stack (which means we instead return SSL_ERROR_SSL) and therefore give a hint as to what went wrong. Upstream PR: https://github.com/openssl/openssl/pull/10882 urllib3 issue: https://github.com/urllib3/urllib3/issues/1825 -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue40018> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40044] Tests failing with the latest update of openssl to version 1.1.1e
Charalampos Stratakis added the comment: Closing it as duplicate of https://bugs.python.org/issue40018 -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40044> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40044] Tests failing with the latest update of openssl to version 1.1.1e
New submission from Charalampos Stratakis : The fedora rawhide buildbots started failing due to the latest update of openssl to version 1.1.1e. e.g. https://buildbot.python.org/all/#/builders/607/builds/137 Changelog: https://www.openssl.org/news/cl111.txt The relevant info which seems to make the tests fail: Properly detect EOF while reading in libssl. Previously if we hit an EOF while reading in libssl then we would report an error back to the application (SSL_ERROR_SYSCALL) but errno would be 0. We now add an error to the stack (which means we instead return SSL_ERROR_SSL) and therefore give a hint as to what went wrong. Upstream PR: https://github.com/openssl/openssl/pull/10882 urllib3 issue: https://github.com/urllib3/urllib3/issues/1825 -- assignee: christian.heimes components: Library (Lib), SSL, Tests messages: 364818 nosy: christian.heimes, cstratak priority: normal severity: normal status: open title: Tests failing with the latest update of openssl to version 1.1.1e versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40044> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.
Charalampos Stratakis added the comment: Closing the issue as python2 is not receiving any more fixes and our downstream workaround is enough for it. Python3 is fine as well. -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue32521> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38913] Py_BuildValue("(s#O)", ...) segfaults if entered with exception raised
Charalampos Stratakis added the comment: After this change, the arm64 buildbots are reporting reference leaks: 1:03:24 load avg: 0.95 Re-running failed tests in verbose mode 1:03:24 load avg: 0.95 Re-running test_capi in verbose mode test_capi leaked [4, 4, 4] references, sum=12 e.g. https://buildbot.python.org/all/#/builders/563/builds/25 -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue38913> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] test_struct failure on s390x Fedora Clang buildbot
Charalampos Stratakis added the comment:
On this loop:
for c in [b'\x01', b'\x7f', b'\xff', b'\x0f', b'\xf0']:
self.assertTrue(struct.unpack('>?', c)[0])
It fails for the b'\xf0' case
--
___
Python tracker
<https://bugs.python.org/issue39689>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] test_struct failure on s390x Fedora Clang buildbot
Charalampos Stratakis added the comment: Failed assertion here: https://github.com/python/cpython/blob/master/Lib/test/test_struct.py#L520 -- ___ Python tracker <https://bugs.python.org/issue39689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] test_struct failure on s390x Fedora Clang buildbot
New submission from Charalampos Stratakis :
The clang build was recently added for that buildbot and it seems on that
particular architecture, test_struct fails with:
==
FAIL: test_bool (test.test_struct.StructTest)
--
Traceback (most recent call last):
File
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-rawhide-z.clang-ubsan/build/Lib/test/test_struct.py",
line 520, in test_bool
self.assertTrue(struct.unpack('>?', c)[0])
AssertionError: False is not true
https://buildbot.python.org/all/#/builders/488/builds/6
Fedora rawhide recently upgraded Clang to version 10. The rest of the
architectures seem fine.
--
components: Tests
messages: 362277
nosy: cstratak, vstinner
priority: normal
severity: normal
status: open
title: test_struct failure on s390x Fedora Clang buildbot
versions: Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue39689>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39676] test_shutil fails with OSError: [Errno 28] No space left on device on "PPC64LE Fedora Stable LTO + PGO 3.x" buildbot
Charalampos Stratakis added the comment: The issue has been fixed. root was 15GB, but there was still 30GB of un-allocated space in the volume group, so just expanded the logical volume. -- ___ Python tracker <https://bugs.python.org/issue39676> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37096] Add large-file tests for modules using sendfile(2)
Charalampos Stratakis added the comment: Can we reopen the issue? Clearly this change modifies the expectations of free disk space for the temp files created by the tests. Or at least clarify that those tests require more than 6gb of free disk space in /tmp for unix -- ___ Python tracker <https://bugs.python.org/issue37096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38965] test_stack_overflow (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10
Charalampos Stratakis added the comment: Would it make sense to also backport this fix to the 3.6 release? People compiling 3.6 with gcc 10 will stumble upon that. -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue38965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38980] Compile libpython with -fno-semantic-interposition
Charalampos Stratakis added the comment: > Maybe it should only be default when using --with-optimizations I think it will add to the complexity of the --with-optimizations flag which already implies PGO and LTO. Maybe an opt-in flag would be better IMHO. -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue38980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38270] Tests: Avoid MD5 or check for MD5 availablity
Change by Charalampos Stratakis : -- pull_requests: +16927 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/17446 ___ Python tracker <https://bugs.python.org/issue38270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38270] Tests: Avoid MD5 or check for MD5 availablity
Change by Charalampos Stratakis : -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue38270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38850] test_largefile fails on android
Charalampos Stratakis added the comment: I got the same failures on Fedora rawhide. See https://bugs.python.org/issue37096 -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue38850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37096] Add large-file tests for modules using sendfile(2)
Charalampos Stratakis added the comment: Alright added some more disk space at the buildbots, however it seems that it is not related to that. The current Fedora rawhide buildbot has 19GB of free space and the test is still failing. I tested on the Fedora stable buildbot for which I reduced intentionally the free disk space to 14GB and it passed: https://buildbot.python.org/all/#/builders/233/builds/398 So something else might be at play here. -- ___ Python tracker <https://bugs.python.org/issue37096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38576] CVE-2019-18348: CRLF injection via the host part of the url passed to urlopen()
Change by Charalampos Stratakis : -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue38576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34028] Python 3.7.0 wont compile with SSL Support 1.1.0 > alledged missing X509_VERIFY_PARAM_set1_host() support
Charalampos Stratakis added the comment: Have you also tried $ yum install openssl-devel ? That should work without requiring to compile openssl from source, unless you want a later version, which isn't advisable to install system-wide, as it could break other things. -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue34028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38510] build python with --enable-shared with static linked python against libpython*.a
Change by Charalampos Stratakis : -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue38510> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38350] ./configure --with-pydebug should use -O0 rather than -Og
Charalampos Stratakis added the comment: It seems that it's still being worked on from gcc's side: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=78685 -- ___ Python tracker <https://bugs.python.org/issue38350> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38350] ./configure --with-pydebug should use -O0 rather than -Og
Charalampos Stratakis added the comment: Correction, not fail, just a ton of warnings. The same is true for -D_FORTIFY_SOURCE=1 -- ___ Python tracker <https://bugs.python.org/issue38350> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38350] ./configure --with-pydebug should use -O0 rather than -Og
Charalampos Stratakis added the comment: Do note though that if the -D_FORTIFY_SOURCE=2 hardening flag is used, the compilation will fail with an optimization level less than -Og. Haven't tried yet with -D_FORTIFY_SOURCE=1 to see if it works with -O0. -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue38350> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37631] EXTRA_CFLAGS get overrided by CFLAGS_NODIST
Charalampos Stratakis added the comment: Also this is due to an expected behaviour from gcc. From the documentation: "If you use multiple -O options, with or without level numbers, the last such option is the one that is effective. " -- ___ Python tracker <https://bugs.python.org/issue37631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37631] EXTRA_CFLAGS get overrided by CFLAGS_NODIST
Charalampos Stratakis added the comment: Dug a bit further here. The issue is that CFLAGS_NODIST will always come after normal CFLAGS (which are subsets of PY_CFLAGS and PY_CFLAGS_NODIST) [0][1]. The EXTRA_CFLAGS variable is appended at the end of PY_CFLAGS [2], hence as reported here, whatever compiler flag comes after, embedded within PY_CFLAGS_NODIST, will override the previous flags if they contradict each other. So basically EXTRA_CFLAGS can be used only for flags that can't be overwritten by PY_CFLAGS_NODIST, which in my opinion, is not very useful in the context of just adding extra flags. Commit adding the variable to Python 2.5: https://github.com/python/cpython/commit/08cd598c2145d00f1517c93cabf80a5d7d2a4bc0 "EXTRA_CFLAGS has been introduced as an environment variable to hold compiler flags that change binary compatibility" Apparently it was added in order to avoid using the OPT variable for the various debug builds described in https://github.com/python/cpython/blob/master/Misc/SpecialBuilds.txt On another note this flag will get passed down to distutils, so if it was used for building the interpreter, C extensions compiled by users will also inherit it. Honestly I am not sure what the best solution would be here. If the various sub-debug special builds are still relevant and they stack, by doing for example $ make CFLAGS_NODIST="-DPy_TRACE_REFS" EXTRA_CFLAGS="-DPy_REF_DEBUG" then the issue can be closed, and the documentation can be more explicit that the EXTRA_CFLAGS is to be used only for the special builds. If the EXTRA_CFLAGS can also be used for adding our own flags, then the flag handling needs to change to take this into account. [0] https://github.com/python/cpython/blob/master/setup.py#L85 [1] https://github.com/python/cpython/blob/master/Makefile.pre.in#L115 [2] https://github.com/python/cpython/blob/master/Makefile.pre.in#L97 -- nosy: +brett.cannon ___ Python tracker <https://bugs.python.org/issue37631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37096] Add large-file tests for modules using sendfile(2)
Charalampos Stratakis added the comment: It seems that the -uall argument is passed to regrtest invocation for the buildbot run [0] which invokes the largefile tests (including all the resource intensive tests). However when configure is run you can see: checking whether to enable large file support... no [0] https://github.com/python/cpython/blob/master/Lib/test/libregrtest/cmdline.py#L81 -- ___ Python tracker <https://bugs.python.org/issue37096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37096] Add large-file tests for modules using sendfile(2)
Charalampos Stratakis added the comment: After this change I get some disk space issues on the Fedora rawhide buildbot for the clang installed build only (and strangely enough not for the other jobs). There are currently around 9GB of free space there: https://buildbot.python.org/all/#/builders/188/builds/1110 == ERROR: test_tofromfile (test.test_array.DoubleTest) -- Traceback (most recent call last): File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.clang-installed/build/target/lib/python3.9/test/test_array.py", line 374, in test_tofromfile f.close() OSError: [Errno 28] No space left on device -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue37096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38269] AMD64 Debian PGO 3.x, AMD64 Clang UBSan 2.7 buildbots: No space left on device
Charalampos Stratakis added the comment: It's already explained that the build directories are duplicated, however it could be more verbose indeed. When a config is being used alongside a config which inherits from the previous one, then buildbot aborts with an error as it tries to compile cpython in the same directory. -- ___ Python tracker <https://bugs.python.org/issue38269> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38269] AMD64 Debian PGO 3.x, AMD64 Clang UBSan 2.7 buildbots: No space left on device
Charalampos Stratakis added the comment: Yep that was my change as some jobs couldn't be run on the same worker due to the configs using the same directory. -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue38269> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38239] test_gdb fails on AMD64 Fedora Stable LTO 3.8 and AMD64 RHEL8 LTO 3.x: Unexpected gdb output
Change by Charalampos Stratakis : -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue38239> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17258] multiprocessing.connection challenge implicitly uses MD5
Change by Charalampos Stratakis : -- pull_requests: +15857 pull_request: https://github.com/python/cpython/pull/16264 ___ Python tracker <https://bugs.python.org/issue17258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38132] Simplify hashlib implementation
Charalampos Stratakis added the comment: Yes that would be awesome! Indeed hashlib has been a bit of a pain to work with especially with FIPS related modifications, simplifying it would help a ton. -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue38132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38033] Use After Free: PyObject_Free (valgrind)
Charalampos Stratakis added the comment: Another thing also, is to be sure to utilize the python's suppression file by adding the --suppressions= to valgrind's command line invocation. -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue38033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37631] EXTRA_CFLAGS get overrided by CFLAGS_NODIST
Charalampos Stratakis added the comment: I agree that documenting the flags is quite important, I've had a hard time trying to figure out how to implement the LDFLAGS_NODIST, and the change still broke macos builds (luckily it was fixed swiftly). Nevertheless, this is still a bug which should be addressed. On another note, where would be the best place to start documenting those flags? Makefile, the python docs, somewhere else? -- ___ Python tracker <https://bugs.python.org/issue37631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37630] Investigate replacing SHA3 code with OpenSSL
Change by Charalampos Stratakis : -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue37630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9216] FIPS support for hashlib
Charalampos Stratakis added the comment: Providing a simple keyword as a workaround for bypassing the FIPS restrictions, could potentially violate the standard, as there is no way from the python side to verify if the code in question is used for security purposes or not. Thus I would close this issue as wontfix. Application distributors who would like their code to work under FIPS should preferably use the FIPS approved ciphers. -- ___ Python tracker <https://bugs.python.org/issue9216> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37631] EXTRA_CFLAGS get overrided by CFLAGS_NODIST
Charalampos Stratakis added the comment: Could you provide more info, e.g. comparison between the proper and the erroneous output, as well as what it affects (test_gdb if I recall correctly)? -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue37631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37382] Improve conditional check for test_gdb
Charalampos Stratakis added the comment: There is a fleet of buildbots with a variety og versions of gcc and gdb, so if a change like that is pushed, all the fleet has to be monitored for potential failures, as there are many older OSes supported there. -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue37382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36742] CVE-2019-10160: urlsplit NFKD normalization vulnerability in user:password@
Change by Charalampos Stratakis : -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue36742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37081] Test with OpenSSL 1.1.1c
Charalampos Stratakis added the comment: Also those failures are recorded on the Fedora buildbot, it seems to be happening randomly: https://buildbot.python.org/all/#/workers/32 -- ___ Python tracker <https://bugs.python.org/issue37081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37081] Test with OpenSSL 1.1.1c
Charalampos Stratakis added the comment: Reported here: https://bugs.python.org/issue35998 -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue37081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)
Charalampos Stratakis added the comment: A small clarification on the differences of those two CVE's. CVE-2019-9740: CLRF sequences are not properly handled in python built-in modules urllib/urllib2 in the query part of the url parameter of urlopen() function CVE-2019-9947: CLRF sequences are not properly handled in python built-in modules urllib/urllib2 in the path part of the url parameter of urlopen() function -- nosy: +cstratak -hroncok, koobs, ned.deily versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue30458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35907] Unnecessary URL scheme exists to allow file:// reading file in urllib
Change by Charalampos Stratakis : -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue35907> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36659] distutils UnixCCompiler: Remove standard library path from rpath
Change by Charalampos Stratakis : -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue36659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36276] Python urllib CRLF injection vulnerability
Change by Charalampos Stratakis : -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue36276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36367] tokenizer.c memory leak in case of realloc failure
New submission from Charalampos Stratakis : In tokenizer.c we have those lines of code [0]: if (final_length < needed_length && final_length) /* should never fail */ buf = PyMem_REALLOC(buf, final_length); return buf; If however that realloc fails, the memory allocated initially for buf, will not be freed. [0] https://github.com/python/cpython/blob/master/Parser/tokenizer.c#L652 -- messages: 338375 nosy: cstratak priority: normal severity: normal status: open title: tokenizer.c memory leak in case of realloc failure ___ Python tracker <https://bugs.python.org/issue36367> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on Fedora 29
Charalampos Stratakis added the comment: On my system with openssl 1.1.1b, by reducing the PAYLOAD_SIZE the test passes successfully. It starts failing when it's bigger than 1024 * 95 -- ___ Python tracker <https://bugs.python.org/issue35998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18368] PyOS_StdioReadline() leaks memory when realloc() fails
Change by Charalampos Stratakis : -- pull_requests: +12305 ___ Python tracker <https://bugs.python.org/issue18368> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36292] Coverity scan: Resource leaks in longobject.c
Charalampos Stratakis added the comment: This code is unreachable. Will mark it as such. -- ___ Python tracker <https://bugs.python.org/issue36292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36292] Coverity scan: Resource leaks in longobject.c
Change by Charalampos Stratakis : -- versions: -Python 2.7, Python 3.7 ___ Python tracker <https://bugs.python.org/issue36292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36292] Coverity scan: Resource leaks in longobject.c
Change by Charalampos Stratakis : -- keywords: +patch pull_requests: +12304 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36292] Coverity scan: Resource leaks in longobject.c
New submission from Charalampos Stratakis : The coverity scan was run on python2, however the same defect seems to exist in python3 as well. Error: RESOURCE_LEAK (CWE-772): [#def69] Python-2.7.15/Objects/longobject.c:3793: alloc_fn: Storage is returned from allocation function "_PyLong_New". Python-2.7.15/Objects/longobject.c:76:5: alloc_fn: Storage is returned from allocation function "PyObject_Malloc". Python-2.7.15/Objects/obmalloc.c:982:5: alloc_fn: Storage is returned from allocation function "malloc". Python-2.7.15/Objects/obmalloc.c:982:5: return_alloc_fn: Directly returning storage allocated by "malloc". Python-2.7.15/Objects/longobject.c:76:5: identity_transfer: Passing "(PyVarObject *)PyObject_Malloc((size_t)(PyLong_Type.tp_basicsize + size * PyLong_Type.tp_itemsize + 7L & 0xfff8L))" as argument 1 to function "PyObject_InitVar", which returns that argument. Python-2.7.15/Objects/object.c:237:5: return_parm: Returning parameter "op". Python-2.7.15/Objects/longobject.c:76:5: return_alloc_fn: Directly returning storage allocated by "PyObject_InitVar". Python-2.7.15/Objects/longobject.c:3793: var_assign: Assigning: "z" = storage returned from "_PyLong_New(size_a)". Python-2.7.15/Objects/longobject.c:3797: var_assign: Assigning: "a" = "z". Python-2.7.15/Objects/longobject.c:3847: leaked_storage: Variable "z" going out of scope leaks the storage it points to. Python-2.7.15/Objects/longobject.c:3847: leaked_storage: Returning without freeing "a" leaks the storage that it points to. 3845| default: 3846| PyErr_BadArgument(); 3847|-> return NULL; 3848| } 3849| Error: RESOURCE_LEAK (CWE-772): [#def70] Python-2.7.15/Objects/longobject.c:3793: alloc_fn: Storage is returned from allocation function "_PyLong_New". Python-2.7.15/Objects/longobject.c:76:5: alloc_fn: Storage is returned from allocation function "PyObject_Malloc". Python-2.7.15/Objects/obmalloc.c:982:5: alloc_fn: Storage is returned from allocation function "malloc". Python-2.7.15/Objects/obmalloc.c:982:5: return_alloc_fn: Directly returning storage allocated by "malloc". Python-2.7.15/Objects/longobject.c:76:5: identity_transfer: Passing "(PyVarObject *)PyObject_Malloc((size_t)(PyLong_Type.tp_basicsize + size * PyLong_Type.tp_itemsize + 7L & 0xfff8L))" as argument 1 to function "PyObject_InitVar", which returns that argument. Python-2.7.15/Objects/object.c:237:5: return_parm: Returning parameter "op". Python-2.7.15/Objects/longobject.c:76:5: return_alloc_fn: Directly returning storage allocated by "PyObject_InitVar". Python-2.7.15/Objects/longobject.c:3793: var_assign: Assigning: "z" = storage returned from "_PyLong_New(size_a)". Python-2.7.15/Objects/longobject.c:3797: var_assign: Assigning: "a" = "z". Python-2.7.15/Objects/longobject.c:3820: var_assign: Assigning: "z" = "a". Python-2.7.15/Objects/longobject.c:3820: var_assign: Assigning: "b" = "z". Python-2.7.15/Objects/longobject.c:3847: leaked_storage: Variable "z" going out of scope leaks the storage it points to. Python-2.7.15/Objects/longobject.c:3847: leaked_storage: Returning without freeing "b" leaks the storage that it points to. 3845| default: 3846| PyErr_BadArgument(); 3847|-> return NULL; 3848| } 3849| -- components: Interpreter Core messages: 337933 nosy: cstratak priority: normal severity: normal status: open title: Coverity scan: Resource leaks in longobject.c versions: Python 2.7, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue36292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36291] [2.7] Coverity Scan: Modules/_json.c: leaked_storage: Variable "numstr" going out of scope leaks the storage it points to.
Change by Charalampos Stratakis : -- keywords: +patch pull_requests: +12301 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36291] [2.7] Coverity Scan: Modules/_json.c: leaked_storage: Variable "numstr" going out of scope leaks the storage it points to.
New submission from Charalampos Stratakis : Coverity reports a leak within the json module: Error: RESOURCE_LEAK (CWE-772): [#def26] Python-2.7.15/Modules/_json.c:1367: alloc_fn: Storage is returned from allocation function "PyString_FromStringAndSize". Python-2.7.15/Objects/stringobject.c:88:5: alloc_fn: Storage is returned from allocation function "PyObject_Malloc". Python-2.7.15/Objects/obmalloc.c:982:5: alloc_fn: Storage is returned from allocation function "malloc". Python-2.7.15/Objects/obmalloc.c:982:5: return_alloc_fn: Directly returning storage allocated by "malloc". Python-2.7.15/Objects/stringobject.c:88:5: var_assign: Assigning: "op" = "PyObject_Malloc(37UL + size)". Python-2.7.15/Objects/stringobject.c:111:5: return_alloc: Returning allocated memory "op". Python-2.7.15/Modules/_json.c:1367: var_assign: Assigning: "numstr" = storage returned from "PyString_FromStringAndSize([start], idx - start)". Python-2.7.15/Modules/_json.c:1379: leaked_storage: Variable "numstr" going out of scope leaks the storage it points to. 1377|NULL, NULL); 1378| if (d == -1.0 && PyErr_Occurred()) 1379|-> return NULL; 1380| rval = PyFloat_FromDouble(d); 1381| } -- components: Extension Modules messages: 337927 nosy: cstratak priority: normal severity: normal status: open title: [2.7] Coverity Scan: Modules/_json.c: leaked_storage: Variable "numstr" going out of scope leaks the storage it points to. versions: Python 2.7 ___ Python tracker <https://bugs.python.org/issue36291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36289] [2.7] Coverity scan: Modules/_io/bufferedio.c leaked_storage: Variable "data" going out of scope leaks the storage it points to.
Change by Charalampos Stratakis : -- keywords: +patch pull_requests: +12300 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36289] [2.7] Coverity scan: Modules/_io/bufferedio.c leaked_storage: Variable "data" going out of scope leaks the storage it points to.
New submission from Charalampos Stratakis :
Coverity scan reports this for bufferedio.c :
Error: RESOURCE_LEAK (CWE-772): [#def23]
Python-2.7.15/Modules/_io/bufferedio.c:1353: alloc_fn: Storage is returned from
allocation function "PyString_FromStringAndSize".
Python-2.7.15/Objects/stringobject.c:88:5: alloc_fn: Storage is returned from
allocation function "PyObject_Malloc".
Python-2.7.15/Objects/obmalloc.c:982:5: alloc_fn: Storage is returned from
allocation function "malloc".
Python-2.7.15/Objects/obmalloc.c:982:5: return_alloc_fn: Directly returning
storage allocated by "malloc".
Python-2.7.15/Objects/stringobject.c:88:5: var_assign: Assigning: "op" =
"PyObject_Malloc(37UL + size)".
Python-2.7.15/Objects/stringobject.c:111:5: return_alloc: Returning allocated
memory "op".
Python-2.7.15/Modules/_io/bufferedio.c:1353: var_assign: Assigning: "data" =
storage returned from "PyString_FromStringAndSize(self->buffer + self->pos,
current_size)".
Python-2.7.15/Modules/_io/bufferedio.c:1366: leaked_storage: Variable "data"
going out of scope leaks the storage it points to.
1364| if (res == NULL) {
1365| Py_DECREF(chunks);
1366|-> return NULL;
1367| }
1368| Py_CLEAR(res);
--
components: Extension Modules
messages: 337923
nosy: cstratak
priority: normal
severity: normal
status: open
title: [2.7] Coverity scan: Modules/_io/bufferedio.c leaked_storage: Variable
"data" going out of scope leaks the storage it points to.
versions: Python 2.7
___
Python tracker
<https://bugs.python.org/issue36289>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36212] [2.7] Coverity scan: Modules/_hotshot.c , Variable "s1" going out of scope leaks the storage it points to.
Change by Charalampos Stratakis : -- keywords: +patch pull_requests: +12298 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36262] Coverity scan: Python/dtoa.c resource leak
Change by Charalampos Stratakis : -- nosy: +mark.dickinson, vstinner ___ Python tracker <https://bugs.python.org/issue36262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36262] Coverity scan: Python/dtoa.c resource leak
New submission from Charalampos Stratakis : Coverity report on dtoa.c. It was run on python2 but the same code resides on python3. Error: RESOURCE_LEAK (CWE-772): [#def89] Python-2.7.15/Python/dtoa.c:1846: alloc_fn: Storage is returned from allocation function "s2b". Python-2.7.15/Python/dtoa.c:526:9: alloc_fn: Storage is returned from allocation function "multadd". Python-2.7.15/Python/dtoa.c:479:13: alloc_fn: Storage is returned from allocation function "Balloc". Python-2.7.15/Python/dtoa.c:371:13: alloc_fn: Storage is returned from allocation function "PyMem_Malloc". Python-2.7.15/Objects/object.c:2348:5: alloc_fn: Storage is returned from allocation function "malloc". Python-2.7.15/Objects/object.c:2348:5: return_alloc_fn: Directly returning storage allocated by "malloc". Python-2.7.15/Python/dtoa.c:371:13: var_assign: Assigning: "rv" = "PyMem_Malloc(len * 8UL)". Python-2.7.15/Python/dtoa.c:379:5: return_alloc: Returning allocated memory "rv". Python-2.7.15/Python/dtoa.c:479:13: var_assign: Assigning: "b1" = "Balloc(b->k + 1)". Python-2.7.15/Python/dtoa.c:486:13: var_assign: Assigning: "b" = "b1". Python-2.7.15/Python/dtoa.c:491:5: return_alloc: Returning allocated memory "b". Python-2.7.15/Python/dtoa.c:526:9: var_assign: Assigning: "b" = "multadd(b, 10, *s++ - 48)". Python-2.7.15/Python/dtoa.c:530:5: return_alloc: Returning allocated memory "b". Python-2.7.15/Python/dtoa.c:1846: var_assign: Assigning: "bd0" = storage returned from "s2b(s0, nd0, nd, y)". Python-2.7.15/Python/dtoa.c:2249: leaked_storage: Variable "bd0" going out of scope leaks the storage it points to. 2247| 2248| undfl: 2249|-> return sign ? -0.0 : 0.0; 2250| 2251| ovfl: Error: RESOURCE_LEAK (CWE-772): [#def90] Python-2.7.15/Python/dtoa.c:2006: alloc_fn: Storage is returned from allocation function "diff". Python-2.7.15/Python/dtoa.c:952:5: alloc_fn: Storage is returned from allocation function "Balloc". Python-2.7.15/Python/dtoa.c:371:13: alloc_fn: Storage is returned from allocation function "PyMem_Malloc". Python-2.7.15/Objects/object.c:2348:5: alloc_fn: Storage is returned from allocation function "malloc". Python-2.7.15/Objects/object.c:2348:5: return_alloc_fn: Directly returning storage allocated by "malloc". Python-2.7.15/Python/dtoa.c:371:13: var_assign: Assigning: "rv" = "PyMem_Malloc(len * 8UL)". Python-2.7.15/Python/dtoa.c:379:5: return_alloc: Returning allocated memory "rv". Python-2.7.15/Python/dtoa.c:952:5: var_assign: Assigning: "c" = "Balloc(a->k)". Python-2.7.15/Python/dtoa.c:962:5: var_assign: Assigning: "xc" = "c". Python-2.7.15/Python/dtoa.c:996:5: return_alloc: Returning allocated memory "c". Python-2.7.15/Python/dtoa.c:2006: var_assign: Assigning: "delta" = storage returned from "diff(bb, bd)". Python-2.7.15/Python/dtoa.c:2016: noescape: Resource "delta" is not freed or pointed-to in "cmp". Python-2.7.15/Python/dtoa.c:890:13: noescape: "cmp(Bigint *, Bigint *)" does not free or save its parameter "a". Python-2.7.15/Python/dtoa.c:2129: noescape: Resource "delta" is not freed or pointed-to in "ratio". Python-2.7.15/Python/dtoa.c:1179:15: noescape: "ratio(Bigint *, Bigint *)" does not free or save its parameter "a". Python-2.7.15/Python/dtoa.c:2249: leaked_storage: Variable "delta" going out of scope leaks the storage it points to. 2247| 2248| undfl: 2249|-> return sign ? -0.0 : 0.0; 2250| 2251| ovfl: -- components: Interpreter Core messages: 337668 nosy: cstratak priority: normal severity: normal status: open title: Coverity scan: Python/dtoa.c resource leak versions: Python 2.7, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue36262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36212] [2.7] Coverity scan: Modules/_hotshot.c , Variable "s1" going out of scope leaks the storage it points to.
New submission from Charalampos Stratakis : Coverity scan reports a leak on _hotshot.c: Python-2.7.15/Modules/_hotshot.c:442: alloc_arg: "unpack_string" allocates memory that is stored into "s1". Python-2.7.15/Modules/_hotshot.c:329:5: alloc_fn: Storage is returned from allocation function "PyString_FromStringAndSize". Python-2.7.15/Objects/stringobject.c:88:5: alloc_fn: Storage is returned from allocation function "PyObject_Malloc". Python-2.7.15/Objects/obmalloc.c:982:5: alloc_fn: Storage is returned from allocation function "malloc". Python-2.7.15/Objects/obmalloc.c:982:5: return_alloc_fn: Directly returning storage allocated by "malloc". Python-2.7.15/Objects/stringobject.c:88:5: var_assign: Assigning: "op" = "PyObject_Malloc(37UL + size)". Python-2.7.15/Objects/stringobject.c:111:5: return_alloc: Returning allocated memory "op". Python-2.7.15/Modules/_hotshot.c:329:5: var_assign: Assigning: "*pvalue" = "PyString_FromStringAndSize(buf, len)". Python-2.7.15/Modules/_hotshot.c:486: leaked_storage: Variable "s1" going out of scope leaks the storage it points to. 484| result = PyTuple_New(4); 485| if (result == NULL) 486|-> return NULL; 487| PyTuple_SET_ITEM(result, 0, PyInt_FromLong(what)); 488| PyTuple_SET_ITEM(result, 2, PyInt_FromLong(fileno)); -- components: Extension Modules messages: 337301 nosy: cstratak priority: normal severity: normal status: open title: [2.7] Coverity scan: Modules/_hotshot.c , Variable "s1" going out of scope leaks the storage it points to. type: resource usage versions: Python 2.7 ___ Python tracker <https://bugs.python.org/issue36212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36186] [2.7] Coverity scan: Modules/linuxaudiodev.c , fd handle is not closed.
Change by Charalampos Stratakis : -- keywords: +patch pull_requests: +12161 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36186> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36186] [2.7] Coverity scan: Modules/linuxaudiodev.c , fd handle is not closed.
New submission from Charalampos Stratakis : There are two places [0][1] in the code where NULL is returned but the fd handle is not closed. [0] https://github.com/python/cpython/blob/2.7/Modules/linuxaudiodev.c#L129 [1] https://github.com/python/cpython/blob/2.7/Modules/linuxaudiodev.c#L133 -- components: Extension Modules messages: 337131 nosy: cstratak priority: normal severity: normal status: open title: [2.7] Coverity scan: Modules/linuxaudiodev.c , fd handle is not closed. versions: Python 2.7 ___ Python tracker <https://bugs.python.org/issue36186> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36147] [2.7] Coverity scan: Modules/_ctypes/cfield.c , Variable "result" going out of scope
Change by Charalampos Stratakis : -- keywords: +patch pull_requests: +12108 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36147] [2.7] Coverity scan: Modules/_ctypes/cfield.c , Variable "result" going out of scope
Charalampos Stratakis added the comment: Also the change from PyUnicode_FromStringAndSize to PyBytes_FromStringAndSize happened here: https://bugs.python.org/issue8966 -- ___ Python tracker <https://bugs.python.org/issue36147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36147] [2.7] Coverity scan: Modules/_ctypes/cfield.c , Variable "result" going out of scope
New submission from Charalampos Stratakis : Coverity scan on python2 resulted in this error. Python-2.7.15/Modules/_ctypes/cfield.c:1297: alloc_fn: Storage is returned from allocation function "PyString_FromString". Python-2.7.15/Objects/stringobject.c:143:5: alloc_fn: Storage is returned from allocation function "PyObject_Malloc". Python-2.7.15/Objects/obmalloc.c:982:5: alloc_fn: Storage is returned from allocation function "malloc". Python-2.7.15/Objects/obmalloc.c:982:5: return_alloc_fn: Directly returning storage allocated by "malloc". Python-2.7.15/Objects/stringobject.c:143:5: var_assign: Assigning: "op" = "PyObject_Malloc(37UL + size)". Python-2.7.15/Objects/stringobject.c:164:5: return_alloc: Returning allocated memory "op". Python-2.7.15/Modules/_ctypes/cfield.c:1297: var_assign: Assigning: "result" = storage returned from "PyString_FromString((char *)ptr)". Python-2.7.15/Modules/_ctypes/cfield.c:1311: leaked_storage: Variable "result" going out of scope leaks the storage it points to. 1309| } else 1310| /* cannot shorten the result */ 1311|-> return PyString_FromStringAndSize(ptr, size); 1312| } 1313| This was fixed on python3 with https://github.com/python/cpython/commit/19b52545df898ec911c44e29f75badb902924c0b Partially backporting this change for this file should fix the issue. -- components: Extension Modules messages: 336859 nosy: cstratak, vstinner priority: normal severity: normal status: open title: [2.7] Coverity scan: Modules/_ctypes/cfield.c , Variable "result" going out of scope versions: Python 2.7 ___ Python tracker <https://bugs.python.org/issue36147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13096] ctypes: segfault with large POINTER type names
Change by Charalampos Stratakis : -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue13096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13096] ctypes: segfault with large POINTER type names
Charalampos Stratakis added the comment: It seems the python2 backport was incomplete as a PyMem_Free is missing, making buf leak. -- nosy: +cstratak ___ Python tracker <https://bugs.python.org/issue13096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13096] ctypes: segfault with large POINTER type names
Change by Charalampos Stratakis : -- pull_requests: +12107 ___ Python tracker <https://bugs.python.org/issue13096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
