Re: [R-pkg-devel] [External] SETLENGTH()

[Vladimir Dergachev]

On Sat, 4 May 2024, luke-tier...@uiowa.edu wrote:


On Sat, 4 May 2024, Vladimir Dergachev wrote:

[Some people who received this message don't often get email from 
volo...@mindspring.com. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]


I noticed a note on RMVL package check page for development version of R:

Found non-API call to R: ?SETLENGTH?

Is this something that is work-in-progress for the development version, or
has SETLENGTH() been deprecated ? What should I use instead ?


SETLENGTH has never been part of the API. It is not safe to use except
in a very, very limited set of circumstances. Using it in other
settings will confuse the memory manager, leading at least to
mis-calculation of memory use information and possibly to
segfaults. For most uses I have seen, copying to a new vector of the
right size is the only safe option.

The one context where something along these lines might be OK is for
growable vectors. This concept is emphatically not in the API at this
point, and the way it is currently implemented in base is not robust
enough to become an API (even though some packages have used it). It
is possible that a proper API for this will be added; at that point
SETLENGTH will be removed from the accessible entry points on
platforms that allow this.

So if you are getting a note about SETLENGTH, either stop using it or
be prepared to make some changes at fairly short notice.

[Similar considerations apply to SET_TRUELENGT. In most but not all
cases using it is less dangerous, but you should still look for other
options if you want your code to continue to work.]


Great, thank you for the explanation ! I will rewrite the code to not use 
SETLENGTH().


My use case was to allocate a vector of some size N_max and then 
repeatedly populate it with variable number of elements. Since the vector 
was protected during the loop, I would have expected to save on memory 
allocation calls.


best

Vladimir Dergachev



Best,

luke



thank you very much

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



--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
  Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu



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

Re: [R-pkg-devel] [External] SETLENGTH()

[luke-tierney]

On Sat, 4 May 2024, Vladimir Dergachev wrote:

[Some people who received this message don't often get email from 
volo...@mindspring.com. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]


I noticed a note on RMVL package check page for development version of R:

Found non-API call to R: ?SETLENGTH?

Is this something that is work-in-progress for the development version, or
has SETLENGTH() been deprecated ? What should I use instead ?


SETLENGTH has never been part of the API. It is not safe to use except
in a very, very limited set of circumstances. Using it in other
settings will confuse the memory manager, leading at least to
mis-calculation of memory use information and possibly to
segfaults. For most uses I have seen, copying to a new vector of the
right size is the only safe option.

The one context where something along these lines might be OK is for
growable vectors. This concept is emphatically not in the API at this
point, and the way it is currently implemented in base is not robust
enough to become an API (even though some packages have used it). It
is possible that a proper API for this will be added; at that point
SETLENGTH will be removed from the accessible entry points on
platforms that allow this.

So if you are getting a note about SETLENGTH, either stop using it or
be prepared to make some changes at fairly short notice.

[Similar considerations apply to SET_TRUELENGT. In most but not all
cases using it is less dangerous, but you should still look for other
options if you want your code to continue to work.]

Best,

luke



thank you very much

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



--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

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

[R-pkg-devel] SETLENGTH()

[Vladimir Dergachev]

I noticed a note on RMVL package check page for development version of R:

Found non-API call to R: ‘SETLENGTH’

Is this something that is work-in-progress for the development version, or 
has SETLENGTH() been deprecated ? What should I use instead ?


thank you very much

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

Re: [R-pkg-devel] Urgent Review of R Packages in Light of Recent RDS Exploit

[Vladimir Dergachev]

On Sat, 4 May 2024, Maciej Nasinski wrote:


Hey Vladimir,
Thank you for your answer.
GitHub codespaces are "a separate computer" and are free for students and the 
educational sector.


Hi Maciej,

   What I was suggesting is that instead of encapsulating the application 
in a container that runs on the same physical hardware as other 
containers, you would be more secure to use a dedicated computer for the 
application.


   best

