[Rd] Proposal to limit Internet access during package load

[Tomas Kalibera]

On 9/27/22 18:42, Blätte, Andreas wrote:
> Dear all,
>
> my apologies for a dull question. I think I do understand that unnoticed Internet access requires scrutiny and a more explicit approach.
>
> But I am not sure how this would impact on the practice on many Windows machines to download static libraries from one of the rwinlib repositories? See https://github.com/rwinlib, an approach taken by quite a few packages (src/Makevars.win triggers tools/winlibs.R for downloading a static library).
>
> I am asking because a package I maintain (RcppCWB) uses the approach, and  am not sure whether and how the discussion has addressed this scenario. It may not be covered by Iñakis initial three scenario?

Dear Andreas,

please let me clarify for others that your package only downloads 
pre-compiled static libraries for R 4.1 and earlier on Windows, what is 
already now the "old release" and will not be checked against by CRAN 
once R 4.3 is released. For R 4.2 ("release") and R-devel, your package 
includes the source code of the library and links it, which is in 
compliance with the CRAN policy. So if any new possible restriction in 
downloading along the lines Inaki raised was set, it probably won't 
affect you.

Downloading pre-compiled static libraries is only possible as very last 
resort and only with agreement of the CRAN team - see the CRAN policy 
for details (https://cran.r-project.org/web/packages/policies.html, look 
for "external"). In other words, unless those special conditions are 
met, it is already banned now.

More explanation for why it is a bad thing can be found in 
https://cran.r-project.org/bin/windows/base/howto-R-4.2.html:

"For transparency, source packages should contain source (not executable 
code). Using pre-compiled libraries may lead to that after few years the 
information on how they were built gets lost or significantly outdated 
and no longer working. Using older binary code may provide insufficient 
performance (newer compilers tend to optimize better). Also, the CRAN 
(and Bioconductor) repositories are used as a unique test suite not only 
for R itself but also the toolchain, and by re-using pre-compiled 
libraries, some parts will not be tested. Compiler bugs are found and 
when fixed, the code needs to be re-compiled. Finally, object files (and 
hence static libraries, particularly when using C++) on Windows tend to 
become incompatible when even the same toolchain is upgraded. Going from 
MSVCRT to UCRT is an extreme case when all such code becomes 
incompatible, and adding support to 64-bit ARM would be another extreme 
case, but smaller updates of different parts of the toolchain or even 
some libraries in it lead to incompatibilities. The issues mentioned 
here are based on experience with the transition to UCRT and Rtools42; 
all of these things have happened and dealing with the downloads and 
re-use of static libraries was one of the biggest challenges."

With respect to any possible restriction on downloading in principle, 
this is no different from downloading external source code (both is 
needed when the native code of packages is being built, so during "R CMD 
INSTALL"), and that has already been mentioned in this thread. So it 
doesn't have to be discussed specially I think.

Best
Tomas

>
> Kind regards, Andreas
>
>
>
>
>
> Am 27.09.22, 10:15 schrieb "R-devel im Auftrag von Iñaki Ucar" <r-devel-bounces using r-project.org im Auftrag von iucar using fedoraproject.org>:
>
>      El mar., 27 sept. 2022 4:22, Dirk Eddelbuettel <edd using debian.org> escribió:
>
>      >
>      > Regarding 'system' libraries: Packages like stringi and nloptr download the
>      > source of, respectively, libicu or libnlopt and build a library _if_ the
>      > library is not found locally.  If we outlaw this, more users may hit a
>      > brick
>      > wall because they cannot install system libraries (for lack of
>      > permissions),
>      > or don't know how to, or ...  These facilities were not added to run afoul
>      > of
>      > best practices -- they were added to help actual users. Something to keep
>      > in
>      > mind.
>
>
>      Yes, but then IMO Internet access should be explicitly enabled by the user
>      with a flag. By default, it should be disabled and packages on CRAN should
>      install as is.
>
>      Iñaki
>
>      	[[alternative HTML version deleted]]
>
>      ______________________________________________
>      R-devel using r-project.org mailing list
>      https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel