[issue23262] webbrowser module broken with Firefox 36+

[Oleg Broytman]

Oleg Broytman added the comment:

> I'm not sure that we can break the compatibility with old browser

I agree with this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23218] Modernize the IDLE Find/Replace/Find in Files dialogs

[Al Sweigart]

Al Sweigart added the comment:

*Bump* Just wanted to bring attention to this issue. We could keep "Regular 
expression" instead of "Regex" for the label (Sublime Text and other editors 
have "Regular expression")

I think Mark's patch would be better over mine.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28617] Why isn't "in" called a comparison operation?

[Raymond Hettinger]

Raymond Hettinger added the comment:

newpatch.diff looks fine.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28524] Set default argument of logging.disable() to logging.CRITICAL

[Al Sweigart]

Al Sweigart added the comment:

Setting up different configurations for dev/prod is a bit more complicated than 
I'd like for most projects. I'd instead just call 
logging.disable(logging.CRITICAL).

The entire point of this is just for the convenience of being able to disable 
logging messages by calling logging.disable() instead of 
logging.disable(logging.CRITICAL).

It's a two-line change, backwards compatible, and (imo) a sensible default. You 
call logging.disable() expecting it to disable logging. You might want to 
disable a lower level, but as the Google search shows, most people just want to 
disable all logging period.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python

[STINNER Victor]

STINNER Victor added the comment:

Antoine Pitrou added the comment:
>> Do you mean comparison between current Python with PGO and patched
>> Python without PGO?
>
> Yes.

Oh ok, sure. I will try to run these 2 benchmarks.

>>> Ubuntu 14.04 is old, and I don't think this is something we should worry 
>>> about.
>>
>> Well, it's a practical issue for me to run benchmarks for speed.python.org.
>
> Why isn't the OS updated on that machine?

I am not sure that I want to use PGO compilation to run benchmarks.
Last time I checked, I noticed performance differences between two
compilations. PGO compilation doesn't seem 100% deterministic.

Maybe PGO compilation is fine when you build Python to create a Linux
package. But to get reliable benchmarks, I'm not sure that it's a good
idea.

I'm still running benchmarks on Python recompiled many times using
different compiler options, to measure the impact of the compiler
options (especially LTO and/or PGO) on the benchmark stability.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28621] Refactor duplicate code calculating digit's bit length

[SilentGhost]

Changes by SilentGhost :


--
nosy: +mark.dickinson
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le 05/11/2016 à 16:37, STINNER Victor a écrit :
> 
> Antoine Pitrou added the comment:
>> Can you compare against a PGO build?
> 
> Do you mean comparison between current Python with PGO and patched
> Python without PGO?

Yes.

>> Ubuntu 14.04 is old, and I don't think this is something we should worry 
>> about.
> 
> Well, it's a practical issue for me to run benchmarks for speed.python.org.

Why isn't the OS updated on that machine?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26935] android: test_os fails

[Xavier de Gaye]

Xavier de Gaye added the comment:

New patch. Thanks for the review Martin!

--
Added file: http://bugs.python.org/file45368/test_urandom_fd_reopened_3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28621] Refactor duplicate code calculating digit's bit length

[Adrian Wielgosik]

Changes by Adrian Wielgosik :


--
keywords: +patch
Added file: http://bugs.python.org/file45367/bit_length.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28621] Refactor duplicate code calculating digit's bit length

[Adrian Wielgosik]

New submission from Adrian Wielgosik:

The attached patch uses an existing function bits_in_digit() in two other 
functions:

- in long_bit_length() - it already had identical logic
- in _PyLong_NumBits() - it used a naive, slower way of calculating bit length, 
so as an added bonus the patch speeds it up a bit. It's visible in float-long 
comparison microbenchmark:

$ ./old -m timeit "1 == 1.0"
500 loops, best of 5: 55 nsec per loop

$ ./new -m timeit "1 == 1.0"
500 loops, best of 5: 52.3 nsec per loop

$ ./old -m timeit "12345678 == 12345678.0"
500 loops, best of 5: 70.4 nsec per loop

