[Rd] OfficeScan deletes Rterm as malware

[Roland Fuß]

I'm not sure if the problem is actually with R but thought I should 
report this anyway.


After Peter's email regarding the R 3.5.2 release today, I installed the 
Windows version right away (directly from CRAN and not from a mirror).


Unfortunately, my institute's AV sofware TrendMicro OfficeScan 12.0.5147 
Service Pack 1 stops and deletes Rterm.exe when running Rcmd.exe INSTALL 
with a local source package. It reports "OfficeScan detected a Behavior 
Monitoring policy violation and blocked the offending process(es)." and 
"Unauthorized File Encryption" by Rterm.exe.


I've deinstalled R 3.5.2 for now and switched back to 3.5.1, which works 
fine.


Best,

Roland Fuß

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] OfficeScan deletes Rterm as malware

[Joris Meys]

Dear Roland,

quite surprising, as online scans of TrendMicro turn up completely clean.
It looks like a false positive, which you can report to TrendMicro as
explained here :

https://success.trendmicro.com/solution/1115668-preventing-behavior-monitoring-false-detections-in-officescan#collapse1

On the same website they explain how you can whitelist it. I'll check at
home with a few other antiviruses, but I'm pretty certain this is a case of
TrendMicro being overly enthousiast in its protection.

Cheers
Joris

On Thu, Dec 20, 2018 at 2:52 PM Roland Fuß  wrote:

> I'm not sure if the problem is actually with R but thought I should
> report this anyway.
>
> After Peter's email regarding the R 3.5.2 release today, I installed the
> Windows version right away (directly from CRAN and not from a mirror).
>
> Unfortunately, my institute's AV sofware TrendMicro OfficeScan 12.0.5147
> Service Pack 1 stops and deletes Rterm.exe when running Rcmd.exe INSTALL
> with a local source package. It reports "OfficeScan detected a Behavior
> Monitoring policy violation and blocked the offending process(es)." and
> "Unauthorized File Encryption" by Rterm.exe.
>
> I've deinstalled R 3.5.2 for now and switched back to 3.5.1, which works
> fine.
>
> Best,
>
> Roland Fuß
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)


---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] OfficeScan deletes Rterm as malware

[Jeroen Ooms]

On Thu, Dec 20, 2018 at 2:52 PM Roland Fuß  wrote:
>
> I'm not sure if the problem is actually with R but thought I should
> report this anyway.
>
> After Peter's email regarding the R 3.5.2 release today, I installed the
> Windows version right away (directly from CRAN and not from a mirror).
>
> Unfortunately, my institute's AV sofware TrendMicro OfficeScan 12.0.5147
> Service Pack 1 stops and deletes Rterm.exe when running Rcmd.exe INSTALL
> with a local source package. It reports "OfficeScan detected a Behavior
> Monitoring policy violation and blocked the offending process(es)." and
> "Unauthorized File Encryption" by Rterm.exe.

I can't think of anything that has changed between R 3.5.1 and 3.5.2.
What does "Behavior Monitoring policy violation" mean? Does it say
what sort of policy?

A quick search reveals that the TrendMicro "Unauthorized File
Encryption" message is a frequent false positive for many different
software programs, including this thread at the rstudio forum:
https://support.rstudio.com/hc/en-us/community/posts/208171047-rsession-exe-flagged-as-virus

Perhaps it's just because you're one of the first people to install
this version, and your AV might use some "smart" learning system such
that the false positive will automatically disappear after a few more
people have installed and whitelisted the new R binaries.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Using `--configure.args` with configure.win on Windows

[Jim Hester]

Looking at the code for `R CMD INSTALL` [1] it looks like
`--configure-args` is not used on Windows, so there is not a way to pass
arguments to the `configure.win` script like there is for `configure`.

Is this lack intentional or simply an oversight because support for
configure.win was added later?

[1]:
https://github.com/wch/r-source/blob/8bc3a6f4b0c2fca3195cac427e9ad8b4448eaa73/src/library/tools/R/install.R#L670-L697

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] formula(model.frame(..)) is misleading

[William Dunlap via R-devel]

When formula() is applied to the output of model.frame() it ignores the
formula in the model.frame's 'terms' attribute:

  > d <- data.frame(A=log(1:6), B=LETTERS[rep(1:2,c(2,4))], C=1/(1:6),
D=rep(letters[25:26],c(4,2)), Y=1:6)
  > m0 <- model.frame(data=d, Y ~ A:B)
  > formula(m0)
  Y ~ A + B
  > `attributes<-`(terms(m0), value=NULL)
  Y ~ A:B

This is in part because model.frame()'s output has class "data.frame"
instread of c("model.frame","data.frame"), as SV4 did, so there are no
methods for model.frames.

Is there a reason that model.frame() returns a data.frame with extra
attributes but no special class or is it just an oversight?

Bill Dunlap
TIBCO Software
wdunlap tibco.com

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] formula(model.frame(..)) is misleading

[Martin Maechler]

> William Dunlap via R-devel 
> on Thu, 20 Dec 2018 15:09:56 -0800 writes:

> When formula() is applied to the output of model.frame()
> it ignores the formula in the model.frame's 'terms'
> attribute:

>> d <- data.frame(A=log(1:6), B=LETTERS[rep(1:2,c(2,4))],
>> C=1/(1:6),
> D=rep(letters[25:26],c(4,2)), Y=1:6)
>> m0 <- model.frame(data=d, Y ~ A:B) formula(m0)
>   Y ~ A + B
>> `attributes<-`(terms(m0), value=NULL)
>   Y ~ A:B

> This is in part because model.frame()'s output has class
> "data.frame" instread of c("model.frame","data.frame"), as
> SV4 did, so there are no methods for model.frames.

> Is there a reason that model.frame() returns a data.frame
> with extra attributes but no special class or is it just
> an oversight?

May guess is "oversight" || "well let's keep it simple"
Do you (all readers) see situation where it could harm now (with
the 20'000 packages on CRAN+BIoc+...) to do as SV4 (S version 4) has been doing?

I'd be sympathetic to class()ing it.
Martin

> Bill Dunlap TIBCO Software wdunlap tibco.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel