|Summary:||dev-lang/R < 2.2.1-r1 Multiple issues in embedded PCRE|
|Product:||Gentoo Security||Reporter:||Robert Buchholz (RETIRED) <rbu>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Package list:||Runtime testing required:||---|
Description Robert Buchholz (RETIRED) 2007-11-12 22:26:30 UTC
R ships a copy of PCRE which is vulnerable to several security issues as pointed out in bug #198198. Highes curent stable is: 2.2.1: PCRE Version 6.2 2.6.0: Version 7.2 PCRE 7.3 fixes the issues mentioned. R has no newer version shipping it. Sci herd, could you advise on the following questions: * What is PCRE in R used for? * Would it be feasible to require and compile against the system PCRE (possible in configure) -- same question for the other libraries R needs (and includes) * Is upstream aware of the issues and what is the best road to fix this in Gentoo?
Comment 1 Sébastien Fabbro (RETIRED) 2007-11-15 12:11:04 UTC
> Sci herd, could you advise on the following questions: > * What is PCRE in R used for? Probably for re's in R. > * Would it be feasible to require and compile against the system PCRE (possible > in configure) -- same question for the other libraries R needs (and includes) yes. > * Is upstream aware of the issues and what is the best road to fix this in > Gentoo? Upstream has updated to pcre-7.4 for their next R release. Meanwhile, I have updated the ebuilds to use the system libs, not just pcre. Waiting for other sci team members to answer since I'm not a R user.
Comment 2 Robert Buchholz (RETIRED) 2007-11-15 12:54:06 UTC
(In reply to comment #1) > Waiting for other sci team members to answer since I'm not a R user. Did you intend to do a straight to stable bump? If not, you should revert the keywords and ping us if you think it's good.
Comment 3 Sébastien Fabbro (RETIRED) 2007-11-15 20:07:15 UTC
> Did you intend to do a straight to stable bump? > > If not, you should revert the keywords and ping us if you think it's good. It was intended: I followed blindly the gentoo developer handbook part 5.e. I did not realize it wasn't the proper way, sorry about that. Anyway, this is now reverted: ping.
Comment 4 Robert Buchholz (RETIRED) 2007-11-15 22:27:30 UTC
The handbook could be clearer on that, I agree. It is meant that there's no need to wait 30 days with security fixes, but we still require the arch teams to test. Arches, please test and mark stable dev-lang/R-2.2.1-r1. Target keywords : "amd64 ia64 ppc ppc64 sparc x86"
Comment 5 Ferris McCormick (RETIRED) 2007-11-15 23:36:52 UTC
Stable on sparc. This version of R seems ancient (I'm up to the R-2.6.xx series on my systems).
Comment 6 Neil 2007-11-16 10:08:47 UTC
(In reply to comment #5) > Stable on sparc. This version of R seems ancient (I'm up to the R-2.6.xx > series on my systems). > It is very rather old (it was released around the end Dec-2005). For what its worth I've been using R-2.6.0 (and intermediate versions as ebuilds have been updated) since its release without any problems on three x86 systems and haven't had any crashes.
Comment 7 Robert Buchholz (RETIRED) 2007-11-16 14:11:20 UTC
This bug is for stabling a non-vulnerable version of R. It is up to the maintainers to decide *which* version that should be. While I agree that a newer version could be more suited, if the maintainers don't agree, please open a new stabling bug.
Comment 8 Markus Meier 2007-11-17 01:45:03 UTC
x86 stable, please note: dodoc: BUGS does not exist
Comment 9 Raúl Porcel (RETIRED) 2007-11-17 20:29:35 UTC
Comment 10 Markus Rothe (RETIRED) 2007-11-18 13:51:12 UTC
Comment 11 Tobias Scherbaum (RETIRED) 2007-11-18 17:40:52 UTC
Comment 12 Chris Gianelloni (RETIRED) 2007-11-20 21:56:29 UTC
Comment 13 Robert Buchholz (RETIRED) 2007-11-20 22:34:39 UTC
Comment 14 Pierre-Yves Rofes (RETIRED) 2008-01-09 20:34:31 UTC
GLSA 200801-02, sorry for the delay