[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
Florian Weimer added the comment: The report/justification for the removal is simply incorrect. Linux still supports s390-*-linux-gnu in user mode. The GNU toolchain is maintained, and the glibc testsuite is in good shape. Some distributions still support s390 (31-bit) applications. Others (Fedora 24 or later, for example) no longer do so. I expect that 31-bit s390 Linux Python is really unusual these days, so removing it could still be fine, but lack of support from the GNU toolchain or the Linux kernel is not the correct justification for its removal. If you have questions about the maintenance status of various parts of the GNU toolchain, please feel free to reach out to any of the GNU lists. https://gcc.gnu.org/mailman/listinfo/gcc https://sourceware.org/mailman/listinfo/binutils https://sourceware.org/mailman/listinfo/libc-alpha -- nosy: +fweimer ___ 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
[issue44409] compile raises SyntaxError with undocumented lineno attribute None
Florian Weimer added the comment: I suppose changing the documentation to mention `None` would be possible as well, but restoring the old behavior works for me too. Thanks. -- ___ Python tracker <https://bugs.python.org/issue44409> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44409] compile raises SyntaxError with undocumented lineno attribute None
New submission from Florian Weimer :
This example results in an undocumented value None for the lineno attribute:
```
source = b"\xef\xbb\xbf#coding: utf8\nprint('\xe6\x88\x91')\n"
try:
compile(source, filename="example.py", mode="exec")
except SyntaxError as e:
print(str(e))
print(type(e.lineno))
```
Output:
```
encoding problem: utf8 with BOM
```
Seen with python3-3.9.5-2.fc33.x86_64.
python3-3.8.10-1.fc32.x86_64 used a lineno value of 0 (type int).
--
components: Parser
messages: 395740
nosy: fweimer, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: compile raises SyntaxError with undocumented lineno attribute None
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue44409>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x
Florian Weimer added the comment:
I believe you might be observing an XFS limitation in combination with a Linux
VFS bug.
On disk, XFS only supports 32-bit timestamps:
typedef struct xfs_timestamp {
__be32 t_sec; /* timestamp seconds */
__be32 t_nsec; /* timestamp nanoseconds */
} xfs_timestamp_t;
This is on the roadmap being fixed.
However, the Linux VFS code does not appear to know about this. It caches the
full 64-bit value. You only see the truncated value if it is read back from
disk:
# touch -t 01020304 /tmp/t
# ls -l /tmp/t
-rw-r--r--. 1 root root 0 Jan 2 /tmp/t
# echo 3 > /proc/sys/vm/drop_caches
# ls -l /tmp/t
-rw-r--r--. 1 root root 0 Oct 19 1949 /tmp/t
This is a bug in the Linux VFS layer.
--
nosy: +fweimer
___
Python tracker
<https://bugs.python.org/issue39460>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37154] test_utf8_mode: test_env_var() fails on AMD64 Fedora Rawhide Clang Installed 3.7
Florian Weimer added the comment: Just to be clear: glibc-all-langpacks normally contains the data from glibc-langpack-en, but a packaging bug caused removal of the /usr/lib/locale/locale-archive file during upgrades. This only applies to upgrades. New installations are fine. Details here: https://bugzilla.redhat.com/show_bug.cgi?id=1716710 -- nosy: +fweimer ___ Python tracker <https://bugs.python.org/issue37154> ___ ___ 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
Florian Weimer added the comment: Note that linking with -Wl,-rpath,/usr/lib64 (even if it's redundant) disables part of the ld.so cache on Linux. Instead, paths under /usr/lib64 are probed explicitly. This can add quite a few failing open/openat system calls to the process startup. -- ___ 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
[issue36659] distutils UnixCCompiler: Remove standard library path from rpath
Change by Florian Weimer : -- nosy: +fweimer ___ 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
[issue27987] obmalloc's 8-byte alignment causes undefined behavior
Florian Weimer added the comment: Minor correction: glibc malloc follows ABI on x86-64 and always returns a 16-byte-aligned pointer, independently of allocation size. However, other mallocs (such as jemalloc and tcmalloc) may return pointers with less alignment for allocation sizes less than 16 bytes, violating ABI. They still follow ABI for allocations of 16 bytes and more. But as you said, the distinction should not matter for Python because of the object header. Furthermore, without LTO, the compiler will not be able to detect that a pointer returned from Py_NewObject is a top-level allocation, and therefore has to be more conservative about alignment, using information from the type definitions only. -- ___ Python tracker <https://bugs.python.org/issue27987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36618] clang expects memory aligned on 16 bytes, but pymalloc aligns to 8 bytes
Florian Weimer added the comment:
The issue is related to the definition of PyCArgObject:
typedef struct tagPyCArgObject PyCArgObject;
struct tagPyCArgObject {
PyObject_HEAD
ffi_type *pffi_type;
char tag;
union {
char c;
char b;
short h;
int i;
long l;
long long q;
long double D;
double d;
float f;
void *p;
} value;
PyObject *obj;
Py_ssize_t size; /* for the 'V' tag */
};
This object must be allocated with suitable alignment (which is 16 on many
platforms), and the default Python allocator apparently provides 8-byte
alignment only on 64-bit platforms. In short, using PyObject_New with
PyCArgObject results in undefined behavior.
This issue potentially affects all compilers, not just Clang.
--
___
Python tracker
<https://bugs.python.org/issue36618>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36618] clang expects memory aligned on 16 bytes, but pymalloc aligns to 8 bytes
Change by Florian Weimer : -- nosy: +fweimer ___ Python tracker <https://bugs.python.org/issue36618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36024] ctypes: test_ctypes test_callbacks() crash on AArch64
Florian Weimer added the comment: Filed as an libffi issue: https://github.com/libffi/libffi/issues/470 -- ___ Python tracker <https://bugs.python.org/issue36024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36024] ctypes: test_ctypes test_callbacks() crash on AArch64
Florian Weimer added the comment: We believe this is a libffi bug. On certain aarch64 implementations, it is necessary to flush both the writable mapping and the executable mapping. I have a patch which I confirmed to work. -- ___ Python tracker <https://bugs.python.org/issue36024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36024] ctypes: test_ctypes test_callbacks() crash on AArch64
Change by Florian Weimer : -- nosy: +fweimer ___ Python tracker <https://bugs.python.org/issue36024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
Florian Weimer added the comment: offsets = ( 4096, 12288, 20480, 28672, 36864, 45056, 53248, 61440, 69632, 77824,) These offsets are less than 64 KiB apart. On systems with a 64 KiB page size, this will not result in a sparse file on tmpfs because the effective block size is the page size (tmpfs lives in the page cache). Red Hat Enterprise Linux uses 64 KiB pages on aarch64, ppc64, ppc64le. Only s390x and x86_64 use 4 KiB pages. -- nosy: +fweimer ___ Python tracker <https://bugs.python.org/issue35772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35752] test_buffer fails on ppc64le: memoryview pack_single() is miscompiled
Florian Weimer added the comment: No, GCC will optimize away the union. -- ___ Python tracker <https://bugs.python.org/issue35752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35752] test_buffer fails on ppc64le: memoryview pack_single() is miscompiled
Florian Weimer added the comment: We don't know yet if the GCC bug is specific to POWER. That depends on what causes it. Other targets my have double-to-float conversion instructions which hard-code the wrong rounding mode. -- ___ Python tracker <https://bugs.python.org/issue35752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35752] test_buffer fails on ppc64le: memoryview pack_single() is miscompiled
Florian Weimer added the comment: I believe this is a GCC bug, and filed <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892>. -- ___ Python tracker <https://bugs.python.org/issue35752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35752] test_buffer fails on ppc64le: memoryview pack_single() is miscompiled
Change by Florian Weimer : -- nosy: +fweimer ___ Python tracker <https://bugs.python.org/issue35752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
Florian Weimer added the comment: I wouldn't bother with POSIX_SPAWN_USEVFORK on GNU/Linux. Current versions of glibc always use a vfork-style clone call, so there would be a difference on older versions only. But there, the vfork code has subtle bugs, so using POSIX_SPAWN_USEVFORK there is not a good idea, either. -- nosy: +fweimer ___ Python tracker <https://bugs.python.org/issue34663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33312] ubsan undefined behavior sanitizer flags struct _dictkeysobject (PyDictKeysObj)
Florian Weimer <fwei...@redhat.com> added the comment: Why does the code even need the flexible struct member? If you use the surrounding backing store directly, the aliasing issue disappears if the backing store is untyped memory (if not, you have the aliasing problem with the rest of the struct anyway). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27987] obmalloc's 8-byte alignment causes undefined behavior
Florian Weimer <fwei...@redhat.com> added the comment: This bug causes miscompilation of Python 2.7 by GCC 8 on x86-64 (with no sanitizers enabled, just compiler optimization). I think this is a fairly conservative way for papering over the issue: https://mail.python.org/pipermail/python-dev/2018-January/152011.html -- nosy: +fweimer ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27987] obmalloc's 8-byte alignment causes undefined behavior
Change by Florian Weimer <fwei...@redhat.com>: -- versions: +Python 2.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31912] PyMem_Malloc() should guarantee alignof(max_align_t)
Florian Weimer <fwei...@redhat.com> added the comment: max_align_t is a bit of a kitchen sink and will specify larger and larger alignment in the future, e.g. 32-byte alignment for a complex _Float128 type (a pair of two _Float128 variables). The alignment is also not generally useful for allocations whose size is smaller than the alignment. (Many mallocs do not follow the C standard and do not provide 16-byte alignment when 8 bytes are allocated, although alignof(max_align_t) is 16.) -- nosy: +fweimer ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31912> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31343] Include major(), minor(), makedev() from sysmacros
Change by Florian Weimer <fwei...@redhat.com>: -- nosy: +fweimer ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30013] Compiler warning in Modules/posixmodule.c
Change by Florian Weimer <fwei...@redhat.com>: -- nosy: +fweimer ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names
Florian Weimer added the comment: * pattern is replace with '[^.]+' regex, so I may not cause the exponential complexity issue. (I didn't check.) A possessive quantifier might also help, that is [^.]+?. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names
Florian Weimer added the comment: Antoine, support for OpenSSL host name matching is quite new: http://www.openssl.org/docs/crypto/X509_check_host.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names
Florian Weimer added the comment: OpenSSL supports only a single wildcard character. In my tests, I used a host name like .example.org, and a dNSName like a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*.example.org. Quadratic behavior wouldn't be too bad because the host name is necessarily rather short (more than 255 characters will not pass through DNS). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names
Florian Weimer added the comment: The host name is looked up to get the IP address to connect to. The lookup will fail if the host name is longer than 255 characters, and the crafted certificate is never retrieved. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17980] ssl.match_hostname() trips over crafted wildcard names
New submission from Florian Weimer: If the name in the certificate contains many * characters, matching the compiled regular expression against the host name can take a very long time. Certificate validation happens before host name checking, so I think this is a minor issue only because it can only be triggered in cooperation with a CA (which seems unlikely). The fix is to limit the number of * wildcards to a reasonable maximum (perhaps even 1). -- components: Library (Lib) messages: 189280 nosy: fweimer priority: normal severity: normal status: open title: ssl.match_hostname() trips over crafted wildcard names versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10441] some stdlib modules need to be updated to handle SSL certificate validation
Changes by Florian Weimer fwei...@redhat.com: -- nosy: +fweimer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Changes by Florian Weimer fwei...@redhat.com: -- nosy: +fweimer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7672] _ssl module overwrites existing thread safety callbacks
Changes by Florian Weimer fwei...@redhat.com: -- nosy: +fweimer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8106] SSL session management
Changes by Florian Weimer fwei...@redhat.com: -- nosy: +fweimer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8106 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default
Changes by Florian Weimer fwei...@redhat.com: -- nosy: +fweimer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13647] Python SSL stack doesn't securely validate certificate (as client)
Changes by Florian Weimer fwei...@redhat.com: -- nosy: +fweimer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13647 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13655] Python SSL stack doesn't have a default CA Store
Changes by Florian Weimer fwei...@redhat.com: -- nosy: +fweimer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13655 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13747] ssl_version documentation error
Changes by Florian Weimer fwei...@redhat.com: -- nosy: +fweimer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13747 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13403] Option for XMLPRC Server to support HTTPS
Changes by Florian Weimer fwei...@redhat.com: -- nosy: +fweimer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13403 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13747] ssl_version documentation error
Florian Weimer added the comment: OpenSSL cross-version updates are sometimes difficult because they invalidate certifications. Updating Python to SSLv23 with SSL_OP_NO_SSLv2 is comparatively easy and also much less riskier. Shall I submit a patch which changes the default? I would also like to restrict the cipher suites to strong ones plus RC4, so that Python code isn't forced to set cipher preferences. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13747 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17347] bsddb._openDBEnv() should not touch current directory
New submission from Florian Weimer:
This code:
def _openDBEnv(cachesize):
e = db.DBEnv()
if cachesize is not None:
if cachesize = 20480:
e.set_cachesize(0, cachesize)
else:
raise error, cachesize must be = 20480
e.set_lk_detect(db.DB_LOCK_DEFAULT)
e.open('.', db.DB_PRIVATE | db.DB_CREATE | db.DB_THREAD | db.DB_INIT_LOCK |
db.DB_INIT_MPOOL)
return e
causes Berkeley DB to read the DB_CONFIG file from the current directory, which
may have unexpected side effects. Unfortunately, Berkeley DB still reads
./DB_CONFIG even if the first argument to DBEnv.open() is None/NULL, so the
only way to suppress this behavior seems a non-existing or known-to-by-empty
directory (such as /var/empty).
--
components: Extension Modules
messages: 183430
nosy: fweimer
priority: normal
severity: normal
status: open
title: bsddb._openDBEnv() should not touch current directory
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17347
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8085] PyObject_GC_VarNew should be PyObject_GC_NewVar
New submission from Florian Weimer f...@deneb.enyo.de: The manual mentions the wrong C function (Var and New are transposed). -- assignee: georg.brandl components: Documentation messages: 100580 nosy: fw, georg.brandl severity: normal status: open title: PyObject_GC_VarNew should be PyObject_GC_NewVar versions: Python 2.6, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4408] re.compile(regexp).groups not documented
New submission from Florian Weimer [EMAIL PROTECTED]:
This does result in the expected result 2:
re.compile('(.)(.)').groups
But as far as I can see, the groups property is missing from the HTML
documentation. Please clarify if this an internal interface, or a
documentation oversight.
--
components: Regular Expressions
messages: 76321
nosy: fw
severity: normal
status: open
title: re.compile(regexp).groups not documented
versions: Python 2.5.3
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4408
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
