similar to: Regarding the Security Vulnerability CVE 2024 - 27322

Dear Aishwarya Priyadarshini, Welcome to R-help! Most people here aren't affiliated with R Foundation. ? Wed, 26 Jun 2024 17:03:37 +0000 "Priya, Aishwarya via R-help" <r-help at r-project.org> ?????: > I am reaching out to seek your guidance on addressing the security > vulnerability CVE-2024-27322. > To address this issue effectively, it appears that we need to

Hi Ivan and R - Help Team, Thank you for your prompt response and the helpful information. I have another query: Is there a way to patch or upgrade the existing installation to version 4.4.0, rather than having to uninstall the older version and then install the latest one? A direct upgrade or patch would greatly simplify the process and reduce downtime. Your guidance on this matter would be

Dear R-core, I just received notification of CVE-2024-27322 [1] in RedHat's Bugzilla. We updated R to v4.4.0 in Fedora rawhide, F40, EPEL9 and EPEL8, so no problem there. However, F38 and F39 will stay at v4.3.3, and I was wondering if there's a specific patch available, or if you could point me to the commits that fixed the issue, so that we can cherry-pick them for F38 and F39. Thanks.

svn diff -c 86235 ~/r-devel/R (or 86238 for the port to the release branch) should be easily backported. (CC Luke in case there is more to it) - pd > On 30 Apr 2024, at 11:28 , I?aki Ucar <iucar at fedoraproject.org> wrote: > > Dear R-core, > > I just received notification of CVE-2024-27322 [1] in RedHat's Bugzilla. We > updated R to v4.4.0 in Fedora rawhide, F40,

On 30 April 2024 at 11:59, peter dalgaard wrote: | svn diff -c 86235 ~/r-devel/R Which is also available as https://github.com/r-devel/r-svn/commit/f7c46500f455eb4edfc3656c3fa20af61b16abb7 Dirk | (or 86238 for the port to the release branch) should be easily backported. | | (CC Luke in case there is more to it) | | - pd | | > On 30 Apr 2024, at 11:28 , I?aki Ucar <iucar at

Many thanks both. I'll wait for Luke's confirmation to trigger the update with the backported fix. I?aki On Tue, 30 Apr 2024 at 12:42, Dirk Eddelbuettel <edd at debian.org> wrote: > > On 30 April 2024 at 11:59, peter dalgaard wrote: > | svn diff -c 86235 ~/r-devel/R > > Which is also available as > >

All, There seems to be a hullaboo about a vulnerability in R when deserializing untrusted data: https://hiddenlayer.com/research/r-bitrary-code-execution https://nvd.nist.gov/vuln/detail/CVE-2024-27322 https://www.kb.cert.org/vuls/id/238194 Apparently a fix was made for R 4.4.0, but I see no mention of it in the changes report: https://cloud.r-project.org/bin/windows/base/NEWS.R-4.4.0.html

Hi, Martin et al.: On 6/10/24 9:32 AM, Martin Maechler wrote: >>>>>> Spencer Graves >>>>>> on Mon, 10 Jun 2024 07:50:13 -0500 writes: > > > Hi, Gabor et al.: Thanks for this. I should change my > > current application to use either zoo or xts, as Gabor > > suggests. > > > > However, I was

zoo overcomes many of the limitations of ts: library(zoo) as.ts(head(as.zoo(presidents))) ## Qtr1 Qtr2 Qtr3 Qtr4 ## 1945 NA 87 82 75 ## 1946 63 50 xts also works here. On Sun, Jun 9, 2024 at 12:04?PM Spencer Graves <spencer.graves at prodsyse.com> wrote: > > Hello, All: > > > The 'head' and 'tail' functions strip the time

Hello, All: The 'head' and 'tail' functions strip the time from a 'ts' object. Example: > head(presidents) [1] NA 87 82 75 63 50 > window(presidents, 1945, 1946.25) Qtr1 Qtr2 Qtr3 Qtr4 1945 NA 87 82 75 1946 63 50 Below please find code for 'head.ts' and 'tail.ts' that matches 'window'. Comments?

Hi, Gabor et al.: Thanks for this. I should change my current application to use either zoo or xts, as Gabor suggests. However, I was surprised to learn that "[.ts" does NOT return an object of class "ts". I see that "head.default" and "head.matrix" both call "[", so "head" cannot return a ts object, because "["

>>>>> Spencer Graves >>>>> on Mon, 10 Jun 2024 07:50:13 -0500 writes: > Hi, Gabor et al.: Thanks for this. I should change my > current application to use either zoo or xts, as Gabor > suggests. > However, I was surprised to learn that "[.ts" does NOT > return an object of class "ts". I see that

It isn't really clear that it can't work. This does work by inserting NA's. library(zoo) as.ts(as.zoo(lynx)[ c(1:3, 7) ] ) ## Time Series: ## Start = 1821 ## End = 1827 ## Frequency = 1 ## [1] 269 321 585 NA NA NA 3928 On Mon, Jun 10, 2024 at 10:32?AM Martin Maechler <maechler at stat.math.ethz.ch> wrote: > > >>>>> Spencer Graves

> It isn't really clear that it can't work. This does work by inserting NA's... > > library(zoo) > as.ts(as.zoo(lynx)[ c(1:3, 7) ] ) If by 'this' you mean indexing, it would be very confusing and error prone for expressions like lynx[c(1:3, 7)] (lynx is from class 'ts') to return a ts object with NA's inserted and, even more so, since this has been

> In a lattice plot like this: > > win.graph() > xyplot(tmx~frequ|as.factor(as.numeric(spf)),groups=as.factor(blm), > data=tmx,type="l",pch=16,xlab="frequency (N)",ylab="Area held (ha)", > auto.key=list(blm,points=F,lines=T,title="Blm factor",cex.title=0.7, > cex=0.7,corner=c(1,1)),main="Mangroves target=1573ha",layout=c(2,3))

Slightly off topic, but maybe some can suggest something off list... Trying to upgrade a 7960 that was running skinny. I've got sip v3.2.0 installed and running, and am able to place calls via *, etc. However, when upgrading to v4.4.0 I can never get to the point of being able to place a call (eg, no dialtone, etc). I can ping the phone, look at the Network Config, etc, but I can't

I think we will take over to finish the missing parts of the German and French translation. To do this and since I do not want to play around with the .rc format, Trados can directly process a .rc file without the next to process back and forth to another format and because for the 3-4 missing files, and since I want to remain consistent with the rest, I will create a Translation Memory under

A few days ago I demoted my first DC (a v4.2.14, I think) and thought the demote had gone well. Now, when I run "samba-tool dnsupdate --verbose" I can see references to the first DC that remain. Unfortunately, that DC no longer exists so I simply cannot demote it again. Following the instructions on the "Demote a Samba AD DC" page "Verifying The Demotion" section, I

On Thu, 2016-10-13 at 19:00 -0500, Bob of Donelson Trophy via samba wrote: > A few days ago I demoted my first DC (a v4.2.14, I think) and thought > the demote had gone well. Now, when I run "samba-tool dnsupdate > --verbose" I can see references to the first DC that remain. > Unfortunately, that DC no longer exists so I simply cannot demote it > again.  > >

Hello, This problem originally surfaced as an interaction between 'brms', 'rstan' and 'Rcpp' [1]: a call to dimnames() from the 'brms' package on an object of an S4 class owned by the 'rstan' package tried to load its namespace. rstan:::.onLoad needs to load Rcpp modules, which uses load actions and reference classes. Since methods:::.findInheritedMethods