Re: [R-pkg-devel] Possible malware(?) in a vignette

[Simon Urbanek]

Iñaki,

I think you got it backwards in your conclusions: CRAN has not generated that 
PDF file (and Windows machines are not even involved here), it is the contents 
of a contributed package, so CRAN itself is not compromised. Also it is far 
from clear that it is really a malware - in fact it's certainly NOT what the 
website you linked claims as those tags imply trojans disguising ZIPped 
executables as PDF, but the file is an actual valid PDF and not even remotely a 
ZIP file (in fact is it consistent with pdflatex output). I looked at the 
decompressed payload of the PDF and the only binary payload are embedded fonts 
so my guess would be that some byte sequence in the fonts gets detected as 
false-positive trojan, but since there is no detail on the report we can just 
guess. False-positives are a common problem and this would not be the first 
one. Further indication that it's a false-positive is that a simple 
re-packaging the streams (i.e. NOT changing the actual PDF contents) make the 
same file pass the tests as clean.

Also note that there is a bit of a confusion as the currently released version 
(poweRlaw 0.80.0) does not get flagged, so it is only the archived version 
(from 2020).

Cheers,
Simon



> On 26/01/2024, at 12:02 AM, Iñaki Ucar  wrote:
> 
> On Thu, 25 Jan 2024 at 10:13, Colin Gillespie  wrote:
>> 
>> Hi All,
>> 
>> I've had two emails from users in the last 24 hours about malware
>> around one of my vignettes. A snippet from the last user is:
>> 
>> ---
>> I was trying to install a R package that depends on PowerRLaw two
>> weeks ago.  However my virus protection software F secure did not
>> allow me to install it from CRAN, while installation from GitHub
>> worked normally. Virus protection software claimed that
>> d_jss_paper.pdf is compromised. I asked about this from our IT support
>> and they asked it from the company F secure. Now F secure has analysed
>> the file and according them it is malware.
>> 
>> “Upon analyzing, our analysis indicates that the file you submitted is
>> malicious. Hence the verdict will remain
> 
> See 
> https://www.virustotal.com/gui/file/9486d99c1c1f2d1b06f0b6c5d27c54d4f6e39d69a91d7fad845f323b0ab88de9/behavior
> 
> According to the sandboxed analysis, there's something there trying to
> tamper with the Acrobat installation. It tries several Windows paths.
> That's not good.
> 
> The good news is that, if I recreate the vignette from your repo, the
> file is different, different hash, and it's clean.
> 
> The bad news is that... this means that CRAN may be compromised. I
> urge CRAN maintainers to check all the PDF vignettes and scan the
> Windows machines for viruses.
> 
> Best,
> Iñaki
> 
> 
>> 
>> ---
>> 
>> Other information is:
>> 
>> * Package in question:
>> https://cran.r-project.org/web/packages/poweRlaw/index.html
>> * Package hasn't been updated for three years
>> * Vignette in question:
>> https://cran.r-project.org/web/packages/poweRlaw/vignettes/d_jss_paper.pdf
>> 
>> CRAN asked me to fix
>> https://cran.r-project.org/web/checks/check_results_poweRlaw.html a
>> couple of days ago - which I'm in the process of doing.
>> 
>> Any ideas?
>> 
>> Thanks
>> Colin
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> 
> 
> -- 
> Iñaki Úcar
> 

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

Re: [R-pkg-devel] new maintainer for CRAN package XML

[Henrik Bengtsson]

Some thoughts for what the next steps could be:

I could be wrong, but I doubt that there's someone out there that
wants to pick up 'XML' and start developing it beyond keeping the
lights on.  I also think the community agrees that 'xml2' is the
recommended package to use for XML-related needs.  If this can be
agreed upon, I think the best path forward would be to declare 'XML'
being deprecated. This is some that the current maintainer (CRAN Team)
could already do, but updating the document and the package
Description field to:

[WARNING: The 'XML' package is deprecated. Please do not add it as a
dependency to your R package.] Many approaches for both reading and
creating XML (and HTML) documents (including DTDs), both local and
accessible via HTTP or FTP. Also offers access to an 'XPath'
"interpreter".

That would at least help stopping the influx of new packages being
added that depends on XML, especially since not everyone might be
aware of the state of 'XML' and that 'xml2' exists as an alternative.

This also begs the question: Do we need a way to formally declare a
whole package being deprecated?  Is this something that could be added
to the DESCRIPTION file?  Deprecated: TRUE?  Or something richer like
"Lifecycle: deprecated"?  With such a mechanism in place, 'R CMD
check' could give a NOTE for deprecated dependencies.  That could also
be a block for *new* CRAN submission; existing CRAN package should be
accepted ("grandfathered in").  With a richer {deprecation, ...,
defunct} vocabulary, we could produce WARNINGs and eventually ERRORs
too.


/Henrik

