Index index by Group index by Distribution index by Vendor index by creation date index by Name Mirrors Help Search

libpcre1-8.45-20.11.1 RPM for armv7hl

From OpenSuSE Ports Leap 15.3 for armv7hl

Name: libpcre1 Distribution: openSUSE Step 15
Version: 8.45 Vendor: openSUSE
Release: 20.11.1 Build date: Wed Oct 27 09:41:55 2021
Group: System/Libraries Build host: armbuild02
Size: 863923 Source RPM: pcre-8.45-20.11.1.src.rpm
Summary: A library for Perl-compatible regular expressions
The PCRE library is a set of functions that implement regular
expression pattern matching using the same syntax and semantics
as Perl 5.

This PCRE library variant supports 8-bit and UTF-8 strings.
(See also libpcre16.)






* Tue Oct 19 2021
  - pcre 8.45 (the final release)
    * Fixed a small (*MARK) bug in the interpreter (Bugzilla #2771).
  - pcre 8.44
    * Small patch to pcreposix.c to set the erroroffset field to -1 immediately
    after a successful compile, instead of at the start of matching to avoid a
    sanitizer complaint (regexec is supposed to be thread safe).
    * Check the size of the number after (?C as it is read, in order to avoid
    integer overflow. (bsc#1172974, CVE-2020-14155)
    * Tidy up left shifts to avoid sanitize warnings; also fix one NULL deference
    in pcretest.
  - pcre 8.43
    * In a pattern such as /[^\x{100}-\x{ffff}]*[\x80-\xff]/ which has a repeated
    negative class with no characters less than 0x100 followed by a positive class
    with only characters less than 0x100, the first class was incorrectly being
    auto-possessified, causing incorrect match failures.
    * If the only branch in a conditional subpattern was anchored, the whole
    subpattern was treated as anchored, when it should not have been, since the
    assumed empty second branch cannot be anchored. Demonstrated by test patterns
    such as /(?(1)^())b/ or /(?(?=^))b/.
    * Fix subject buffer overread in JIT when UTF is disabled and \X or \R has
    a greater than 1 fixed quantifier. This issue was found by Yunho Kim.
    (bsc#1172973 CVE-2019-20838)
    * If a pattern started with a subroutine call that had a quantifier with a
    minimum of zero, an incorrect "match must start with this character" could be
    recorded. Example: /(?&xxx)*ABC(?<xxx>XYZ)/ would (incorrectly) expect 'A' to
    be the first character of a match.
  - pcre 8.42
    * 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.
* Tue May 11 2021
  - Do not run profiling 'check' in parallel
    to make package build reproducible (boo#1040589)
* Thu Feb 22 2018
  - Use %license (boo#1082318)
* Wed Nov 01 2017
  - 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
  - RunTest needs much stack, on s390x more than the default
    8 MB.  [bnc#1046102]
* Tue Jul 25 2017
  - 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
  - Enable jit on aarch64
  - Enable profiled building
* Thu Feb 09 2017
  - 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 (?<RA>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
  - Explicitly package %{_docdir}/%{name} to fix build with RPM 4.13.
* Mon Aug 01 2016
  - record minor vulnerabilities fixed in 8.39
* Wed Jun 15 2016
  - 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
  - pcre 8.38:
    * CVE-2015-3217: Call Stack Overflow Vulnerability in match()
    * 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
  - 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
    * CVE-2014-8964: If an assertion condition was quantified with a
      minimum of zero, SIGSEGV or other misbehaviour could occur.
    * further bug fixes as listed in ChangeLog
* Mon Mar 09 2015
  - 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



Generated by rpm2html 1.8.1

Fabrice Bellet, Tue Jul 9 15:33:36 2024