Vladimir Dergachev



The GitHub codespaces are a cloud service that can be created anytime, with a 
specific setup behind it (Dockerfile, settings.json, renv.lock,  ...).
The machines GitHub codespaces offer are quite decent (4core 16GB RAM 32GB 
Memory). 
You can destroy and recreate it anytime you want to.
You run GitHub codespaces from a web browser, but as Ivan stated, you may need 
a decent computer to handle them, even if all calculations are done on the 
cloud.
I use GitHub codespaces for all my University projects with my friends.  It is 
great that I do not have to explain many things nowadays to older stuff as many 
things are automatic on GitHub
codespaces.

KR
Maciej Nasinski
University of Warsaw

On Sat, 4 May 2024 at 18:53, Vladimir Dergachev  wrote:


  On Sat, 4 May 2024, Maciej Nasinski wrote:

  > Thank you all for the discussion.Then, we should promote "code 
awareness" and count on the CRAN Team to continue their great work:)
  >
  > What do you think about promoting containers?
  > Nowadays, containers are more accessible, with GitHub codespaces being 
more affordable (mostly free for students and the educational sector).
  > I feel containers can help a little bit in making the R work more 
secure, but once more when used properly.

  I think it is not a good idea to focus on one use case. Some people will
  find containers more convenient some don't.

  If you want security, I am sure containers are not the right approach -
  get a separate physical computer instead.

  >From a convenience point of view containers are only ok as long as you
  don't need to interface with outside software, then it gets tricky as the
  security keeping things containerized starts interfering with getting work
  done. (Prime example: firefox snap on ubuntu)

  One situation where containers can be helpful is distribution of
  commercial applications. Containers allow you to freeze library versions,
  so your app can still run with old C library or a specific version of
  Python. You can then _hope_ that containers will have fewer compatibility
  issues, or at least you can sell containers to your management on this
  idea.

  But this is not really a good thing for an open source project like R.

  best

  Vladimir Dergachev

  >
  > KR
  > Maciej Nasinski
  > University of Warsaw
  >
  > On Sat, 4 May 2024 at 07:17, Vladimir Dergachev 
 wrote:
  >
  >
  >       On Fri, 3 May 2024, Ivan Krylov via R-package-devel wrote:
  >
  >       > Dear Maciej Nasinski,
  >       >
  >       > On Fri, 3 May 2024 11:37:57 +0200
  >       > Maciej Nasinski  wrote:
  >       >
  >       >> I believe we must conduct a comprehensive review of all 
existing CRAN
  >       >> packages.
  >       >
  >       > Why now? R packages are already code. You don't need poisoned 
RDS files
  >       > to wreak havoc using an R package.
  >       >
  >       > On the other hand, R data files contain R objects, which 
contain code.
  >       > You don't need exploits to smuggle code inside an R object.
  >       >
  >
  >       I think the confusion arises because users expect "R data files" 
to only
  >       contain data, i.e. numbers, but they can contain any R object, 
including
  >       functions.
  >
  >       I, personally, never use them out of concern that accidentally 
saved
  >       function can override some functionality and be difficult to 
debug. And,
  >       of course, I never save R sessions.
  >
  >       If you need to pass data it is a good idea to use some common 
format like
  >       tab-separated CSV files with column names. One can also use MVL 
files
  >       (RMVL package).
  >
  >       best
  >
  >       Vladimir Dergachev
  >
  >
  >




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

Re: [R-pkg-devel] Urgent Review of R Packages in Light of Recent RDS Exploit

[Ben Bolker]

 This is true, and useful.

  Many old-school R users are nervous about coming to rely on tools 
that are controlled by a company that may rescind that availability in 
the future, or may possibly use your code in ways you don't want (I have 
not gone all the way through 
https://docs.github.com/en/site-policy/privacy-policies/github-general-privacy-statement 
...)


   For example, Travis was great for CI for a while then pulled the 
