A fresh -Wformat-security issue under r-devel

[eddelbuettel]

Update 2023-11-28: If you came here because of a similar message in your package please read on and see particularly this comment below for the fairly simple fix.

---

While working on an update for RQuantLib with a few r-devel discovered minor changes, CRAN and I both came across a new nag this time from -Wformat-security.. Our glue code in src/attributes.cpp does

                     << "    if (rcpp_isError_gen) {" << std::endl
                     << "        SEXP rcpp_msgSEXP_gen = Rf_asChar(rcpp_result_gen);" << std::endl
                     << "        UNPROTECT(1);" << std::endl
                     << "        Rf_error(CHAR(rcpp_msgSEXP_gen));" << std::endl
                     << "    }" << std::endl

and the Rf_error(someCharvariablehere) now makes the compiler bark under -Wformat-security:

RcppExports.cpp:180:18: warning: format string is not a string literal (potentially insecure) [-Wformat-security]

The fix is pretty easy: add a "%s". I will take care of that shortly.

[DISOhda]

Hello,

Today I was contacted by CRAN to take care of -Wformat-security compiler warnings which are identical to yours, otherwise my package (https://github.com/DISOhda/PoissonBinomial) would be removed at 2023-12-12.

In the check log (https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/PoissonBinomial-00check.html), there were 27 identical warnings like

RcppExports.cpp:45:18: warning: format string is not a string literal (potentially insecure) [-Wformat-security]

All the indicated lines are identical:

Rf_error(CHAR(rcpp_msgSEXP_gen));

When looking at the install log (https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/PoissonBinomial-00install.html), it becomes clear that the security warnings originate from Rcpp header print.h:

/home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages/Rcpp/include/Rcpp/print.h:30:26: warning: format string is not a string literal (potentially insecure) [-Wformat-security]
   30 |     Rf_warningcall(call, s.c_str());
      |                          ^~~~~~~~~
/home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages/Rcpp/include/Rcpp/print.h:30:26: note: treat the string as an argument to avoid this
   30 |     Rf_warningcall(call, s.c_str());
      |                          ^
      |                          "%s", 

Seems to be the very issue that you pointed out. Maybe there are other packages that are affected by this, too.

Is there something I have to do or do I just have to wait for you to release a fixed package version and the warning to vanish?

Best

[eddelbuettel]

Yes, I actually got five such emails myself today for packages of mine using Rcpp.

The fix is simple thanks to PR #1288 we made two days ago. Install Rcpp 1.0.11.5 from the Rcpp drat repo via, e.g.,

 Rscript -e 'install.packages("Rcpp", repos=c("https://RcppCore.github.io/drat", getOption("repos")))'

and then re-run compileAttributes(). That will fix the RcppExports.cpp file for you. You then need to upload your updated package to CRAN. It has no change in its run-time dependency on Rcpp so you do not need to change anything in DESCRIPTION related to Rcpp (but a new upload of course needs a new version). Just re-run compileAttributes(), and increment your version (and do whatever else R(-devel) CMD check --as-cran may need).

[TobiasFellinger]

Thanks for the quick fix and the comment on how to fix issues with packages linking to Rcpp.

[eddelbuettel]

My pleasure! As you see in this ticket, I actually hit is myself updating a package a few days ago. r-devel and a new g++ are good at this.

And I am sure we will hear more about it here, at StackOverflow, or on lists such as rcpp-devel or r-package-devel so when you see it by all means feel free to share the word 😀

[DISOhda]

You then need to upload your updated package to CRAN. It has no change in its run-time dependency on Rcpp so you do not need to change anything in DESCRIPTION. Just re-run compileAttributes().

I tried to resubmit my fixed package without changing DESCRIPTION. But it was rejected because it is unchanged, i.e. I got warned that the date is quite old and that the version string is the same as the existing version's. So, I had to increase it and change the date to get it approved.

But still, thank you very much for your quick response. It is very much appreciated.

[eddelbuettel]

So, I had to increase it and change the date to get it approved.

That is expected.

You actually changed code, so that requires a version that is strictly monotonically higher than the one it replaces.

PS I see where I confused you writing "so you do not need to change anything in DESCRIPTION". Will edit.

[DISOhda]

PS I see where I confused you writing "so you do not need to change anything in DESCRIPTION". Will edit.

Purely my mistake. I should have known not to take that so literally. Anyway...

While I am at it: Which Rcpp version should be specified as the minimum requirement in DESCRIPTION?