[FEATURE / Discussion] Addressing C++ dependencies w/in R packages

[JosiahParry]

• What are you trying to do?

Many R packages include C++ code via Rcpp or cpp11. Should these be addressed? If so, how would be best to go through this? SystemRequirements in description file? Manually scanning src/?

• What feature or behavior is this required for?

Ensuring a thorough check of R packages

• How could we solve this issue? (Not knowing is okay!) Unsure!

• Anything else?

cc @bhamail / @DarthHater / @brittanybelle / @adrianpowell / @csgillespie

[DarthHater]

This will be kinda tricky. I'm gonna tag @ken-duck and send this to another person to look at. There's a couple different ways to think about this:

• Should the purl for a cran component also be smart enough to know it has a cpp component in it, and it's thus vulnerable as a result of that?
• Should you just find the cpp component and add a purl for it?

This is definitely something I have thought about a LOT with R because of the extensive use of c++ code! There's gotta be dragons lurking!

[ken-duck]

Thanks @DarthHater . I am looking into some options for improving the R data, and targeting the C++ is definitely a good direction to look. I am hoping to scrape together some time in the next couple of weeks to dig into this more deeply.

I don't actually know how C/C++ libraries are references in cran components. Are there files that reference the library names directly (such as "libpng-1.3.so"), or is this information buried in Makefiles or dependent on the system where the R component is built? In either case we can probably leverage some of the concepts used in cheque to provide more data, either directly in oysteR or by creating new vulnerabilities in the database.

@JosiahParry do you have any sample components that illustrate the typical scenario, or otherwise provide an example of what you are looking at?

[JosiahParry]

@ken-duck I truly do not know anything about C/C++ so I can't be tooo much use. But if an R package contains c++ code it is in a directory called src/ e.g.

• https://github.com/tidyverse/tidyr/tree/master/src
• https://github.com/tidyverse/dplyr/tree/master/src

Alternatively their is an optional field in the DESCRIPTION file (required for a package) called SystemRequirements (example). The downside with the DESCRIPTION file is that there is no standardization and you may not get consistent naming. This is a known problem for R packages.

[JosiahParry]

It looks like RStudio Package Manager now has an experimental API end point which will list sys reqs https://packagemanager.rstudio.com/__api__/swagger/index.html. This could be the answer to better sysreqs

[ken-duck]

Sorry for the delay. I have finally been able to start getting into this. I found a reasonable way for us to find the C/C++ library dependencies, I think, and we can leverage he C library data in OSS Index at that point. I am still working out the details, but am slowly working my way through this.

I will be prototyping a solution in a different tool for two reasons:

1. The other tool already does some of what we need
2. I don't know R

Once I have a solution prototyped we will start exploring how to make it work in oysteR

Incidentally, I might also take a shot at finding JS related vulnerabilities, but that can get really ugly so might take a bit longer.

[JosiahParry]

@ken-duck that sounds great! I'll see what I can figure out from it :)

[JosiahParry]

Hey all, I've made some progress here. I can get the C/C++ deps no problem & versions for ubuntu but not centos / rpm. We need versions for purls as the API cannot handle it (though the website can). I've considered scraping the web page but that feels...questionable at best.

Does anyone know of any APIs for getting C/C++ library versions programmatically?