$ ./new -m timeit "12345678 == 12345678.0"
500 loops, best of 5: 53.5 nsec per loop

--
components: Interpreter Core
messages: 280123
nosy: Adrian Wielgosik
priority: normal
severity: normal
status: open
title: Refactor duplicate code calculating digit's bit length
type: performance
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28563] Arbitrary code execution in gettext.c2py

[Xiang Zhang]

Xiang Zhang added the comment:

Christian, I think our patches are quite similar in function. They only allow 
limited tokens. 

> I consider it a superior solution and a fix for more generic attacks

Mine now still allows **. But it can be easily fixed.

But both our patches still translate a C expression to Python and still suffer 
from nested ternary operator and different semantics between C and Python, e.g. 
(2==2==2 as Serhiy notes). :-( I plan to try a simple parser.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28542] document cross compilation

[Xavier de Gaye]

Xavier de Gaye added the comment:

Yes, I was not aware of DESTDIR. The 2.7 README contains also useful 
information on the build process, for example about some use cases of the 
'*shared*' entries in the Setup files (for when setup.py cannot detect/build an 
extension module) or about the '*static' entries (to be able to profile 
extension modules). It also explains Setup.local whereas the only information 
on Setup.local in the Python3 documentation, is restricted to 
https://docs.python.org/3/extending/extending.html#compilation-and-linkage :(

There is also a lot of noise in the 2.7 README, this possibly explains the 
trimming. Maybe the cross-build section in the 3.6 README could be a link to a 
new build section in the documentation ?

> --prefix etc are already mentioned in “./configure --help”

The documentation on sys.prefix and sys.exec_prefix gives details about where 
go which files which is useful when trying to figure out where to copy the 
files on the target after a cross-build.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28563] Arbitrary code execution in gettext.c2py

[Christian Heimes]

Christian Heimes added the comment:

Argh, sorry. I meant to write "The gettext module might be vulnerable to more 
than f-string attacks.".

May I suggest that you have a look at my old patch? It uses an AST visitor to 
inspect the AST of a gettext plural expression. It allows only a limited set of 
AST types as well as limited amount of expressions. I consider it a superior 
solution and a fix for more generic attacks.

I haven't tested my patch with f-strings yet. It either refuses f-strings 
FormattedValue already or can be easily modified to reject it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28563] Arbitrary code execution in gettext.c2py

[Carl Ekerot]

Carl Ekerot added the comment:

> The gettext module might be vulnerable to f-string attacks

It is. See the example in the first comment:

   gettext.c2py('f"{os.system(\'sh\')}"')(0)

This vulnerability seems to be solved in Xiang's patch. The DoS aspect is 
interesting though, since there's no constraints against malicious use of the 
power-operator, say "9**9**9**..**9". This too would be solved by implementing 
a parser with only simple arithmetics.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1647489] zero-length match confuses re.finditer()

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28563] Arbitrary code execution in gettext.c2py

[Christian Heimes]

Christian Heimes added the comment:

The gettext module might be vulnerable to f-string attacks, too. Also see 
#18317.

--
nosy: +christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28610] Provide PDB hook to customize how to find source files

[Xavier de Gaye]

Xavier de Gaye added the comment:

This patch is an attempt at allowing the source debugging of scripts executed 
by the Python exec() function. It misses tests and documentation.

You may use it using the idiom given in the following example to avoid stepping 
into the pdb code on the first invocation of pdb.exec_script() (see the 
exec_script() doc string):

import sys

def main():
foo = 123
s = """if 1:
x = foo
x = 555
"""
exec_script(s)

if __name__ == '__main__':
if '--debug' in sys.argv[1:]:
import pdb
exec_script = pdb.exec_script
pdb.Pdb(skip=['pdb']).set_trace()
else:
exec_script = exec

main()

--
components:  -Demos and Tools
keywords: +patch
stage:  -> needs patch
versions: +Python 3.7 -Python 3.5
Added file: http://bugs.python.org/file45366/debug_script.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Moreover, I like the idea of getting a fast(er) Python even when no
advanced optimization techniques like LTO or PGO is used.