plug on free use for public repos, then everyone jumped to GitHub 
actions ...; Microsoft Open R and MRAN were around for a while and then 
weren't ...


  That doesn't mean one should necessarily avoid these tools; it just 
explains why some people do.


On 2024-05-04 1:43 p.m., Maciej Nasinski wrote:

Hey Vladimir,

Thank you for your answer.
GitHub codespaces are "a separate computer" and are free for students and
the educational sector.
The GitHub codespaces are a cloud service that can be created anytime, with
a specific setup behind it (Dockerfile, settings.json, renv.lock,  ...).
The machines GitHub codespaces offer are quite decent (4core 16GB RAM 32GB
Memory).
You can destroy and recreate it anytime you want to.
You run GitHub codespaces from a web browser, but as Ivan stated, you may
need a decent computer to handle them, even if all calculations are done on
the cloud.
I use GitHub codespaces for all my University projects with my friends.  It
is great that I do not have to explain many things nowadays to older stuff
as many things are automatic on GitHub codespaces.

KR
Maciej Nasinski
University of Warsaw

On Sat, 4 May 2024 at 18:53, Vladimir Dergachev 
wrote:




On Sat, 4 May 2024, Maciej Nasinski wrote:


Thank you all for the discussion.Then, we should promote "code

awareness" and count on the CRAN Team to continue their great work:)


What do you think about promoting containers?
Nowadays, containers are more accessible, with GitHub codespaces being

more affordable (mostly free for students and the educational sector).

I feel containers can help a little bit in making the R work more

secure, but once more when used properly.

I think it is not a good idea to focus on one use case. Some people will
find containers more convenient some don't.

If you want security, I am sure containers are not the right approach -
get a separate physical computer instead.

 From a convenience point of view containers are only ok as long as you
don't need to interface with outside software, then it gets tricky as the
security keeping things containerized starts interfering with getting work
done. (Prime example: firefox snap on ubuntu)

One situation where containers can be helpful is distribution of
commercial applications. Containers allow you to freeze library versions,
so your app can still run with old C library or a specific version of
Python. You can then _hope_ that containers will have fewer compatibility
issues, or at least you can sell containers to your management on this
idea.

But this is not really a good thing for an open source project like R.

best

Vladimir Dergachev



KR
Maciej Nasinski
University of Warsaw

On Sat, 4 May 2024 at 07:17, Vladimir Dergachev 

wrote:



   On Fri, 3 May 2024, Ivan Krylov via R-package-devel wrote:

   > Dear Maciej Nasinski,
   >
   > On Fri, 3 May 2024 11:37:57 +0200
   > Maciej Nasinski  wrote:
   >
   >> I believe we must conduct a comprehensive review of all

existing CRAN

   >> packages.
   >
   > Why now? R packages are already code. You don't need poisoned

RDS files

   > to wreak havoc using an R package.
   >
   > On the other hand, R data files contain R objects, which contain

code.

   > You don't need exploits to smuggle code inside an R object.
   >

   I think the confusion arises because users expect "R data files"

to only

   contain data, i.e. numbers, but they can contain any R object,

including

   functions.

   I, personally, never use them out of concern that accidentally

saved

   function can override some functionality and be difficult to

debug. And,

   of course, I never save R sessions.

   If you need to pass data it is a good idea to use some common

format like

   tab-separated CSV files with column names. One can also use MVL

files

   (RMVL package).

   best

   Vladimir Dergachev





[[alternative HTML version deleted]]

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


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


__
R-package-devel@r-project.org mailing list

Re: [R-pkg-devel] Urgent Review of R Packages in Light of Recent RDS Exploit

[Maciej Nasinski]

Hey Vladimir,

Thank you for your answer.
GitHub codespaces are "a separate computer" and are free for students and
the educational sector.
The GitHub codespaces are a cloud service that can be created anytime, with
a specific setup behind it (Dockerfile, settings.json, renv.lock,  ...).
The machines GitHub codespaces offer are quite decent (4core 16GB RAM 32GB
Memory).
You can destroy and recreate it anytime you want to.
You run GitHub codespaces from a web browser, but as Ivan stated, you may
need a decent computer to handle them, even if all calculations are done on
the cloud.
I use GitHub codespaces for all my University projects with my friends.  It
is great that I do not have to explain many things nowadays to older stuff
as many things are automatic on GitHub codespaces.

