[Rd] unsafe parsing of DESCRIPTION Authors maybe from R

Fri Apr 17 07:52:15 CEST 2026

Thank Kurt.

Can we whitelist as.person?

See https://github.com/StoreyLab/qvalue/issues/41

Thanks again,

H.

On 11/04/2026 03:32, Kurt Hornik wrote:
>>>>>> Simon Urbanek writes:
> Indeed, you/Simon and I had discussed this some time ago and put on our
> TODO lists, but with low priority :-)
>
> So I changed priorities.  The current situation on CRAN Authors using R uses
> is quite manageable: about 20 packages use "strange" calls in these, in
> most cases from mis-specifying the ORCID comment like
>
>    comment(ORCID = ...)
>    ORCID =
>
> instead of
>
>    comment = c(ORCID = ...)
>
> Yesterday I committed
>
> r89866 | hornik | 2026-04-10 21:31:32 +0200 (Fri, 10 Apr 2026) | 1 line
> Complain about possibly unsafe calls in Authors using R.
>
> so these calls now get speeding tickets which also give check NOTEs,
> like
>
> * checking DESCRIPTION meta-information ... NOTE
> Malformed Authors using R field:
>    Found the following possibly unsafe calls:
>      comment("SwissMarbledWhite")
>    Please only use calls to ‘person’, ‘c’, ‘list’, ‘paste’, ‘paste0’.
>
> I will "eventually" change the reader code to no longer eval when seeing
> calls not in the whitelist.
>
> The harder part will be narrowing down the calls allowed in CITATION
> files, where the original design was to be permissive.
>
> Best
> -k
>
>> Levi,
>> thanks, I understand what you are saying in that compared to other eval'ed things Authors using R may possibly have an increased chance of being used in contexts other than package building/installation. As I said, that particular instance is something that is on our TODO list (so you just successfully bumped its priority :)), but I'm just cautioning that it's not the only way, so, generally, dealing with packages should be considered "dirty" in that you should assume it involves executing code from the package, so corresponding precautions should be taken when handling packages from untrusted sources.
>> Thanks,
>> Simon
>
>>> On 8/04/2026, at 05:35, Levi Waldron <lwaldron.research using gmail.com> wrote:
>>>
>>> Thanks, Simon. Just to clarify:
>>>
>>>> there are numerous ways that R code can be evaluated (Authors using R is just one of several examples), this is well known and not unexpected. After all, you can simply call source() or eval() at any point, so it is not clear what threat model you have in mind. (BTW: your GitHub page requires 3rd party package so I fail to see the point as you can always install a package that does anything).
>>> A scenario I had in mind was that the CRAN incoming package server sends an immediate email containing a confirmation link and an interpreted version of DESCRIPTION, prior to any build/check. If that server is using desc::description or utils:::.read_authors_at_R_field, then this might provide an attacker an efficient way to modify trusted packages in the queue before they're sent to build servers.
>>>
>>> BTW the example demonstrated arbitrary code execution when 1) installing a package with no dependencies and no R/, src/, tests/, or other code outside of its DESCRIPTION, and 2) parsing its DESCRIPTION file using desc::description without installing it, but it would apply to anything else that results in utils:::.read_authors_at_R_field(). I was surprised that arbitrary code execution can happen when installing but before loading a package, or when parsing its DESCRIPTION without ever installing it, but if that introduces no new risks, I'm glad to hear it.
>>>
>>> Sincerely,
>>> Levi
>>>
>>> On Tue, Apr 7, 2026 at 1:06 AM Simon Urbanek <simon.urbanek using r-project.org> wrote:
>>> Levi,
>>>
>>> there are numerous ways that R code can be evaluated (Authors using R is just one of several examples), this is well known and not unexpected. After all, you can simply call source() or eval() at any point, so it is not clear what threat model you have in mind. (BTW: your GitHub page requires 3rd party package so I fail to see the point as you can always install a package that does anything). By definition, installing a package or running R code gives the user full access to R and the system - so adding a system() doesn't do anything new - if you can run R code then you could have simply written system() yourself instead.
>>>
>>> I understand where you are coming from, but it should be expected that anything that deals with packages is by design executing code from the package, so you can always create a malicious package - by design. That doesn't mean that we shouldn't strive to limit eval()s or to perform validity checks, but this is not practical in all instances, because R relies heavily on the ability to run R code in those instances - by design. For example, some use a canonical document in the package that is parsed when creating the authors list instead of embedding it directly in the DESCRIPTION. We could disallow that and limit the language (funnily, we discussed exactly this case last year in Vienna), but this is just one of many use-cases of this approach, there are several others in the packages toolbox. You can always find internal R functions that do various tasks using eval(), so I think the starting premise that this shouldn't happen is simply wrong. The only way you can get something "safe" is to disallow R code and only enable very specific API (like REST or OCAP), anything else is free for all by design.
>>>
>>> Cheers,
>>> Simon
>>>
>>>
>>>> On 7 Apr 2026, at 15:32, Levi Waldron <lwaldron.research using gmail.com> wrote:
>>>>
>>>> This issue arose during an AI-assisted security review of core Bioconductor
>>>> packages, that an attacker could execute arbitrary code on any system that
>>>> calls `utils:::.read_authors_at_R_field()` or other tools for parsing a
>>>> DESCRIPTION file,  regardless of whether it installs, builds, or checks the
>>>> package. I put some details and a reprex at
>>>> https://github.com/lwaldron/nothing/tree/check-vulnerability. Let me know
>>>> if you'd prefer I take the github page down.
>>>>
>>>> This seems worse than the inherent .onLoad(), tests/, etc vulnerabilities,
>>>> because it can be exploited in environments not intended to install or
>>>> check packages or run their code, like the CRAN incoming package queue
>>>> which does seem to parse the DESCRIPTION file.
>>>>
>>>> -Levi
>>>>
>>>> -- 
>>>>
>>>> Levi Waldron
>>>>
>>>> Professor and Chair
>>>>
>>>> Department of Epidemiology and Biostatistics
>>>>
>>>> CUNY Graduate School of Public Health and Health Policy
>>>>
>>>> Institute for Implementation Science in Population Health
>>>>
>>>> 55 W 125th St, New York NY 10035
>>>>
>>>> https://waldronlab.io
>>>>
>>>> Join the microbiome Virtual International Forum: https://microbiome-vif.org
>>>>
>>>> [[alternative HTML version deleted]]
>>>>
>>>> ______________________________________________
>>>> R-devel using r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>
>>>
>>> -- 
>>> Levi Waldron
>>> Professor and Chair
>>> Department of Epidemiology and Biostatistics
>>> CUNY Graduate School of Public Health and Health Policy
>>> Institute for Implementation Science in Population Health
>>> 55 W 125th St, New York NY 10035
>>> https://waldronlab.io
>>> Book a meeting with me
>>> Join the microbiome Virtual International Forum: https://microbiome-vif.org
>> ______________________________________________
>> 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

-- 
Hervé Pagès

Bioconductor Core Team
hpages.on.github using gmail.com