Seconded.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python

[STINNER Victor]

STINNER Victor added the comment:

Antoine Pitrou added the comment:
> Can you compare against a PGO build?

Do you mean comparison between current Python with PGO and patched
Python without PGO?

The hot attribute is ignored by GCC when PGO compilation is used.

> Ubuntu 14.04 is old, and I don't think this is something we should worry 
> about.

Well, it's a practical issue for me to run benchmarks for speed.python.org.

Moreover, I like the idea of getting a fast(er) Python even when no
advanced optimization techniques like LTO or PGO is used. At least,
it's common to build quickly Python using "./configure && make" for a
quick benchmark.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28620] Build Memory Leak

[R. David Murray]

Changes by R. David Murray :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> memory leaks in pgen build step abort build with address 
sanitizer enabled

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1647489] zero-length match confuses re.finditer()

[irdb]

Changes by irdb :


--
nosy: +irdb

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28620] Build Memory Leak

[Honor]

Honor added the comment:

Hmmm, Ok. Thanks a lot.

On Sat, Nov 5, 2016 at 4:50 PM, Xiang Zhang  wrote:

>
> Xiang Zhang added the comment:
>
> This seems a same problem as in #27780.
>
> --
> nosy: +xiang.zhang
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28620] Build Memory Leak

[Xiang Zhang]

Xiang Zhang added the comment:

This seems a same problem as in #27780.

--
nosy: +xiang.zhang

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28563] Arbitrary code execution in gettext.c2py

[Xiang Zhang]

Xiang Zhang added the comment:

> '1?2:3?4:5' -> '(2 if 1 else 3)?4:5' -> '(4 if (2 if 1 else 3) else 5'

This is not right. It's right associative so it should be

1?2:(3?4:5) -> 1?2:(4 if 3 else 5) -> 2 if 1 else (4 if 3 else 5)

> It would be nice to make c2py() working with any expressions, but if this is 
> too hard, this can be left for other issue.

Agree. But I am interested in trying.

> gettext_c2py.patch itself LGTM for fixing security issue, but tests are 
> needed.

It gets drawbacks so I don't include tests. I'll add in next try.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28620] Build Memory Leak

[Honor]

New submission from Honor:

Hi,

I am compiling python from source code with clang compiler.

as follows result:

==5284==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 11776 byte(s) in 8 object(s) allocated from:
#0 0x49ccbe (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x49ccbe)
#1 0x4c86ca (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x4c86ca)

Indirect leak of 2000 byte(s) in 3 object(s) allocated from:
#0 0x49ccbe (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x49ccbe)
#1 0x4c86ca (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x4c86ca)

Indirect leak of 898 byte(s) in 86 object(s) allocated from:
#0 0x49c9cb (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x49c9cb)
#1 0x2ad0d5405679 (/lib/x86_64-linux-gnu/libc.so.6+0x89679)

Indirect leak of 520 byte(s) in 1 object(s) allocated from:
#0 0x49c9cb (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x49c9cb)
#1 0x4cb549 (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x4cb549)

Indirect leak of 178 byte(s) in 33 object(s) allocated from:
#0 0x49c9cb (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x49c9cb)
#1 0x4c14d4 (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x4c14d4)

SUMMARY: AddressSanitizer: 15372 byte(s) leaked in 131 allocation(s).

Python version 3.5.2
Operating System: Linux y 3.13.0-24-generic  14.04 ubuntu
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)

--
messages: 280111
nosy: Stone
priority: normal
severity: normal
status: open
title: Build Memory Leak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Proposed patch marks most deprecated functions. Code is rewritten for using 
non-deprecated functions if possible. Unfortunately some deprecated function 
still are used in the code and can't be easier replaced. They are left not 
marked.

* PyEval_ReleaseLock() is used in Python/pystate.c. It can't be replaced with 
PyEval_ReleaseThread() since the latter don't accept NULL.

