The armor regex:
|
# the re.VERBOSE flag allows for: |
|
# - whitespace is ignored except when in a character class or escaped |
|
# - anything after a '#' that is not escaped or in a character class is ignored, allowing for comments |
|
__armor_regex = re.compile(r"""# This capture group is optional because it will only be present in signed cleartext messages |
|
(^-{5}BEGIN\ PGP\ SIGNED\ MESSAGE-{5}(?:\r?\n) |
|
(Hash:\ (?P<hashes>[A-Za-z0-9\-,]+)(?:\r?\n){2})? |
|
(?P<cleartext>(.*\r?\n)*(.*(?=\r?\n-{5})))(?:\r?\n) |
|
)? |
|
# armor header line; capture the variable part of the magic text |
|
^-{5}BEGIN\ PGP\ (?P<magic>[A-Z0-9 ,]+)-{5}(?:\r?\n) |
|
# try to capture all the headers into one capture group |
|
# if this doesn't match, m['headers'] will be None |
|
(?P<headers>(^.+:\ .+(?:\r?\n))+)?(?:\r?\n)? |
|
# capture all lines of the body, up to 76 characters long, |
|
# including the newline, and the pad character(s) |
|
(?P<body>([A-Za-z0-9+/]{1,76}={,2}(?:\r?\n))+) |
|
# capture the armored CRC24 value |
|
^=(?P<crc>[A-Za-z0-9+/]{4})(?:\r?\n) |
|
# finally, capture the armor tail line, which must match the armor header line |
|
^-{5}END\ PGP\ (?P=magic)-{5}(?:\r?\n)? |
|
""", flags=re.MULTILINE | re.VERBOSE) |
has
catastrophic backtracking problems.
See this example on regex101.com, which results in:
Catastrophic backtracking has been detected and the execution of your expression has been halted. To find out more and what this is, please read the following article: Runaway Regular Expressions
The problem are the six dashes (while only 5 are valid PGP):
------BEGIN PGP SIGNATURE-----
------END PGP SIGNATURE-----
which does not match, and because of some nested * capture, there is a backtracking chaos.
After some tweaking I've a regex patch that has the same py39 outcome:
The armor regex:
PGPy/pgpy/types.py
Lines 49 to 69 in 30a7571
has catastrophic backtracking problems.
See this example on regex101.com, which results in:
The problem are the six dashes (while only 5 are valid PGP):
which does not match, and because of some nested
*capture, there is a backtracking chaos.After some tweaking I've a regex patch that has the same py39 outcome: