Changelog for pcre-devel-8.45-lp155.137.2.x86_64.rpm :

* Thu Feb 29 2024 Dominique Leuenberger - Use %autosetup macro. Allows to eliminate the usage of deprecated %patchN.
* Wed May 11 2022 Jason Sikes - Added pcre-8.45-bsc1199232-unicode-property-matching.patch
* bsc#1199232
* Fixes unicode property matching issue
* Mon Jul 26 2021 Dirk Müller - update to 8.45:
* This is the final PCRE1 release. A very few small issues have been fixed.
* Mon Feb 22 2021 Andreas Schwab - Copy pcre_jit_test only if jit is enabled
* Mon Feb 15 2021 Radoslav Kolev - package testsuite in a separate RPM (boo#1182235)
* Wed Apr 15 2020 Martin Pluskal - Update to version 8.44:
* This is a bug-fix release.
* Fri Aug 02 2019 Martin Liška - Use FAT LTO objects in order to provide proper static library.
* Thu Oct 25 2018 laufferAATTph-freiburg.de- pcreposix patch taken from debian. Solves cyrus-imapd issue #1731, too. pcre-8.42-pcreposix.patch
* Tue Sep 04 2018 astiegerAATTsuse.com- pcre 8.42:
* Fix outdated real_pcre definitions in pcre.h.in
* pcregrep was truncating components of file names to 128 characters when processing files with the -r option, and also truncating path names to 512 characters. There is now a check on the absolute length of full path file names, which may be up to 2047 characters long
* Using pcre_dfa_exec(), in UTF mode when UCP support was not defined, there was the possibility of a false positive match when caselessly matching a \"not this character\" item such as [^\\x{1234}] (with a code point greater than 127) because the \"other case\" variable was not being initialized
* Although pcre_jit_exec checks whether the pattern is compiled in a given mode, it was also expected that at least one mode is available. This is fixed and pcre_jit_exec returns with PCRE_ERROR_JIT_BADOPTION when the pattern is not optimized by JIT at all.
* The line number and related variables such as match counts in pcregrep were all int variables, causing overflow when files with more than 2147483647 lines were processed (assuming 32-bit ints). They have all been changed to unsigned long ints.
* If a backreference with a minimum repeat count of zero was first in a pattern, apart from assertions, an incorrect first matching character could be recorded. For example, for the pattern /(?=(a))\\1?b/, \"b\" was incorrectly set as the first character of a match.
* Fix out-of-bounds read for partial matching of /./ against an empty string when the newline type is CRLF.
* When matching using the the REG_STARTEND feature of the POSIX API with a non-zero starting offset, unset capturing groups with lower numbers than a group that did capture something were not being correctly returned as \"unset\" (that is, with offset values of -1).
* Matching the pattern /(
*UTF)\\C[^\\v]+\\x80/ against an 8-bit string containing multi-code-unit characters caused bad behaviour and possibly a crash. This issue was fixed for other kinds of repeat in release 8.37 by change 38, but repeating character classes were overlooked.
* A small fix to pcregrep to avoid compiler warnings for - Wformat-overflow=2.
* Added --enable-jit=auto support to configure.ac.
* Fix misleading error message in configure.ac.
* Sun Apr 15 2018 bwiedemannAATTsuse.com- Do not run profiling \'check\' in parallel to make package build reproducible (boo#1040589)
* Thu Feb 22 2018 fvogtAATTsuse.com- Use %license (boo#1082318)
* Wed Nov 01 2017 kstreitovaAATTsuse.com- add pcre-8.41-stack_frame_size_detection.patch to fix pcre stack frame size detection because modern compilers broke it by cloning and inlining pcre match() function [bsc#1058722]
* Tue Sep 12 2017 matzAATTsuse.com- RunTest needs much stack, on s390x more than the default 8 MB. [bnc#1046102]
* Tue Jul 25 2017 astiegerAATTsuse.com- pcre 8.41:
* If pcregrep in multiline mode with --only-matching matched several lines, it restarted scanning at the next line instead of moving on to the end of the matched string, which can be several lines after the start.
* Fix a missing else in the JIT compiler reported by \'idaifish\'. CVE-2017-6004 bsc#1025709
* A (?# style comment is now ignored between a basic quantifier and a following \'+\' or \'?\' (example: /X+(?#comment)?Y/.
* Avoid use of a potentially overflowing buffer in pcregrep
* Fix issues reported by fuzzers in pcretest: - Check for values < 256 when calling isprint() in pcretest. - Give an error for too big a number after \\O.
* In the 32-bit library in non-UTF mode, an attempt to find a Unicode property for a character with a code point greater than 0x10ffff (the Unicode maximum) caused a crash. CVE-2017-7186 bsc#1030066, CVE-2017-7244 bsc#1030807
* The alternative matching function, pcre_dfa_exec() misbehaved if it encountered a character class with a possessive repeat, for example [a-f]{3}+.
* When pcretest called pcre_copy_substring() in 32-bit mode, it set the buffer length incorrectly, which could result in buffer overflow. CVE-2017-7245 bsc#1030805, CVE-2017-7246 bsc#1030803
* Fri Jun 02 2017 mpluskalAATTsuse.com- Enable jit on aarch64- Enable profiled building
* Thu Feb 09 2017 astiegerAATTsuse.com- pcre 8.40:
* Using -o with -M in pcregrep could cause unnecessary repeated output when the match extended over a line boundary.
* Fix register overwite in JIT when SSE2 acceleration is enabled.
* Ignore \"show all captures\" (/=) for DFA matching.
* Fix JIT unaligned accesses on x86
* In any wide-character mode (8-bit UTF or any 16-bit or 32-bit mode), without PCRE_UCP set, a negative character type such as \\D in a positive class should cause all characters greater than 255 to match, whatever else is in the class. There was a bug that caused this not to happen if a Unicode property item was added to such a class, for example [\\D\\P{Nd}] or [\\W\\pL].
* When pcretest was outputing information from a callout, the caret indicator for the current position in the subject line was incorrect if it was after an escape sequence for a character whose code point was greater than \\x{ff}.
* A pattern such as (?abc)(?(R)xyz) was incorrectly compiled such that the conditional was interpreted as a reference to capturing group 1 instead of a test for recursion. Any group whose name began with R was misinterpreted in this way. (The reference interpretation should only happen if the group\'s name is precisely \"R\".)
* A number of bugs have been mended relating to match start-up optimizations when the first thing in a pattern is a positive lookahead. These all applied only when PCRE_NO_START_OPTIMIZE was
*not
* set: + A pattern such as (?=.
*X)X$ was incorrectly optimized as if it needed both an initial \'X\' and a following \'X\'. + Some patterns starting with an assertion that started with .
* were incorrectly optimized as having to match at the start of the subject or after a newline. There are cases where this is not true, for example, (?=.
*[A-Z])(?=.{8,16})(?!.
*[\\s]) matches after the start in lines that start with spaces. Starting .
* in an assertion is no longer taken as an indication of matching at the start (or after a newline).
* Tue Feb 07 2017 dimstarAATTopensuse.org- Explicitly package %{_docdir}/%{name} to fix build with RPM 4.13.
* Mon Aug 01 2016 astiegerAATTsuse.com- record minor vulnerabilities fixed in 8.39
* Wed Jun 15 2016 mpluskalAATTsuse.com- Update to version 8.39:
* Some appropriate PCRE2 JIT improvements have been retro-fitted to PCRE1.
* CVE-2016-3191: workspace overflow for (
*ACCEPT) with deeply nested parentheses (boo#971741)
* CVE-2016-1283: Heap buffer overflow DoS (boo#960837)
* Apart from that, this is another bug-fix release.
* Thu Nov 26 2015 astiegerAATTsuse.com- pcre 8.38:
* CVE-2015-3217: Call Stack Overflow Vulnerability in match() bsc#933878
* Other fixes to assertions, crashes, buffer overflows and performance issues found by fuzzer, affecting applications accepting regular expression from untrusted sources
* Thu Apr 30 2015 astiegerAATTsuse.com- pcre 8.37:
* CVE-2015-2325: Patterns with certain groups specifying a zero minimum quantifier caused incorrect code to be compiled, leading to an incorrect memory read. [boo#924960]
* CVE-2015-2326: Specific patterns containing a forward reference with subroutine calls caused incorrect code to be compiled [boo#924961]
* CVE-2014-8964: If an assertion condition was quantified with a minimum of zero, SIGSEGV or other misbehaviour could occur. [boo#906574]
* further bug fixes as listed in ChangeLog
* Mon Mar 09 2015 p.drouandAATTgmail.com- Update to version 3.16
* This is primarily a bug-fix release.
* The Unicode data tables have been updated to Unicode 7.0.0.- Remove pcre-commit1472.patch; fixed on upstream release- Remove obsolete \"Obsoletes\" tag