* Py_UNICODE (currently an alias of wchar_t) is used in a number of deprecated 
functions and bridges between deprecated and new APIs. Maybe it can be just 
replaced with wchar_t.

* Macros PyUnicode_GET_SIZE, PyUnicode_GET_DATA_SIZE, PyUnicode_AS_UNICODE, 
PyUnicode_AS_DATA, functions PyUnicode_AsUnicode and PyUnicode_AsUnicodeAndSize 
are used in a number of places. They can't be easily replaced with wchar-based 
functions since they return a borrowed reference to cached representation.

* PyUnicode_FromUnicode, PyUnicode_EncodeDecimal and 
PyUnicode_TransformDecimalToASCII are used only in Modules/_testcapimodule.c. I 
think we should write tests for modern APIs and eliminate tests for deprecated 
APIs. Or temporary silence compiler warning in test functions.

* _PyUnicode_ToLowercase, _PyUnicode_ToUppercase and corresponding public 
macros Py_UNICODE_TOLOWER and Py_UNICODE_TOUPPER are used in Modules/_sre.c 
(this is a bug in regex implementation). The problem is that more modern 
functions _PyUnicode_ToLowerFull and _PyUnicode_ToUpperFull is a private API.

All these cases needs separate issues.

--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45365/mark-deprecated-functions.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28619] [Patch] Stop using inet_ntoa() when possible.

[Ed Schouten]

New submission from Ed Schouten:

Modern C code should use inet_ntop()/inet_pton() as opposed to 
inet_addr()/inet_aton()/inet_ntoa().

Though the former functions may typically act as drop-in replacements for the 
latter, the inet_addr()/inet_aton() functions still have the advantage over 
inet_pton() of allowing you to parse IPv4 addresses that don't use the dotted 
quad notation (e.g. '0x0a01' for 10.0.0.1).

There is no difference between inet_ntop() and inet_ntoa(), as they both always 
print the address in dotted quad form. inet_ntop() does have the advantage of 
being thread-safe, as inet_ntoa() uses internal storage for the return value. 
In other words, we'd better not use inet_ntoa() at all.

Attached is a patch for Python's socketmodule that changes the existing call to 
inet_ntoa() to use inet_ntop() when available. This has the advantage of fixing 
the build on CloudABI 
(https://mail.python.org/pipermail/python-dev/2016-July/145708.html), which 
intentionally omits any APIs that are thread-unsafe.

--
components: Extension Modules
files: patch-inet_ntoa.diff
keywords: patch
messages: 280109
nosy: EdSchouten
priority: normal
severity: normal
status: open
title: [Patch] Stop using inet_ntoa() when possible.
versions: Python 3.7
Added file: http://bugs.python.org/file45364/patch-inet_ntoa.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python

[Antoine Pitrou]

Antoine Pitrou added the comment:

Can you compare against a PGO build? Ubuntu 14.04 is old, and I don't think 
this is something we should worry about.

Overall I think this manual approach is really the wrong way to look at it. 
Compilers can do better than us.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28563] Arbitrary code execution in gettext.c2py

[Carl Ekerot]

Carl Ekerot added the comment:

Verified gettext.c2py with gettext_c2py.patch applied agains the plural forms 
actually used in localization, listed over at 
http://docs.translatehouse.org/projects/localization-guide/en/latest/l10n/pluralforms.html.
 I tested all of the none-trivial forms, and from what I can tell they generate 
valid syntax and are correct.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python

[STINNER Victor]

STINNER Victor added the comment:

Oh, I forgot to mention that I compiled Python with "./configure -C". The 
purpose of the patch is to optimize Python when LTO and/or PGO compilation are 
not explicitly used.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python

[STINNER Victor]

STINNER Victor added the comment:

I ran benchmarks. Globally, it seems like the impact of the patch is positive. 
regex_v8 and call_simple are slower, but these benchmarks are microbenchmarks 
impacted by low level stuff like CPU L1 cache. Well, my patch was supposed to 
optimize CPython for call_simple :-/ I should maybe investigate a little bit 
more.