On Thu, Jan 25, 2024 at 9:11 AM Heather Turner  wrote:
>
> Re: guidance on how to migrate from XML to xml2, these notes from Daniel Nüst 
> may be helpful: 
> https://gist.github.com/nuest/3ed3b0057713eb4f4d75d11bb62f2d66.
>
> Best wishes,
> Heather
>
> On Wed, Jan 24, 2024, at 3:38 PM, Emmanuel Blondel wrote:
> > if XML is deprecated, then what would be the choice for a package
> > maintainer? Move to xml2 probably at some point I assume
> >
> > I use XML in the R packages I've been developing. For some of them, I
> > started before CRAN started being the maintainer, and before xml2
> > inception. The thing is that XML fulfills requirements, it works and
> > fulfills needs of depending packages that made the choice to use it. For
> > this, it deserves to be maintained in CRAN, without having to enter into
> > comparison exercices with other packages that , as of today, may be
> > better to rely on (with certainly very good reasons).
> >
> > Moving to xml2 (or whatever other package), which although I could agree
> > on the principle, can be costly for packages that use extensively XML.
> > Doing so would mean that we first get the assurance that all XML
> > features are covered elsewhere, and can be migrated smoothly.
> >
> > In any case, please acknowledge that this kind of migration may take
> > time and require resources that vary (or even are missing) depending on
> > the package projects. I doubt having CRAN setting a common deadline for
> > retirement is a good way to foster an efficient maintenance of R
> > packages depending on XML. It would be good to receive guidance how to
> > migrate, while ensuring backward compatibility on our package features.
> >
> > Best
> >
> > Le 24/01/2024 à 15:59, Jeroen Ooms a écrit :
> >> On Mon, Jan 22, 2024 at 3:51 PM Uwe Ligges
> >>  wrote:
> >>> Dear package developers,
> >>>
> >>> the CRAN team (and Professor Ripley in particular) has been the defacto
> >>> maintainer of CRAN package 'XML'.
> >>> Our hope was that maintainers of packages depending on XML will migrate
> >>> to other packages for reading XML structures. This has not happened and
> >>> we still see dozens of strong dependencies on XML.
> >> How is this hope communicated? Many R users assume that XML package is
> >> in great shape and the preferable choice because it is maintained by
> >> the CRAN team and r-core members.
> >>
> >> Perhaps one could follow the precedent from the rgdal retirement, and
> >> set a deadline.
> >>
> >> One way to communicate this effectively would be by introducing a
> >> formal deprecation field in the package description. This could then
> >> be displayed on the XML CRAN html page, and when loading the package
> >> interactively. Other packages that import such a deprecated package
> >> could be given a CMD check warning.
> >>
> >> __
> >> R-package-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Native pipe in package examples

[Berwin A Turlach]

On Thu, 25 Jan 2024 09:44:26 -0800
Henrik Bengtsson  wrote:

> On Thu, Jan 25, 2024 at 9:23 AM Berwin A Turlach
>  wrote:
> >
> > G'day Duncon,

Uups, apologies for the misspelling of your name Duncan.  Fingers were
too fast. :)

[...]
> > But you could always code your example (not tested :-) ) along lines
> > similar to:
> >
> > if( with(version, all(as.numeric(c(major, minor)) >= c(4, 1))) ){
> >   ## code that uses native pipe
> > }else{
> >   cat("You have to upgrade to R >= 4.1.0 to run this example\n")
> > }  
> 
> That will unfortunately not work in this case, because |> is part of
> the new *syntax* that was introduced in R 4.1.0.  Older versions of R
> simply doesn't understand how to *parse* those two symbols next to
> each other, e.g.
> 
> {R 4.1.0}> parse(text = "1:3 |> sum()")
> expression(1:3 |> sum())
> 
> {R 4.0.5}> parse(text = "1:3 |> sum()")
> Error in parse(text = "1:3 |> sum()") : :1:6: unexpected '>'
> 1: 1:3 |>
>  ^
> 
> In order for R to execute some code, it needs to be able to parse it
> first. Only then, it can execute it.  So, here, we're not even getting
> past the parsing phase.

Well, not withstanding 'fortune(181)', you could code it as:

if( with(version, all(as.numeric(c(major, minor)) >= c(4, 1))) ){
   cat(eval(parse(text="1:3 |> sum()")), "\n")
}else{
  cat("You have to upgrade to R >= 4.1.0 to run this example\n")
}  


Admittedly, it would be easier to say "Depends: R (>= 4.1.0)" in the
DESCRIPTION file. :)

Cheers,

Berwin

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

Re: [R-pkg-devel] Native pipe in package examples

[Henrik Bengtsson]

On Thu, Jan 25, 2024 at 9:23 AM Berwin A Turlach
 wrote:
