Aller au contenu
login
arrow_backRetour aux issues
collective/icalendar #1532

`assert` statements in the parser produce invalid output when Python runs with `-O`

ecoDébutant good first issue

descriptionDescription

While auditing the codebase I found four `assert` statements in the parsing pipeline that guard things we actually care about at runtime. The problem is that Python's `-O` flag strips all assertions silently, and we already reference ruff rule `B011` in `pyproject.toml` which flags exactly this pattern. The most significant one is in [`content_line.py:126`](https://github.com/collective/icalendar/blob/34fafc017778e43eb7c717d3c724ee0d438e69e3/src/icalendar/parser/content_line.py#L126): ```python assert "\n" not in value, "Content line can not contain unescaped new line characters." ``` This runs on every content line during parsing and serialization. Without it, `to_ical()` will happily emit embedded newlines and produce output that violates [RFC 5545](https://www.rfc-editor.org/rfc/rfc5545) line structure. I confirmed this with `-O`: ``` $ python -O -c " from icalendar.parser.content_line import Contentline cl = Contentline('SUMMARY:Test\nINJECTED:Bad') print(cl.to_ical()) " b'SUMMARY:Test\nINJECTED:Bad' ``` The same issue exists in [`string.py:121-122`](https://github.com/collective/icalendar/blob/34fafc017778e43eb7c717d3c724ee0d438e69e3/src/icalendar/parser/string.py#L121-L122), which guards `_foldline`. Without those checks, `_foldline` passes multiline strings through unchanged, again violating the 75-octet line length rule. And [`string.py:33`](https://github.com/collective/icalendar/blob/34fafc017778e43eb7c717d3c724ee0d438e69e3/src/icalendar/parser/string.py#L33) and [`78`](https://github.com/collective/icalendar/blob/34fafc017778e43eb7c717d3c724ee0d438e69e3/src/icalendar/parser/string.py#L78) are type guards in `_escape_char` and `_unescape_char` with the same problem. All four should be replaced with explicit `if`/`raise ValueError` checks.
codeOuvre sur GitHub