Performance comparison (performance 0.3.2):

haypo@smithers$ python3 -m perf compare_to orig.json hot.json -G
Slower (6):
- regex_v8: 40.6 ms +- 5.7 ms -> 47.1 ms +- 0.3 ms: 1.16x slower
- call_simple: 12.6 ms +- 0.2 ms -> 13.2 ms +- 1.3 ms: 1.05x slower
- regex_effbot: 4.58 ms +- 0.07 ms -> 4.70 ms +- 0.05 ms: 1.03x slower
- sympy_integrate: 43.4 ms +- 0.3 ms -> 44.0 ms +- 0.2 ms: 1.01x slower
- nqueens: 239 ms +- 2 ms -> 241 ms +- 1 ms: 1.01x slower
- scimark_fft: 674 ms +- 12 ms -> 680 ms +- 75 ms: 1.01x slower

Faster (32):
- scimark_monte_carlo: 255 ms +- 4 ms -> 234 ms +- 7 ms: 1.09x faster
- chameleon: 28.4 ms +- 3.1 ms -> 27.0 ms +- 0.4 ms: 1.05x faster
- scimark_sor: 488 ms +- 27 ms -> 467 ms +- 10 ms: 1.05x faster
- sqlite_synth: 9.16 us +- 1.03 us -> 8.82 us +- 0.23 us: 1.04x faster
- scimark_lu: 485 ms +- 20 ms -> 469 ms +- 14 ms: 1.03x faster
- xml_etree_process: 226 ms +- 30 ms -> 219 ms +- 4 ms: 1.03x faster
- logging_simple: 29.7 us +- 0.4 us -> 28.9 us +- 0.3 us: 1.03x faster
- pickle_list: 7.99 us +- 0.88 us -> 7.78 us +- 0.05 us: 1.03x faster
- raytrace: 1.26 sec +- 0.08 sec -> 1.23 sec +- 0.01 sec: 1.03x faster
- sympy_expand: 995 ms +- 31 ms -> 971 ms +- 35 ms: 1.03x faster
- deltablue: 17.0 ms +- 0.1 ms -> 16.6 ms +- 0.2 ms: 1.02x faster
- call_method_slots: 16.0 ms +- 0.1 ms -> 15.6 ms +- 0.2 ms: 1.02x faster
- fannkuch: 983 ms +- 12 ms -> 962 ms +- 29 ms: 1.02x faster
- pickle_pure_python: 1.25 ms +- 0.14 ms -> 1.22 ms +- 0.01 ms: 1.02x faster
- logging_format: 34.0 us +- 0.3 us -> 33.4 us +- 1.5 us: 1.02x faster
- xml_etree_parse: 274 ms +- 9 ms -> 270 ms +- 5 ms: 1.02x faster
- sympy_str: 441 ms +- 3 ms -> 433 ms +- 3 ms: 1.02x faster
- genshi_text: 87.6 ms +- 9.2 ms -> 86.0 ms +- 1.4 ms: 1.02x faster
- genshi_xml: 187 ms +- 17 ms -> 184 ms +- 1 ms: 1.02x faster
- django_template: 376 ms +- 4 ms -> 370 ms +- 2 ms: 1.02x faster
- json_dumps: 27.1 ms +- 0.4 ms -> 26.7 ms +- 0.4 ms: 1.02x faster
- sqlalchemy_declarative: 295 ms +- 3 ms -> 291 ms +- 3 ms: 1.01x faster
- call_method_unknown: 18.1 ms +- 0.1 ms -> 17.8 ms +- 0.1 ms: 1.01x faster
- nbody: 218 ms +- 4 ms -> 216 ms +- 2 ms: 1.01x faster
- regex_dna: 250 ms +- 24 ms -> 247 ms +- 2 ms: 1.01x faster
- go: 573 ms +- 2 ms -> 566 ms +- 3 ms: 1.01x faster
- richards: 173 ms +- 4 ms -> 171 ms +- 4 ms: 1.01x faster
- python_startup: 24.6 ms +- 0.1 ms -> 24.5 ms +- 0.1 ms: 1.00x faster
- regex_compile: 404 ms +- 6 ms -> 403 ms +- 5 ms: 1.00x faster
- dulwich_log: 143 ms +- 11 ms -> 143 ms +- 1 ms: 1.00x faster
- pidigits: 290 ms +- 1 ms -> 289 ms +- 0 ms: 1.00x faster
- pickle_dict: 58.3 us +- 6.5 us -> 58.3 us +- 0.7 us: 1.00x faster

