Mailman 3 January 2022 - Docs-bugs

[issue46200] Discourage logging f-strings due to security considerations
by Arie Bovenberg 19 Feb '22

19 Feb '22

New submission from Arie Bovenberg <a.c.bovenberg(a)gmail.com>: (I've already submitted this issue to security(a)python.org, who directed me to propose a documentation change here) Logging f-strings is quite popular, because the `%` style of logging is often considered ugly. However, logging preformatted strings comes with security risks which should explicitly be mentioned in the logging documentation. The following example illustrates the problem: logger.info('look: %s', untrusted_string) # OK logger.info('look: %(foo)s', {'foo', untrusted_string}) # OK logger.info(f'look: {untrusted_string}') # OK (security-wise) logger.info(f'look: {untrusted_string}', some_dict) # DANGER! The problem is that `untrusted_string` will be interpreted as a string template by the logger. If `untrusted_string` has the value `%(foo)999999999s` (where foo is present in `some_dict`), logging gets stuck trying to add over a gigabyte of whitespace to a string. In other words: a Denial-of-Service attack. Of course, this combination of f-string and logger arguments is unlikely. But it is plausible that: - After a refactoring to f-string, removing the dict argument is forgotten; - A developer adding a variable to a message prefers using f-strings and thus creates a template mixing the two styles (e.g. `{foo} and %(bar)s`); - The string is passed through a logging Filter or other function which adds a dict argument. Open questions: 1. Do we want to simply highlight the risks, or actively discourage logging f-strings? My thoughts: I feel it's important enough to actively discourage logging preformatted strings (i.e. also .format and manual %-formatting). A strong recommendation will allow security linters to flag this. Additionally, there are other advantages to the formatting built into `logging` (e.g. performance). 2. Should we type annotate logger `msg` as `Literal[str]` following PEP675? My thoughts: Annotating `msg` as a literal string will greatly help enforce this best practice. The adoption of typecheckers exceeds that of security linters. 3. Where should this risk be documented? a. In the `logger.debug` function docs b. In the `logging` docs introduction (like xml.etree.elementtree) c. In a new "security" section of the `logging` docs d. An informational PEP on logging security considerations (similar to PEP672) My thoughts: I fear option (a) would not get the attention of most readers. Option (c) or (d) may be useful to also highlight general risks of logging (i.e. log injection) As soon as there is agreement on these questions, I would be happy to submit a PR. ---------- assignee: docs@python components: Documentation messages: 409352 nosy: ariebovenberg, docs@python priority: normal severity: normal status: open title: Discourage logging f-strings due to security considerations type: security versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue46200> _______________________________________

8 16

[issue46586] In documentation contents enum.property erroneously links to built-in property
by Dutcho 19 Feb '22

19 Feb '22

New submission from Dutcho <dutcho(a)ziggo.nl>: https://docs.python.org/3.11/library/enum.html#module-contents contains: property() Allows Enum members to have attributes without conflicting with member names. In above, property() is links to: https://docs.python.org/3.11/library/functions.html#property instead of to the proper: https://docs.python.org/3.11/library/enum.html#enum.property ---------- assignee: docs@python components: Documentation messages: 412156 nosy: Dutcho, docs@python priority: normal severity: normal status: open title: In documentation contents enum.property erroneously links to built-in property versions: Python 3.11 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue46586> _______________________________________

8 25

[issue46282] print() docs do not indicate its return value
by Steven D'Aprano 12 Feb '22

12 Feb '22

New submission from Steven D'Aprano <steve+python(a)pearwood.info>: Do the print docs need to mention something so obvious? Functions and methods which operate by side-effect typically don't mention that they return None, see for example the docs for various builtin methods: https://docs.python.org/3/library/stdtypes.html#mutable-sequence-types e.g. s.append, s.clear, s.extend, s.insert, s.remove, s.reverse and likewise for list.sort, set.add, dict.clear and many others. (However, dict.update is a rare exception, it does mention that it returns None.) We should not feel it necessary to add an explicit comment to every function or method that operates by side-effect stating that they return None. ---------- nosy: +steven.daprano _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue46282> _______________________________________

8 19

[issue45393] help() on operator precedence has confusing entries "avait" "x" and "not" "x"
by Max 10 Feb '22

10 Feb '22

New submission from Max <mh+bugs.python.org(a)dsi972.fr>: Nobody seems to have noticed this AFAICS: If you type, e.g., help('+') to get help on operator precedence, the fist column gives a lit of operators for each row corresponding to a given precedence. However, the row for "not" (and similar for "await"), has the entry "not" "x" That looks as if there were two operators, "not" and "x". But the letter x is just an argument to the operator, so it should be: "not x" exactly as for "+x" and "-x" and "~x" and "x[index]" and "x.attribute", where also x is not part of the operator but an argument. On the corresponding web page https://docs.python.org/3/reference/expressions.html#operator-summary it is displayed correctly, there are no quotes. ---------- assignee: docs@python components: Documentation messages: 403321 nosy: MFH, docs@python priority: normal severity: normal status: open title: help() on operator precedence has confusing entries "avait" "x" and "not" "x" type: enhancement versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45393> _______________________________________

5 8

[issue46066] Docs: TypedDict alternative definition syntax with keyword args is confusing
by 97littleleaf11 04 Feb '22

04 Feb '22

New submission from 97littleleaf11 <97littleleaf11(a)gmail.com>: According to the docs: https://docs.python.org/3/library/typing.html?#typing.TypedDict, there are two additional equivalent syntax for TypedDict definition. Point2D = TypedDict('Point2D', x=int, y=int, label=str) Point2D = TypedDict('Point2D', {'x': int, 'y': int, 'label': str}) However, the former one is quite confusing since we have the `total` keyword arg for TypedDict. In addition, PEP589(https://www.python.org/dev/peps/pep-0589/#id19) doesn't have this. I think we could discard the definition syntax using keyword args in the doc. ---------- assignee: docs@python components: Documentation messages: 408458 nosy: 97littleleaf11, docs@python priority: normal severity: normal status: open title: Docs: TypedDict alternative definition syntax with keyword args is confusing versions: Python 3.10, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue46066> _______________________________________

3 8

[issue45380] help() appears confused about the module of typing.Annotated
by Alex Waygood 03 Feb '22

03 Feb '22

New submission from Alex Waygood <Alex.Waygood(a)Gmail.com>: `help()` appears confused about the module of `typing.Annotated`. If you call `help()` on a parameterised "instance" of `typing.Annotated`, it will claim that `Annotated` belongs to whatever module the annotated type is from. Additionally, `help()` appears not to know about the `__metadata__` attribute of `typing.Annotated`. ``` >>> from typing import Annotated, Callable >>> t = Annotated[int | str, "Some metadata"] >>> help(t) Help on _AnnotatedAlias in module types: Annotated = int | str >>> u = Annotated[Callable[[int], str], "Some metadata"] >>> help(u) Help on _AnnotatedAlias in module typing: Annotated = typing.Callable[[int], str] >>> s = Annotated[int, "Some metadata"] Help on _AnnotatedAlias in module builtins: Annotated = class int(object) | int([x]) -> integer | int(x, base=10) -> integer # (etc., giving the entire output of help() for `int`) ``` ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 403258 nosy: AlexWaygood, docs@python priority: normal severity: normal status: open title: help() appears confused about the module of typing.Annotated type: behavior versions: Python 3.10, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45380> _______________________________________

3 4

[issue46569] final note on StrEnum documentation incorrectly refers to int.__format__ instead of str.__format__
by Dutcho 03 Feb '22

03 Feb '22

New submission from Dutcho <dutcho(a)ziggo.nl>: https://docs.python.org/3.11/library/enum.html#enum.StrEnum contains: Note __str__() is str.__str__() to better support the replacement of existing constants use-case. __format__() is likewise int.__format__() for that same reason. This should be (change indicated by triple star): Note __str__() is str.__str__() to better support the replacement of existing constants use-case. __format__() is likewise ***str***.__format__() for that same reason. Likely copied from IntEnum ---------- assignee: docs@python components: Documentation messages: 412067 nosy: Dutcho, docs@python priority: normal severity: normal status: open title: final note on StrEnum documentation incorrectly refers to int.__format__ instead of str.__format__ versions: Python 3.11 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue46569> _______________________________________

4 5

[issue46005] [doc] replace 'distutils' examples with 'setuptools'
by Elmir 02 Feb '22

02 Feb '22

New submission from Elmir <elmir.jagudin(a)maxiv.lu.se>: As the distutils have been deprecated, the documentation on building C/C++ extension modules should be updated to use more future proof tool. I guess the section: 'Building C and C++ Extensions with distutils' should be replaced with: 'Building C and C++ Extensions with setuptools' Here is link to the section that needs to be updated/replaced: https://docs.python.org/3/extending/building.html#building-c-and-c-extensio… ---------- assignee: docs@python components: Documentation messages: 407896 nosy: docs@python, elmjag priority: normal severity: normal status: open title: [doc] replace 'distutils' examples with 'setuptools' type: enhancement versions: Python 3.10, Python 3.11 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue46005> _______________________________________

4 6

[issue29688] Add support for Path.absolute()
by Eryk Sun 31 Jan '22

31 Jan '22

Eryk Sun <eryksun(a)gmail.com> added the comment: > I'd imagine that bug is reproducible with `Path('C:\\Temp', 'C:')` > already, right? If that's the case, should it logged as a > separate issue? Yes, it's a separate issue that affects the _from_parts() call in absolute(). How about designing absolute() to create a new instance from an absolute path that's created by os.path? For example: join(abspath(self.drive) if self.drive else getcwd(), self) Of course use accessor functions. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue29688> _______________________________________

1 0

[issue29688] Add support for Path.absolute()
by Barney Gale 31 Jan '22

31 Jan '22

Barney Gale <barney.gale(a)gmail.com> added the comment: @eryksun thanks for flagging, a couple thoughts: I'd imagine that bug is reproducible with `Path('C:\\Temp', 'C:')` already, right? If that's the case, should it logged as a separate issue? I'm planning to /experimentally/ throw away pathlib's internal path parsing logic and defer to `posixpath` / `ntpath` instead. I suspect this bug and others will be fixed by that change, but I need to see what the performance impact will be. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue29688> _______________________________________

1 0