KR
Maciej Nasinski
University of Warsaw

On Sat, 4 May 2024 at 18:53, Vladimir Dergachev 
wrote:

>
>
> On Sat, 4 May 2024, Maciej Nasinski wrote:
>
> > Thank you all for the discussion.Then, we should promote "code
> awareness" and count on the CRAN Team to continue their great work:)
> >
> > What do you think about promoting containers?
> > Nowadays, containers are more accessible, with GitHub codespaces being
> more affordable (mostly free for students and the educational sector).
> > I feel containers can help a little bit in making the R work more
> secure, but once more when used properly.
>
> I think it is not a good idea to focus on one use case. Some people will
> find containers more convenient some don't.
>
> If you want security, I am sure containers are not the right approach -
> get a separate physical computer instead.
>
> From a convenience point of view containers are only ok as long as you
> don't need to interface with outside software, then it gets tricky as the
> security keeping things containerized starts interfering with getting work
> done. (Prime example: firefox snap on ubuntu)
>
> One situation where containers can be helpful is distribution of
> commercial applications. Containers allow you to freeze library versions,
> so your app can still run with old C library or a specific version of
> Python. You can then _hope_ that containers will have fewer compatibility
> issues, or at least you can sell containers to your management on this
> idea.
>
> But this is not really a good thing for an open source project like R.
>
> best
>
> Vladimir Dergachev
>
> >
> > KR
> > Maciej Nasinski
> > University of Warsaw
> >
> > On Sat, 4 May 2024 at 07:17, Vladimir Dergachev 
> wrote:
> >
> >
> >   On Fri, 3 May 2024, Ivan Krylov via R-package-devel wrote:
> >
> >   > Dear Maciej Nasinski,
> >   >
> >   > On Fri, 3 May 2024 11:37:57 +0200
> >   > Maciej Nasinski  wrote:
> >   >
> >   >> I believe we must conduct a comprehensive review of all
> existing CRAN
> >   >> packages.
> >   >
> >   > Why now? R packages are already code. You don't need poisoned
> RDS files
> >   > to wreak havoc using an R package.
> >   >
> >   > On the other hand, R data files contain R objects, which contain
> code.
> >   > You don't need exploits to smuggle code inside an R object.
> >   >
> >
> >   I think the confusion arises because users expect "R data files"
> to only
> >   contain data, i.e. numbers, but they can contain any R object,
> including
> >   functions.
> >
> >   I, personally, never use them out of concern that accidentally
> saved
> >   function can override some functionality and be difficult to
> debug. And,
> >   of course, I never save R sessions.
> >
> >   If you need to pass data it is a good idea to use some common
> format like
> >   tab-separated CSV files with column names. One can also use MVL
> files
> >   (RMVL package).
> >
> >   best
> >
> >   Vladimir Dergachev
> >
> >
> >

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Urgent Review of R Packages in Light of Recent RDS Exploit

[Vladimir Dergachev]

On Sat, 4 May 2024, Maciej Nasinski wrote:


Thank you all for the discussion.Then, we should promote "code awareness" and 
count on the CRAN Team to continue their great work:)

What do you think about promoting containers?
Nowadays, containers are more accessible, with GitHub codespaces being more 
affordable (mostly free for students and the educational sector).
I feel containers can help a little bit in making the R work more secure, but 
once more when used properly.


I think it is not a good idea to focus on one use case. Some people will 
find containers more convenient some don't.


If you want security, I am sure containers are not the right approach - 
get a separate physical computer instead.


From a convenience point of view containers are only ok as long as you 
don't need to interface with outside software, then it gets tricky as the 
security keeping things containerized starts interfering with getting work 
done. (Prime example: firefox snap on ubuntu)