>
> G'day Duncon,
>
> On Thu, 25 Jan 2024 11:27:50 -0500
> Duncan Murdoch  wrote:
>
> > On 25/01/2024 11:18 a.m., Henrik Bengtsson wrote:
> [...]
> > I think you're right that syntax errors in help page examples will be
> > installable, but I don't think there's a way to make them pass "R CMD
> > check" other than wrapping them in \dontrun{}, and I don't know a way
> > to do that conditional on the R version.
>
> I remember vaguely that 'S Programming' was discussing some nifty
> tricks to deal with differences between S and R, and how to write code
> that would work with either.  If memory serves correctly, those
> tricks depended on whether a macro called using_S (using_R?) was
> defined. Not sure if the same tricks could be used to distinguish
> between different versions of R.
>
> But you could always code your example (not tested :-) ) along lines
> similar to:
>
> if( with(version, all(as.numeric(c(major, minor)) >= c(4, 1))) ){
>   ## code that uses native pipe
> }else{
>   cat("You have to upgrade to R >= 4.1.0 to run this example\n")
> }

That will unfortunately not work in this case, because |> is part of
the new *syntax* that was introduced in R 4.1.0.  Older versions of R
simply doesn't understand how to *parse* those two symbols next to
each other, e.g.

{R 4.1.0}> parse(text = "1:3 |> sum()")
expression(1:3 |> sum())

{R 4.0.5}> parse(text = "1:3 |> sum()")
Error in parse(text = "1:3 |> sum()") : :1:6: unexpected '>'
1: 1:3 |>
 ^

In order for R to execute some code, it needs to be able to parse it
first. Only then, it can execute it.  So, here, we're not even getting
past the parsing phase.

/Henrik

>
>
> > I would say that a package that doesn't pass "R CMD check" without
> > errors shouldn't be trusted.
>
> Given the number of packages on CRAN and Murphy's law (or equivalents),
> I would say that there are packages that do pass "R CMD check" without
> errors but shouldn't be trusted, own packages not excluded. :)
>
> Cheers,
>
> Berwin

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

Re: [R-pkg-devel] Native pipe in package examples

[Henrik Bengtsson]

