[issue36534] tarfile: handling Windows (path) illegal characters in archive member names
Cristi Fati added the comment: As I see things now, there are multiple things (not necessarily related to this issue) to deal with: 1. Update *tarfile* and add *\_sanitize\_windows\_name* (name can change), that uses *pathlib.\_WindowsFlavour.reserved\_names* (or some public wrapper), and also handles control chars (pointed out by @eriksun), so that it covers as many cases as possible (I'd say all, but there's almost always one that gets away) 2. Fix *pathlib.\_WindowsFlavour.reserved\_names* 3. Apply the fix to *zipfile* as well 4. (optional) extract the sanitizing function into a common module (could be *pathlib*?) to avoid duplicates -- ___ Python tracker <https://bugs.python.org/issue36534> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36534] tarfile: handling Windows (path) illegal characters in archive member names
New submission from Cristi Fati :
Although tar is a Nix based (and mostly used) format, it gains popularity on
Win too.
As tarfile is running on Win, I think it should handle (work around) path
incompatibilities, as zipfile (`ZipFile._sanitize_windows_name`) does.
Applies to all branches.
More details on [Tarfile/Zipfile extractall() changing filename of some
files](https://stackoverflow.com/questions/55340013/tarfile-zipfile-extractall-changing-filename-of-some-files/55348443#55348443).
Regarding the current zipfile handling: it also can be improved (as it has a
small bug), for example if the archive contains 2 files ("file:" and "file_")
it won't work as expected. But this is a rare corner case.
I didn't prepare a patch, since I did so for another issue
(https://bugs.python.org/issue36247 - which I consider an ugly one),
and it wasn't well received, also it was rejected (for different reasons). If
this issue gets the green light from whomever is in charge, I'll be happy to
provide one.
--
components: Library (Lib)
messages: 339486
nosy: CristiFati
priority: normal
severity: normal
status: open
title: tarfile: handling Windows (path) illegal characters in archive member
names
type: enhancement
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue36534>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36247] zipfile - extract truncates (existing) file when bad password provided (zip encryption weakness)
Cristi Fati added the comment: Hm, I assumed that a bad password, will raise an exception (at some point). but, if it doesn't, the destination file will be overwritten (with the messed up content), which also happens now (so, no behavior change). This is trying to make wrong passwords behavior (when an exception is raised) consistent. What I can think of is that when some bytes were already extracted when the exception occurs, overwrite the existing file (if any), so at the end the faulty content will be kept (although I don't know haw this could help anyone), but in any case a 0 lengthed file is not a good option (from my PoV). Of course specifying another dir is an option, but I only see it as a workaround. -- versions: -Python 3.6 ___ Python tracker <https://bugs.python.org/issue36247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36247] zipfile - extract truncates (existing) file when bad password provided (zip encryption weakness)
Cristi Fati added the comment: Submitted: https://github.com/python/cpython/pull/12242. As a note, it applies to any Python version. -- keywords: +patch pull_requests: +12230 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36247] zipfile - extract truncates (existing) file when bad password provided (zip encryption weakness)
New submission from Cristi Fati : PKWARE encryption password pre check algorithm (relying on an 8 bits value to differentiate passwords) is insanely short. Most of the wrong passwords are filtered out by the check, but some of them aren't. For the ones in the latter category, when trying to extract an archive member, a 0 lengthed file with its name will be created on the FS (overwriting any previous version). Usecase: 1. Extract an archive member using the good password. File extracted 2. Extract the same member using a wrong password: 2.1 For most of the passwords, they will be detected and the operation cancelled 2.2 But some of them, they won't be detected (false positives), but the decryption itself will fail overwriting the file (from #1.) on FS but leaving it with 0 bytes content This is the about #2.2. More details on [[SO]: zipfile.BadZipFile: Bad CRC-32 when extracting a password protected .zip & .zip goes corrupt on extract (@CristiFati's answer)](https://stackoverflow.com/questions/54532010/zipfile-badzipfile-bad-crc-32-when-extracting-a-password-protected-zip-zip/55063500#55063500). -- components: Library (Lib) messages: 337543 nosy: CristiFati priority: normal severity: normal status: open title: zipfile - extract truncates (existing) file when bad password provided (zip encryption weakness) type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue36247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27592] FIPS_mode() and FIPS_mode_set() functions in Python (ssl)
Cristi Fati added the comment: Thank you all for chiming in (so quickly). I did this in 2013 (maybe back then the situation was different), and have successfully used it since. Regarding comments: - Alex: 1: I'm not an expert, so I'm not going to argue with it. However I thought that if it's enforced by the government (and NIST) it would make sense. Nowadays I get this feeling that when it comes to security, people tend to lose their technical common sense and implement stuff without questioning. 2: I've just read Steve Marquess's post (and a couple of others linked from it) and I'm a little bit surprised since the FIPS funcs have been added to OpenSSL stating with version 1.0.* and they're about to be removed. Anyway, there are IT mammoths that have deals with the government (big bucks deals - involving FIPS) and use OpenSSL as a cryptography and secure socket provider (personally I consider those corporations that make use of open source software in order to get millions and give nothing back, parasites). I think when OpenSSL will publicly announce the FIPS drop, they'll will have nothing to do but chip in, as it will be extremely difficult to switch to other providers (if any - I've seen Bladelogic name mentioned,I'm not sure it will cover, also for Java apps there was RSA or EMC, which is also going out of support). 3: This is a good point, since there's no other alternative (that I know of), that uses/doesn't use FIPS. - David: bug9216 - the patch from RedHat (`usedforsecurity` parameter for md5 hash), I'm using it for 3 years; I didn't encounter the 2nd one. But both apply to hashlib. Reagrding ssl, changing FIPS mode would make a difference, e.g. when creating secure connections with certificates with (now considered weak anyway) md5 hash algorithms. Thanks everyone for reviewing. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27592> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27592] FIPS_mode() and FIPS_mode_set() functions in Python (ssl)
New submission from Cristi Fati: During last years, the FIPS mode, has become more and more popular, especially in US (probably because it was "promoted" by government institutions). All OpenSSL versions (didn't check 1.0.0 or lower since they're no longer supported), have the "basic FIPS functionality", even if built without openssl-fips module. By "basic FIPS functionality", I mean the 2 functions: - `int FIPS_mode(void)` - used to get the current FIPS mode (for non FIPS openssl, it simply returns 0) - `int FIPS_mode_set(int r)` - used to set the current FIPS mode in the currently loaded libcrypto/libeay32 (for non FIPS openssl it sets the openssl error: "error:0F06D065:common libcrypto routines:FIPS_mode_set:fips mode not supported") The goal of this patch is to add the 2 functions in Python (3.4.4 source tarball) - ssl (and _ssl) module - in order to be able to control FIPS mode from within a Python process (I am aware that some platforms allow setting FIPS at a global level, but this offers more granularity). The patch is simple, for the getter it simply returns the OpenSSL function value, while for the setter it doesn't return anything but throws an exception if some error occurs. Note0 (about how do I set the error): `_setSSLError(ERR_error_string(ERR_get_error(), NULL) , 0, __FILE__, __LINE__);` as opposed to the regular way: `_setSSLError(NULL, 0, __FILE__, __LINE__);`. I didn't use the whole make_ssl_data.py mechanism because: - 1 - it binds against the OpenSSL version used at compile time - 1.1 - on Ux (where Python modules are dynamically linked to OpenSSL), if compiling against one OpenSSL version and at runtime another (newer) version which defines new functionality (and new error codes) is present, if one of those newer errors is encountered, the error message won't be as complete: "ssl.SSLError: fips mode already set (_ssl.c:3763)" as opposed to "ssl.SSLError: error:2D078072:FIPS routines:FIPS_module_mode_set:fips mode already set (_ssl.c:3763)" - 1.2 - on Win (where Python modules are statically linked to OpenSSL), there won't be such a problem. However, regarding static linking (this is not related to this post), this is not a scalable solution (now if only _ssl and _hashlib link to OpenSSL, it's __sort of__ OK, but if another one, or more will be added it won't be), so dynamic linking should be used, although that comes with its problems. 2 possible ways to solve them: - 1.2.1 - simply dynamic link to OpenSSL and at runtime it will fail importing the modules; this will happen a lot since (as opposed to Ux), I think that there's a 90%+ chance that no OpenSSL is installed on a Win machine - 1.2.2 - dynamic link to OpenSSL and also redistribute the OpenSSL dlls (although I didn't check what this would mean from licensing PoV). This would also raise the problem of precedence: which dlls should be used by default if an OpenSSL version is installed on the machine. - 2 - It is simpler (here I might be missing something). To me it seems cleaner to delegate the job to (runtime) OpenSSL instead of make_ssl_data.py and the logic from `fill_and_set_sslerror` (which could be removed in the future, I'd say). Note1: The whole thing could also be applied to hashlib (simply copy the changes from ssl.py to hashlib.py - to have as less duplicate code as possible), but since due to hashlib caching, changing the FIPS mode on the fly won't be reflected in the possibility/impossibility of using a hash (e.g. `md5`), I figured that it doesn't worth the effort. As a workaround, for someone who really needs to set it, they can do it from ssl. -- files: Python-3.4.4-ssl_fips.patch keywords: patch messages: 271006 nosy: CristiFati priority: normal severity: normal status: open title: FIPS_mode() and FIPS_mode_set() functions in Python (ssl) type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file43833/Python-3.4.4-ssl_fips.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27592> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25413] ctypes (libffi) fails to compile on Solaris X86
Cristi Fati added the comment: Hi, sorry for spamming everyone, I couldn't find a way to reply to the last message directly on #25413 (https://bugs.python.org/issue25413). Looked over the current version (from MASTER) of the file: https://github.com/libffi/libffi/blob/master/src/x86/ffi.c, and it significantly differs from the one distributed in Python 2.7.10 (and 2.7.11). For example, all the conditional macros (out of which most are Windows related) are gone. So, the patch is not (even close) compatible with the current libffi version. On Fri, Jun 10, 2016 at 8:42 PM, Matthias Klose <rep...@bugs.python.org> wrote: > > Matthias Klose added the comment: > > CristiFati, please could you check if the libffi patch is still needed with > the current upstream libffi? > > See https://github.com/libffi/libffi > > -- > > ___ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue25413> > ___ -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25413] ctypes (libffi) fails to compile on Solaris X86
New submission from Cristi Fati: 2.7.10 regression (at least compared to 2.7.3), not sure which exact version between the 2 first introduced it. Due to addition of `win32.S` in the list build on Solaris X86 (32bit which also identifies the platform as X86) fails. Attaching a patch. After applying it, compiles and runs on Solaris X86 and Windowses. -- components: ctypes files: Python-2.7.10-ux_x86_libffi.patch keywords: patch messages: 253048 nosy: CristiFati priority: normal severity: normal status: open title: ctypes (libffi) fails to compile on Solaris X86 type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file40788/Python-2.7.10-ux_x86_libffi.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23946] Invalid timestamps reported by os.stat() when Windows FILETIME structures are mistakenly reset.
New submission from Cristi Fati: In WinPE environment (at least this is where I found it, but there might be cases where this issue could be spotted in normal Windows), some folders might have some of the FILETIME structures reset (because of RAMDrive?). When the conversion between WIN style (100 * nsecs from 1601/01/01) to UX style (secs from 1970/01/01) is taking place (epoch is being substracted), it could yield invalid filetime values (that will be reported by os.stat). The attached patch simply goes around this initializing the UX timestamps to 0. It was found in Python-2.7.3, the patch is for 2.7.8, but I think it can be reproduced with all the newer versions. -- components: Interpreter Core, Windows files: Python-2.7.8-invalid_filetimes.patch keywords: patch messages: 240875 nosy: CristiFati, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Invalid timestamps reported by os.stat() when Windows FILETIME structures are mistakenly reset. type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file38985/Python-2.7.8-invalid_filetimes.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23946 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