One situation where containers can be helpful is distribution of 
commercial applications. Containers allow you to freeze library versions, 
so your app can still run with old C library or a specific version of 
Python. You can then _hope_ that containers will have fewer compatibility 
issues, or at least you can sell containers to your management on this 
idea.


But this is not really a good thing for an open source project like R.

best

Vladimir Dergachev



KR
Maciej Nasinski
University of Warsaw

On Sat, 4 May 2024 at 07:17, Vladimir Dergachev  wrote:


  On Fri, 3 May 2024, Ivan Krylov via R-package-devel wrote:

  > Dear Maciej Nasinski,
  >
  > On Fri, 3 May 2024 11:37:57 +0200
  > Maciej Nasinski  wrote:
  >
  >> I believe we must conduct a comprehensive review of all existing CRAN
  >> packages.
  >
  > Why now? R packages are already code. You don't need poisoned RDS files
  > to wreak havoc using an R package.
  >
  > On the other hand, R data files contain R objects, which contain code.
  > You don't need exploits to smuggle code inside an R object.
  >

  I think the confusion arises because users expect "R data files" to only
  contain data, i.e. numbers, but they can contain any R object, including
  functions.

  I, personally, never use them out of concern that accidentally saved
  function can override some functionality and be difficult to debug. And,
  of course, I never save R sessions.

  If you need to pass data it is a good idea to use some common format like
  tab-separated CSV files with column names. One can also use MVL files
  (RMVL package).

  best

  Vladimir Dergachev




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

Re: [R-pkg-devel] Trouble with dependencies on phyloseq and microViz

[Ivan Krylov via R-package-devel]

В Sat, 4 May 2024 15:53:25 +
Sharon Bewick  пишет:

> I have a dependency on phyloseq, which is available through GitHub
> but not on the CRAN site. I have a similar problem with microViz,
> however I’ve managed to make it suggested, rather than required.
> There is no way to get around the phyloseq requirement. How do I fix
> this problem so that I can upload my package to the CRAN website?

Did a human reviewer tell you to get rid of the dependencies? There is
at least 444 packages on CRAN with strong dependencies on Bioconductor
packages, so your phyloseq dependency should work. In fact, 14 of them
depend on phyloseq.

What you need is an Additional_repositories field in your DESCRIPTION
specifying the source package repository where microViz could be
installed from. I think that

Additional_repositories: https://david-barnett.r-universe.dev

...should work.

Besides that, you'll need to increment the version and list the *.Rproj
file in .Rbuildignore:
https://win-builder.r-project.org/incoming_pretest/HybridMicrobiomes_0.1.1_20240504_173331/Debian/00check.log

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Trouble with dependencies on phyloseq and microViz

[Duncan Murdoch]

On 04/05/2024 11:53 a.m., Sharon Bewick wrote:

I’m having trouble with:
r-oldrel-macos-arm64 

and
r-oldrel-macos-x86_64 


flagging an error because I have a dependency on phyloseq, which is available 
through GitHub but not on the CRAN site. I have a similar problem with 
microViz, however I’ve managed to make it suggested, rather than required. 
There is no way to get around the phyloseq requirement. How do I fix this 
problem so that I can upload my package to the CRAN website? I feel like I had 
this problem with microViz in the past, but now it’s coming up with phylseq 
too, and I can’t remove that dependency.



phyloseq is a Bioconductor package. It appears to be available from 
BioConductor, so it doesn't matter that it's not on CRAN.


Have you tried submitting your package to CRAN?  If so, could you show 
us the error you received?


Duncan Murdoch

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

[R-pkg-devel] Trouble with dependencies on phyloseq and microViz

[Sharon Bewick]

I’m having trouble with:
r-oldrel-macos-arm64 

and
r-oldrel-macos-x86_64 


