dev-libs/glib contains an internal patched copy of libpcre, which has become stuck to version 8.31 due to the patches needing updating. Prior to glib-2.48.1, the internal copy is used, and as such all or most of the many security bugs affecting libpcre 8.31 are present as well for GRegex API users (albeit it's not a widely used API by glib consumers afaik). Upstream glib-2.48 switched the default over to use system pcre when no configure flag is passed, expressing which to use. We still passed the flag to use internal copy in 2.48.0, but for 2.48.1 ebuild this was changed (and system libpcre dep added). The upstream bug discussing this, together with mentioning security bugs, is at https://bugzilla.gnome.org/show_bug.cgi?id=740573 We should look to stabilize glib-2.48.1, or do a revbump to 2.46 series that switches the configure flag over to use system libpcre and add the dep as well. Theoretically the new 2.48 cycle should be fine to go stable independently of gnome 3.20; it just has to be done together with a split glib package (dev-util/gdbus-codegen-2.48.1). Tests fail right now though due to the switch to system libpcre, as per bug 587042 and mentions of it in the upstream bug as well. Other than preferably fixing or skipping those tests, need to review results from bug 580302 investigation. Not immediately CCing arches yet to first decide about 2.48 vs 2.46 revbump and trying to fix or skip the regex tests if possible easily enough. But bug now to raise awareness to security@
packages out from tree. Marking it as OBSOLETE. Gentoo Security Padawan ChrisADR
