collective / icalendar / 26219394471

98%

push

github

Fix RecursionError in Component.__repr__ on deeply nested calendars (Closes #1370) (#1371)

* Fix RecursionError in Component.__repr__ on deeply nested calendars

Component.__repr__ recursively calls str() on every subcomponent.
Parsing accepts BEGIN/END nesting of arbitrary depth (the parser
itself is iterative), so a ~13 KB .ics with ~500 nested VEVENTs
caused any caller doing repr(cal) / str(cal) / f"{cal}" to raise
an uncaught RecursionError at the default recursion limit.

This affects logging, error reporting, and debug-page rendering of
attacker-controlled calendars (e.g. CalDAV, .ics import endpoints,
calendar invitation processing).

Replaced the recursive implementation with an iterative stack-based
walk. Output format is unchanged for normally-shaped calendars.
Added regression tests covering depths up to 1000 and the unchanged
shallow-calendar format.

Existing OSS-Fuzz harness in src/icalendar/fuzzing/ical_fuzzer.py
exercises from_ical() / walk() / to_ical() but not __repr__, which
is why this code path slipped through fuzzing.

* Address review feedback: parametrize str test, add exact-equality tests

Per @angatha review on PR #1371:

- Parametrize ``test_str_does_not_raise_recursion_error`` with the same
  depths as the ``repr()`` test ([10, 100, 500, 1000]) and combine the
  two into a single test whose only varying axis (besides depth) is the
  string-conversion function.

- Add exact-equality tests for ``repr()`` output:

  * ``test_repr_exact_output_for_nested_components`` builds nested empty
    ``Event``s under a ``Calendar`` and asserts the entire ``repr()``
    string equals the format produced by the previous recursive
    implementation: ``VCALENDAR({}, VEVENT({}, ...))``.

  * ``test_repr_exact_output_for_sibling_components`` does the same for
    two sibling VEVENTs: ``VCALENDAR({}, VEVENT({}), VEVENT({}))``.

  Using empty constructed components keeps the expected string
  independent of the ``repr`` of any parsed property value.

755 of 777 branches covered (97.17%)

Branch coverage included in aggregate %.

53 of 54 new or added lines in 2 files covered. (98.15%)

12399 of 12676 relevant lines covered (97.81%)

6.84 hits per line