* Prevent low-grade poplib REDOS (CVE-2018-1060)
The regex to test a mail server's timestamp is susceptible to
catastrophic backtracking on long evil responses from the server.
Happily, the maximum length of malicious inputs is 2K thanks
to a limit introduced in the fix for CVE-2013-1752.
A 2KB evil response from the mail server would result in small slowdowns
(milliseconds vs. microseconds) accumulated over many apop calls.
This is a potential DOS vector via accumulated slowdowns.
Replace it with a similar non-vulnerable regex.
The new regex is RFC compliant.
The old regex was non-compliant in edge cases.
* Prevent difflib REDOS (CVE-2018-1061)
The default regex for IS_LINE_JUNK is susceptible to
catastrophic backtracking.
This is a potential DOS vector.
Replace it with an equivalent non-vulnerable regex.
Also introduce unit and REDOS tests for difflib.
Co-authored-by: Tim Peters <tim.peters@gmail.com>
Co-authored-by: Christian Heimes <christian@python.org>.
(cherry picked from commit 0e6c8ee235)
requires them. Disable executable bits and shebang lines in test and
benchmark files in order to prevent using a random system python, and in
source files of modules which don't provide command line interface.
Instead of spaces between the filename and date (or whatever the string
is that follows the filename, if any) use tabs. This is what the unix
'diff' command does, for example, and difflib was intended to follow
the 'standard' way of doing diffs. This improves compatibility with
patch tools. The docs and examples are also changed to recommended that
the date format used be the ISO 8601 format, which is what modern diff
tools emit by default.
Patch by Anatoly Techtonik.
adjacent triples in the result list describe non-adjacent matching
blocks. That's _nice_ to have, and Guido said he wanted it.
Not a bugfix candidate: Guido or not ;-), this changes visible
endcase semantics (note that some tests had to change), and
nothing about this was documented before. Since it was working
as designed, and behavior was consistent with the docs, it wasn't
"a bug".
more comments about why it's this way at all; and removed what looked
like needless expense (sorting (i, j, k) triples directly should give
exactly the same order as sorting (i, (i, j, k)) pairs).
