[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 <volodya using mindspring.com>
> 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 <volodya using mindspring.com>
>> 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 <nasinski.maciej using gmail.com> 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 using 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.