On Thu, Jan 25, 2024 at 8:27 AM Duncan Murdoch  wrote:
>
> On 25/01/2024 11:18 a.m., Henrik Bengtsson wrote:
> > On Thu, Jan 25, 2024 at 7:48 AM Duncan Murdoch  
> > wrote:
> >>
> >> On 25/01/2024 10:27 a.m., Josiah Parry wrote:
> >>> Hey all,
> >>>
> >>> I've encountered use of the native pipe operator in the examples for
> >>> 'httr2' e.g.
> >>>
> >>> request("http://example.com;) |> req_dry_run()
> >>>
> >>>
> >>> Since r-oldrel (according to rversions::r_oldrel()) is now 4.2.3, can the
> >>> native pipe be used in example code?
> >>>
> >>> I do notice that the package httr2 requires R >= 3.6.0 which implies that
> >>> the code itself does not use the native pipe, but the examples do.
> >>
> >> I think that the package should state it requires R (>= 4.1.0), since
> >> that code won't work in earlier versions.
> >>
> >> I believe it's a syntax error before 4.1.0, but don't have a copy handy
> >> to test.
> >
> > Yes, support for the |> syntax was introduced in R 4.1.0;
> >
> > $ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
> > [1] ‘4.0.5’
> > Error: unexpected '>' in "1:10 |>"
> > Execution halted
> >
> > $ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
> > [1] ‘4.1.0’
> > [1] 55
> >
> >> That means the package won't pass R CMD check in those old
> >> versions.  If it wasn't a syntax error, just a case of using a new
> >> feature, then I think it would be fine to put in a run-time test of the
> >> R version to skip code that won't run properly.
> >
> > There's also the distinction of package code versus code in
> > documentation. If it's only example code in help pages that use the
> > native pipe, but the code in R/*.R does not, then the package will
> > still install and work with R (< 4.1.0).  The only thing that won't
> > work is when the user tries to run the code in the documented
> > examples.  I'd argue that it's okay to specify, say, R (>= 3.6.0) in
> > such an example.  It allows users with older versions to still use the
> > package, while already now migrating the documentation to use newer
> > syntax.
>
> Is there a way to do that so that R will pay attention, or do you mean
> just saying it in a comment?

As a "comment".

>
> I think you're right that syntax errors in help page examples will be
> installable, but I don't think there's a way to make them pass "R CMD
> check" other than wrapping them in \dontrun{}, and I don't know a way to
> do that conditional on the R version.

I think

$ R CMD check --no-examples --no-vignettes ...

would check everything else but examples and vignettes.

>
> I would say that a package that doesn't pass "R CMD check" without
> errors shouldn't be trusted.

Somewhat agree, but we still get some "trust" from the fact that the
package passes R CMD check --as-cran on R (>= 4.1.0).  Also, if the
maintainer documents something like "On R (> 4.1.0), the package
passes 'R CMD check --no-examples ...'; we use R (>= 4.1.0)-specific
syntax in some of the help-age examples", then there's additional
"trust" in it's working there.  But, yes, there's less "trust" here,
but I think it's okay for maintainers to declare "R (>= 3.6.0)" to be
backward compatible. Another way to put it, it would be extreme to
require "R (>= 4.1.0)" just because of a single "1:3 |> sum()" in some
example code.

/Henrik

PS. Personally, I'd skip the use of |> in examples to avoid these concerns.

>
> Duncan Murdoch

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

Re: [R-pkg-devel] Native pipe in package examples

[Berwin A Turlach]

G'day Duncon,

On Thu, 25 Jan 2024 11:27:50 -0500
Duncan Murdoch  wrote:

> On 25/01/2024 11:18 a.m., Henrik Bengtsson wrote:
[...]
> I think you're right that syntax errors in help page examples will be 
> installable, but I don't think there's a way to make them pass "R CMD 
> check" other than wrapping them in \dontrun{}, and I don't know a way
> to do that conditional on the R version.

I remember vaguely that 'S Programming' was discussing some nifty
tricks to deal with differences between S and R, and how to write code
that would work with either.  If memory serves correctly, those
tricks depended on whether a macro called using_S (using_R?) was
defined. Not sure if the same tricks could be used to distinguish
between different versions of R.

But you could always code your example (not tested :-) ) along lines
similar to:

if( with(version, all(as.numeric(c(major, minor)) >= c(4, 1))) ){
  ## code that uses native pipe
}else{
  cat("You have to upgrade to R >= 4.1.0 to run this example\n")
}


> I would say that a package that doesn't pass "R CMD check" without 
> errors shouldn't be trusted.

Given the number of packages on CRAN and Murphy's law (or equivalents),
I would say that there are packages that do pass "R CMD check" without
errors but shouldn't be trusted, own packages not excluded. :)

Cheers,

Berwin

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

Re: [R-pkg-devel] new maintainer for CRAN package XML

[Heather Turner]

Re: guidance on how to migrate from XML to xml2, these notes from Daniel Nüst 
may be helpful: https://gist.github.com/nuest/3ed3b0057713eb4f4d75d11bb62f2d66.

Best wishes,
Heather

On Wed, Jan 24, 2024, at 3:38 PM, Emmanuel Blondel wrote:
> if XML is deprecated, then what would be the choice for a package 
> maintainer? Move to xml2 probably at some point I assume
>
> I use XML in the R packages I've been developing. For some of them, I 
> started before CRAN started being the maintainer, and before xml2 
> inception. The thing is that XML fulfills requirements, it works and 
> fulfills needs of depending packages that made the choice to use it. For 
> this, it deserves to be maintained in CRAN, without having to enter into 
> comparison exercices with other packages that , as of today, may be 
> better to rely on (with certainly very good reasons).
>
> Moving to xml2 (or whatever other package), which although I could agree 
> on the principle, can be costly for packages that use extensively XML. 
> Doing so would mean that we first get the assurance that all XML 
> features are covered elsewhere, and can be migrated smoothly.
>
> In any case, please acknowledge that this kind of migration may take 
> time and require resources that vary (or even are missing) depending on 
> the package projects. I doubt having CRAN setting a common deadline for 
> retirement is a good way to foster an efficient maintenance of R 
> packages depending on XML. It would be good to receive guidance how to 
> migrate, while ensuring backward compatibility on our package features.
>
> Best
>
> Le 24/01/2024 à 15:59, Jeroen Ooms a écrit :
>> On Mon, Jan 22, 2024 at 3:51 PM Uwe Ligges
>>  wrote:
>>> Dear package developers,
>>>
>>> the CRAN team (and Professor Ripley in particular) has been the defacto
>>> maintainer of CRAN package 'XML'.
>>> Our hope was that maintainers of packages depending on XML will migrate
>>> to other packages for reading XML structures. This has not happened and
>>> we still see dozens of strong dependencies on XML.
>> How is this hope communicated? Many R users assume that XML package is
>> in great shape and the preferable choice because it is maintained by
>> the CRAN team and r-core members.
>>
>> Perhaps one could follow the precedent from the rgdal retirement, and
>> set a deadline.
>>
>> One way to communicate this effectively would be by introducing a
>> formal deprecation field in the package description. This could then
>> be displayed on the XML CRAN html page, and when loading the package
>> interactively. Other packages that import such a deprecated package
>> could be given a CMD check warning.
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Native pipe in package examples

[Duncan Murdoch]

On 25/01/2024 11:44 a.m., Josiah Parry wrote:
The package of course passes R CMD check otherwise it wouldn’t be on 
CRAN! (:


CRAN doesn't run checks using R 3.6.0.  The package claims it works 
there, and maybe it will, but it won't pass R CMD check.


Duncan Murdoch




Thank you Henrik! Good to know my intuition was correct. I’m glad we can 
start to use the new features of R in package documentation :)


On Thu, Jan 25, 2024 at 11:27 Duncan Murdoch > wrote:


On 25/01/2024 11:18 a.m., Henrik Bengtsson wrote:
 > On Thu, Jan 25, 2024 at 7:48 AM Duncan Murdoch
mailto:murdoch.dun...@gmail.com>> wrote:
 >>
 >> On 25/01/2024 10:27 a.m., Josiah Parry wrote:
 >>> Hey all,
 >>>
 >>> I've encountered use of the native pipe operator in the
examples for
 >>> 'httr2' e.g.
 >>>
 >>> request("http://example.com ") |> req_dry_run()
 >>>
 >>>
 >>> Since r-oldrel (according to rversions::r_oldrel()) is now
4.2.3, can the
 >>> native pipe be used in example code?
 >>>
 >>> I do notice that the package httr2 requires R >= 3.6.0 which
implies that
 >>> the code itself does not use the native pipe, but the examples do.
 >>
 >> I think that the package should state it requires R (>= 4.1.0),
since
 >> that code won't work in earlier versions.
 >>
 >> I believe it's a syntax error before 4.1.0, but don't have a
copy handy
 >> to test.
 >
 > Yes, support for the |> syntax was introduced in R 4.1.0;
 >
 > $ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
 > [1] ‘4.0.5’
 > Error: unexpected '>' in "1:10 |>"
 > Execution halted
 >
 > $ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
 > [1] ‘4.1.0’
 > [1] 55
 >
 >> That means the package won't pass R CMD check in those old
 >> versions.  If it wasn't a syntax error, just a case of using a new
 >> feature, then I think it would be fine to put in a run-time test
of the
 >> R version to skip code that won't run properly.
 >
 > There's also the distinction of package code versus code in
 > documentation. If it's only example code in help pages that use the
 > native pipe, but the code in R/*.R does not, then the package will
 > still install and work with R (< 4.1.0).  The only thing that won't
 > work is when the user tries to run the code in the documented
 > examples.  I'd argue that it's okay to specify, say, R (>= 3.6.0) in
 > such an example.  It allows users with older versions to still
use the
 > package, while already now migrating the documentation to use newer
 > syntax.

Is there a way to do that so that R will pay attention, or do you mean
just saying it in a comment?

I think you're right that syntax errors in help page examples will be
installable, but I don't think there's a way to make them pass "R CMD
check" other than wrapping them in \dontrun{}, and I don't know a
way to
do that conditional on the R version.

I would say that a package that doesn't pass "R CMD check" without
errors shouldn't be trusted.

Duncan Murdoch



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

Re: [R-pkg-devel] Native pipe in package examples

[Josiah Parry]

The package of course passes R CMD check otherwise it wouldn’t be on CRAN!
(:

Thank you Henrik! Good to know my intuition was correct. I’m glad we can
start to use the new features of R in package documentation :)

On Thu, Jan 25, 2024 at 11:27 Duncan Murdoch 
wrote:

> On 25/01/2024 11:18 a.m., Henrik Bengtsson wrote:
> > On Thu, Jan 25, 2024 at 7:48 AM Duncan Murdoch 
> wrote:
> >>
> >> On 25/01/2024 10:27 a.m., Josiah Parry wrote:
> >>> Hey all,
> >>>
> >>> I've encountered use of the native pipe operator in the examples for
> >>> 'httr2' e.g.
> >>>
> >>> request("http://example.com;) |> req_dry_run()
> >>>
> >>>
> >>> Since r-oldrel (according to rversions::r_oldrel()) is now 4.2.3, can
> the
> >>> native pipe be used in example code?
> >>>
> >>> I do notice that the package httr2 requires R >= 3.6.0 which implies
> that
> >>> the code itself does not use the native pipe, but the examples do.
> >>
> >> I think that the package should state it requires R (>= 4.1.0), since
> >> that code won't work in earlier versions.
> >>
> >> I believe it's a syntax error before 4.1.0, but don't have a copy handy
> >> to test.
> >
> > Yes, support for the |> syntax was introduced in R 4.1.0;
> >
> > $ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
> > [1] ‘4.0.5’
> > Error: unexpected '>' in "1:10 |>"
> > Execution halted
> >
> > $ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
> > [1] ‘4.1.0’
> > [1] 55
> >
> >> That means the package won't pass R CMD check in those old
> >> versions.  If it wasn't a syntax error, just a case of using a new
> >> feature, then I think it would be fine to put in a run-time test of the
> >> R version to skip code that won't run properly.
> >
> > There's also the distinction of package code versus code in
> > documentation. If it's only example code in help pages that use the
> > native pipe, but the code in R/*.R does not, then the package will
> > still install and work with R (< 4.1.0).  The only thing that won't
> > work is when the user tries to run the code in the documented
> > examples.  I'd argue that it's okay to specify, say, R (>= 3.6.0) in
> > such an example.  It allows users with older versions to still use the
> > package, while already now migrating the documentation to use newer
> > syntax.
>
> Is there a way to do that so that R will pay attention, or do you mean
> just saying it in a comment?
>
> I think you're right that syntax errors in help page examples will be
> installable, but I don't think there's a way to make them pass "R CMD
> check" other than wrapping them in \dontrun{}, and I don't know a way to
> do that conditional on the R version.
>
> I would say that a package that doesn't pass "R CMD check" without
> errors shouldn't be trusted.
>
> Duncan Murdoch
>

[[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] Native pipe in package examples

[Duncan Murdoch]

On 25/01/2024 11:18 a.m., Henrik Bengtsson wrote:

On Thu, Jan 25, 2024 at 7:48 AM Duncan Murdoch  wrote:


On 25/01/2024 10:27 a.m., Josiah Parry wrote:

Hey all,

I've encountered use of the native pipe operator in the examples for
'httr2' e.g.

request("http://example.com;) |> req_dry_run()


Since r-oldrel (according to rversions::r_oldrel()) is now 4.2.3, can the
native pipe be used in example code?

I do notice that the package httr2 requires R >= 3.6.0 which implies that
the code itself does not use the native pipe, but the examples do.


I think that the package should state it requires R (>= 4.1.0), since
that code won't work in earlier versions.

I believe it's a syntax error before 4.1.0, but don't have a copy handy
to test.


Yes, support for the |> syntax was introduced in R 4.1.0;

$ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
[1] ‘4.0.5’
Error: unexpected '>' in "1:10 |>"
Execution halted

$ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
[1] ‘4.1.0’
[1] 55


That means the package won't pass R CMD check in those old
versions.  If it wasn't a syntax error, just a case of using a new
feature, then I think it would be fine to put in a run-time test of the
R version to skip code that won't run properly.


There's also the distinction of package code versus code in
documentation. If it's only example code in help pages that use the
native pipe, but the code in R/*.R does not, then the package will
still install and work with R (< 4.1.0).  The only thing that won't
work is when the user tries to run the code in the documented
examples.  I'd argue that it's okay to specify, say, R (>= 3.6.0) in
such an example.  It allows users with older versions to still use the
package, while already now migrating the documentation to use newer
syntax.


Is there a way to do that so that R will pay attention, or do you mean 
just saying it in a comment?


I think you're right that syntax errors in help page examples will be 
installable, but I don't think there's a way to make them pass "R CMD 
check" other than wrapping them in \dontrun{}, and I don't know a way to 
do that conditional on the R version.


I would say that a package that doesn't pass "R CMD check" without 
errors shouldn't be trusted.


Duncan Murdoch

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

Re: [R-pkg-devel] Native pipe in package examples

[Henrik Bengtsson]

On Thu, Jan 25, 2024 at 7:48 AM Duncan Murdoch  wrote:
>
> On 25/01/2024 10:27 a.m., Josiah Parry wrote:
> > Hey all,
> >
> > I've encountered use of the native pipe operator in the examples for
> > 'httr2' e.g.
> >
> > request("http://example.com;) |> req_dry_run()
> >
> >
> > Since r-oldrel (according to rversions::r_oldrel()) is now 4.2.3, can the
> > native pipe be used in example code?
> >
> > I do notice that the package httr2 requires R >= 3.6.0 which implies that
> > the code itself does not use the native pipe, but the examples do.
>
> I think that the package should state it requires R (>= 4.1.0), since
> that code won't work in earlier versions.
>
> I believe it's a syntax error before 4.1.0, but don't have a copy handy
> to test.

Yes, support for the |> syntax was introduced in R 4.1.0;

$ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
[1] ‘4.0.5’
Error: unexpected '>' in "1:10 |>"
Execution halted

$ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
[1] ‘4.1.0’
[1] 55

> That means the package won't pass R CMD check in those old
> versions.  If it wasn't a syntax error, just a case of using a new
> feature, then I think it would be fine to put in a run-time test of the
> R version to skip code that won't run properly.

There's also the distinction of package code versus code in
documentation. If it's only example code in help pages that use the
native pipe, but the code in R/*.R does not, then the package will
still install and work with R (< 4.1.0).  The only thing that won't
work is when the user tries to run the code in the documented
examples.  I'd argue that it's okay to specify, say, R (>= 3.6.0) in
such an example.  It allows users with older versions to still use the
package, while already now migrating the documentation to use newer
syntax.

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

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

Re: [R-pkg-devel] Native pipe in package examples

[Duncan Murdoch]

On 25/01/2024 10:27 a.m., Josiah Parry wrote:

Hey all,

I've encountered use of the native pipe operator in the examples for
'httr2' e.g.

request("http://example.com;) |> req_dry_run()


Since r-oldrel (according to rversions::r_oldrel()) is now 4.2.3, can the
native pipe be used in example code?

I do notice that the package httr2 requires R >= 3.6.0 which implies that
the code itself does not use the native pipe, but the examples do.


I think that the package should state it requires R (>= 4.1.0), since 
that code won't work in earlier versions.


I believe it's a syntax error before 4.1.0, but don't have a copy handy 
to test.  That means the package won't pass R CMD check in those old 
versions.  If it wasn't a syntax error, just a case of using a new 
feature, then I think it would be fine to put in a run-time test of the 
R version to skip code that won't run properly.


Duncan Murdoch

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

[R-pkg-devel] Native pipe in package examples

[Josiah Parry]

Hey all,

I've encountered use of the native pipe operator in the examples for
'httr2' e.g.

request("http://example.com;) |> req_dry_run()


Since r-oldrel (according to rversions::r_oldrel()) is now 4.2.3, can the
native pipe be used in example code?

I do notice that the package httr2 requires R >= 3.6.0 which implies that
the code itself does not use the native pipe, but the examples do.

Is this an accurate summation?

Thanks!

[[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] New Package Removal because Shared Library Too Large from Debugging Symbols

[Johann Gaebler]

It seems some of my emails didn’t make it onto the list, so I just wanted 
briefly to follow up to say thank you to Dirk, Ivan, Uwe, and Ben for helping 
with this.

Ultimately, following Ivan’s advice, I just added a GitHub action to the repo 
as a temporary patch to ensure that the signature gets corrected if cpp11 gets 
rerun.

I uploaded a new version with the correct signature to CRAN, and, as best I’m 
able to discern, it has passed the LTO check.

All the best,
Hans

> Johann Gaebler  於 2024年1月20日 下午2:38 寫道：
> 
> Hi everyone,
> 
> I received the following message regarding  `rar` 
> , a package that I put up on CRAN two 
> days ago:
> 
>> Dear maintainer,
>> 
>> Please see the problems shown on
>> .
>> 
>> Please correct before 2024-02-02 to safely retain your package on CRAN.
> 
> The issue is that the compiled libraries are too large. The Mac CRAN checks 
> turned up the following note:
> 
>> installed size is  8.9Mb
>> sub-directories of 1Mb or more:
>>  libs   8.7Mb
> 
> I have not been able to reproduce the issue either locally or on any machine 
> I have ready access to. I have built it on some of the Rhub and R-Project 
> build systems, and the same issue (with very different `libs` sizes) came up 
> on some of them:
> 
> • (RHub) Ubuntu Linux 20.04.1 LTS, R-release, GCC: 18.2Mb,
> • (RHub) Fedora Linux, R-devel, clang, gfortran: 6.8Mb,
> • (R-Project) r-release-macosx-arm64: 8.5Mb.
> 
> Based on trying to read up about this, it seems that this is a pretty common 
> problem 
>  
> for compiled packages because of debugging symbols getting inserted into the 
> shared library file. Using the fix from that blog post where you modify the 
> Makevars to strip debugging symbols from the shared library seems to solve 
> the issue on those build systems, so I feel reasonably confident that this is 
> what’s going on.
> 
> Apparently many, many existing packages on CRAN have the same issue. However, 
> I’m very new to R package development, so I’m not exactly sure what to do. I 
> have two questions:
> 
> 1. Is there anything I need to “fix” here, or should I just make contact with 
> the CRAN folks and bring the fact that this is being caused by debugging 
> symbols to their attention?
> 2. Regardless of whether or not I have to fix this issue for CRAN, is there a 
> way to strip out the debugging symbols that comports with CRAN policies? The 
> method suggested in the blog post above (adding a phony target in `Makevars` 
> that strips the shared library) seems not to be CRAN-compliant, but I could 
> be mistaken about that. (In particular, I had to modify it locally to get it 
> to run, so I’m not sure what the platform-independent version of it looks 
> like.)
> 
> Thanks in advance for the help!
> 
> Sincerely,
> Johann D. Gaebler


[[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] Possible malware(?) in a vignette

[Robert M. Flight]

I decided to grab a copy of that PDF from the RStudio CRAN mirror, and
downloaded on Linux (where hopefully it won't be an issue) from the list of
vignettes.

Virus Total gives it the same hash as the above linked PDF, so it's
definitely been propagated from CRAN, and *may* be malicious.

That is *disconcerting* to say the least.

-Robert

On Thu, Jan 25, 2024 at 6:03 AM Iñaki Ucar  wrote:

> On Thu, 25 Jan 2024 at 10:13, Colin Gillespie 
> wrote:
> >
> > Hi All,
> >
> > I've had two emails from users in the last 24 hours about malware
> > around one of my vignettes. A snippet from the last user is:
> >
> > ---
> > I was trying to install a R package that depends on PowerRLaw two
> > weeks ago.  However my virus protection software F secure did not
> > allow me to install it from CRAN, while installation from GitHub
> > worked normally. Virus protection software claimed that
> > d_jss_paper.pdf is compromised. I asked about this from our IT support
> > and they asked it from the company F secure. Now F secure has analysed
> > the file and according them it is malware.
> >
> > “Upon analyzing, our analysis indicates that the file you submitted is
> > malicious. Hence the verdict will remain
>
> See
> https://www.virustotal.com/gui/file/9486d99c1c1f2d1b06f0b6c5d27c54d4f6e39d69a91d7fad845f323b0ab88de9/behavior
>
> According to the sandboxed analysis, there's something there trying to
> tamper with the Acrobat installation. It tries several Windows paths.
> That's not good.
>
> The good news is that, if I recreate the vignette from your repo, the
> file is different, different hash, and it's clean.
>
> The bad news is that... this means that CRAN may be compromised. I
> urge CRAN maintainers to check all the PDF vignettes and scan the
> Windows machines for viruses.
>
> Best,
> Iñaki
>
>
> >
> > ---
> >
> > Other information is:
> >
> >  * Package in question:
> > https://cran.r-project.org/web/packages/poweRlaw/index.html
> >  * Package hasn't been updated for three years
> >  * Vignette in question:
> >
> https://cran.r-project.org/web/packages/poweRlaw/vignettes/d_jss_paper.pdf
> >
> > CRAN asked me to fix
> > https://cran.r-project.org/web/checks/check_results_poweRlaw.html a
> > couple of days ago - which I'm in the process of doing.
> >
> > Any ideas?
> >
> > Thanks
> > Colin
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
>
> --
> Iñaki Úcar
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] Possible malware(?) in a vignette

[Iñaki Ucar]

On Thu, 25 Jan 2024 at 10:13, Colin Gillespie  wrote:
>
> Hi All,
>
> I've had two emails from users in the last 24 hours about malware
> around one of my vignettes. A snippet from the last user is:
>
> ---
> I was trying to install a R package that depends on PowerRLaw two
> weeks ago.  However my virus protection software F secure did not
> allow me to install it from CRAN, while installation from GitHub
> worked normally. Virus protection software claimed that
> d_jss_paper.pdf is compromised. I asked about this from our IT support
> and they asked it from the company F secure. Now F secure has analysed
> the file and according them it is malware.
>
> “Upon analyzing, our analysis indicates that the file you submitted is
> malicious. Hence the verdict will remain

See 
https://www.virustotal.com/gui/file/9486d99c1c1f2d1b06f0b6c5d27c54d4f6e39d69a91d7fad845f323b0ab88de9/behavior

According to the sandboxed analysis, there's something there trying to
tamper with the Acrobat installation. It tries several Windows paths.
That's not good.

The good news is that, if I recreate the vignette from your repo, the
file is different, different hash, and it's clean.

The bad news is that... this means that CRAN may be compromised. I
urge CRAN maintainers to check all the PDF vignettes and scan the
Windows machines for viruses.

Best,
Iñaki


>
> ---
>
> Other information is:
>
>  * Package in question:
> https://cran.r-project.org/web/packages/poweRlaw/index.html
>  * Package hasn't been updated for three years
>  * Vignette in question:
> https://cran.r-project.org/web/packages/poweRlaw/vignettes/d_jss_paper.pdf
>
> CRAN asked me to fix
> https://cran.r-project.org/web/checks/check_results_poweRlaw.html a
> couple of days ago - which I'm in the process of doing.
>
> Any ideas?
>
> Thanks
> Colin
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
Iñaki Úcar

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

[R-pkg-devel] Possible malware(?) in a vignette

[Colin Gillespie]

Hi All,

I've had two emails from users in the last 24 hours about malware
around one of my vignettes. A snippet from the last user is:

---
I was trying to install a R package that depends on PowerRLaw two
weeks ago.  However my virus protection software F secure did not
allow me to install it from CRAN, while installation from GitHub
worked normally. Virus protection software claimed that
d_jss_paper.pdf is compromised. I asked about this from our IT support
and they asked it from the company F secure. Now F secure has analysed
the file and according them it is malware.

“Upon analyzing, our analysis indicates that the file you submitted is
malicious. Hence the verdict will remain

---

Other information is:

 * Package in question:
https://cran.r-project.org/web/packages/poweRlaw/index.html
 * Package hasn't been updated for three years
 * Vignette in question:
https://cran.r-project.org/web/packages/poweRlaw/vignettes/d_jss_paper.pdf

CRAN asked me to fix
https://cran.r-project.org/web/checks/check_results_poweRlaw.html a
couple of days ago - which I'm in the process of doing.

Any ideas?

Thanks
Colin

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