flagging an error because I have a dependency on phyloseq, which is available 
through GitHub but not on the CRAN site. I have a similar problem with 
microViz, however I’ve managed to make it suggested, rather than required. 
There is no way to get around the phyloseq requirement. How do I fix this 
problem so that I can upload my package to the CRAN website? I feel like I had 
this problem with microViz in the past, but now it’s coming up with phylseq 
too, and I can’t remove that dependency.

Thanks!
Sharon__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Urgent Review of R Packages in Light of Recent RDS Exploit

[Ivan Krylov via R-package-devel]

On Sat, 4 May 2024 08:09:28 +0200
Maciej Nasinski  wrote:

> What do you think about promoting containers?

Containers have an attack surface too, have user experience problems
(how's Docker on Windows?) and may bring in more third-party code than
what you're trying to protect against (whole operating system images!).
Even Firejail and Bubblewrap, containers specifically designed to
sandbox untrusted code, have bugs in their setup or implementation
every now and then.

Still, you are welcome to run third-party code in a virtual machine or
a container. It may be not everyone's favourite trade-off, but is a net
increase in security over running untrusted code directly. Feel free to
search for a point on the Pareto optimal line between security and
convenience that you'll be comfortable with: https://xkcd.com/2044/

> Nowadays, containers are more accessible, with GitHub codespaces
> being more affordable (mostly free for students and the educational
> sector).

The GitHub-isation of the development process is kind of a
vulnerability too, or at the very least has a cost. I'm a few
handshakes away from several people who have been disappeared from
GitHub and couldn't get their accounts back. Microsoft is too big to
have real tech support [*], so once you fall foul of their AI
moderation systems, you'll have to be a Hacker News celebrity to
attract attention of a human on the inside.

I've got an ageing ThinkPad that I cannot afford to replace. It can
process all the data I've been gathering during my PhD and then some,
least squares, inverse problems, you name it, all while playing music
and having Quake I open. But the moment I try to launch Codespaces, it
downloads more bytes of JavaScript than the whole Quake I installation
takes in size, and then the browser overheats the laptop.

Maybe programming other people's computers in the browser is the
future, but then you need a fancy laptop and maybe a friend in
Microsoft just to be admitted into that future. A solution for some,
but not for all.

-- 
Best regards,
Ivan

[*] https://danluu.com/diseconomies-scale/

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

Re: [R-pkg-devel] Urgent Review of R Packages in Light of Recent RDS Exploit

[Maciej Nasinski]

Thank you all for the discussion.
Then, we should promote "code awareness" and count on the CRAN Team to
continue their great work:)

What do you think about promoting containers?
Nowadays, containers are more accessible, with GitHub codespaces being more
affordable (mostly free for students and the educational sector).
I feel containers can help a little bit in making the R work more
secure, but once more when used properly.

KR
Maciej Nasinski
University of Warsaw

On Sat, 4 May 2024 at 07:17, Vladimir Dergachev 
wrote:

>
>
> On Fri, 3 May 2024, Ivan Krylov via R-package-devel wrote:
>
> > Dear Maciej Nasinski,
> >
> > On Fri, 3 May 2024 11:37:57 +0200
> > Maciej Nasinski  wrote:
> >
> >> I believe we must conduct a comprehensive review of all existing CRAN
> >> packages.
> >
> > Why now? R packages are already code. You don't need poisoned RDS files
> > to wreak havoc using an R package.
> >
> > On the other hand, R data files contain R objects, which contain code.
> > You don't need exploits to smuggle code inside an R object.
> >
>
> I think the confusion arises because users expect "R data files" to only
> contain data, i.e. numbers, but they can contain any R object, including
> functions.
>
> I, personally, never use them out of concern that accidentally saved
> function can override some functionality and be difficult to debug. And,
> of course, I never save R sessions.
>
> If you need to pass data it is a good idea to use some common format like
> tab-separated CSV files with column names. One can also use MVL files
> (RMVL package).
>
> best
>
> Vladimir Dergachev
>
>

[[alternative HTML version deleted]]

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