Benchmark hidden because not significant (26): 2to3, call_method, chaos, 
crypto_pyaes, float, hexiom, html5lib, json_loads, logging_silent, mako, 
meteor_contest, pathlib, pickle, python_startup_no_site, 
scimark_sparse_mat_mult, spectral_norm, sqlalchemy_imperative, sympy_sum, 
telco, tornado_http, unpack_sequence, unpickle, unpickle_list, 
unpickle_pure_python, xml_etree_generate, xml_etree_iterparse

--

More readable output, only display differences >= 5%:

haypo@smithers$ python3 -m perf compare_to orig.json hot.json -G --min-speed=5
Slower (1):
- regex_v8: 40.6 ms +- 5.7 ms -> 47.1 ms +- 0.3 ms: 1.16x slower

Faster (2):
- scimark_monte_carlo: 255 ms +- 4 ms -> 234 ms +- 7 ms: 1.09x faster
- chameleon: 28.4 ms +- 3.1 ms -> 27.0 ms +- 0.4 ms: 1.05x faster

Benchmark hidden because not significant (61): 2to3, call_method, 
call_method_slots, call_method_unknown, call_simple, chaos, crypto_pyaes, 
deltablue, django_template, dulwich_log, fannkuch, float, genshi_text, 
genshi_xml, go, hexiom, html5lib, json_dumps, json_loads, logging_format, 
logging_silent, logging_simple, mako, meteor_contest, nbody, nqueens, pathlib, 
pickle, pickle_dict, pickle_list, pickle_pure_python, pidigits, python_startup, 
python_startup_no_site, raytrace, regex_compile, regex_dna, regex_effbot, 
richards, scimark_fft, scimark_lu, scimark_sor, scimark_sparse_mat_mult, 
spectral_norm, sqlalchemy_declarative, sqlalchemy_imperative, sqlite_synth, 
sympy_expand, sympy_integrate, sympy_str, sympy_sum, telco, tornado_http, 
unpack_sequence, unpickle, unpickle_list, unpickle_pure_python, 
xml_etree_generate, xml_etree_iterparse, xml_etree_parse, xml_etree_process

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 

[issue28563] Arbitrary code execution in gettext.c2py

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> How does it work for '1?2:3?4:5'?

'1?2:3?4:5' -> '(2 if 1 else 3)?4:5' -> '(4 if (2 if 1 else 3) else 5'

But there are other problems. Precedence of some operators is different in C 
and Python. Chained comparison in Python cause different result that in C (e.g. 
'2 == 2 == 2'). Seems there is no other way besides a simple parser.

gettext_c2py.patch itself LGTM for fixing security issue, but tests are needed. 
It would be nice to make c2py() working with any expressions, but if this is 
too hard, this can be left for other issue. I'm going to commit a variant of 
gettext_c2py.patch before 3.6 release if there will be not better patches.

--
priority: high -> deferred blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28563] Arbitrary code execution in gettext.c2py

[Xiang Zhang]

Xiang Zhang added the comment:

> gettext.c2py("n()")(lambda: os.system("sh"))
> gettext.c2py("1()")(0)

Empty parentheses should be disallowed. Function calls are not allowed in 
plural expression. And non-integer argument should be disallowed either, just 
as Serhiy's example shows.

> What if make repeated replacements with regular expression 
> r'([^?:]*?)\?([^?:]*?):([^?:]*)'?

How does it work for '1?2:3?4:5'? :-( I am considering a parser.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com